Cabbage Logo
Back to Cabbage Site

Slider jumping when recording automation

#1

When recording automation in Ableton Live, slider makes random jumps. It seem this behaviour is invoked if I record a bit, stop, and then continue recording as shown in the video. You can see the jumps in the screen shot. System: MacBook Pro (Retina, 15-inch, Mid 2015), MacOS 10.14.6, Ableton Live 9, Cabbage 2.7.13.

This one seems quite problematic. I hope it can be mitigated.


slider_jump
slider_jump2058×996 290 KB 
<Cabbage>
form caption("test") size(300, 200), colour(58, 110, 182), pluginId("taf5") guiMode("queue")

rslider bounds(2, 22, 120, 120) range(0.5, 10000, 220, 0.25, 0.001) channel("OscFrq") popupText("0") colour(0, 255, 0, 255) trackerColour(255, 0, 0, 255)

button bounds(126, 20, 65, 65) latched(0) channel("OscFrqMultiplier2")  text("x2","x2") value(0)  corners(3) colour:0(255, 0, 0, 255) colour:1(255, 255, 0, 255) fontColour:0(0, 0, 0, 255) fontColour:1(160, 0, 0, 255)
button bounds(126, 88, 65, 65) latched(0) channel("OscFrqMultiplier05") text("/2","/2")  value(0)  corners(3) colour:0(0, 255, 0, 255) colour:1(255, 255, 0, 255) fontColour:0(0, 0, 0, 255) fontColour:1(160, 0, 0, 255)

</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d 
</CsOptions>
<CsInstruments>
ksmps = 32
nchnls = 2
0dbfs = 1


instr 1

kOscFrq cabbageGetValue "OscFrq"

if (trigger(cabbageGetValue:k("OscFrqMultiplier2"), .5, 0) == 1) then; 0->1
    kOscFrq *= 2
    cabbageSetValue  "OscFrq", kOscFrq
endif
    
if (trigger(cabbageGetValue:k("OscFrqMultiplier05"), .5, 0) == 1) then; 0->1
   kOscFrq *= 0.5
   cabbageSetValue  "OscFrq", kOscFrq
endif   

endin

</CsInstruments>
<CsScore>
f0 z
i 1 0 -1
</CsScore>
</CsoundSynthesizer>
What happened to CHNSET_GESTURES?
#2

This is an odd one. The automation curve is correct, but the visual position of the slider is not. This might take a while…

The fact that this only happens with Live is also quite worrying…

#3

I suspect what is going on is related to a feedback loop from broadcasting channel change to Live. If I override a varying automation (not just a constant offset as in my video), I can see that now and then it plays the old automation instead of recording new. I’m not sure but this might be a clue.

#4

It seems Live handles automation begin/end gestures differently to other hosts. I’ve had to add Live specific code for this which is a pain. But it might be the only solution. Can you test it and let me know if it works?

1 Like
#5

It seems to work! You’re amazing!
How can you figure all this stuff out - so quickly?!
:love_you_gesture:

#6

That one took me a while actually! It was a tricky one to find, especially considering Live takes an age to launch on my machine. I hate having to debug anything in Live or Logic for this reason. But I’m glad it’s working. It’s a very Live solution to a very Live problem.

#7

I’m sorry for your pain. With all your insights and overview it might be a good idea to report the peculiarity to Ableton? But what if they change this “thing”, will your solution then be a problem?

#8

Host changes things all the time. And the underlying SDKs and APIs change all the time too. No one thinks of Cabbage farmers :rofl:

1 Like
#9

@Samo, I’ve pushed another attempted ‘fix’ for this. Once again, it works fine on my end and it definitely make far fewer calls to underlying SDK functions. I hope this resolves the dropouts you were experiencing and leaves you in a better state in terms of automation.

I’ve bumped the minor number to 14 as there have been a good few changes in the past few days.

#10

This all sounds great! This is interesting too

Curious to get a rough idea where you could spare the calls.
Thanks! Testing time… :slight_smile:

#11

Just tried with vst in Ableton. Testing code below. I’m getting similar jumps as discussed above when gestures = 0 or 1 and I’m moving the slider. So it seems that gestures only works correctly when setting the value from Csound and it has issues when automation recording is stopped and then continued. So maybe this is still half cooked?

<Cabbage>
form caption("test") size(300, 200), colour(58, 110, 182), pluginId("taf5") guiMode("queue")

rslider bounds(2, 22, 120, 120) range(0.5, 10000, 220, 0.25, 0.001) channel("OscFrq") popupText("0") colour(0, 255, 0, 255) trackerColour(255, 0, 0, 255)

button bounds(126, 20, 65, 65) latched(0) channel("OscFrqMultiplier2")  text("x2","x2") value(0)  corners(3) colour:0(255, 0, 0, 255) colour:1(255, 255, 0, 255) fontColour:0(0, 0, 0, 255) fontColour:1(160, 0, 0, 255)
button bounds(126, 88, 65, 65) latched(0) channel("OscFrqMultiplier05") text("/2","/2")  value(0)  corners(3) colour:0(0, 255, 0, 255) colour:1(255, 255, 0, 255) fontColour:0(0, 0, 0, 255) fontColour:1(160, 0, 0, 255)

checkbox bounds(224, 42, 40, 30), channel("csound_gestures"), corners(2) value(1) colour:0(255, 255, 0, 100) colour:1(255, 255, 0, 255) automatable(0)  colour:0(255, 255, 0, 100) colour:1(255, 255, 0, 255) automatable(0)
label   bounds(200, 74, 84, 18) text("GESTURES") fontColour(255, 255, 0, 150) channel("label9")


</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d 
</CsOptions>
<CsInstruments>
ksmps = 32
nchnls = 2
0dbfs = 1


instr 1

kCsoundGestures, kTrig cabbageGetValue "csound_gestures"
if kTrig == 1 then
    chnset kCsoundGestures, "CSOUND_GESTURES"
endif

kOscFrq cabbageGetValue "OscFrq"

if kCsoundGestures == 1 then
if (trigger(cabbageGetValue:k("OscFrqMultiplier2"), .5, 0) == 1) then; 0->1
    kOscFrq *= 2
    cabbageSetValue  "OscFrq", kOscFrq
endif
    
if (trigger(cabbageGetValue:k("OscFrqMultiplier05"), .5, 0) == 1) then; 0->1
   kOscFrq *= 0.5
   cabbageSetValue  "OscFrq", kOscFrq
endif   
endif

endin

</CsInstruments>
<CsScore>
f0 z
i 1 0 -1
</CsScore>
</CsoundSynthesizer>
#12

Balls. I see I may have been overly optimistic on this one. :rage: And we go again…

#13

I just tried something else now. Hmm, it works Ok here, but I’m not sure it’s the best we can do. Although everything seems to work fine now, the one issue is that Live doesn’t automatically jump to the parameter that is most recently changed as it used to. So if you launch the sample plugin and start moving a slider when it’s armed for record, Live won’t bring you to that slider’s automation track. But if you manually select it, you can see it’s working fine. Buy why is this?

Because I have disabled the begin/end gesture in Live when moving a slider with the mouse. I am not sure this is the best approach, but I’m curious to see if it works Ok for you. Ca you try it and let me know. Thanks as always for your patience!

#14

I just tried my test code above and all seems to work fine now! Thank You for the patience and persistence!

I see that and while it is not ideal, to me this is a minor concern relative to the other issues. With many sliders it will be difficult to find the one to automate though.

Tomorrow I’ll try out the dropout situation and the gestures channel and I hope it will go through my stress tests. If you can make this work, I think it will be an unprecedented feature :slight_smile: This will enable simple MIDI switching of presets, which could thus be used in unconventional ways. In light of the difficulties of getting this robust, it is not surprising that we haven’t seen a similar feature in other plugins, or I might be wrong? Thank you again!

1 Like
#15

This is madness. While the test example and my stripped down version of the preset system kind of work, my big instrument goes crazy along with me. Reading tables seems a bit sluggish especially in vst version (significant difference vs au) and there is something strange with re-enabling automation.
The big instruments behave unpredictable. One time the vst went into some feedback loop just switching averting randomly. After that the presets were completely scrambled and I was not able to save them. Ones I couldn’t load presets in au, then I could. I notice dropouts in vst then no more droputs after I reloaded it after au. While it worked before, now I can’t record automation in neither au nor vst. I re-exported, still no recording of automation. It is like there is something that is piling up in some memory and restarting Live or overwriting plugins doesn’t help. I am very sory, this is difficult to describe! I might test some more and try to come up with more clear example of mad behaviours, but things seem very random, not repeatable, totally moody.

I think I’m slowly giving up on my preset idea - after a year. Also, I’d soon like to put the plugin in practice, and I’m running out of tweaking time soon (for now of course). So, I think it would be good if you could get back Live’s ability to “bring me to the slider” (automation lane). My plan is to only do classic automation and forget about presets for now. I guess I could at some point adapt them to only change Csound parameters and not mess with widgets?

[edit] some more observations the day after: I optimized my code as you taught me here New cabbageChanged opcode
I did first a simple test instrument for loading and saving presets. The Par1,2… are just test slidrs and ON/OFF and print are also test buttons, below are buttons to load defaults, reload and L1-L16 are for loading presets, S1-S16 are yellow when they contain presets, which are all saved in a table that can be loaded/saved with buttons below, “browse” and “save as” are used for non-defualt file names, and there is also the “gestures” switch at the bottom left corner.

image
image656×574 46.7 KB

I then included this to my big instrument, so I could test them separately and with/without inclusion as AU/VST in Ableton Live.
With “gestures” and presets included, the behaviour is in all flavours of incomprehensible. I tried re-exporting several times also checking if the file-name would make a difference (e.g. newName.vst doesn’t make a difference). AU appear more tamed. In AU I observed automation re-enable remaining activated while automation was playing - Live is getting really strange on Cabbage :astonished: In VST Live travelled at least out of the solar system! The plugin couldn’t load the presets - it actually made them up on the fly randomly on every click on the load button. Note that I have no such randomization included by design. It really randomized all widgets! :astonished: When I did not do anything with the file on disk - just used internal memory to save a preset with S1 and another with S2 button, and then used L1 and L2 buttons to load them (from internal memory), Live started switching between the two like crazy and randomizing things. There are definitely some internal loops and leaking messages.

The main peace of info that I can describe more concisely is shown in the clips recorded in Live for an AU and for VST separately. I did a test without including any preset nor “gestures” business. As you noted, Live doesn’t bring me to the automation parameter, but there is more probably related to this. It also doesn’t record automation (in the case of my big instrument). For AU I can get it to start recording if I push an arbitrary button on the plugin first, but even these doesn’t resurrect recording for VST. Note that the button I pushed in the video is not at all related to the filter sliders.

AU-example:

VST-example:

I really hope you can fix at least the non-gestures/non-presets part! :pleading_face:
When you get the time of course :slight_smile:

#16

I’m adding some more info on top of the above today - hopefully useful! I think this will be revealing.
I exported an old instrument of mine, which uses only the default (polling) guiMode and a similar principle of chnset sliders with buttons.

In VST everything (except Live hiding automation lanes) seems to work as intended! Sliders move by chnset without Csound gestures enabled. This plugin was the final iteration after we struggled with the old “chnset_gestures” (What happened to CHNSET_GESTURES?). And now I know why I “abandoned” AU. Because VST worked and AU not, which is still the case in the default guiMode. AU doesn’t record automation on sliders, only on momentary buttons. To make things more confusing, I couldn’t get automation recorded also on radio-grouped buttons. Consequently, chnset changes also don’t get recorded.

So chnset has seen some sparks of light in VST and in default guiMode but not in AU. While in the queue mode, AU seems to behave better. The “gestures business” works in VST and default mode without actually using it - witch seem ideal, but in the queue mode, it seems to work partially for AU. There seems to be remnants of the old ghosts lying around combined with the polling/queue mode dualism and a layer of Ableton’s caprices on top. The sticky tapes start to make development very difficult for me - I don’t know in which corner of the game I shall be manoeuvring.

#17

Thanks for the report, and extensive testing. So we’re still not any way closer to solving this issue. Perhaps I need to look elsewhere in the code base for a solution. It’s so frustrating when one host presents such issues. If I could recreate the problem in another host there is a chance I could get better information.

Tomorrow I will remove some layers of sticky tape and come at this again :slight_smile:

#18

Btw, do you have a minimal example that I can use to test here? The example you posted originally seems to pass all tests.

#19

I hope you manage to get through my scattered thriller above and that you can get some hints out of it. The current situation, at least in Live, is pretty dysfunctional even without my gestures gymnastics.

I’ll message you my instruments. They are not really minimal, but I hope they could help you find what is going on. The most minimal is the preset template shown in the screen-shot above. But I’ll send you also the one using only the polling mode. I’m glad you still have the patience to check further options. Again, if the gestures things don’t work, my priority would be to get the normal functionally right. So frustrating indeed, since we were so close to get it right (it felt) several times. Please refer to my post above for details.