Cabbage Logo
Back to Cabbage Site

Non-latched buttons & automation

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.

… 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: