Today a new experimental build of Cantabile is available with a significant set of improvements to Bindings.
These changes let you do things like bind directly to and from plugins and devices, bind MIDI to MIDI, mirror settings across parameters and the much awaited MIDI Reflection to reflect internal settings on external LED rings and motorized faders.
Warning, Warning, Warning!
Before jumping into this, please note that these changes are still very experimental. You should not use this for live performance and this is only being made available for testing, evaluation and feedback.
Also, the file format of songs and racks has changed slightly. If you save a song in this build and try to load it in an earlier build it won’t load correctly. Any triggers and some binding settings will be dropped. In other words before you use this build please make sure you’ve got a backup of all your song and rack files so you can go back when you have to.
Back up now. Don’t use it live.
Binding Anything to Anything
The main idea behind this new binding framework was to allow binding of anything to anything.
- MIDI to Object — as per previous builds aka “MIDI Controller Assignments”
- MIDI to MIDI — connect a specific MIDI controller on one device to send a MIDI event to another device
- Object to MIDI — reflect a setting or plugin parameter through MIDI to an external device (eg: control LED rings and motorized faders)
- Object to Object — reflect a setting from one object to another
- Trigger to Object or MIDI — set a parameter, or send a MIDI event when a particular action occurs. eg: reset a plugin’s gain level on state load.
You can now bind directly to/from any rack, plugin or media player’s MIDI port. This lets you do things like create bindings directly from a media player or directly send MIDI events to a plugin.
You can also direcly bind to and from the parameters of a plugin.
Each binding now has 5 main settings:
- Source — the object or MIDI port to bind from
- Event — the event kind to monitor for (eg: MIDI CC and the controller number).
- Target — the object or MIDI port to bind to
- Action — the action to invoke (eg: MIDI CC and controller number).
- Mapping — how to map values between the source and target.
Because of the wide range of things that can be bound together not all bindings support all settings and not all binding combinations make sense. For unavailable settings the unused fields will be blanked out in the UI and for invalid combinations an error message will be displayed in the Mapping field.
For example, binding from a MIDI port requires the event to bind to. eg:
Main Keyboard, Channel 1, MIDI CC, CC# 10 -> Target
Where as most object sources just require the source object and parameter. eg:
Metronome, Tempo, [no event selection necessary] -> Target
Similarly, it doesn’t make sense to bind a variable controller to an action. eg:
MIDI Controller -> Load Next Song
If the CC is really a button controller, you should choose one of the button CC events
MIDI Controller (Button) -> Load Next Song MIDI Controller (No Edge Button) -> Load Next Song
This is different from before where Cantabile would automatically internally switch to button detection. When loading an old song the conversion will automatically change it to a button CC event but be aware that when setting up new bindings you need to explicitly choose “Controller (Button)” or “Controller (No Edge Button)”.
Depending on the source and target objects, the type of mapping between the two can vary.
* MIDI CC -> MIDI CC = source and target range * MIDI CC -> Gain Level = relative encoding, jump prevention and source and target ranges * MIDI CC Button -> Switch Setting = on/off/toggle options * etc...
Once you’ve selected the source and target the value mapping column will display the kind of mapping and clicking it will show a popup where you can adjust it.
Some binding sources support pre and post delays. These are basically the same binding points as the old triggers (eg: Song Load, State Load etc…) and should work as before.
Most source binding points don’t support delays.
Bindings are completely state controllable except for the source part of the binding. This was a deliberate restriction to simplify the management of bindings — it would be confusing to have different binding sources hidden behind different states.
As mentioned Triggers have now been integrated into Bindings and the Triggers panel and all related commands removed. On opening on older song or rack file Cantabile will convert each trigger to an equivalent binding.
For 99% of cases this will be a completely seamless process however there is one edge case where the conversion won’t work — triggers that use a different trigger event across different states. As mentioned above, the source of a binding can’t be controlled by states so triggers that utililise this functionality won’t convert.
If you have trigger that can’t be accurately converted to a binding you’ll get a warning message and the work around is to split the trigger into multiple bindings and use states to enable/disable each one as required.
In practice I doubt this is going to affect anyone.
At this stage I haven’t really addressed the learn mode functionality of bindings and currently it should work as per before — just on MIDI sources.
I’ll be addressing this soon and hopefully improving it over what was there before.
These improvements are only available in Cantabile Performer. Cantabile Solo inherits the new binding framework but the available binding points are limited to MIDI to Object bindings (as before).
This is a significant change and I’m almost certain there will be issues and missed binding possibilities. Give it a go and let me know what you think.
Available now in experimental build 3182. Get It Now (well after you’ve backed up).