MRCC needs powercycle in fully booted windows

[oldgearguy]

I'm planning to go do some MacOS experiments today with the NDLR at a friends house to create a LOGIC PRO X set up guide. I will bring my MRCC along and see if I can reproduce your issue as well.

What I've been seeing is that when the MRCC is powered up and connected before the Mac is on, everything is golden.  Where it seems the Mac gets confused is when it powers up with the last remembered state of the world (the previously recognized MIDI device config) and then you change it by either powering on another MRCC, taking one off line then bringing it back on, etc.  In my case, it almost always recognizes the MRCC as a USB device; where it fails is to read/recognize the unique name for the MRCC and therefore you end up with multiple MRCCs hanging around in the Audio/MIDI window.

[HunniBunni]

I'm planning to go do some MacOS experiments today with the NDLR at a friends house to create a LOGIC PRO X set up guide. I will bring my MRCC along and see if I can reproduce your issue as well.

I had posted in the beta area but this thread caught my eye as similar issues to what I’m facing. 
I think I have been able to isolate the behavior but I don’t know what the technical term is so I’ll refer to it as “timing out” for now. 

What I first thought might be damaged cables, seems to be an issue where my MRCCs ‘time out’ and stop passing midi note data through to the computer/DAW. They seem to do this individually not at the same time. 

Running Catalina on a new Mac pro with Cubase 11.
I have two MRCCs connected as MRCC_C and MRCC_D. They are connected by RJ45, but nothing is cross routed. 
Both are running firmware ….44. 

No issues with them showing up in Cubase or audio/midi settings as _C and _D, but after a few minutes, or hours, the MRCCs stop passing through the midi note data (from all connected midi hardware) to the computer (though they still show up as connected/enumerated, and seem to still be receiving clock data from Cubase). I have confirmed it’s not a Cubase specific issue by using a midi monitoring app. The issue is not unique to any of my midi controllers, or ports, or port types (i.e. happening with my Nord electro 6D connected by DIN TRS(B), my Roland SPDSX connected by DIN, my arturia keylab88 connected by DIN, and my ROLI Seaboard connected by USB). 


It doesn’t seem to matter if I have turned on one or both of the MRCC before the computer or cubase. The problem has been solved by both power cycling OR briefly unplugging the MRCC to computer USB connection - however that fix usually only lasts a few minutes before it happens again. 

Thanks! Looking forward for the fix!

[Raphie]

Above counts for Windows as well, booted before windows, it’s fine, (re)booted in Windows, it’s visually there, but no longer works until reboot.

[starfish]

Jesse, what did you find out in your Mac OS tests – and what's the state of fixing this? The last beta firmware update was released almost three months ago.

[Jesse Johannesen]

OK we were able to test it out on High Sierra on a 2011 Mac Pro and a 2012 MBP running Mojave. Results were consistently the same, disconnecting and reconnecting the device immediately shows back up in the Audio MIDI settings menu, only being greyed out when disconnected. No reboot necessary.

[starfish]

2012 is the last MBP generation compatible with Mojave – and it doesn't have USB C ports, right? I think you should try it with a USB C Mac. Perhaps that's the core of the problem?

If I can run any additional tests to move forward with this issue, please let me know.

[oldgearguy]

OK we were able to test it out on High Sierra on a 2011 Mac Pro and a 2012 MBP running Mojave. Results were consistently the same, disconnecting and reconnecting the device immediately shows back up in the Audio MIDI settings menu, only being greyed out when disconnected. No reboot necessary.

If/when you used more than one MRCC, did the unique names get preserved or were you only seeing the generic 'MRCC' name?

Reason for asking is that sometimes I'm seeing the unique name get dropped and that causes confusion with applications looking for the specific MRCC.

[Jesse Johannesen]

I wasn't testing for that as we've already confirmed that issue and are working on a fix. In this case I was just seeing if I could recreate the removed MIDI device requiring a hardware reboot to reappear on MacOS, and in this case I was unable to reproduce the issue.

[oldgearguy]

I wasn't testing for that as we've already confirmed that issue and are working on a fix. In this case I was just seeing if I could recreate the removed MIDI device requiring a hardware reboot to reappear on MacOS, and in this case I was unable to reproduce the issue.

Got it.  Thanks for the clarification.

[starfish]

Jesse, this is getting weirder and weirder. I was just about to shoot a short video to proove that this issue exists here – and while doing this I found out something that might explain why it worked when you tested it, and why it still doesn't work here.

• When I unplug/replug the cable at the MRCC host port, it works flawlessly: MRCC disappears when unplugging and reappears when re-plugging.
  
• When I unplug/replug the cable between MRCC host port and MacBook Pro at the Mac side, the issue occurs: MRCC disappears in Audio/MIDI setup and doesn't reappear until a MRCC reboot.
  

I can recreate this consitently with different cables, so I'm pretty sure it's not related to any wonky cable or port connection.

I don't know if the naming issue is related to this, but another observation:

• When I delete MRCC in Audio/MIDI setup and unplug/replug the cable at the MRCC side, it always shows up as "MRCC" in Audio/MIDI setup.
  
• When I reboot MRCC it shows up as "MRCC_?" in Audio/MIDI setup. 
  Now I see two instances of MRCC in Audio/MIDI setup: "MRCC" and "MRCC_?"
  When I unplug/replug at the MRCC side, "MRCC" becomes active.
  When I reboot MRCC, "MRCC_?" becomes active.
  

Currently I'm on MRCC firmware 1.0.44 and Mac OS 12.2.1.

Of course just always unplugging the cable at MRCC side is no solution in practice, because I can't drag the cable attached to the MacBook Pro with me, but I think this might be crucial new findings that might help you to locate and fix the problem.