Possible bug in triggers?

[Torsten]

@brad: I’m currently in a pretty complicated setup, and it looks like specific trigger events aren’t quite doing what they’re supposed to.

I have an embedded rack (called “Guitar Return”) set up that reacts to CC66 sent to it and sends out state-specific triggers:

In this specific case, it should trigger event #0

Now I’ve got the corresponding bindings set up to set specific states in two racks upon receiving this trigger.

So after receiving the trigger, rack “Guitar 17” should be set to state 2 and rack “Guitar FX Routing” should be set to state 1.

When I execute these bindings manually (clicking the triangle), this works fine; racks get switched.

But when I try to execute them by sending CC 66 to the “Guitar Return” rack, the "LED"s on both of the trigger bindings light up, but the racks don’t get changed. So even though the trigger events seem to reach the binding, the action doesn’t fire.

Hope this can be fixed - can I do anything to help identify the problem?

Thanx & cheers,

Torsten

[Torsten]

Just as a quick addition: I tested the same bindings to react to a program change instead of the “specific trigger”, and they worked nicely. So there seems to be something broken with the “on specific trigger” source - or I’m doing something wrong here?

Anyone else working with the “On specific trigger” binding?

Cheers,

Torsten

[Juergen]

tested >> it’s a bug…

with next state it works… no problem

[brad]

Hi @Torsten. Are you running 3272 there was a fix for this.

(although there’s a typo in the release notes, it should say:

Fixed - using indexed trigger as a source binding failing

Let me know if this is a different issue.

[Torsten]

Hi @brad,

yes, I’m running 3272 - and I’ve got things working now after some crazy experimenting.

But there seems to be something really weird going on with this setup - I’ll need to elaborate a bit, so I recreated a simpler version of my problem in a demo file. It consists of three racks:

The first (Guitar OnPedal) waits for CC66, then depending on its state either raises a trigger (#7) to set the guitar rack (Rack 4) to a lead sound or it sends another CC66 to the next rack (GuitarReturn) to then return the guitar sound to its original state.

The GuitarReturn rack contains just a binding that waits for CC 66 and then raises a state-specific trigger to return Rack 4 to a preset sound. So for its first state, it should send trigger #0, for the second state trigger #1 etc.

Now I set my Rack 4 to its third state and repeatedly press my soft pedal. The Guitar OnPedal rack dutifully switches back and forth between its two states and also sends CC66 to the GuitarReturn rack:

In the Guitar OnPedal rack bindings page, the LED for the binding lights up, so the trigger should be raised; also on the song leven bindings page, the LED lights up as well:

(both “State” LEDs turn green)

But Rack4 stubbornly stays at State 3.

Now it gets interesting:

• when I manually trigger the binding on the song-level bindings page by clicking the triangle, Rack 4 dutifully turns to State 1
• when I manually trigger the binding within the GuitarReturn rack, Rack 4 changes state correctly
• when I manually trigger the binding within the Guitar OnPedal rack, Rack 4 changes state correctly
• when I connect the Main Keyboard to the GuitarReturn rack instead of through the Guitar OnPedal rack, Rack 4 changes correctly

So it looked like somewhere between the Guitar OnPedal rack and its successor, something goes wrong, even though all optical indicators (MIDI monitor, Binding LEDs) signal that things are happening correctly. I suspected this was due to the fact that the Guitar OnPedal rack changes its own state on receiving CC66 and possibly messes up the routing.

So I changed the state-switching binding in the Guitar OnPedal rack to “Load State by index (delayed)” instead of “instant”. And suddenly everything works - Rack 4 dutifully switches back to State 1!

So - to cut a long story short: it looks like even though both the MIDI monitor as well as the bindings LEDs indicate a correct transmission, the state changing of the OnPedal rack (and the deactivation of the binding that sends CC66 to the GuitarReturn rack) interrupt the flow of the message that was sent before the changing of the state. Not sure why the state change should interrupt a CC message that has already been sent (and that shows on a MIDI monitor) and why the binding LEDs should flash but the actual binding not be executed??? Maybe some crazy multithreading issue?

I’ll send you the song file via email - maybe you can find some logic here…

Plus one annoyance I found while editing: when I change one of the problematic bindings’ target from “instant” to “delayed”, suddenly this changes the source from “Controller (No Edge Button)” to “Controller” and messes up the “value” column on the target side when I change it back to “Controller (No Edge Button)”. Maybe also something for the bug fix list?

Cheers,

Torsten

[Torsten]

@brad: here’s another interesting trigger scenario:

I’ve set up a test song with two (empty) embedded racks, each with three states.

Now my bindings page is set up to react to key C4 on the on-screen keyboard:

• set the state of rack 1 directly to index 3
• then raise trigger #0
• on trigger #0, rack 2 should also be set to its third state.

Now when I press C4, I’d expect both racks 1 and 2 to change to their third state. But only rack 1 changes. But when I press C4 again, rack 2 changes as well. But if I change rack 1 back to state 1 between the first and second press of C4, rack 2 does NOT change - so it seems that changing one rack’s state somehow changes something inside Cantabile so triggers don’t reach their destination…

OK, this is some pretty fancy-shmancy binding and trigger wiring, I’ll concede. But in the heat of the battle, I need triggers to work reliably; current state is somewhat dodgy…

I’ll send you this file as well - hope you can find what’s going on here!

Cheers,

Torsten

[Alexander]

Hi!
@brad …just tested build 3273 bug is still there
Key is changing one rack state at a time (routing mode is set to continue)

kind regards

[dave_dore]

Hi Torsten,

I too am having trouble with the Specific trigger function on a rack or two I am working on. What happens to me is that I have 2 media players that both start on any key press, when they stop they send two specific triggers (#0 for media player 1 and #1 for media player 2) to reset the states in 2 other different racks. The tape players have identical length files so they end together and roughly send the triggers together. The problem is only one of the triggers is honored and the other does not change as expected. I played with adding a delay to one of these triggers and with over 150 mS it started to trigger both state changes in the 2 racks. So my gut is telling me the conflict is centered around C3 trying to process multiple triggers at roughly the same time. Thanks for posting about this, I was unsure how to explain it but you did a good job of bringing it out to look at. I hope @brad can figure this one out. By the way, these comments are based on latest 3273 release.

Dave

[brad]

Thanks guys… going to take a look at this right now.

[brad]

OK. I’ve made a fix for this will be 3274.

The problem here is the bindings mechanism trying to prevent re-entrant state changes. eg: you invoke one state change, the plugins are loading and before they’re finished another state change happens which causes another state load at the same time. I probably need to clean up this area a bit to make it more precise but I’ll do that after code freeze is over.

BTW: @Torsten gets the prize for best ever bug reporting… that song file made it a snap to repro.

[dave_dore]

Checked this new build on my problems and it appears to be successful. Thanks for that @brad!

Dave