I am using a simple 4 switch controller to change states to previous and next and also to use transport controls. This stompbox is connected to Boss GT1000 and upon hitting the switch, Boss sends a CC message (configured to specific switch) via CME WIDI dongles to my computer.
I have set up Cantabile to listen to these messages and, for example change state to next state when it receives CC#1.
Then, in my bindings I have a binding with source ‘On State Load’ and targeting WIDI out port on device specific channels - this binding is there to send PC messages back to guitar gear to change patches. I also have transport specific bindings and some other things - approximately at least 16 bindings all together on any song. In routing I usually have 2-3 embedded racks and a few media players along with occasional vst-effects.
I have been experiencing a notable latency on this rig when it comes to guitar patches changing based on state changes when using this configuration. I have been in contact with Roland to troubleshoot GT1000 and while it seems to have a little bit of latency when changing patches through it’s midi block (versus changing with device’s own switches) it is not the only problem here.
In short, I started debugging my Cantabile configuration and found out based on the logs that from receiving a CC message to sending out a PC to GT1000 takes around 110-125 milliseconds. It looks like state changes to bindings and binding groups and some other stuff are all handled first and then the PC finally gets sent.
Is there a way to prioritize or sequence bindings in a way that would allow for me to handle midi messaging first and then continue on other state updates? Or am I misunderstanding something here?
Bindings are processed in the order they are listed and you can apply delays to them if needed to make room for issues like yours. So I would place the bindings you want processed first at the top of the list and add delays if needed.
I get that bindings are processed in order, but if logs give any true indication of execution the outbound midi program change message (this binding is topmost of state bound bindings) is sent only after all bindings are processed. I don’t think adding delays will help with the latency problem either.
I would just need Cantabile to send midi pc out as soon as possible, otherwise the latency from Cantabile handling the bindings’ states and gt1000 midi handling will add up making this kind of manual control somewhat unusable.
At this point, I have to count in the latency and when for example using transport to change states - I have to set the triggering point somewhere in the previous bar so that patch changes are handled in timely manner. This is of course most notable when changing from clean to distortion and vice versa.
Have you tried changing the binding delays (the little clock icon next to each binding in the bindings pane) to “Nothing (simple pre-delay only)” and uncheck “Pause song and state load operations until complete”?
When a binding doesn’t need to fire in any particular order relative to other bindings (e.g., you just want to get that PC message out the door as fast as possible), I’ve found that these settings make my bindings fire much faster. The effect is particularly significant when state changes are involved, since otherwise Cantabile tries to ensure that everything that happens during the state change is fully “finished” before it moves on to bindings.
You might also try changing the PC-send binding to be triggered by the incoming CC message instead of by the state change. That will prevent it from waiting for the state change before sending it.
And if you want a nuclear option, here’s what I do when I want maximum speed: I abandon bindings entirely and use route filters. With the right filters you can transform a CC message directly into a PC message. This causes it to be sent as fast as your audio cycle allows without waiting for bindings to process.