Do you need this MRCC accessory?

[Raphie]

ThNX Darryl! Will do that now

[WaldMeister]

I would definitely buy one... when there will be usb hub support for port A-D! (Any news about it?)
(I wonder if there is until now any device, that takes advantage from the 4 channels per usb port?)
BTW, I love my mrcc. Great work!

[Darryl]

Q: Should I get an MRCC XpandR 4x1 or a Remote 7 for my MRCC - MIDI Router Control Center?
A: These two accessories support different use cases.
The Remote 7 adds 5 more routable outputs at up to 50 feet (about 15M) away.
XpandR provides 4 additional DIN inputs and one DIN output in exchange for occupying an MRCC USB host port. XpandR is limited to the USB 2.0 cable length of 3 meters, unless you invest in an active USB extender cable which is essentially a USB repeater.
You can have one Remote 7 per MRCC, and 4 XpandR's per MRCC (one for each MRCC host port).

MRCC XpandR 4x1 can also be used as a PC MIDI interface, or a stand-alone USB powered 4 to 1 MIDI merger.

In summary, if you need more outputs at a distance, Remote 7 is a great solution. If you need more inputs, use XpandR, or get both. If you need lots of Inputs and Outputs, use 2 MRCC's, taking advantage of the remote routing feature.

[Darryl]

MRCC XpandR 4x1 preliminary (draft) User Guide. We've sent out a couple of beta units for testing, but in the mean time we're ready to start hardware production just as soon as our manufacturing rep is done assembling our next batch of MRCCs. 


  MRCC XpandR 4x1 draft User Guide v0.06a FEB 23 2022.pdf (Size: 335.77 KB / Downloads: 5)

Updated to fix an incorrect assumption regarding merging and large SysEx files, as it works as it should.

[Darryl]

I would definitely buy one... when there will be usb hub support for port A-D! (Any news about it?)
(I wonder if there is until now any device, that takes advantage from the 4 channels per usb port?)
BTW, I love my mrcc. Great work!

Because we've been having trouble getting to the bottom of some USB host compatibility issues, we haven't wanted to add hub support, which would complicate things further. 

We put 4 virtual port inputs on each USB host port because The NDLR has 4 USB MIDI virtual port outputs.

[WaldMeister]

I would definitely buy one... when there will be usb hub support for port A-D! (Any news about it?)
(I wonder if there is until now any device, that takes advantage from the 4 channels per usb port?)
BTW, I love my mrcc. Great work!

Because we've been having trouble getting to the bottom of some USB host compatibility issues, we haven't wanted to add hub support, which would complicate things further. 

We put 4 virtual port inputs on each USB host port because The NDLR has 4 USB MIDI virtual port outputs.

So what about creating a 4 Port USB Hub by yourself? 

[nexgenmusic]

Just ordered a second MRCC. Big thank you to those posting information on the use case scenarios/configurations. I'll be going with the RJ45 splitter option to use with our Remote 7 unit if necessary, however, 2x MRCC's is more than enough midi I/O for our present needs.

[Raphie]

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)

[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.

[Raphie]

ThnX Darryl, I didn’t expect it to be easy and it’s icing on the cake sort of speak.
If in any way I can contribute by running scripts, providing dumps, even screen shares on ZOOM sessions, I’m more that happy to do so. It’s indeed unrealistic to expect all gear to be available for testing 1:1 But if I can help remotely in any way, let me know.