I’m not a scripting kinda guy, but I have a sense that what I want to do should be easy to accomplish in the new bindings system.
A simple condition facility does exist in the MIDI route window but a quick glance at the binding menus with all those $ signs hints to a non scripter that it should be possible to describe, with reasonably obvious terms, far deeper instructions.
I’d like to know if, in practice, the bindings can allow a MIDI instruction to be invoked as long as other MIDI instructions are specified as a condition for firing.
For example, if F4 is played turn on Effect XX as long as a MIDI CC @ value X on Chan X is also invoked.
Hi Adrian,
Yes, it can. You would have to uses the Onscreen Keyboard to act as a storage memory for your condition values. An example of your binding might look like this. This binding disables the plugin when you hit F4 and the value of CC1 that is stored in the Onscreen keyboard is a value of 64.
If you wanted to use the same trick you could enable and/or disable input routes to the effect.
You can initialize values in the Onscreen buffer using Song On Load bindings and you are not required to have buttons assigned for them them to be recognized and stored.
Both these examples are one shot bindings and if you wanted to reset the route or plugin’s running mode you would need another binding and means to do it.
Cheers,
Dave
2 Likes
@dave_dore
Thanks as ever for the pointers. So the second midi byte is determined by ==? What if there was an additional byte, say with a Poly AT or Note On?
Hi Adrian,
Yes, by setting the math operator another value is expected to follow the operator. In this case == or “equals”. You can also use <> greater or less than operators too.
Then you could use either the AND (&&) function or the OR (||) function. This allows you to chain your arguments in a single expression. Example, I want the F4 key to disable the input route to the reverb ONLY when the lowest is pressed and held and the MIDI volume is greater than 64.
Dave
1 Like
This is really great help!
No doubt familiarity will produce dividends. I’m wondering whether some future binding enhancements offering something along the lines of Halion’s Megatrig might FastTrack use of this functionality?
That way, each line is clearly visible. If the current Cantabile system is required to perform a deeper set of conditions, it looks like they must all be presented within that one field. Yes?
Yes, correct. The expressions can be short or very long with a ton of conditions in them.
Not sure on future enhancements @brad might do though, the MegaTrig GUI looks very accessible but is also limited in ways when compared to the current Cantabile expressions support IMO. I’m still ironing out my syntax skills with it and have to test a lot of things I dream of to see how the syntax would make them happen but I’m making great progress and I have found several fixes using it not available to me or others before.
2 Likes
I’m thinking there’s enough room in the notes field to lay out expressions clearly and then paste them into the appropriate condition field.
In this way the data is with the binding and, perhaps, more easily visualized?
Just want to get a practical connection to all this syntax and the inevitable editing to get it in 100% shape.
1 Like
I love that idea for longer expressions Adrian. I will likely adopt it! 
1 Like
Or… I could make the expression field editors popups with a bigger editing area (like the sys-ex editor).
(logged here)
4 Likes
That makes sense. Would the user have to ‘OK’ and close window before testing?
Good question… normally yes, but I can see why this would be a pain. Let me think about it and whatever I do I might do the same for the sys-ex editor.
1 Like