One of the ways I liked to wire up racks internally is to have separate specific routes from the rack MIDI inputs to the plugin(s) - typically one for notes, one for aftertouch, one for pitch bend, and separate ones for CC1, 7 and 64. This means on a rack state basis I can suppress any of these. I find it particularly useful to suppress aftertouch or pitch bend for some sounds. It also gives me peace of mind, knowing that’s ALL that’s being sent into a plugin - no spurious controllers that might do something unexpected in my plugin.
However to achieve this, as far as I can see, a “Suppress Events” MIDI filter has to be set up for each of these, basically suppressing everything apart from what you want to allow through. For example, to just route CC7:
Wouldn’t it be nice to have a “Controller Select” MIDI filter, that just lets through a specific MIDI controller (or potentially a list of ranges) ? Essentially the inverse of “Suppress Events” but specifically for controllers. It would make for much cleaner routing rules I think.
I am doing the same, separating certain controllers out.
I wonder what “Learn Mode” does in this dialog??? (Will try later on…)
I actually have it set to pass multiple controllers from my Wavestation (16 + 17 for joystick), plus convert my CC#4 to CC#1 (foot pedal to mod wheel) to multiple other channels. At least once I’ve made one setup, it is easy to add other channels/MIDI outs to it.
Having a “Controller Select” would be easier, especially if it allowed selecting multiple controllers in one move.
but my actual preference would be to use MIDI-to-MIDI-bindings for this instead of routes - would make things far more explicit:
bind “main keyboard” aftertouch —> CC1 at “Solo synth rack” MIDI in
bind “main keyboard” cc11 (expression) —> CC7 at “Organ rack” MIDI in
bind “main keyboard” cc31 (slider C) —> CC11 at “Pad rack” Midi In
bind “main keyboard” CC64 (sustain) —> CC64 at “Piano rack” MIDI in
this would make controller assignments so much more explicit and easy to debug. Currently, they are hiding within the (usually collapsed) input route section, and you need to open the MIDI filters dialog to understand what is going on. I sometimes have 20 routes in this section, half of them like Neil’s filtering out all but one controller, with only a lot of comments helping me understand what is going on.
@brad: can we have MIDI to MIDI bindings, pleeeease?
This all falls under a bunch of MIDI handling improvements I’m planning. These changes fall into two groups - those that rely on some re-design in the binding framework:
Binding “take-over” support
Binding Reflection (ability to reflect an internal parameter value back out via MIDI)
Binding MIDI to MIDI
Binding Relative Encoder support (ie: rotary encoders)
Better support for bindings to be processed on the audio thread eg: MIDI to MIDI bindings shouldn’t be dependent on the UI thread (which if I was to hack this in would be the easiest way to do it).
and those that don’t:
A MIDI CC “take-over” filter (as suggested by Neil).
Enhancing the suppress events filter to allow specifying either cc’s to accept or cc’s to suppress.
A per plugin option (or MIDI Filter) to map CC7 to the plugin output gain.
State controllable per-route MIDI velocity curves.
Those that don’t rely on bindings I’ll probably knock over soon, the rest will come later (and probably all at once)
