Seems that cantabile had different ways of filtering.
- There’s the midi routing on the input, which can do transpose, all midi filters, key range, …
- there’s the key range in that same menu
- There’s the transpose on the input
- filter on the input
- there’s the midi routing on the plugin
- there’s the filter on the plugin
So what filter /routing do we best use, what’s the practice and maybe some are double function?
I use the input to filter and use the routing for the key range.
Routings are stored per state. Filters are not.
Good to know, can make a lot of difference in frustration
so why is it double? I don’t see any use of it?
I think it is this way for converting files from version 2…
The duplication allows you to achieve things in a cleaner way. For example, suppose you use a controller keyboard that has a broken continuous controller that sends spurious data that you need to filter out. Or maybe you want to apply a velocity curve to everything from your keyboard, to make it feel different, or perhaps filter out all program changes. These things you can do at the input, so you don’t need to worry about it in any of your songs. Set it up and forget about it.
MIDI filters on plugins are useful when you want process incoming MIDI to the plugin because of some behaviour of the plugin. For example, suppose a plugin always uses CC13 for volume instead of CC07, you can put a mapping in there. Or maybe the plugin doesn’t support sustain pedal (as some don’t, annoyingly!), and you need to map incoming CC64 to some other mechanism. This can be done at the plugin level, so that regardless of which MIDI route you use to drive the plugin, the processing will always be done.
MIDI routes have MIDI filters, which I guess are the main way to do MIDI filtering on a song-dependent basis, for creative purposes, and certainly for me, I tend to use these the most - usually for filtering out sustain pedal where I don’t want it, and stuff like that.
So to sum up, you have filters to pre-process incoming MIDI to accommodate peculiarities in your MIDI controller, filters to pre-process MIDI to accommodate peculiarities in your plugins, and then filters to do stuff you need to do in your song.
Of course, you don’t need to use that categorisation; but having the MIDI filters appearing in several places allows you to maintain that separation if you want to, for clarity and convenience.
Hope that makes sense!
The main distictions are:
- MIDI Filters are generally more flexible, are included for backwards compatibility with v2 but aren’t state aware. They weren’t designed from the outset to handle state changes that might cause stuck notes (eg: consider a state change where the transpose setting changes - unless the filter is smart about it you’ll get stuck notes.
- Routes aren’t as flexible but are aware of state changes and will correctly handle transpose and other changes while notes are held.
As for the different places where filters can be inserted - it’s basically exactly as @Neil_Durant describes.