Fixed for next build.
1 Like
Build 4120
- Fixed crash when selecting “Adjust Transpose” binding point
- Fixed Learn button not updating all source binding point fields
Here: https://download.cantabilesoftware.com/SetupCantabile-4120.exe
3 Likes
Thanx @brad - now my Adjust Transpose works!
Here’s a new gremlin: in my songs, I have a bindings group that fires on “StateChange” to start scrolling for LivePrompter - sends out a couple of CC messages to activate scrolling on different connections
I use the “Enabled” state property for the group “Prompter Start” to select on which song states these bindings should trigger. So the three bindings within the group always stay on; just the “Enabled” for the group changes by state.
With build 406x, this works nicely; with 41xx, however, nothing happens - no MIDI messages get triggered. Looks like there’s something messed up with the processing sequence of groups vs. bindings: in this case, on a state load the “Enable” for the bindings group needs to be processed first to enable the group, then the individual bindings within the group need to fire for the state load. But this doesn’t seem to happen.
Another indication of something going wrong: when I enter the state with the bindings group set to “enabled”, the three sub-bindings stay “grayed out”:
When I un-check and re-check the “enabled” box for the group, they become white again - but now they fire on every state load, even though the group is disabled for all other states.
So it looks like the enabling and disabling of binding groups via song states is broken…
Aaaaaand another one: on my StreamDeck, I have two commands that have stopped working in 41xx: Update State and Save Song. Both are based on the “Invoke UI command” action - is the new binding system sabotaging this action?
Hi Torsten,
Thanks for reporting… both issues fixed in build 4121:
Brad
5 Likes
Just copying the latest download link to keep them all in this thread:
(fixes MIDI channel 16 missing - see this thread)
3 Likes
Question to @brad: is it possible that the new binding system is affecting the performance of state changes?
In most of my songs, there are a couple of instruments that stay pretty much unchanged over the course of my song, and state changes shouldn’t affect them at all. But since upgrading Cantabile to 41xx, I get state changes affecting MIDI notes coming in to these instruments massively - playing an 8th note ostinato through state changes creates some very ugly hiccups; looks like these state changes now delay MIDI routing to un-affected instruments - like the bindings triggered by a state change are now somehow taking priority over note routing.
Can you please check this and (hopefully) get things back to normal again? I have gotten very used to using state changes to drive sound (and light) changes while playing, and having my playing thrown out of whack is really annoying.
Having to revert to pre-41xx would be a bit of an annoyance as well - since upgrading to 41xx, I’ve tweaked a number of my songs and racks; wouldn’t like to go through all that again to go back to pre-41…
Hope you can help here!
Cheers,
Torsten
Hi Torsten,
Thanks for reporting - I’ll do some testing and see if I can figure it out.
In the meantime, if you’ve got time, could you send me a debug log:
- Go to Tools -> Options -> Diagnostics and turn on Log MIDI In events.
- Close Options
- Reproduce the issue
- From the Tools menu, choose Open Settings Folder.
- Close Cantabile (important)
From the folder opened in step 4, send me log.txt.
Brad
OK, log sent!
Hi @Torsten,
Still investigating this but maybe narrowing in on something. I’m wondering if this is related to Cantabile’s route manager instead of state switching.
Could you test something for me: does this happen if instead of switching states you just enable/disable an arbitrary unused, but connected, route?
eg: create a dummy route from an input port, perhaps with an unused channel to any plugin/rack and then toggle it on/off while playing and see if causes the same stalls as the state switches.
Brad
OK, did the following:
- created a route from my upper keyboard to my organ rack, named it “Organ Route”
- created a binding from the lowest note of my main keyboard to toggle the “Enabled” status
- played a chord ostinato while repeatedly turning the route on/off via the lowest key
Result: no hiccups, also no “busy” cursor when switching (when switching states, I do get the “busy” cursor for a short time, which may I suspect is the time my notes get delayed)
Next, I went for something more ambitious and used a route on the keyboard I am actually playing: created a binding that switches the route to my Organ rack on my main keyboard on and off while I am actually playing the main keyboard.
Result: no problem at all; organ layer turning on and off nicely during my ostinato playing, with no hiccups or stalls - and no stuck notes 
So turning routes on or off seems to be innocent.
Cheers,
Torsten
Addendum: I just tried this with a brutal strip-down of all state-based automation (removed all state behavior from racks and routes, even created an empty Background Rack and activated it), then stepped through my states. Of course, state changes are now quicker, but even then, I get
- “busy” cursor during state switching (just shorter duration of this)
- the occasional hiccup when a state change happens to hit a note. Less of a delay than previously (of course, since state changes are quicker
So it looks like the state change suspends processing of incoming MIDI notes until it is done making all changes that are driven by song state (or even when there’s no change to be made at all to the configuration beside the “song state” status changing). That would explain my ostinatos being thrown out of rhythm.
It would be better if the configuration changes driven by state changes were queued and processed in parallel to normal operations continuing, instead of holding up normal operations (that shouldn’t be affected by the state change, e.g. playing of notes on routes and racks that don’t change) until they are done.
Am I making sense?
Hi Torsten,
Thank you… that’s all good info. The hour glass happens on every state/song load - its just hard coded to do that, but the state loading shouldn’t take priority over audio/midi processing.
I’ll keep looking into it tomorrow.
Brad
To be sure: audio processing is not interrupted during state switching - held notes and effects stay active; just any new MIDI notes generated during the state change get affected.
Quick update: pretty sure I know what’s going on here. I’ll try to get an update in the next day or so.
5 Likes
Hey @Torsten
I’ve just put up build 4123 which hopefully should address this.
To explain:
In reworking the bindings I incorrectly decided to make all load song/state bindings block incoming MIDI until the load had finished and removed the “Suppress and Block” routing mode. In retrospect this was a poorly considered decision on my part - especially since I think the blocking option was rarely used.
To rectify this, I’ve updated the load song/state bindings to have a new option “Block MIDI” which is off by default. When enabled and when the binding is invoked from a MIDI source any following MIDI events are blocked until the load finishes.
The idea behind this blocking mode is to allow sending a MIDI program change (to load a song/state) followed immediately by other MIDI events to the newly loaded song for configuration without having to introduce arbitrary changes.
For the moment at least the routing mode blocking option won’t be upgraded from pre-41xx - I might add it later, but for the moment just wanted to get you a fix for the current problem. Let me know if it helps.
Brad
5 Likes
Hey @brad,
I’ve just given this a quick test: installed 4123, checked my background rack for the relevant binding - looks good to me - no blocking:
Now used the same test song as previously, played my ostinato while switching state - unfortunately still getting thrown off-rhythm by state changes…
Tried this with “block MIDI” set to “Yes” and “No” - no discernible difference to me.
Sorry to be the bearer of bad news, but this build didn’t fix it.
Hi @Torsten,
Thanks for the update… hrm I was pretty sure it was going to be that. I’ll take another look at it in the morning.
Brad
ahaaaaaa - much better now!
What did you do for this version?
4 Likes