Not sure if anybody else has come across this issue:
recently, I often encounter situations where some bindings aren’t working on loading the song in a pre-loaded setlist. Typical candidates are bindings that connect cc64 (sustain) or aftertouch to a rack; when loading these songs via program change, the bindings don’t work. Loading a different song and then re-loading the song usually fixes the problem.
I haven’t really found any logic in the missing bindings; I suspect (but can’t say for sure) that it only happens when loading a song for the first time; and it only occurs sporadically; so it’s a bit of a scare – what if this happens in the middle of a gig?
I have finally found a reproducible one: in one of my songs (“Song 1”) there is a binding that sends channel pressure to my solo rack. This binding is active in state 3:Solo to send aftertouch to the solo synth. When I load this song stand-alone, this binding works perfectly. But when I have it in a pre-loaded set list, activate it either via program change or by clicking in the setlist, it does not work when I step to state 3: no aftertouch! Then I load a different song, go back to Song 1 – suddenly, aftertouch works!
Is this something you have encountered so far?`
ATM, I make sure to step through the whole set list before rehearsal or a gig, but that’s a bit of a pain - plus, really a bit scary, since I can never be 100% sure that my bindings will work correctly.
@brad: I sent you an email with some log files on this - not sure if you got it?
Out of interest, why do you need bindings to get sustain/aftertouch/etc into racks? Can’t you just do this with routes using suppress/allow? Or are you binding these messages to parameters, rather than simply feeding them into a plugin in the normal way? Either way, what you’re doing ought to be reliable, and for what it’s worth, I’ve never seen this problem.
Have you tried setting the routing mode to “Block until complete” for bindings triggered when you load a song, including any in your background rack? I usually use this to ensure song setup always happens sequentially in the order bindings are listed, rather than being potentially at the mercy of timings. Perhaps what you’re seeing is something related to this, where songs are being initialised slightly differently when loading stand-alone, as opposed to from the setlist.
Also, have you seen this happen in all your racks, or just certain ones?
to keep things clean, I only use routes to send NOTES to all my racks; I filter out all other controllers. Then, I use bindings to specifically send controllers like mod wheel, expression, after touch, pitch bend to individual racks. This makes my songs much easier to read and manage, especially with multi-zone splits etc… Plus, it gives me far more flexibility to change these bindings by state (route filters don’t react to states) - modwheel gets sent to string layer in state 1, to solo in state 2.
So, these bindings look like
MainKeyboard, CC 11 --> StringLayerRack, CC7, 0-127–>0-64 (control string layer volume via expression)
MainKeyboard, ChannelPressure --> SoloSynthRack, ChannelPressure, 0-127 --> 0-32 (send reduced aftertouch to solo synth)
Not sure if “Block until complete” makes any difference here; these bindings are not “triggers” but controller bindings. So it’s not about initialization; the controller data doesn’t reach the rack at all, no matter how often I use the respective controller
This is not dependent on racks; I’ve had it happen for my piano and string layer rack (sustain pedal wasn’t working until I reloaded the song) as well as for my solo synth rack (aftertouch wasn’t sent on first loading of the song).
I’ll have to check to verify, but I believe the activity “LED” for the respective binding does light up when I use the controller (e.g. aftertouch); data just doesn’t get sent to the binding target.
Aha. I send all MIDI data into my racks, but my racks have song-related rack states selected, which internally have a number of input routes, each of which allows only one type of data - note, sustain, mod, aftertouch etc, which I then enable/disable on a rack state basis. Same result, different approach, I think.
The “Block until complete” suggestion was any for bindings that are triggered on song load, or to actually select songs (e.g. in your background rack), to ensure consistent initialisation, rather than for the problematic bindings dealing with routing your controllers. But still, it was a bit of a shot in the dark, based on the observation that your songs behave differently depending on how they’re selected - the suspicion that something in the way your song is selected affects subsequent behaviour.
You don’t have jump prevention enabled on the bindings do you? I’ve had some unusual jump prevention problems in the past that happen when different controllers are mapped to something with jump prevention enabled.
The big difference to me is that I can easily use different controllers to do the same thing in my racks: sometimes I control rack volume via expression, sometimes via mod wheel, or with a slider on my masterkeyboard; sometimes this changes during a song (solo vs. verse). To do this via routes, I’d have to use a numer of routes with filters (which don’t respond to states, so I need even more routes and turn them on and off). Debugging of this is notoriously difficult, so I was super-happy when @brad finally introduced MIDI-to-MIDI bindings. My bindings page is my central “control matrix” - for each song state, I can decide which controller connects to what parameter within a rack.
To me, this logic makes most sense: I consolidate the CONTROL configuration (keyboards, key zones, controllers, …) at song level, whilst the racks are focused on generating SOUND, with no control or zone configuration. Keeps things nice and tidy…
I think our setups probably have similar complexity, but from different sides - I probably have more complex routing, and you have more complex bindings. My songs typically have few if any bindings - the bindings I use are all neatly encapsulated into reusable utility racks. I also have some utility racks with states for doing different types of controller mapping etc., which simplifies my routing too. But yes, my routing list is usually a bit complex, although I wouldn’t call it notoriously difficult - no more so than bindings anyway!
Anyway, this is getting way off topic - apologies for hijacking your thread with an aside! The great thing is that Cantabile allows such flexibility that completely different approaches can be used to achieve similar results.
My problem with assigning controllers via the routing list is that if I want to route my controllers separately, I need to do this all with filtering, which isn’t visible “from the outside” (just a little icon that filters are active), whereas on the bindings page, I see at first glance what is bound to what.
Sorry for slow reply - had a hectic couple of days.
I’m not aware of any issues there but want to look into this and get to the bottom of it if there is a bug. What would be the easiest way for me to be able to reproduce it? Can you send me the song/rack files and some steps to repro it?
Thinking about the general problem though - would a “bindings monitor” be useful for diagnosing things like this? Perhaps even combine it with the MIDI monitor somehow.
It would be really useful, if it provided a chronological log of binding events, but I can also imagine it getting quite cluttered with controller data in some situations, so being able to do some filtering on the log by binding type would be very valuable.
I did send you some specific song files, plus the logs for a reproducible situation - went to the contact@… mail address on Sunday - seems like you didn’t get it? I’ll send again to brad@…; hope it doesn’t get stuck in a spam filter!
I could also send you a ZIP/RAR archive of my song / racks / setlist folder if the logs aren’t conclusive. Just let me know.
For the record, this happened when a rack is activated for the first time in the same state transition as enabling a binding that refers to it. Basically the rack’s port weren’t created in time and the binding silently failed to connect.
I’ll check it out today.