NDLR USB not recognized by iConnectivity MIDI4+ host

[zenkick]

Bumping this. Any update?

I received a NDLR not too long ago and was reconfiguring my routing around an iConnectivity device and was saddened and surprised to not see it recognized, as it works without issue on my MPC and FORCE (but ALSA does handle these oddities pretty well, eg: some non-standard Roland stuff, etc. so guess I got spoiled a bit...)

[MMSMSC]

Hello all & new here, 

Tuning in by asking if the USB host issue with the iConnectivity MIDI4+ has been fixed in the meantime.

[Jesse Johannesen]

No, it's not solved at this point.
Jesse

[MMSMSC]

Awesome & thanks for the feedback! Gonna hook up in a few days then when my NDLR arrives ~
MMS

---

Sorry, misread, haha — well, hope this can be fixed at some point
MMS

[Synthetica]

Another iConnectivity Mio XL user here. Awaiting a fix for the USB host ports also not working. Was highly disappointed when plugging The NDLR into a USB host port. I love the device but could really use the USB MIDI functionality.

[MMSMSC]

Another iConnectivity Mio XL user here. Awaiting a fix for the USB host ports also not working. Was highly disappointed when plugging The NDLR into a USB host port. I love the device but could really use the USB MIDI functionality.

+1

[Raphie]

I've plugged it into my MRCC and my MRCC into the MioXL
And not ideal, but the NDLR works perfectly into the Midi in /out on the MioXL.
But agreed, a fix would be nice.

[Jesse Johannesen]

Are you telling me the MioXL works with the MRCC?! Via USB?

[autopoiesis]

Hi Jesse/team,

Any update on this, or - better - a fix ETA?

The root cause appears to have been identified over a year ago in the excellent post by microbug:
https://conductivelabs.com/forum/showthr...79#pid3179

Jesse's response, Dec 2020 - https://conductivelabs.com/forum/showthr...97#pid3197
"NDLR should easily be hostable by any embedded USB host out there that follows the 1.0 specs or later, and the fact that it isn't is, fundamentally a bug on the NDLR, not anything else"

We hear of bug/compatibility trackers, and we suggest enhancements, but there's little visibility into whether, or when, any bug/feature request/compatibility issue is ever going to be addressed. This is really frustrating, and leaves users feeling abandoned in spite of the efforts we make to test/document. We do get thanked, which is appreciated; but then we just wait...

From an unrelated feature request Aug '21 https://conductivelabs.com/forum/showthr...36#pid4836
"At this point we're not likely to be making any behavioral changes to the NDLR unless it is to fix things that are broken [...]" (looks like I'll never get the reverse-video display I suggested ).

It's OK to decide to stop development, we understand that. But if that's the really case then as a courtesy you should (IMHO) lock the Feature Requests sub-forum, and formally state that NDLR is now EOL.

However, it is NOT OK to let allow impactful, but well-characterised, bugs to persist for this long.

So for this (USB) issue, please:
- commit to a fix date; or
- commit to not fixing it

All the best,
auto

PS I still love the little critter, warts and all

[Tim_]

Hi Team,

Bumping this issue and joining the line of NDLR users awaiting a fix for its USB host port bug.

As stated above, user microbug has done a great job investigating the issue and identifying the problem at the beginning of this thread.
And I feel like the last post by autopoiesis's - from 9 months ago - is respectfully asking for some clarity on behalf of all the users experiencing this issue.

So here I am, bumping it again and asking if you could you please let us know if:

Conductive Labs has the intentions to fix this issue? (and if so, if we as a community can again help in anyway with investigating/testing/debugging and the like).
Or not...

Many thanks & Kind Regards,

-Tim