Part of my excitement with the MC6pro was the idea that I could probably remove one element from my chain (the disaster area micro.ghost et al) which I’d been previously using to integrate my little blue boy into my rig for years. It absolutely does work out of the box, both power and MIDI! Problem is, the Zoom doesn’t really do MIDI ‘properly’ and it’s not even an advertised feature. It listens on all channels for PC/CC messages over USB HOST and acts on them all. If I send a PC anywhere, it changes the zoom as well etc. The micro.ghost is channel selectable, which it then blasts onward to the channel-agnostic zoom to get around this problem.
Is there a way, either an option that could be added, or something existing, that could restrict MIDI messages over the USB HOST port to only a specific channel(s) before it leaves the MC6? I’m imagining something like either it’s own “destination” or an option in general configurations to limit the messages passed by the port to be certain channels.
This is really helpful, thank you! Didn’t know anything about it.
If i’m understanding the behaviour correctly from the example, all messages beneath the mask inherit the masks behaviour? So what I would need to do is for every preset/every bank have a midi mask as the first message which excludes USB from everything beneath it, and then one at the end to set USB mask and place the messages for the Zoom after that? I can see that getting pretty complicated on some of my presets and I definitely couldn’t have done it before the 32-message limit. I can see it working but it’d be an incredible amount of work, and I presume it’s also gesture based… I’m making a lot of assumptions because the behaviour isn’t explained in much detail.
An ideal situation would be a global mask of some kind (i.e. channel 3 is passed over usb but not omniports or DIN etc., all other channels have an inverse mask passing to omniports and DIN but not USB).
Yes, adding MASK messages will get complicated. What we could possibly do in future updates is have a global setting to send MIDI out on selected ports during start up. So you just need to add MASK message on these Zoom presets to enable sending via USB Host for that preset only
Something like this solution I would greatly prefer - and it’s a bit more logical as it works top down rather than bottom up. Makes more sense to only allow the limited/selected channels or messages to be sent over HOST rather than individually restrict all the other unwanted messages.
In my case my Zoom “channel” is 3, so all messages on MIDI channel 3 are for the zoom and only the zoom, but because it is an omni device it responds to all messages on all channels. The ideal solution would a global setting “zoom mode” that masks all channel 3 (for instance) messages to usb-host only, and hides all other messages from usb-host.
Either way, thanks for taking an interest in solving this with me!
All MIDI devices should have a setting to respond to only a specific MIDI channel so implementing a port setting for each channel may not be so useful i.e. not looking to implement a solution specifically for the Zoom product which does not officially support MIDI. Not 100% sure yet, will need to think about it.
There might be some use cases where we want to avoid sending MIDI messages on specific ports to overcome specific issues like MIDI Clock or Exp CC noise on some products.
All Zoom multistomps behave this way (it’s assumed to be connected to a PC not a MIDI hub, and you’re right in that it isn’t “officially” a feature, it’s a byproduct of being able to use the zoom effect manager over USB and things like ToneLib to navigate and manage preset data). It does respond logically to standard midi (certain CC, PC and has a SysEx implementation) but because of the above assumptions there’s no way for the user to specify what channel to listen on. There’s no need to specify if you’re using it “as intended”.
Anyway given that the official marketing/feature description for the USB-Host port on the MC6 Pro explicitly mentions “control … Zoom Multistomps without a costly and cumbersome adaptor” I hope we can arrive at a way that makes doing so more easy, whatever it is. Hopefully it would have wider applications than just for this issue
