Update: Whatever is causing the problem also sometimes crashes Cantabile. I have a song that does so consistently—I load the song, push the button for a rack-state-change, and Cantabile immediately crashes every time. But if I trigger the binding manually (by pushing its play button), everything works. It’s only when I trigger it via external MIDI input that it crashes.
I sent a crash report, but I’m worried that my example is quite far from minimal atm. (It’s a song with about 10 racks, 20 VSTs, and hundreds of bindings.) Should I try to pull things out one at a time to see if I can create a smaller example, or does the crash report already reveal the important code point?
Thanks for this info and for the crash report. I’ve looked at the crash report and have made a fix, but currently don’t understand why it’s happening - so I’d like to reproduce it here to properly understand it.
Can you send me full details (including any scheduling or routing mode settings) on just the binding that does the rack-state change?
I spent some time today ripping out every element of my bug-exhibiting test song piece by piece, until I isolated the following problem:
Create a rack with at least 2 rack states.
Add a binding from an external MIDI event (button press) to a target of Next Rack State.
Set the binding’s Enabled property to be rack state-controlled, and set the binding to be Enabled in rack state #1, but Disabled in rack state #2.
Trigger the binding via the external MIDI event while the rack is in rack state #1.
Result: Cantabile crashes.
Note that triggering the binding by pushing its “play” or “test” button does not induce the bug. Triggering the binding via an external MIDI event causes the crash.
Thanks for that. I reproduced this using your steps, but can you confirm that this only happens when the routing mode on the source is set to “Suppress”. In Continue mode it doesn’t crash.
Yes, I had the routing mode set to “Suppress” (but there were no other bindings, so the routing mode wasn’t actually impacting any other bindings).
I also ran into the following bug while testing: If I copy+paste a VST or rack (using Ctrl-C then Ctrl-V) to which there are named routes attached, the new copy gets route copies with the same names. Since route names are supposed to be unique, this puts the song in a weird state where actions on one of the route clones sometimes have erratic effects on the duplicately named routes (e.g., deleting one will sometimes delete the other). I think probably the route copies should be nameless by default?
So far everything works under 4171! (Even my older racks that weren’t behaving correctly have started working again.) So I think that fix nailed the problem. Thanks, @brad!
One more question if you don’t mind: In trying to understand the song-controlled rack-state issue, I’ve discovered that there’s also a checkbox in the Rack Properties that says, “Let the parent song control this rack’s selected state and gain.” How does that interact with the “State Behavior - Selected Rack State” checkbox that we talked about earlier? If one is checked and the other isn’t, what happens?
These are kind of the same thing, but from different perspective.
When “Let the parent” settings is turned on, the parent song can opt-in to control the rack’s state and the external gain slider for the rack is enabled allowing the song to control the rack’s output gain.
When “Let the parent” settings is turned off, this prevents the owning song from opting in to controlling these settings - the gain slider will be disabled and the Selected Rack State state behaviour is removed.
The “Let the parent” setting is intended for shared racks that you really don’t want the song messing with. Turn this option off and you don’t need to worry about configuring the behaviours and gain settings in any song that uses it.
Got it. Okay, so it sounds like I want to leave that checked, because I do want the parent song to (optionally) control rack-gain, and I can just opt-out of the parent song controlling rack state. It’s still a mystery to me how all my rack-states became parent-song-controlled, but at least I now know how to fix it when I see it.
I don’t know how to change the thread topic, but it could now be changed to “… [Solved]” if desired.
Thanks,