Bug: MRCC stops creating new routes

[Jesse Johannesen]

Great news, we've managed to solve the issue in the lab, and expect to have a release with this fix out very soon!

[Darryl]

New MRCC Beta Firmware posted in the MRCC Open Beta Firmware forum. You must be logged in to see it.

MRCC Firmware Beta 1.1.076

Features:
- Number of simultaneous routes allowed/saved/recalled has been increased to 255  
- A number of routes counter was added to the top left corner of the Activity screen. The counter turns Red once the maximum number of routes is reached.

We have not tested it extensively, but enough to feel confident that we could share it with the folks in this thread. We have not seen any outstanding issues. If you encounter issues related to these changes, please post them in the Beta forum.

Note: see my speech regarding having too many merged ports and routes in the beta posting.  

[leftcoastlex]

Hello MRCC Support,

I was reading through this problem, and my new MRCC which I just hooked up today seems to be experiencing the "freeze" problem.

I updated the firmware from 1.1.071 to 1.1.075, but the MRCC will still "freeze" and become unresponsive after a while of switching around inputs/outputs.

The only way I have found to unfreeze the unit, is to power it off and on again, and then it is ok for a while before it freezes again.

Have you seen this behavior before, and/or is it related to what people are talking about on this thread?

Please advise.

Thank You!

[RadekPilich]

My experience is unfortunately similar. 

I can confidently claim that my MRCC has experienced more freezes than all my other boxes combined

What makes it even worse that it's not easy to catch when and why is it happening. I might only suggest (I haven't tried it myself yet) to point a camera at MIDI monitor so you can actually see, what was happening. Maybe it would be enough to have the monitor opened as a home screen, I just almost never have it opened when it freezes, because I mostly use the main routing view.

[SteveECrane]

Jesse / Steve,

The new beta firmware (facilitating the increase in possible routes) has helped a lot; however, I have still had to employ 2 Kenton MIDI merge boxes and it looks like their MIDI Through boxes are going to have to come out to play too! I just hope I don't have to press the ESi M8U eX into use as well - it's a l'il bit odd!!! This scenario is really not ideal; far from it!

Whilst it's true that the limitations originally referred to by Jesse are (now!?) buried deep in the spec - and I genuinely don't want to sound ungrateful or be accused of having impossible expectations - but I genuinely did not expect to have to compromise so heavily when investing in a unit of this (supposed) calibre. It's likely going to become a real show-stopper for me, which just means I'm left with little choice but to sell the unit. And that's a real shame given how long I waited before acquiring this box of tricks. I still like it ... but it simply doesn't do all that I need it to do. Perhaps nothing at this price point does(!)?

I waited for Kenton's own MIDI router unit for almost 3 years since its initial announcement (it's still not manifested itself!), bought gear by ESi (and more Kenton) to tide me over, lived with a MotU MIDI Express XT parallel port, no less!!!) set to Merge ALL, and even considered the iConnectivity mioXL along the way. However, I was sold on the MRCC with the MRCC Remote 7 because of the sheer number of controllers and sound devices in my studio (their location and the fact that this number will undoubtedly continue to grow) and came close to dropping some more cash on the MRCC XpandR 4×1 DIN Expander too. 

LooPop's MRCC Review, alongside vids by Ranzee's MIDI Router Control Center video and Ricky Tinez MRC880 review - not forgetting the superb Conductive Labs' MRCC video manual series - coupled to CL's hyperbolic marketing rhetoric, all helped seal the deal ... and not once did I spot any serious limitations worthy of note.

I also owned CL's NDLR and rated its build quality and ease of use highly, valuing much of the support it garnered online (especially this forum) despite its limited ability to manage, store and recall 'setups' effectively - another compromise I'm finding really hard to live with in practice - all of which convinced me to part with my money quite readily!

While I recognise (and respect) that Steve and his team design devices they themselves want to use - to solve issues and problems they have experienced - once these products are being sold in the wild, then there's almost a moral obligation to more accurately reflect and account for their real-world users' requirements, not simply the whims, passions and desires of the designers. Again, I don't mean to sound harsh or unreasonable, but that's commercial reality ... and the difference between success and failure. Looking at what Chris Brown (no, not that Chris Brown) has done with the MIDICake Arp is incredibly impressive ... and that started off as a pet project too but has evolved to meet the demands of its users!

Furthermore, while I needed to be able to use any MIDI router I employed in standalone mode (i.e. without a DAW or computer) the ability to (pre-)configure it using a tablet or laptop interface would have solved a lot of head-scratching, plenty of trees(!) and much backache too! It's almost impossible to create more complex routing and filtering setups using that screen alone without a LOT of pre-planning, a LOT of paper, and a LOT of careful MIDI design. And, even then - as an ex-network designer for finance institutions (not known for their patience or tolerance of failure in their LANs!) - I'm still finding the odd loop or inappropriate filter which requires amending. 

It's just too difficult to keep track of everything in anything like a medium-complexity setup without making mistakes along the way ... and, trust me, I've Excel tabs galore attempting to manage everything!  The MRCC requires something akin to this, IMHO, for anything but the most basic of setups: Auracle MIDI Router Config App.

That is NOT what a MIDI router should require - IT should be doing all the heavy lifting, not demanding its users reconsider their setup complexity and placing prerequisites on the rig itself before it can be effectively deployed. All I wanted was any-to-any connectivity so I could sit down at any controller or MIDI device, anywhere in my studio - using the filters to remove MIDI Clock and MIDI loops - and to write music without having to clamber under, over and around gear to reconnect MIDI cables when that creative urge took a hold!

I'm genuinely sorry to all at Conductive Labs but, despite some of the MRCC's successes - and there are many and myriad - this device still falls short of (my) expectations for a full-featured MIDI router. I'm a mere amateur, not a demanding pro user, so I doubt I'm the only one who's frustrated - this forum's post hints likewise. It would be interesting to see just how many pro rigs this unit appears in given its manifest limitations.

So, it looks like I'm back to the drawing board ... again.

Thanks all...

PS When I talk about an any-to-any MIDI Merge, there's not that much data flying around (I understand the limitations of MIDI's 31,250kbps baud rate) so I doubt it's that which is causing the frequent lock-ups referred to in my OP; rather its a merge to achieve any port-to-port connectivity, typically with only 2 or 3 controllers being played alongside 1-3 sequencers/drum machines and/or a DAW (Cubase 14 under Win10) playing between 1 and 5 external MIDI devices receiving MIDI Note On/Off and a modicum of CC data.

[RadekPilich]

Hmmm, now I am wondering about how serial / parallel processing works in the MRCC / MioXL / CME boxes etc.

I have only surface level idea of how such things work, but it's unlikely that the chips inside those devices do much if any parallel processing. At the same time a routing device such as these calls for s parallel processing, no?

Or are the chips fast enough, so that they round robin across all the routings in a fraction of a millisecond and process everything in serial manner?

I guess that's no issue right? And that 1990s chips were probably fest enough already.

So the issue when it comes to the routing and processing limitations are more related to the design and size of the software rather then to the processing power....?

[Darryl]

Hello MRCC Support,

I was reading through this problem, and my new MRCC which I just hooked up today seems to be experiencing the "freeze" problem.

I updated the firmware from 1.1.071 to 1.1.075, but the MRCC will still "freeze" and become unresponsive after a while of switching around inputs/outputs.

The only way I have found to unfreeze the unit, is to power it off and on again, and then it is ok for a while before it freezes again.

Have you seen this behavior before, and/or is it related to what people are talking about on this thread?

Please advise.

Thank You!

This is most certainly caused by a MIDI feedback loop. If you remove the feedback loop, the MRCC will typically start responding again without having to power cycle. If you have a MIDI clock on an MRCC input, I would start with that. Try filtering the clock on that input, then make your routings and see if it still freezes.
The only other thing we've seen lock MRCC is the Waldorf Blofeld when attached to USB host. Depending on what other devices are attached, somehow it causes some trouble.

[leftcoastlex]

Hello MRCC Support,

I was reading through this problem, and my new MRCC which I just hooked up today seems to be experiencing the "freeze" problem.

I updated the firmware from 1.1.071 to 1.1.075, but the MRCC will still "freeze" and become unresponsive after a while of switching around inputs/outputs.

The only way I have found to unfreeze the unit, is to power it off and on again, and then it is ok for a while before it freezes again.

Have you seen this behavior before, and/or is it related to what people are talking about on this thread?

Please advise.

Thank You!

This is most certainly caused by a MIDI feedback loop. If you remove the feedback loop, the MRCC will typically start responding again without having to power cycle. If you have a MIDI clock on an MRCC input, I would start with that. Try filtering the clock on that input, then make your routings and see if it still freezes.
The only other thing we've seen lock MRCC is the Waldorf Blofeld when attached to USB host. Depending on what other devices are attached, somehow it causes some trouble.

Thank you for this reply Darryl - can you explain more about the conditions for a "MIDI feedback loop", and specifically how it gets setup in the MRCC so I can compare it to what I am currently doing and make the necessary change?  If necessary, I can list the synth devices I have plugged in to MRCC and which port they are plugged in to.

[Darryl]

Lets say you have a clock being sent from your DAW via USB device port on the MRCC. That port is then routed to a synth on a USB host port. So far so good, you can sync the synth to the DAW's clock, and play notes to the synth from a DAW track. But wait, you also want to capture MIDI from the keyboard on the synth, so you route that synths output/MRCC USB host input back to the MRCC PC port connection to the DAW. Now there's a loop.

Another example, just take the MRCC out of the picture. You connect a sequencers MIDI output to the input of a synth. You connect the output of the synth to the input of the sequencer. Now there's a loop. Sometimes it is very convenient to have this sort of configuration, it's even intuitive to connect things this way, but in many cases the MIDI data coming from the sequencer will be passed through the synths output back to the sequencer making a feedback loop. For channel specific data, you can sometimes use different channels to prevent, for instance, MIDI notes from feeding back, but clock is a realtime message and not channel specific.

Some synths have a setting to prevent using the output as "MIDI thru". Older synths sometimes have a hardware MIDI thru so it's not configurable. So the bottom line is, it's not always possible to get the ideal MIDI routing depending on what hardware you have. Experienced MIDI users learn to use what works rather than waste time chasing an ideal patch setup. It's just the nature of MIDI and the choices made by the MIDI device makers.

The MRCC makes it much easier to make MIDI loops by just pressing the buttons in an attempt to get an output from something back to an input. It also makes it easier to make this work; you can look at the Activity matrix to see where there's a clock(s) coming in indicated by the red arrow, then switch to the Routing screen, and try enabling the clock filter for that input. If there's more than one clock coming in, that isn't ideal, and it's best to disable the extra clock source, but if you can't then use the MRCC's clock filter. If the extra clock source is not coming from another device, but is a MIDI loop, then filter that input with a clock filter if clock is the issue, or unroute the output from the looped device to eliminate the MIDI loop.