MIDI routing to >2 destinations breaks sysex transfer

[Red_Hector]

I tried a simple test today of routing a one-way sysex bank dump though the MRCC (MIDI In 1 to MIDI Out 5) to a Roland D-550.

The bank was being sent from a PC using Bome SendSX software, routed out the MIDI DIN port of a RME UFX II -> MRCC In 1.
MRCC MIDI out 5 was cabled to the D-550.

The bank dump was transmitted successfully when MIDI IN 1 was routed just to out 5. It It also worked when it was routed to outs 5 and 6.

But, if I route MIDI In 1 to three outputs, (5, 6 & 7), the bank receive on the D-550 will fail with a 'MIDI communication error' message on the D-550 screen. The other synths on outputs 6 & 7 were turned off.

Obviously this is early testing with just one receiving device. But, this leads me to believe that the MRCC is possibly unable to reliably route sysex simultaneously to more than two output destinations. 

If this is true, it is going to make me have to use many work arounds, and possibly be quite limiting on how I use different sysex librarians and editors, whether on PC, Patchbase on Ipad routed through PC rptMIDI, or from my Electra One. I have around ten hardware synths that need to be controlled, many from multiple sources.

One answer is to use a PC virtual MIDI cable for each controller/synth combo, but this increases the complexity of my set-up a lot, and will be a pain to set up.

Has anyone else here experienced unreliable sysex when routing through the MRCC to more more than one or two outputs?

[oldgearguy]

I can confirm that sysex to more than one destination is *generally* hosed.
You seem to be able to successfully send to multiple destinations if the destinations are one each of USB, PC, ports 1-5, and ports 6-10

I was using a Korg DL8000R dump all which is 18468 bytes
In 1 -> USB A, PC (3), and port 1 was successful.

In 1 -> DIN ports 5,6 consistently dropped 1 byte.
In 1 -> DIN ports 5 and 7 dropped many many bytes.

and so on.  

Basically there either needs to be better/more buffering of sysex inside the MRCC or users have to restrict sysex transfers to a 1 to 1 mapping for ports (in general).

Yes, I know that sending sysex to multiple ports is most likely not what you want to do in 99.9% of the cases, but if you happened to have more than 1 of the same device and wanted to send sysex to them both, this would be a legitimate use case.  In any scenario, you would expect the sysex buffer to be transferred cleanly no matter how many destinations were selected.

[Royce]

I was wondering if you can try to put 'space" between the blocks of data you are sending.
This is particularly helpful for older synths, but might also help with the MRCC.

It is highly likely that the excellent Bome software would have an adjustment to allow it, but if not MidiOx certainly does.

Many synths send there sysex in groups of blocks (often 255 bytes as MS likes that).
MidiOx can separate the blocks with a settable time interval.

Menu View / Sysex then on the Sysex dialog menu Sysex / Configure
You can set a "Delay After F7" (end of sysex / block) in mSec.

If you are sending large sized blocks of Sysex then you can make the Low Level Buffers (output in this case) small - and have quite a few buffers.
Then you can try various times of "Delay between Buffers" to give time for the MRCC to do its stuff.

The Midi 1.0 spec allows certain Midi messages to break the flow of the sysex so machines should be able to cope and not have any problems with breaking up sysex blocks.

I usually try overly large delays just to see if this approach helps.
Then reduce the numbers till it stops working so you know the minimum needed.
Worth the effort as the 'spaces' can slow down the transfers to annoying levels..
 

Hope that helps.
Royce

[oldgearguy]

These are all good suggestions and for sure some set of them will tend to work. The slightly annoying thing I found in my brief tests is that the failures were not consistent across various combinations.
Even changing a destination from port 6 to port 12 changed the amount of info that got dropped each time.

So it is likely you can do some tweaking to get it all to work, but as soon as something changes, it could break again. For me, I tend to treat all the 'infrastructure' gear as appliances like a toaster or microwave. Set them up, use them, and they just work. When I'm questioning multiple pieces of gear in a path to determine the root cause of an issue it becomes super annoying.

There's been more than one occasion that I regretted selling my Sycologic M16 (16x32 config). Sure no merging or filtering, but it always 'just worked' sending MIDI data around my system.

[Red_Hector]

I was wondering if you can try to put 'space" between the blocks of data you are sending.

The synth editor/librarians I use do not allow this.


The following is quite long so...

To summarize  - 
The PC->MRCC USB virtual MIDI cables solve most sysex dump routing issues. 
But...
Even with a 1:1 routing, the Remote 7 will only pass a large sysex dump sourced from a PC In virtual cable. Routing the DIN inputs will not work. 
Again, with just a 1:1 routing, the XpandR 4x1 will only pass a large sysex dump in 4->1 MIDI-DIN 'merge' mode (red led). Forget about using the 4 port USB 'expander' mode (blue LED).


Most of my sysex dump issues have been solved by using the twelve PC In virtual MIDI cables on the MRCC. One for each editor/librarian. These seem to be more reliable when patched to multiple MRCC outputs. There may still be some data loss, but dumps not failing and timing out, like before.

There are other major sysex issues, though, with the Remote 7 and XpandR 4x1 modules. I could not initially get the 'Trinitro' Trinity editor to send or receive PCG sysex dumps. These are sizable multi-bank sysex files, and a real test for the MRCC. The Trinity is routed through the Remote 7 outbound, and the XpandR 4x1 inbound.

I should say first that a directly cabled RME UFX II to Trinity two-way MIDI connection has absolutely no issues at all with PCG sysex dumps. Each MRCC routing was then tested individually to isolate what was causing the dumps to fail.

MRCC MIDI DIN In 1 routed to Remote 7 DIN out 3, with a simple 1:1 routing, cannot pass PCG sysex dumps to the Trinity. It fails every time, about 3/4's through part 2 (of 6) of the dump. For the test, the return Trinity to PC MIDI connection was a direct physical cable to the RME.

However, if the MRCC routing source is changed over from a DIN in socket to a PC USB virtual MIDI in, the PCG sysex dump though the Remote 7 will work properly with no errors.

But, there is more....

The XpandR 4x1, in expander mode with the solid blue LED, cannot pass a requested PCG sysex dump, back from the Trinity to Trinitro, even with just a 1:1 routing through the MRCC. IIRC, it instantly fails. For the test, the outbound MIDI was a direct RME to Trinity physical MIDI cable, to rule out the MRCC.

However, if the XpandR 4x1 is changed over to 4->1 MIDI merger mode, with the red status LED, and connected to an MRCC DIN input, the retrieved PCG dump will pass successfully.

The problem for me is that XpandR 4x1 is way too expensive to be acting as a basic 4->1 MIDI DIN merge unit. I will keep for now, to see if it will get fixed.

All the tests happened yesterday, and my memory is a little fuzzy. But, I can do more tests if needed.

............

More detail on my set up. The MRCC is used just for the subset of hardware synths that need sysex librarian/editor control, and excluding those synths that work with CTRLR-based VST plugin editors. The MRCC is augmented with the Remote 7 and XpandR 4x1 modules.

There are ten synths being routed through the MRCC, plus an Electra One Controller also patched in.

DAW traffic, (non-SYSEX MIDI), uses the two RME UFX II MIDI DIN outs.
RME MIDI Out 1 --> MRCC MIDI In 1, and routed to:
MIDI Out 9 - DSS-1
Remote 7 outs 1-4 for SY77, TG77, Trinity, CZ-1.

RME MIDI Out 2 --> MRCC MIDI IN 2, and routed to:
MIDI Outs 5 - D-550, 6 - K4r, 7 - Microwave, 8 - ESQ-1, 10 - AN1X 

MRCC MIDI DIN I/O 3 & 4 give two-way connection to MIDI I/O 1 & 2 on the Electra One.

A Unitor 8 in standalone mode, merges the returns from from the D-550, K4r, Microwave, ESQ1, AN1X, before passing to a DIN input on the MRCC.