Do you need this MRCC accessory?

[Darryl]

After 2 weeks with 2 mrcc’s installed it’s a dream come true.
For now I’ve got both MRCC’s connected to DAW as I need more than 12 virtual USB ports from DAW to synths, but I think with a bit more clever channel mapping, I can bring it down to 1 USB DAW connection and use the conductor button to map 12 virtual USB ports between the 2 MRCC’s
Software less patching and creating multiple midi entry/end points, close to the gear, are just priceless.
Since I can’t get my pics uploaded here, here is a link to GS with pics how I’ve done it https://gearspace.com/board/showpost.php...ount=21410
Still waiting on my final package, just paid the taxes so should come this week.
The whole Conductive Labs ecosystem is just lightyears ahead!.

4 things withholding perfection for me:
- label the virtual DAW port, with the same name as the port they are assigned to, so they present themselves with custom names in DAW (i.e. “Moog One” rather than “Midi In 1 (MRCC-A)”
- fix sysex
- rename presets
- fix “class compliant” compatibility (that is the one thing that iConnectivity still does better)

Thank you Raphie! Nice looking studio you have there.

Regarding perfection, we would love to be perfect. My wife often reminds me that she would like for me to be (more) perfect, but still a work in progress  
Making good progress getting SysEx fixed up, with a "beta" release to arrive soon.

Wide USB MIDI device compatibility on a microcontroller is challenging. We don't have the decades of tweaking of the USB host for the broad compatibility that Windows has. I still remember when Windows didn't always work with new USB devices. It took years to get it to be as good as it is.
All we can do is look at devices, one by one as they are reported to us. It helps a lot if someone can lend us a problematic device, we can't afford to buy them all (we already have a lot). 
Our host is written to the MIDI spec for USB class compliant MIDI devices. There's no "bug" to fix that makes our host work better, only learnings on how to deal with different device enumeration scenarios, including devices that have errors and uncommon enumeration configurations. We've seen egregiously bad clients connect and function on Windows. In some cases, we can make a workaround to intelligently handle (or ignore) an error (like Windows does), and in other cases making a workaround would be too risky as we could break other things. In that case, we'll report the issue to the device vendor and work with them to address any problems in a mutually beneficial way.
We are sorry for the frustration caused by USB host compatibility issues. Just by its nature, it takes time to mature and get smarter about handling the more complex and less typical implementations of USB MIDI clients.

If anyone is curious about what is involved in USB enumeration, try running USB Device Tree Viewer on Windows (at your own risk). While the output is interesting, and could be helpful, its not usually going to help us determine how to fix it.  Though sometimes it shows specific errors which is useful. For the most part, we need to run the actual device with the MRCC code debugger to see where things go wrong.