Cabbage Logo
Back to Cabbage Site

Non-latched buttons & automation

I’m experiencing unexpected and annoying behaviour of non-latched buttons when handling automation in Ableton Live and Reaper. A test example is below. It basically only has some latched and some non-latched buttons. I export vst instrument and try to expose the automation lane/envelope for any button.

Ableton Live: click on a non-latched button, envelope is exposed, hover mouse over (without clicking) any non-latched button, envelope is exposed - this is not happening for any other widget (test with latched buttons).

Reaper: use “Show/hide track envelope for last touched FX parameter” to expose the envelope. In Trim/Read automation mode non-latched buttons can become “latched” - even after clearing automation. I’m not quite a Reaper power user, but something seems strange.

The problem with this seems minor at first, but when you have a lot of widgets and you accidentally pass the mouse over a non-latched button it will expose its envelope instead of the intended one. It makes it difficult to map (learn) MIDI controllers and I suspect something else is amiss in the guts.

Something seems wrong with how communication between the non-latched buttons and the host is handled or am I missing something? Tested with Cabbage 2.8.120

And I though I’d mention another strange behaviour, which might be related or not: having a radio group of non-automatable buttons (B) and a slider (S) updating B - not in the example below. Reaper automation of S resulted in situations when multiple B remained ON. I could restore normal radio group behaviour by clicking on the buttons. It seems this happens when the plugin is not visible (its GUI is not open).

form caption("latched vs non-latched buttons") size(400, 100), colour(58, 110, 182), pluginId("tlvn")

button bounds(76, 24, 80, 20) channel("NL1") latched(0) text("nonLatch1", "nonLatch1")  colour:0(100, 80, 0, 255) colour:1(255, 255, 0, 255)  fontColour:1(0, 0, 0, 255)  
button bounds(166, 24, 80, 20) channel("NL2") latched(0) text("nonLatch2", "nonLatch2")  colour:0(100, 80, 0, 255) colour:1(255, 255, 0, 255)  fontColour:1(0, 0, 0, 255)  
button bounds(254, 24, 80, 20) channel("NL3") latched(0) text("nonLatch3", "nonLatch3")  colour:0(100, 80, 0, 255) colour:1(255, 255, 0, 255)  fontColour:1(0, 0, 0, 255)  

button bounds(76, 56, 80, 20) channel("L1") latched(1) text("latch1", "latch1") colour:0(100, 80, 0, 255) colour:1(255, 255, 0, 255)  fontColour:1(0, 0, 0, 255)  
button bounds(166, 56, 80, 20) channel("L2") latched(1) text("latch2", "latch2") colour:0(100, 80, 0, 255) colour:1(255, 255, 0, 255)  fontColour:1(0, 0, 0, 255)  
button bounds(254, 56, 80, 20) channel("L3") latched(1) text("latch3", "latch3") colour:0(100, 80, 0, 255) colour:1(255, 255, 0, 255)  fontColour:1(0, 0, 0, 255)  

-n -d -+rtmidi=NULL -M0 
ksmps = 32
nchnls = 2
0dbfs = 1

instr 1

i1 0 z

No time to look into this tonight but I’ll take a look tomorrow :+1:

While I couldn’t recreate your issue (due to me being a DAW moron) I did look through the code and you’re right, something it not right there. Just working on a fix now…

Just pushed a fix now. I’ve tested it in reaper and it seems to work fine now. Can you test and let me know?

Thank you Rory.

It seems to behave fine in Live but not in Reaper.
While the envelopes do no longer get selected just by hoovering over the non-latched buttons, the non-latched buttons are now latching in Trim/Read mode - see screen shot. This doesn’t seem right behaviour? Please try pushing the buttons after you have exposed their envelopes.

Is there anyway you can record a short video of this for me? For me it seems to record the gestures/automation fine now?

btw, in reaper I have to set the mode to touch, latch or write to record any automation?

Here come the video.
I have it in Trim/Read mode and use the action to show last touched. After I have the automation lanes, non-latched buttons are latching. Maybe it is something in Reaper that I am not doing right?

In reaper you have to select write mode in order to capture automation, and even then it will only be captured if you start recording? Btw, what version of Reaper are you using?

A different “hidden” bug in Live results now. Paradoxically, I can use CSOUND_GESTURES in Reaper but not in Live. It kind of worked before the fix in Live. :thinking:

While my simple example above works fine in Live, a more complex instrument doesn’t. It remind me of previous experience with this. It seems like csound broadcasting is scrambled, some sliders not getting through, some getting through with wrong channel names (automation lanes), very confusing to describe, so here are two episodes to watch :wink:

I’m saving presets on the fly, then I record automation with gestures ON, then turn OFF gestures and stop recording. Deleting automation for preset selector buttons … in the first example you can see automation for non-intended widgets being made up (random?), in the second example similar but a no-change is recorded for other widgets, in both examples no intended automation is recoded… I’m pretty sure if I repeat this all possible combinations would come out. :exploding_head:

Sure, but I’m not even trying to capture automation in the Reaper video example. Just exposing the envelopes, so they could be edited manually for example. But the latched non-latching buttons seems off, not expected. Reaper v6.61.

After looking some more into Reaper, I think it behaves normally. After exposing automation, the button state is governed by automation lane and no longer by widget input. I apologize for my ignorance!

In the case of Live, however, CSOUND_GESTURES seem to not work properly (again). I suspect the “wrong” channel recording/detection might be related to some internal delay. if I remember correctly, you have included some delay to make gestures work in Live?

The no-change recording is probably expected, since I’m loading all channel states saved in a function table when I push the preset button, including those which did not change. But not all channels get recorded - note the two sliders that should be recorded but are not in the video. If I keep switching presets, more and more channels get recorded, so it seems Live has a limited time frame to hear Csound gestures (too short or too delayed or…?). I believe it worked OK before the non-latched button fix though. Thank you for being so patient with my obscure gestures fixation!

But I think there was clearly an issue in the way os worked before. A mouse over gesture shouldn’t trigger an automation update message in the host. Does your simple example show the same problems in Live?

Yes, I meant apart from the mouse over issue, which is nice to have resolved. The simple example works fine, but there is no gestures there and even if I have them it still works fine, so I suspect it has to do with a large amount of gestures triggered by my presets. This is Live specific though, or at least it works fine in Reaper. I could test with more widgets, but I was hoping you might be able to infer something by looking at how gestures work in Live?

I know we put in some live specific fixes for this before but I can’t see how the non-latched button fix has any effect on it. It would be great if you can get me a sample .csd that shows the problem? Your instrument is a little complex for testing purposes.

OK. I’ll try to come up with a test.

1 Like

I did some more tests on my large instrument (video above) in Live.

By gradually removing widgets I come to the point where it works fine. There seems to be a limited number of widgets that CSOUND_GESTURES can handle in Live (about 90). No matter which widgets I add/remove or if I rename them, the limit seems to be what is braking the functionality. And one more interesting thing: if I load the plugin by initializing CSOUND_GESTURES = 0 instead of 1, and set it to 1 after it has loaded, then it seems to work regardless of the widget count!?

Does this give you some idea?

I’m glad you found a workaround. I’ll take a look to the source code and see if I can find what is causing the problem, very strange, I don’t think there’s any hard limit to the number of channels.

Thanks! It is not really a workaround … Meanwhile I’ve tested a simple instruments with gestures and many channels (128), no problem there. So I suspect it might be related to reading from function tables. When I manage, I’ll try to build another simple (but not too simple) instrument.

I thought this was a work around?

You’re right! It seems to be. :slight_smile: but doesn’t feel right :hole:

In case you’re up to some more Live-Csound_gestures torture, here comes more feedback. I stripped down my timed-button preset mechanism to the minimum (I think). In the video you see examples with 64, 63, 62 sliders. Automation clearly breaks at the count of 63 sliders and maybe starts to feel a bit jittery at 62, but it works fine for <= 62. Note the channels reported by Live. I could send you the csd if you like.