When would I want to apply a midi filter at the midi port versus plugin level to manage a plug-in? Similarly, why would I set my note range in the midi routing dialogue box versus using the key range midi filter at the plugin level?
Hi Lee,
well I think there is no best practice that fits for every need. So I only can tell how I use the
possibilities. My intention was to have a (more or less) clear strategy. If we talk of midi filters there are different levels where you can place them so far:
midi-ports, midi-routings and plugins, additionally midi-plugins and routings inside a rack – means there can be up to 5 midi-filters in the midi path from midi-in to plugin.
In my case I only use racks. My strategy is simple and as follows:
I route midi-signals from virtual input ports to racks and there are a bunch of controllers I dedicate to several functions, in detail (dependent on the keyboard I use) there are (at maximum) the following virtual ports available for each keyboard:
midi notes
pitchbend
modwhell (Cc#01)
volume (Cc#11)
drawbars (Cc#12-20)
ribbon control (Cc#22)
sustain (Cc#64)
ribbon control (Cc#22)
This is done by using the suppress event filter. Im very strict here as I suppress everything but the one parameter I want to be surpassed. This keeps traffic small and prohibits unexpected trouble. Another thing done here is to map any midi channel to channel 1. This can solve problems with unproper settings in the keyboards. In my case it has a special background: I use an older DX7S als 2nd Keyboard. For some reason the backup battery doesnt work even though I exchanged it which led to the situation this keyboard always sends on channel 16. With the channel mapping it is not of any interest any more.
Another aspect for midi-filters in virtual inputs is the use of different keyboards for the same soundsets (f.e. home / stage). Here I have 2 different configurations of cantabile with the same virtual input names but different midi-filters. For my DX7S I`m so able to rescale velocity velues as
this synth only sends values from 1-100. For the same application with another keyboard on stage I simply leave this filter away.
For the plugins and routings inside a rack this means: map controllers so that meaningful mappings are possible without a remapping. F.e. I map Cc#11 to the controller that controls volume inside a plugin (mostly Cc#07 or Cc#11). If plugins dont have this channels mapped by design I tend to not use midi-learn functions but parameter automation filter instead. If for any case the midi-learn gets damaged Im not bound to this. Handling the volume by parameter automation is a good way to get u-he plugs like HIVE controlled.
This way it is very simple to do simple mappings by creating midi routes: f.e. a piano without volume control has two mappings: notes & sustain. A typical synth could look like this: notes, volume, modwheel & pitchwheel,…
Midi-Filters are also used for a second reason here: I again (as in virtual ports) suppress any events I don`t want to be routed to the plugin. This was an often occouring problem in former projects where I got volume or filter manipulations inside the plugin and no clue what had iniciated them.
All this may look cumbersome at first glance but has the advantage to be very transparent as the functions mapped can be directly seen now in the mappings (in contrast to realise individual filters that hide this information).
Same is true for note ranges: I normally only influence them in midi-routings (again transparency).
There are some exceptions when I also use them inside a rack: f.e. it can be useful to suppress the lowest octave of the upper keyboard of a hammond emulation as this is not used for playing notes but for switching between sounds. This function is not needed as I`d do this by using song states. So it is a good idea to suppress them.
This only as my personal taste on this. I`m sure there will be lots of other ways to make use of them.
Regards, humphrey:sunglasses:
2 Likes
Massively helpful insights, Humphrey. Thanks!
Terry
The forum software wanted to know if I really want to revive this 3 year old topic. The answer is yes. Last night I checked the rack state I set up for Hybrid just before carrying my setup on stage. Unbeknownst to me my 7th Axiom 61 slider was mapped to OSC 1 Shape which must have been bumped into while moving the keyboard so when I did the sound check it sounded like it was coming through an AM radio. I reverted the rack and all was well but I’m very interested in knowing if Humphrey’s midi filtering from virtual input ports to racks is a good way to make sure in the future I’m not surprised again.
Hey Doug,
To avoid issues like this, I have “abstracted” my keyboards into encapsulated racks and only connect specific MIDI outputs like “Notes”, “Modulation”, “Aftertouch” to my racks - never the full MIDI output. This way, only the commands that I really want to have an effect connect to the instruments. See here:
I use two keyboards abstraction racks “Main Keyboard” and “Second Keyboard” that provide notes, aftertouch, modulation and pitchbend through individual outputs. This is great for multi-zone setups - making sure that aftertouch or pitchbend affects only one zone or layer is a breeze!
Then I have a separate “Faders” rack, which actually takes inputs from faders / rotaries on BOTH keyboards and transforms them into either expression (cc11) or volume (cc7) commands on separate outputs. When I get a new keyboard controller, I simply edit the “Faders” rack to adapt to a new setup - my songs stay the same.
Pedals are also encapsulated in a separate rack - I have lots of different uses for the expression pedal, both on the upper and on the lower keyboard, depending on the song. Same with the sustain pedal - I sometimes duplicate my lower keyboard setup on the lower octave of the upper to make it easier to play a left-hand chord foundation for a right-hand solo. In these cases, the sustain pedal will be routed to those racks that constitute the left hand part as well as the lower keyboard part.
With all this, I rarely need to use any filtering on routes anymore - I only route the stuff I want, so nothing else can interfere!
And now with the new routing view, this method becomes even more powerful - far easier to string together a setup from all these different ports!
Cheers
Torsten
3 Likes
Very nice Torsten ! 
Thanks Torsten (and Humphrey for the original explanation of why you don’t want full midi). Thanks to Brad for the diagramming view - already coming in so handy!
And it’s way easier to visualize than some alternative mad scientist scripts and explanations I’ve put together lol 
honestly, very much easier to view the logic of your method all this way from my own educational point of view. Thanks @Torsten for the sharing!
Dave
1 Like