Cabbage Logo
Back to Cabbage Site

Non-latched buttons & automation

… just wanted to add… I tested the initialization “workaround” on the example above. Sometimes it works, sometimes not. We had this kind of non-deterministic behaviour before (Live+gestures). So the only possible real workaround might be using Reaper - yet to test how robust it is there.

Yes please send me the csd file thank you :+1:

Thank You for checking this!

Just to recap, if I export vst from the uploaded csd as is, it doesn’t work, reducing the number of widgets make it work (at least with respect to automation, but it stutter initially - as you can see in the videos). Initializing gestures to 0 makes it work - sometimes!

This could probably be simplified further but it is a striped down version of an instrument with broader preset functionality, for example saving/loading several preset slots (labelled SL) to disk etc. is removed.

test_preset_timed.csd (5.5 KB)

I hope you’ll be able to look into the Live issue (above).
Here I have another one that might be related - this time from Reaper land.

A slider (automatable) is connected to a radiogroup of buttons (non-automatable), so that different buttons get selected when I change slider, and vice versa, buttons can be selected (by mouse only) to change slider. It might seem a bit silly, but I’ll have the slider mapped to touchable buttons in Open Stage Control to jump between 1 and 4 for example (without sliding through values) and I like the visual feedback in plugin as well as the ability to move slider in jumps with a mouse, but I only need the slider to be automatable.

Test in Cabbage 2.8.121 - this happens only if plugin GUI is closed while automation is playing/changing
csd file: test_slider2buttons.csd (1.6 KB)

  1. make automation on slider (only one button is latched as it should be)
  2. close plugin GUI and move play head manually or play a loop
  3. open plugin GUI - now multiple buttons are latched!
  4. when automation goes though all 4 states, all 4 buttons are latched forever

I’m not sure this is related to the other issue, but it’s equally baffling! It looks like the buttons aren’t being updated when the plugin is not visible…

I thought we found a Reaper specific caprice, but I just tested in Live and it is the same there.

Yeah it looks like a bug. Btw, have you noticed any issues with regular button outside a radio group? Do automations work ok there?

Normal buttons seem fine, both latched and non-latched.
But now I see that the simple radio group of latched buttons craps out, like this for example:

button bounds(170, 52, 32, 16) latched(1) channel("RG1")  text("1", "1") value(1) radioGroup("RG") colour:0(255, 255, 0, 50) colour:1(0, 0, 0, 255) 
button bounds(170, 32, 32, 16) latched(1) channel("RG2")  text("2", "2") value(0) radioGroup("RG") colour:0(255, 255, 0, 50) colour:1(0, 0, 0, 255) 
button bounds(206, 52, 32, 16) latched(1) channel("RG3")  text("3", "3") value(0) radioGroup("RG") colour:0(255, 255, 0, 50) colour:1(0, 0, 0, 255) 
button bounds(206, 32, 32, 16) latched(1) channel("RG4")  text("4", "4") value(0) radioGroup("RG") colour:0(255, 255, 0, 50) colour:1(0, 0, 0, 255) 

Not even considering the GUI problem, I cannot automate these in Live and Reaper. If try to expose automations, it goes into some kind of loop blinking frenetically the buttons (ON/OFF). In the previous example I had radio buttons linked to the slider and they were not automatable, so it works OK there, but only when plugin GUI is visible.

1 Like

I won’t lie to you, this is a tricky one! In fact I’m not sure it can be done without some major reconstructive work, i.e., rewriting the entire radio group mechanism. Since my accident I’m trying to limit work to absolutely required changes. Can this be done with a home-rolled radio group?

I came across a mention of your accident on this forum, which appeared so surreal that is heard to take in or imagine what it may entail. I’m so sorry and hope very much that the rehabilitation is going well and the side effects and losses will be minimal, and that you’ll be able to compensate or work around them.

I can surely work around the relatively insignificant issue of the radio group. In fact I had to in the past, before you “fixed” something. In my notes I see that this was before 2.7.13, maybe related to the “new” widget opcodes and guiMode("queue"), but I’m not sure about the thread, maybe this one New cabbageChanged opcode.

What about the bug that shows up in Live - automation missing?

As I understood each DAW has it’s own special needs (btw. just came across this yesterday https://www.youtube.com/watch?v=6cXjGzeOZ4U). I’m still a novice with Reaper, I find it great for mixing and I spend most of my little free time in it rather than in Live. But when it comes to speed of getting ideas down and handling many automation lanes, I might prefer Live :confused:. So I hope the issue I mentioned is solvable somehow.

Sorry @Samo, I’m still looking into this…

Looks to be working in Reaper with the full array of widgets. So this must be another issue tied to Live :thinking:

I’m not sure I’m following your steps to the letter, can you tell why this is wrong? I’m just trying to do what you did, but might be wrong. What I did here was record some channel changes with the SL1/SL2 buttons, then disable automation writing, remove the automation lanes for SL1/SL2 and hit playback. i just need to know what’s wrong. Btw, I haven’t jumped into your csd file yet.

Thanks! It seems you’re doing it the same way as I did and it works for you but not for me. The only difference I notice is that you exported as effect, while I exported VST instrument. Could that be relevant?
Maybe this is a Live 10 issue? What version do you have?
Maybe the number of widgets limit is different for you? You could simply change that in my csd. The key indicator is when you look at the automation list (as you did). You can see what I get - a truncated and scrambled list. And yes, this is not an issue in Reaper but in Live 10 (for me).

[edit] just tested again 2x restarting Live in between. One time it worked, the other not. :thinking:

It’s worth looking into for sure.

I’m using Live 11.

I’ll try that the next time I get a chance.

:roll_eyes: nothing is ever simple is it :rofl:

Right. Still, Cabbage seems the simplest thing these days.

I’ve done some more tests by doing the steps above to record and expose automations. It doesn’t work apparently randomly. I just deleted the plugin and loaded it again in these tests. Restarting Live has similar effect.

I just tested using a VSTi and I seem to get the same results as before. No issues as far as I can tell. After that I increased the number of widgets to 128 and still no issues, although there was a little lag when hitting the S1/S2 buttons as they update all channels at once. So we’re still no clearer on what the issue is :confounded:

Thanks! The only remaining thing I can think of is brute forcing this little bugger out - repeating the test by resetting the plugin. As I mentioned, it is working sometimes here as well and reloading the plugin or restarting Live can provoke the bug. I’ve also noticed the lag and my feeling was that it is associated with the automations issue, since it was kind of a jump in lag from tolerable to scary.

We surely have limited bandwidth for chasing this low priority one, but my feeling is that something is not right with Live + Cabbage automation and it would be good to find out, or perhaps there will be something else that will tell on this issue.

There are 1000s of Cabbage plugins in the wild without any reports of issues with automation in Live. I think the issue here is more centred around recording gestures from the plugin itself. I consider this to be a fairly unique use-case, I haven’t come across many plugins that allow this kind of thing, but we know that is at least supported, ergo it should work.

In my case the lags appeared when I tried to update 128 plugin parameters at the exact same time. I kind of expected that, no only are you asking the host to update 128 plugin parameters, and associated controls, but also Csound.

Please keep on looking for the cause of the problem. I would love to resolve this.

Yes, we’re pushing the limits on this, specially with gestures (recorded or not, the issue is the same). The gestures feature is indeed unique and I become somewhat reliant on it, it enables using presets as real-time composition tool, not only for changing the character of the instrument. I’ll keep on with it and taking my chances for now. Thanks for your patience and support!