Hi!
Currently I have an ML5R controlled via my MC8Pro. For a “clean” preset I use the SysEx message (ML5R type) to run the command below. The idea is to turn off all drives, which live in loops A, B, and C.
I also have a rack attached to this MC8PRO with a fryette ZMACS and a Synergy SYN-2 set in omni mode. I have presets on those devices that correspond to various amplifier, module, and power amp combinations.
I have those devices connected to omniport 2, which is configured as follows:
Finally, I have my midi channels configured as such:
My expectation here is that if the ML5R is set to receive MIDI via the DIN MIDI and the rack system is set to receive MIDI via the omniport, there should never be any crosstalk. However, when I run my “clean” preset it causes the ZMACS and the SYN-1 to revert to preset 1, which I assume correlates with preset 1 that’s being executed through the SYSEX message. Note that the ML5R has been properly configured to listen on the target MIDI channel, but I don’t see how that would impact how the MC8PRO is distributing the SYSEX message unless it sends to all ports and doesn’t respect the output port mapping above. Finally, I am 100% sure this is the message causing the trouble via deploying the process of elimination.
Shouldn’t this work?
Something I may try later is to convert the SYSEX message to CC messages on the ML5R, but that would be a bummer for my workflow.
SysEx messages aren’t channel-specific, instead using the manufacturer id, device id, etc. to let the downstream devices know what to read and not read. Consequently, they don’t “respect” MIDI channels because they are not sent on any specific MIDI channel.
I’m curious what happens if you switch to CC messaging for the ML5R. It’s a bit more hassle, but the ML5R has equivalent single message CCs for engaging/bypassing multiple loops at once. Those should respect your settings above.
If the problem is for sure that the ZMACS and SYN-1 are responding to SysEx messages that don’t “belong” to them, but you really like using the ML10X SysEx messages, one possible solution would be to put a MIDI filter in front of them. For example, I know that the CME H2MIDI Pro and H4MIDI Pro can be set up to drop SysEx messages.
Thanks Jason. I’m planning on giving that a try. The Fryette is the weakest link here, as it only lives in omni mode. The Synergy can be configured for a specific channel.
I’d prefer to avoid more hardware, so I’ll give the CC messages a try. However, I do want to point out that based on the UX of the system I expected no additional messages to be sent down Omniport 2 unless configured, but it makes sense that because these are system wide broadcasts you send them everywhere.
Would be cool if we had a filter capability inside the software for the MC8 too ;).
Actually, that’s a great point. Please don’t use the firmware listed there since it’s quite old, but I’ll look into it and see if I can reproduce your behavior and find the bug (or a solution).
Yay, I think we have a solution. I’d forgotten that the MIDI filters apply for this situation. If you want to limit your ML10X messages to just one output, you can add a message before it using the same trigger type (i.e. “press”, “release”, etc.) and executing the “Utility” message type. Pick the “Set MIDI Output Mask” option, and then only toggle on the port you want.
The MIDI Output Mask applies through until the end of that device’s actions, so if you’re messaging to multiple devices on one switch, do the ML10X message last (or send another “Set MIDI Output Mask” to reset it after the ML10X message).
I added an article about it here: How to filter / mask MIDI messages to specific ports (both standard MIDI and SysEx) | Morningstar Engineering
Reminder that I’m running an ML5R. Same thing apply?
Ah sorry. Yes it’s the same!
