# Plugin feedback DAW automation

**URL:** <https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012>\
**Category:** Cabbage Stew\
**Created:** [28 June 2020 10:06 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012 "2020-06-28T10:06:11Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [28 June 2020 10:06 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/1 "2020-06-28T10:06:11Z")

</div>

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-next.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](https://forum-next.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](https://forum.cabbageaudio.com/uploads/default/original/2X/c/c08114a672b66475e9147c26abdd07d0a5a2002a.gif)

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

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [28 June 2020 16:11 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/2 "2020-06-28T16:11:46Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [29 June 2020 08:44 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/3 "2020-06-29T08:44:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [29 June 2020 10:01 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/4 "2020-06-29T10:01:54Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [30 June 2020 09:35 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/5 "2020-06-30T09:35:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [30 June 2020 09:56 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/6 "2020-06-30T09:56:31Z")

</div>

> [@Samo](#):
>
> I image having both should be possible since both automation and feedback seem to work with other plugins.

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

> [@Samo](#):
>
> 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?

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.

---

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [30 June 2020 10:45 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/7 "2020-06-30T10:45:51Z")

</div>

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.

> [@rorywalsh](#):
>
> FWIW, this only breaks Live. It works fine in other DAWs from what I can tell.

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.

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [30 June 2020 10:58 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/8 "2020-06-30T10:58:30Z")

</div>

> [@Samo](#):
>
> But I don’t know of an example where the plugin parameters are changed internally after loading from a preset as in my application.

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

> [@Samo](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [5 July 2020 09:23 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/9 "2020-07-05T09:23:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [5 July 2020 12:09 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/10 "2020-07-05T12:09:33Z")

</div>

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.

> [@Samo](#):
>
> BTW. How can I find different beta Cabbage versions? There seems to be a gap between #20200118.3 and #20200605.1.

The most recent beta are presented [here](https://dev.azure.com/rorywalsh/cabbage/_build?view=runs). The current beta has reverted to the old behavior, i.e, chnsets from Csound won’t be automated in the DAW.

---

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [5 July 2020 14:43 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/11 "2020-07-05T14:43:04Z")

</div>

> [@rorywalsh](#):
>
> I could add a special reserved channel to let you swap between these modes.

Wonderful that you could do that. Looking forward to try it 🤤

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.

> [@rorywalsh](#):
>
> The most recent beta are presented [here](https://dev.azure.com/rorywalsh/cabbage/_build?view=runs).

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!

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [5 July 2020 15:13 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/12 "2020-07-05T15:13:31Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [6 July 2020 10:04 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/13 "2020-07-06T10:04:24Z")

</div>

There is a new build available [here](https://dev.azure.com/rorywalsh/cabbage/_build/results?buildId=686&view=artifacts&type=publishedArtifacts) 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. 😉

---

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [6 July 2020 19:19 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/14 "2020-07-06T19:19:24Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [8 July 2020 09:08 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/15 "2020-07-08T09:08:11Z")

</div>

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>
```

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [8 July 2020 18:26 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/16 "2020-07-08T18:26:17Z")

</div>

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 😆

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…

---

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [9 July 2020 07:02 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/17 "2020-07-09T07:02:30Z")

</div>

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).

> [@Samo](#):
>
> I can no longer see the cursor in Cabbage (MacOS 10.12.6). Anything obvious?

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [10 July 2020 09:54 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/18 "2020-07-10T09:54:57Z")

</div>

> [@Samo](#):
>
> I can no longer see the cursor in Cabbage (MacOS 10.12.6). Anything obvious?

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

---

<div class="post-metadata">

**Author:** ![Samo](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/71c47a/32.png) [@Samo](https://forum.cabbageaudio.com/u/Samo)\
**Post date:** [29 July 2020 14:47 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/19 "2020-07-29T14:47:00Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [29 July 2020 15:00 UTC](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012/20 "2020-07-29T15:00:38Z")

</div>

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 ☹

[Next page](https://forum.cabbageaudio.com/t/plugin-feedback-daw-automation/2012.md?page=2)
