I’m currently on Cantabile Performer 4064. I tried upgrading to 4140, 4150, and 4160 today but all of those versions broke a lot of my bindings so I had to downgrade back to 4064. Is this a known problem?
The bindings that seemed to break were those that have a MIDI route Enable/Disable as their source, and a rack output port CC value as their destination. (I have a lot of those in order to change controller lights when MIDI routes turn on/off.) On Performer versions past 4064, those bindings seem to momentarily send the “Enabled” value, but then immediately send the “Disabled” value all the time, so that the light never turns on for more than a brief moment. Even pressing the “Test” button doesn’t seem to work properly for those bindings—it seems to send the “Disabled” value even when I want it to send the “Enabled” value.
I’m not completely sure what’s happening because some of my other bindings from different MIDI Enabled/Disabled sources seemed to be turning the wrong lights off/on. It almost seemed like triggering some bindings caused other bindings to “wake up” and realize they had sent the wrong values previously. Downgrading back to 4064 fixed everything for now.
I think there’s still an unfixed bug related to “Resend Bound Values” binding targets in versions past v4064. In particular, it seems like “Resend Bound Values” now often sends “old” CC values instead of the most recent CC values sent by the rack.
It’s hard for me to diagnose this bug because I’m not sure I have a correct understanding of how “bound values” are supposed to work. Maybe the more experienced members of the community can help me out by clarifying. Here’s my (possibly wrong) understanding:
Whenever a rack sends a MIDI CC value to a rack output port, Cantabile remembers that port’s CC’s value in its set of “bound values” for the port. Then, when a binding with target “Resend Bound Values” is triggered, Cantabile resends all the “bound values” for all the rack’s output ports. Is that correct?
In versions past v4064, it seems like the set of “bound values” is not updating properly, causing “Resend Bound Values” targets to send “old” values. This might be related to something wrong with song/rack states. I thought (but perhaps I’m wrong?) that “bound values” were not state-controlled. But after v4064, it seems like changing the song state reverts the rack’s “bound values” to an old, state-specific set of remembered values.
Is that the intended behavior? If so, is there a way to turn off state-control for bound values so that I can make my racks work the same way they did in v4064 and earlier?
My understanding is that resend bound values applies to any continuous controller Source that is Bound (in a binding). So that means Cantabile sliders. It doesn’t apply to Song or Rack “OnLoad” type bindings that send fixed values. To resend those you use the Re-invoke Load or Re-invoke State load bindings. I assume your bindings all have a slider as the source? Maybe show what you have in the rack bindings that is giving the bad result.
FWIW I gave a quick check on 4168 and it does send updated values on a resend here.
Thanks, Dave. This is really useful info. I didn’t know “Re-invoke State Load” existed (is that part of the new bindings system after 4064?), and I didn’t know that “Resend Bound Values” only resent values previously sent by bindings with non-state sources.
That’s not how it worked in v4064 and before, since my racks worked just fine in 4064 with only “Resend Bound Values” as targets. Is it an intentional change?
To clarify: My bindings send CC events in response to many different source events, including Rack State On-Load, MIDI Route Enabled/Disabled, VST parameter changes, input CC events, etc. It used to be that “Rsend Bound Values” resent all the CC values sent by bindings in response to all those sources.
So in order to get the pre-4127 behavior, I guess I need to find every binding that targets “Resend Bound Values” and make a second binding from the same source to also target “Re-invoke State Load”. That way all the values will actually be resent. But does “Re-invoke State Load” trigger all “On Load” bindings–even the ones that don’t merely send CC events? I don’t want to do that. I just want to resend all the CC values (to reinitialize my external controller display) without doing the other things that happen when a state change occurs.
I thought that that was how it always was but if you can show me an example of it working that way I would be better informed. For me Resend bound always applied only to continuous sliders. Triggered value sends like song state loads and song loads were never part of resend bound. State changes like state on load values also were not available for resend. As I recall Brad added the re-invoke options after some requests from some of us. Maybe I missed a period where it did work that way so at this point since we have different results @brad might be able to help explain the chronology.
I understand and as I said Brad might have to explain this.
No, only bindings where there was a CC event value to send but not local Cantabile based commands.
I believe that you can accomplish that but would need the extra bindings you spoke of added to cover what resend bound isn’t covering.
Update: I’ve been able to reproduce this bug without using “Re-send Bound Values”, so whatever is going wrong in versions past 4064 is not specific to that binding target.
Here is an example of a set of rack bindings that works correctly on 4064, but that malfunctions on all versions past 4064:
Explanation: This rack supports an external controller with four illuminated buttons on CCs 71-74. Sending a value of 44 lights the button, and sending a value of 36 dims it.
The first four bindings (green box) cause pressing button n to switch the rack to its nth rack state.
The next four bindings (yellow box) cause the nth button to light up when the rack is in its nth state (and make the other buttons dim). Their targets are all rack state-controlled; the picture shows their targets when in the 1st rack state (so CC 71 gets sent value 44 and the others get sent value 36). If I switch to the 2nd rack state, the targets change so that CC 72 gets sent 44 and the others get sent 36, etc.
The final four bindings (red box) do the same thing as the yellow box, except that they respond to an incoming message on CC 127, which is how the song containing this rack asks racks to re-initialize the external controller. (I probably could have used a single binding with a “Re-invoke State Load” target, but I didn’t know about that when I made this rack.)
The song containing this rack uses song states. Each song state allows one rack to “take control” of the external controller. It does so by ignoring the MIDI outputs of the other racks and only routing one rack’s outputs to the external controller. When the song state changes, the song turns off all lights on the external controller, and then sends CC 127 to the rack that is taking control, triggering the bindings in the red box, which turn on the appropriate lights.
Test Procedure: To test these bindings, I take the following steps:
Start in rack state 1, song state 1. (The first button is lit, the other three are dimmed.)
Push button 3. (Rack state changes to 3rd state. First button dims and 3rd button alights.)
Switch to song state 2. (All lights clear.)
Switch back to song state 1. (Different behaviors before and after v4064.)
Expected Behavior: On v4064 and earlier, step 4 correctly lights button 3 and dims the others. This happens because switching song states sends CC 127 to the rack, triggering the bindings in the red box.
Observed Behavior: On all versions after 4064, step 4 causes the 1st and the 3rd buttons to light up. It’s as if Cantabile is triggering some of the bindings in the wrong rack state, even though the rack state never changes on steps 3 or 4 of the test procedure. When I look at the MIDI monitor, the results are even more confusing. I see the following CC outputs:
CC 72 → value 36
CC 73 → value 44
CC 74 → value 36
CC 71 → value 44
CC 72 → value 36
CC 73 → value 36
CC 74 → value 36
It’s as if Cantabile is triggering some (but not all??) of the bindings twice, once in a wrong rack state and once in a correct rack state. But for some reason it never triggers the binding for CC 71 twice. No idea why.
Thanks for taking a look at this. I indeed want to create an MRE for you. I think I need to first better understand what is “intended behavior” and what isn’t, so I know what to remove to get to an MRE that isolates the problem.
After some more testing, I’ve discovered that at least part of my problem is that changing song states always now triggers all my Rack State OnLoad bindings. I don’t think that was the case on 4064 and earlier, correct?
To reproduce this, I do the following (on Cantabile Performer 4168 x64):
Create a fresh song and add a fresh embedded rack to it.
Create two song states.
In the rack, create a binding from Rack State OnLoad to Transport-Play/Stop-Toggle.
Create two rack states.
Switch song states without switching rack states.
Expected outcome: The transport should not toggle, since the rack state has not changed.
Actual outcome: The transport does toggle (though the rack state does not change).
Is this a bug, or is this just intended behavior that I never noticed before?
The State On Load bindings fire whenever the state becomes active - either because the containing song/rack is loaded, the audio engine is started or the state is changed. The behaviour you’re describe is correct and I believe unchanged from older builds.
The Resend Bound Values binding point doesn’t resent the last sent controller value. Instead it only applies to bindings that are mapped from a readable source value (eg: a gain setting) to a target value. The resent value is the value re-read from the source (ie: the current gain value).
The Re-Invoke State Load binding point re-invokes all On Load bindings.
I hope this helps. It definitely looks like something weird is happening with your setup but without reproducing it here, I can’t really say.
Thanks, @brad. That helps me narrow down what I should be looking for. I think maybe I’ve figured it out. Here’s what I’ve discovered:
When I load songs created prior to 4064 into newer versions of Cantabile, their rack states get set as song-state-controlled. This was causing the problem because the rack state was suddenly changing whenever the song state changed, which was triggering the rack-state-onload bindings at unintended times. When I de-select the song-state-controlled checkbox for rack states for all of my linked racks in my songs, the problem disappears.
When I exit Cantabile 4168, it appears to save everything (e.g., rack and song changes) automatically. This was confusing me because I previously could exit Cantabile without saving in order to “undo” all my temporary changes. Is there a way to exit without saving anything?
Just to clarify: In my testing, I do not see Rack State On-Load bindings get triggered when the song state changes but the rack state does not. They only trigger when the rack state actually changes (e.g., because the rack state is song-state-controlled, and the song state change results in a rack state change).
Not to derail the thread, but i’ll also chime in with a wish for being able to exit Cantabile without saving edited racks. I often find myself using Windows to make a copy of the (unedited) rack, exiting Cantabile, and overwriting the newly-saved rack with the original.
– Jimbo
PS @Brad If i recall correctly, this also applies to exiting a song, where a linked racked referenced by the song will have any changes (inadvertent or otherwise) saved.
The behaviour of this setting shouldn’t have changed between pre- and post-4100. Do you have a reproducible example of a problem here?
Again nothing here has changed pre/post 4100. The behaviour has always been:
Songs may or may not prompt to save depending on settings in Tools → Options → General → Save and Load. The default is to prompt so usually if the song has changed you will be prompted to save. If the song is in a preloaded set list, the prompt won’t happen until the set list is closed or preload turned off.
So far, all of my songs that I’ve checked are so affected. Every rack in every song now has its rack states marked song-state-controlled. But creating a reproducible example won’t be easy because now I don’t know which version of Cantabile did it due to the autosave feature. I tried every version between 4064 and 4168 over the past few weeks while trying to find one that worked for me, and I didn’t know that Cantabile had started to re-save all my racks every time I exited even if I said “No” to the song-save prompt. That means pretty much all my racks got updated with the new setting somewhere along the line, but I don’t know when.
The “Save Rack on Unloading” option looks like it’s per-rack. Is it also per-rack-instance (for linked racks) in each song? If so, does that mean that the only way to stop Cantabile from autosaving racks on exit is to go through every rack instance in every song and set them to “Never” one at a time?
Are you referring to this Selected Rack State rack behaviour? That has always been enabled by default, so I’m not sure what you’re saying has changed?
Yes it is.
No, the same setting will be used for all songs that use that rack.
Yes - which sounds painful but has never been raised as an issue before. Very, very old builds of Cantabile used to prompt to save racks, but it got very tedius, very quickly hence the approach now used.
Yes, that’s the checkbox I’m referring to. My songs had that checkbox unchecked for almost all of my racks. But now when I load old songs, the “Selected Rack State” checkbox is checked for every rack in every song. When I uncheck the box, save the song, and then restart Cantabile, it (correctly) remains unchecked. So I’m assuming that some version of Cantabile between 4064 and 4168 must be changing that option when loading old songs. Either that, or it’s interpreting that option differently so that versions 4064 and earlier behave differently than later versions. Because when I was on 4064, my songs all worked; and when I load them into 4168 they don’t work until I deselect that box.
I indeed never remember seeing a prompt to save racks (my Cantabile experience doesn’t go back that far). However, I often fire up Cantabile, make a bunch of changes to a song and its racks, then decide I hate everything I just did, and just exit out without saving. I thought that when I clicked the “close without saving” button at the prompt on exit, that resulted in no saves to songs or to the racks within them. But since it does save the racks (without saving the song), that means I’ve been inadvertently saving my experimental changes to racks, making it hard to now “go back” and replicate whatever sequence of events manifests the above bug.
I don’t know whether other Cantabile users would agree, but I would certainly benefit from having more ways to “escape without saving” (especially as Cantabile gets more complex, and my susceptibility to error increases). Two ideas:
On exit, I wish there was a prompt-option for “don’t save anything (including racks)”.
I wish the new Bindings editor window didn’t commit its changes immediately, and had an OK and Cancel buttons at the bottom. That way if I start to create or edit a binding, and then realize this isn’t going to work, I can just hit Cancel. This would also solve the problem that sometimes a half-created binding will trigger before I’ve had a chance to set all its fields correctly, causing weird side-effects that must be manually tracked down and undone. Having an OK button that commits the finished binding in one step rather than incrementally as the widget fields change would solve this.
I can’t recall any changes in this area and I just created a test in 4064 with it turned off, opened it in 4168 and it was still off. I suspect there must be something else going on there.
Do you have a copy of a song/rack that works in 4064 but not in 4168 that I can repro the issue with and work out what’s going on?
OK, let me have a think about it. The problem is that since racks save automatically on unload it might cause some confusion if there’s an option to not save racks on shutdown, but a previously loaded/unloaded rack was already saved.
I did have numerous examples, but then the rack autosave feature overwrote them, so I’ll try to recreate one of them for you. (But I need to wait a week because have a couple of gigs coming up and I’m scared to switch Cantabile versions until those are over.)
Speaking purely from a user perspective, that wouldn’t confuse me. Most software (e.g., Word processors) save at various times for various reasons, so when I click on “don’t save” at a program exit prompt, I assume it’s only affecting what gets saved right now, not what may have gotten saved previously.
Testimonial: By the way, I think Cantabile is a brilliant piece of software. It’s really helped me improve my musical skill because it lets me customize absolutely everything to be the most intuitive to me, freeing me to focus on my musicianship during live performance. There’s really nothing else like it on the market. So thank you for creating and maintaining it.
