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?

I use my sequencer to automate chord changes. Everything is fine, except when I display the pattern page while the sequencer is running, the patterns steps are being edited by the received notes. I would like this not to happen, i.e. make changes to the pattern manually, with the NDLR knobs, while the chord sequence unfolds.

Question 1: what is the purpose of this behavior?

Question 2: can I disable this?

If you could turn the usb ports into a standard USB hub there should be no problem using them for audio over usb. Not sure if that would be possible.

For now my last question. Hopefully. The MRCC features an internal clock and can act as a midi master. That is fantastic. What has not been made clear in the video I have seen, wether this also works in conjunction with all the other merge features.

Let's say, there is a sequencer signal coming in each on port one and two and those data get merged to output 5. Standard business.
The two incoming signals from two sequencers happen to have their own clock signal, that of course needs to be filtered by MRCC on the input side - to then being replaced with the internal clock.

So at output 5 we have the merged signal from both sequencers (sans original clock of course) with the internal clock signal (plus start/stop/cont) added to the stream.

Does it work this way? And are there any limitations to adding the internal realtime data to any output data?

Thanks again

Hello, new noodler here. Query about the 1/8 clk setup:

If I clk out to a Rucci Clock Manipulator and then return its output to clk in, what’s gonna happen?

https://handmadeelectronicinstruments.co...nipulator/

Manual says:

“Clock In” must be enabled in the Settings 3 menu. It must be set for “ClkIn CV”. Once this is set The NDLR uses the input pulse signal as it’s internal “heart beat”.

But the Rucci gear uses the clk out as it’s source material, so I’m guessing it wouldn’t works as intended?

Thoughts, criticisms, jokes all very welcome!

qdrnmx

Hello,

first of all thanks for finally building a midi merger, that is also compatible with linux. Even if only by not needing a PC at all. And, well, stick to class compliant usb.

This is more a general inquiry, more of a buying decision helper, as I do not have this device yet. But as they are supposed to be back in stock shortly, it is time to get serious. If this is the wrong subforum to ask this, lets call it pre sales inquiry, please feel free to move it around.

My proposed setup is rather simple:

I have all 5 DIN inputs connected, one USB host and one device on TRS-A. Makes up for 7 input devices, whereas 9 instruments are connected to DIN out 1-9.

As to be guessed from the topic, I would like to do channel based routing/merging. That is, everything, on any of the 7 inputs, that is being send in on midi channel 1, is being merged an send to DIN  out 1, everything on any connected input on midi channel 2 is being merged and send out to DIN output 2, you get the idea, continue up to midi channel 8 to DIN out 8.
Finally,  everything on any input on midi channels 10-12 is being routed to DIN out 9. Just 1:1 routing and merging, no channel rewrite needed. 

I addition, midi clock is being received on the TRS input jack, and filtered on all other inputs, but only distributed to DIN out ports 1,3 and 5. So I would need filtering on the output ports as well.

Could that setup be accomplished with the MRCC? Not sure, wether there are enough layers for channel based routing, if possible at all? Maybe I just have not comprehended the videos well enough, in this case please bear with me.


I am not a native speaker, so if anything is unclear, please feel free to ask

Thanks

I really need more inputs any chance of adding more please

Just wanted to drop by and say that I LOVE the features and functionality of the MRCC. I ordered one last month along with the Remote 7. I do have to get off my chest that I was not at all thrilled about the shipping from Hong Kong (and if I knew that was going to be the case before I placed my order I may have gone in another direction...)

It really would have been icing on the cake to have had a couple of MIDI IN's on the Remote 7. After ripping apart a portion of our studio to wire the Remote 7 to the other side of our console (the supplied Ethernet cable was perfectly long as well!), and then a few weeks later installing some new analogue synth rackmount gear that unfortunately needs to dump patch data and the such over MIDI, it would have been great to have been able to go MIDI IN into the Remote 7. We ended up having to rip everything open again to run midi cables from the gear back over to the MRCC (so in hindsight pretty much defeating the need to have the remote).

I did just read that we can connect another MRCC unit to the other one via Ethernet (and I am seriously considering getting another one), however, it is a more expensive route which I am sure not everyone can afford. An expanded remote with at least 4 MIDI IN slots would be a solid way to go.

While playing with my routing, I noticed a curious thing: it seems that some USB MIDI hardware (in this case, Morningstar MC8) only seems to work on USB port A, but not on USB port C. I verified other hardware (Keystep) works just fine on all ports. I also noticed USB keyboards only seem to be supported on USB port A. Is this by design (not mentioned in the manual I think) or a bug?

I have two esi m4u-xl's that I use(d) to route all my synths in and and out of my pc. Now that I've got the MRCC I was wondering if I could use them in the usb host ports. They're midi class compliant but only input and output ports 1 out of the 4 work when I plug them into the MRCC. Any chance this might change in a future firmware update or is this a limitation of the hardware?