Cabbage Logo
Back to Cabbage Site

Plugin feedback DAW automation

#1

Hi Rory,

I’m having rouble automating plugin parameters in DAW (Ableton Live). This seems related to my previous question about sending MIDI feedback to controller (https://forum.cabbageaudio.com/t/midi-feedback-from-plugin-to-midi-controller-can-plugin-inform-a-mapped-midi-controller-about-the-state-of-variables-when-they-change-internally-without-using-a-mouse/1847), which you resolved by fixing the code (I am currently running Cabbage 2.3.41). So, now plugins do inform DAW about parameter changes, which in turn send MIDI feedback to an external harware MIDI controller via MIDI mapping. However, when automation is applied to a plugin knob, DAW seems to interpret plugins’ feedback as if the knob was changed manually, thus interrupting automation. In Ableton, the “Re-Enable Automation Button” is tuned on when automation is not active - see example:

cabbage_automation
cabbage_automation1920×984 2.51 MB

The examples here are the basic synth and effect Cabbage templates exported as vst. I tried also with au (same behaviour). In GarageBand the automation is not interrupted, but the knob value stutters more or less depending on the slew rate of the automation.

I find automation critical for a good plugin work-flow, so I really hope you can help me resolve this problem.

Best regards,
Samo

DAW crashing when plugin is a synth but not when it is an effect
MIDI controllable custom presets + csound to DAW feedback
MIDI controllable custom presets + csound to DAW feedback
#2

I should get a moment to look into this tomorrow. I’ll get back to you then…

#3

This is a tricky one. There is an ugly recursion problem here that is causing Live to crap itself. In addressing your last reported issue, we modified things so that changes made to a channel within Csound (using chnset) are broadcast to the host. The problem here is that when automation is used it sends a channel update to Csound, which in turn broadcasts that update back to the Live, which in turns sends it back again, and so on. Before you know it Live has enable that little Re-enable Automation button.

I’m not sure how best to solve this. I’ll keep looking into it. Hopefully there is an eloquent solution.

#4

I’m afraid to say that I can’t think of any workable solution to this issue. So it looks like the changes I added for you more or less break automation in Live for other users. I think I will have to revert them. I’m open to ideas here, but it’s quite a conundrum…

#5

Thanks for looking into this. Too bad if we could not have both MIDI feedback (sent to a mapped hardware controller) and DAW automation to work properly with Cabbage plugins. If we have to choose, I agree that automation should be a priority.

I image having both should be possible since both automation and feedback seem to work with other plugins. But I might be pushing it a bit here with my extended preset handling.
I am sorry that I cannot offer a good suggestion for resolving this due to my lack of knowledge of the inner workings of Cabbage, DAWs and the communication between the two. At best I can only come up with some naive ideas…

Perhaps there are some specific messages that DAWs can understand, which could be used to interrupt the recursion?
Maybe some conditional messaging could be applied, e.g. send info to DAW only when parameter is changed internally and not when it is received from DAW or from moving widget with a mouse. Or send info only when parameter changes - this might already be enough to brake automation?

I’d really need the MIDI feedback only when I change a preset, so the hardware controller gets updated allowing for smooth parameter take-over.

I really hope you or some other guru could find a solution to this.

Best,
Samo

#6

Do you know of any open source plugins that can do this? Perhaps I can take a look at the code.

This is the route I explored yesterday, and it lead me around in circles. FWIW, this only breaks Live. It works fine in other DAWs from what I can tell.

#7

Automation and MIDI feedback both seem to work fine for internal and external plugins. But I don’t know of an example where the plugin parameters are changed internally after loading from a preset as in my application. The usual handling of presets (browsing for a preset with a mouse or keyboard) seems to use a different mechanism, which doesn’t brake automation.

Trying in Garageband, I see the knob stuttering with automation - not following smoothly. While it doesn’t break automation, I am not sure this is OK either.

#8

Yes, this is something I’m looking for myself.

True. It may might not ‘break’ in other DAWs, but it probably doesn’t ‘work’ either.

#9

Hi Rory,

I’ve been looking around a bit and testing some plugins. If at all possible, preset changing is always done using a dropdown menu, which can sometimes be scrolled through by using buttons. When a preset is changed this way, MIDI feedback about plugin parameter change is sent out to an external hardware controller. My overview is limited but it seem rare that plugin presets can also be changed via MIDI program change messages. In Live, MIDI program change can be sent from a separate channel by launching clips (MIDI mappable). There are also Max4Live devices that can translate CC to program change… However, it seems that when presets are changed via MIDI program change, plugins don’t send MIDI feedback (DAW is not notified about plugin parameter changes). I’m not sure how generally this applies.

It could be very useful and unique if we could have Cabbage plugins that can handle preset switching in a more claver way, which would open interesting new possibilities for live performance (when using appropriate hardware, e.g. with motorised or endless encoders). So now we either have automation working and no MIDI feedback when changing presets or automation breaking while MIDI feedback is available. This makes me think of a probably very naive idea: maybe we could have a new Cabbage widget - a “magic switch”, which could be flipped to enable feedback (notifying DAW of changes triggered within a plugin). Such a switch could be turned ON for live performance and turned OFF for “studio” use, when automation is needed. Of course the default should be no feedback, but perhaps feedback could be enabled by the user? I really hope something like this (or any other meaningful solution) is possible.

If we shall give up on this (for now), are you updating the code by rolling back the DAW notification changes you did in version 2.3.38 (I believe)? It would be good to know the limitations we have to adapt to.

BTW. How can I find different beta Cabbage versions? There seems to be a gap between #20200118.3 and #20200605.1.

Best,
Samo

#10

I could add a special reserved channel to let you swap between these modes. That shouldn’t be too much working considering both parts are known to be working on their own.

The most recent beta are presented here. The current beta has reverted to the old behavior, i.e, chnsets from Csound won’t be automated in the DAW.

#11

Wonderful that you could do that. Looking forward to try it :drooling_face:

Please let me know when you have it (and where to get it) and how can I use it. Will I be able to flip the state of that channel with a button or some other widget? Please tell me how it can be used.

The last version I can see is from Jun 19. Have you reverted the chnset behaviour already in that version (before I started this topic)?

Thank you so much!

#12

Sorry, it looks like the latest version didn’t get built. I will run off a build later. I’ll also let you know when I have are the other stuff.

#13

There is a new build available here now. There is a new reserved channel name AUTOMATION. Set it to 1 to have the host racks changes to a channel from Csound. Set it back to 0 for the default behaviour. I haven’t had time to extensively test this, so please have a good luck and see if it works. :wink:

#14

Super! I’ll test it more these days, but just a quick feedback/question for now:

I can no longer see the cursor in Cabbage (MacOS 10.12.6). Anything obvious?

And just to be sure: can I just do something like chnset kAutomation, "AUTOMATION", where I get kAutomation from a button?

#15

The “AUTOMATION switch” seems to work as expected when I load/reload the plugin, but if I add automation and let it loop over it, the switch stops working after a while. I tried this many times and I see that sooner or later the switch stops working. At first I thought that if I push the plugin buttons (more or less frenetically) breaks the switch functionality, but then I realized that I just need to let it run with automation for a while to break the switch. The automation slew doesn’t seem to matter.

Do you get the same behaviour? Any ideas?

My test code:

<Cabbage>
form caption("test automation fx 200707") size(300, 200), colour(58, 110, 182), pluginid("taf3")

rslider bounds(2, 22, 120, 120) range(0.5, 10000, 220, 0.25, 0.001) channel("OscFrq") identchannel("OscFrqID") 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)

button bounds(196, 20, 92, 134) channel("automationON") text("AUTOMATION switch", "AUTOMATION switch") colour:1(255, 255, 0, 255) fontcolour:1(0, 0, 0, 255)
label   bounds(2, 164, 286, 22), identchannel("textID")

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


instr 1
;chnset chnget:k("automationON"), "AUTOMATION" ; test 1 (a shorter version of the block below)

kAutomationON chnget "automationON"; test 2 
if kAutomationON == 1 then
chnset k(1), "AUTOMATION"
elseif kAutomationON == 0 then
chnset k(0), "AUTOMATION"
endif

ka chnget "AUTOMATION"
Stext = sprintfk("text(AUTOMATION = %d)", ka)
chnset Stext, "textID"
kOscFrq chnget "OscFrq"

; -------- internal parameter change -------    

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

endin

</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
;starts instrument 1 and runs it for a week
i1 0 [60*60*24*7] 
</CsScore>
</CsoundSynthesizer>
#16

I’m sorry for not getting back to your first message. You seem to have worked it out. As to why it’s not working, I’m not sure. It could have something to do with the fact that the button you are using to set automation mode is itself automatable? Ha, this is quite meta :laughing:

Can you try setting the automation mode only using Csound, and not with an actual widget? For example, the following code should enable disable AUTOMATION mode every 10 seconds.

kAuto init 0
if metro(.1) == 1 then
    if kAuto == 1 then
        kAuto = 0
        printks "Setting automation mode to 1", 0
        chnset kAuto, "AUTOMATION"
    else
        kAuto = 1
        printks "Setting automation mode to 0", 0
        chnset kAuto, "AUTOMATION"
    endif
endif

If this works then we know that using standard widgets to control automation might not work…

#17

I tested your code for changing automation mode only using Csound. Similarly as with the widget, it works fine if I let the plugin sit without automation, but when I run automation it breaks and DAW stops getting info from internal changes of plugin parameters. I actually noticed a similar behaviour in the previous Cabbage version when we had automation mode fixed. It seems like something weird might be going on with sending info to DAW.

I then tried initiating “AUTOMATION” = 1 without changing it. No notifications are sent to DAW just as with “AUTOMATION” = 0. If instead I set “AUTOMATION” = 1 at k-rate then it works… until it breaks. It seems that “AUTOMATION” needs to be repeatedly set to 1? Even though the printed state is 1 after initiation, it seem like it’s not really doing its job as it should in state 1. Hope this may give some clues.

BTW., just wanted to remind you of the cursor missing in Cabbage editor (2.3.45).

#18

I’m away for a few days but look into this, and the other issue when I get back. :+1:

#19

Hi Rory,
I hope you’re well.
I’m curious if you managed to look into the issues above?

#20

Briefly, but I didn’t have enough time I’m afraid. It’s on my todo list, but my time is fairly restricted at the moment :frowning: