Older Firmware Releases

[oldgearguy]

ok, it's weirder now.
If I boot up the MRCCs and then start the DAW, I now see MRCC-A ports 1-5 and the rest are coming up generic MRCC Port x

So it kind of works? This is on a Mac.

[Jesse Johannesen]

Oh boy! Thanks for the heads up. Too bad weirder isn't always better!

[HunniBunni]

Hello,

Wanted to reach out with some issues re: the firmware update. Perhaps it’s a user error I’ve missed but it appears the Cross routed notes from the MRCC_B are reaching the other MRCC_?’s midi monitor, but not getting passed through to the computer.

The following is how I tested this. I tried it both with and without the 7 port extension setting enabled on both of them. I did full reboots of MRCCs and my computer between those changes as well as MRCC name changes:

Example 1: 2 MRCC’s connected by RJ45 and connected to computer by USB. Both sets of PC MIDI inputs from the MRCCs are showing up in Cubase 11.
In Cubase My first MRCC is:
MRCC_? 
My second is:
MRCC_B

Physical connections and routing:
MRCC_B
Keylab88 (Midi Channel 1)
-IN DIN 3,
-Out to MRCC_B-PC 3,
-Out to MRCC_?-PC10

MRCC_B
SPDSX (Midi Channel 10)
-IN DIN 4,
-Out to MRCC_?-PC10

If I hit a low C-2 on the Keylab, it shows up twice as “P-10 1 On d:36 100, p-10 1 off d:36 0”  in the midi monitor on MRCC_?, however only one of them goes through to the midi monitor on my computer(MacPro) / cubase. It comes in via MRCC_B port 3.

If I hit a pad (note 36) on the SPDSX, I get a p-10 10 ON d:36 127, p-10 10 OFF d:36 0 in the midi monitor on MRCC_?, however it doesn’t go through to the Midi monitor on my MacPro, or cubase. Changing it’s output from a cross routing of MRCC_?P10 to a PC port on MRCC_B does however go through to the MacPro.

Also,  I don’t know if this is expected behavior, but on the MRCC_B, when I hit the button to Un-rout DIN channel 3 from going out PC-3, it sent 16 control messages to my  MacPro that said “all notes off 0.” It sent one per midi channel.


Also, for what it’s worth. It seems to only be MRCC, and MRCC A that causes a ? in Cubase. When I renamed the two MRCCs to _C and _D, those suffixes showed up correctly, however it did not solve the port cross-routing issue described above.

All the Best,
HB

p.s. In the user preset I’ve been trying to route things in, I’m not using any fancy features such as port, clock filtering, etc.

[HunniBunni]

Possible Update: Is it possible for a USB cable to “partially work.” I assumed a USB cable always fully works, or fully doesn’t work (I don’t mean intermittently). For example: Can a USB cable show a device ID to my computer, but be broken/malfunctioning enough to not pass through other data such as MIDI notes?

I eventually noticed that the issue of passing cross-routed MIDI to the computer seems to only exist with one USB cable (going from the MRCC_? to the computer), yet seems to be fine with another USB cable. However, with both cables, the ports show up in Cubase as active whether or not the issue is present. (That behavior in Cubase updates in real-time, and those ports immediately disappear when you unplug the USB cable, which is why at first the question of a cable issue didn’t come to mind, since on the problem cable, it always shows as plugged in)

[Dark Waves]

MRCC_v1.1.044_12-23-2021


FEATURE:
  1) Another update for enabling unique MRCC "USB PC Name" for when you have more than one MRCC attached to your computer. See  SETTING Menu page 4 to set the name.
      We think we've got it (mostly) working as designed. Please give it a try and leave your feedback in this forum. We really appreciate your help!

On a Windows 10 PC, it may be helpful to remove legacy USB cache entries using Device Manager, or the tool USBDeview. At a minimum, after changing the name you will need to reboot for the OS to correctly identify the new USB device names and associated MIDI port numbers. There might still be a race condition where the name could come up as MRCC_?. This shouldn't happen if MRCC is turned on before booting the computer. We're working on it.

---

---

In the Device Manager it wasn't obvious to me where to look to clear the cache, so simply rebooted the PC and the MRCCs a couple of times after loading this latest firmware.  In the few tries before having to bail to go to work, the list of ports in my DAW has repeatedly shown the two sets of 1 to 12 as MIDIOUT1 (MRCC_?) and MIDIOUT1 (MRCC_A), etc., even through reboots.  Previous to this version, there have been several alternating (seemingly random) combinations of port IDs in the list, such as (MRCC_A) and (MRCC_A) (2); (MRCC_B) and (MRCC_B) (2); (MRCC) and (MRCC) (2); and all (MRCC-A), but 1-24 instead of two sets of 1-12.  If the current combination of "?" and "A" stays consistent it will be helpful, so port assignments would persist from session to session for the instruments and keyboards to which they're paired.  When I get back I'll do some more experimenting with start sequences of MRCCs and the PC and the DAW.  Thanks for the progress!  If you can elaborate on the cache clearing process, that would still be worth a try.

[Darryl]

MRCC_v1.1.044_12-23-2021


FEATURE:
  1) Another update for enabling unique MRCC "USB PC Name" for when you have more than one MRCC attached to your computer. See  SETTING Menu page 4 to set the name.
      We think we've got it (mostly) working as designed. Please give it a try and leave your feedback in this forum. We really appreciate your help!

On a Windows 10 PC, it may be helpful to remove legacy USB cache entries using Device Manager, or the tool USBDeview. At a minimum, after changing the name you will need to reboot for the OS to correctly identify the new USB device names and associated MIDI port numbers. There might still be a race condition where the name could come up as MRCC_?. This shouldn't happen if MRCC is turned on before booting the computer. We're working on it.

---

---

In the Device Manager it wasn't obvious to me where to look to clear the cache, so simply rebooted the PC and the MRCCs a couple of times after loading this latest firmware.  In the few tries before having to bail to go to work, the list of ports in my DAW has repeatedly shown the two sets of 1 to 12 as MIDIOUT1 (MRCC_?) and MIDIOUT1 (MRCC_A), etc., even through reboots.  Previous to this version, there have been several alternating (seemingly random) combinations of port IDs in the list, such as (MRCC_A) and (MRCC_A) (2); (MRCC_B) and (MRCC_B) (2); (MRCC) and (MRCC) (2); and all (MRCC-A), but 1-24 instead of two sets of 1-12.  If the current combination of "?" and "A" stays consistent it will be helpful, so port assignments would persist from session to session for the instruments and keyboards to which they're paired.  When I get back I'll do some more experimenting with start sequences of MRCCs and the PC and the DAW.  Thanks for the progress!  If you can elaborate on the cache clearing process, that would still be worth a try.

We're working on fixing that MRCC_? issue. We have to monkey with the USB client interface so its taking some time.

[Dark Waves]

MRCC_v1.1.044_12-23-2021


FEATURE:
  1) Another update for enabling unique MRCC "USB PC Name" for when you have more than one MRCC attached to your computer. See  SETTING Menu page 4 to set the name.
      We think we've got it (mostly) working as designed. Please give it a try and leave your feedback in this forum. We really appreciate your help!

On a Windows 10 PC, it may be helpful to remove legacy USB cache entries using Device Manager, or the tool USBDeview. At a minimum, after changing the name you will need to reboot for the OS to correctly identify the new USB device names and associated MIDI port numbers. There might still be a race condition where the name could come up as MRCC_?. This shouldn't happen if MRCC is turned on before booting the computer. We're working on it.

---

---

In the Device Manager it wasn't obvious to me where to look to clear the cache, so simply rebooted the PC and the MRCCs a couple of times after loading this latest firmware.  In the few tries before having to bail to go to work, the list of ports in my DAW has repeatedly shown the two sets of 1 to 12 as MIDIOUT1 (MRCC_?) and MIDIOUT1 (MRCC_A), etc., even through reboots.  Previous to this version, there have been several alternating (seemingly random) combinations of port IDs in the list, such as (MRCC_A) and (MRCC_A) (2); (MRCC_B) and (MRCC_B) (2); (MRCC) and (MRCC) (2); and all (MRCC-A), but 1-24 instead of two sets of 1-12.  If the current combination of "?" and "A" stays consistent it will be helpful, so port assignments would persist from session to session for the instruments and keyboards to which they're paired.  When I get back I'll do some more experimenting with start sequences of MRCCs and the PC and the DAW.  Thanks for the progress!  If you can elaborate on the cache clearing process, that would still be worth a try.

We're working on fixing that MRCC_? issue. We have to monkey with the USB client interface so its taking some time.

On returning home, a slightly surprising development: the Windows 10 OS notified via pop-up message that it discovered the new device MRCC B (it had done that earlier today with MRCC A) and then said it's ready for use.  Either right before or after, only the 12 MRCC A ports were listed in the DAW, but after a reboot or two, the 24 ports have now been displaying as 1-12A and 1-12B (in longer form, of course).  So far, they've remained stable through a PC reboot in which the MRCC routers were left on.

[Dark Waves]

Just a follow up to the last post -- PC and DAW recognition of the two MRCCs has been solid since the last update, which has been very nice!

[HunniBunni]

Possible Update: Is it possible for a USB cable to “partially work.” I assumed a USB cable always fully works, or fully doesn’t work (I don’t mean intermittently). For example: Can a USB cable show a device ID to my computer, but be broken/malfunctioning enough to not pass through other data such as MIDI notes?

I eventually noticed that the issue of passing cross-routed MIDI to the computer seems to only exist with one USB cable (going from the MRCC_? to the computer), yet seems to be fine with another USB cable. However, with both cables, the ports show up in Cubase as active whether or not the issue is present. (That behavior in Cubase updates in real-time, and those ports immediately disappear when you unplug the USB cable, which is why at first the question of a cable issue didn’t come to mind, since on the problem cable, it always shows as plugged in)

Ok. So I'm still having stranger behavior.

I am still trying to get my MRCC working reliably in a pretty basic sense, so I have not tried utilizing many features to control the troubleshooting.

Basically All I am setting up is a bunch of DIM and USB midi devices, all of which are compatible with the MRCC. Many of them are connected to Input and Outputs, some just one or the other.

They have all been routed to their respective PC virtual port that I have labeled in Cubase 11.

My MRCCs are labeled MRCC_C and MRCC_D to avoid the ? thing.

I am usually using Cubase as the midi clock source (but sometimes my RC505 looper). I am only sending midi clock to a few devices that have parameters that respond to tempo controlled elements via midi clock.

While my MRCCs are connected by RJ45, I'm not cross routing anything to keep things simple.

Many of my inputs and outputs work as expected, showing activity on the MRCC and triggering things as expected in Cubase.



Right now however;
I am not getting MIDI data showing for the MRCC USB inputs or the PC ports they're routed to..however, if I take any of those midi devices connected to the MRCC by USB, and plug them into the computer USB hubs, they trigger my midi synths in Cubase immediately. This USB port issue has only been a problem since i installed the latest BETA firmware.

Also, Turning on one of the MRCCs turns on super super slowly, populating the display word by word for several minutes, unless I unplug the PC USB from the MRCC. The top MRCC is receiving midi clock for 3 channels. Sometimes it seems like stopping clock from going to the MRCC from Cubase alleviates this problem, but that's been hard to replicate consistently enough to be certain of.

The above issues have been consistent issues that persist through restarts of the MRCCs, cubase, the devices themselves, and my computer. Any suggestions? :/

[Dark Waves]

Just a follow up to the last post -- PC and DAW recognition of the two MRCCs has been solid since the last update, which has been very nice!

Slight clarification: rebooting an MRCC while the computer is on reintroduces the ID confusion, but if I stick with having them on before booting the PC it's back to normal.