Posts: 28
Threads: 6
Joined: Dec 2020
Reputation:
1
0
09-24-2021, 05:29 PM
We are a duo. Maybe we had too big expectations with the MRCC with the latest firmware. Basically, what we do is use a Pyramid and NDLR as MIDI sources to control several (10) machines. So there's quite a bit of splitting and a bit of merging (mainly taking clock of out A and notes of out B from the Pyramid and merging them to the NDLR, which is only connected in USB). The setup crashes the MRCC consistently, within a 10 minute timeframe, but at totally (apparently) random moments. Setups without USB ports crash it the same.
It is down to a point where we're considering selling the MRCC because we would like to rely on it as the brains of our MIDI network, and it is simply not trustworthy, if even usable.
It does not look like such a big setup, for there are many ports still free on the front panel...
The frustration is big. Do other users experience the same kind of heavy trouble? Could our MRCC be broken?
Posts: 1,279
Threads: 7
Joined: Jan 2020
Reputation:
65
8
First off, sorry for the frustration. I know how it feels to want to just use the thing you bought without it having problems. If the MRCC is crashing when being used via DIN MIDI only, then we either have a bug, (likely) or your device is faulty (probably less likely). Would you mind sending me an email to Support@conductivelabs.com to discuss it in more depth. Maybe we can arrange to do a zoom call and try to figure out what's up?
Jesse
Posts: 333
Threads: 52
Joined: Nov 2018
Reputation:
39
0
When I've been testing the MRCC, the vast majority of the time I caused a lockup or crash was due to a complex route causing a MIDI loop. My suggestion would be to slowly build up the connections from a blank MRCC preset and see what happens.
Posts: 28
Threads: 6
Joined: Dec 2020
Reputation:
1
0
We do nothing that obviously causes the freezes. Everything clicks perfectly for a while. Can a loop be sustained for a while and then suddenly overflow the memory, or something of that ilk?
Posts: 1,279
Threads: 7
Joined: Jan 2020
Reputation:
65
8
Thanks, I'll go take a look at the email.
Cheers
Posts: 28
Threads: 6
Joined: Dec 2020
Reputation:
1
0
Thanks to Jesse's help, we've narrowed down the problem to improper USB host port functionality when using Arturia's KeyStep37. Which side is problematic, the MRCC or KeyStep37, is impossible for us to tell. This connection hangs the MRCC pretty fast, and it recovers by power cycling the KeyStep37. It might be a MIDI loop of some kind, but we configured a channel modifier to ensure the was no backtalk (the KeyStep37 uses an unique channel, IN and OUT), and still the problem is there.
Plugging the KeyStep37 through DIN ports exclusively completely solves the problem, though.
Thanks for great support.
Posts: 1,279
Threads: 7
Joined: Jan 2020
Reputation:
65
8
I don't know if the 37 is specifically in our arsenal, but the MRCC was designed interfacing primarily with arturia devices (keystep and BSP) as the primary inputs, so it seems really unlikely that they would develop a completely different USB protocol for the 37, but it's possible. can we test the Keystep without the feedback and see if it still causes a fault if the MIDI goes out directly to a synth. If we can establish that it's not feedback related that would help.
I suggest we test it with just the simplest setup possible, like MIDI in from a keyboard into port 1 on channel 10 out to keystep on USB whatever, channel 10 and out keystep din into a synth to listen to the notes. If this doesn't hang then try incorporating the same feedback routing and see if that hangs us up.
FYI I added a feature request to identify midi loops and block them rather than hang the device, so hopefully we can make that happen at some point to avoid this kind of thing. I'm sending that NDLR FW now by the way.
Jesse
