Plugin feedback DAW automation

[Samo]

Hi!
I hope you had a good summer.
Any progress on this issue? I hope you at least have some ideas to keep my hopes up

[rorywalsh]

The last I remember, I entered some kind of automation black hole. Everything after that is a bit of a blur! I just couldn’t figure out a way to do this as the automation and channels are so tightly connected. Each channel is a plugin parameter.

Anyway, to summarise, the last attempt used an AUTOMATION channel to disable/enable the plugin from broadcasting changes to the host? Is that right?

[Samo]

The black hole is leaking. That’s the funny part!
The AUTOMATION switch works for a while but eventually breaks and then neither feedback nor automation work properly.

@rorywalsh

Anyway, to summarise, the last attempt used an AUTOMATION channel to disable/enable the plugin from broadcasting changes to the host? Is that right?

Yes that is correct. I tried it now again with version 2.4.7 and I have the same observations as before (in this thread). An important one seems to be:

@Samo

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

I like the switch idea, but it doesn’t help much if MIDI feedback (to controller) stops working. Again, MIDI feedback stops working also for chnset k(1), "AUTOMATION" without switching it to 0. It is also puzzling to me why AUTOMATION can’t be set at i-rate.

If I’d need to chose weather my synths would have either automation or feedback working, I’d most often prefer feedback, since I could always record audio output. I hope at least the option of permanent choice could be available. But of course I still hope for a better solution with both features available.

Thanks again for all your great work!

[HuBandiT]

@rorywalsh

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

Are we trying to break cycles in what should be a directed acyclic graph?

Would it perhaps be possible to “tag” each message that is received for broadcasting with its sender, so that we never send back broadcast messages to their senders (thereby breaking the cycle)?

Or if this is not feasbile, but processing is single-threaded, then you could have one (per instance global) “sender” variable that gets set when the message broadcast processing gets triggered. Then the broadcast gets processed, discovering all recipients in the process (who, in turn, might broadcast to further recipients… ad infinitum). Along the way of the processing, whenever a (re)broadcast message is to be sent, skip sending if the destinee is the original “sender” (happening to be the host/DAW). This way whatever complex broadcast graph is within the plugin, the currently processed message never gets sent back out to the host/DAW. Finally – upon conclusion of the broadcast processing – the “sender” variable gets cleared.

This way, when the user triggers a change on the plugin UI, the sender of that change (broadcast message) is not the host/DAW, so the broadcasting process will eventually do send the message to the host/DAW. (Apologies for unclear wording.)

Alternatively, make the messages idempotent: have them only rebroadcast if they actually effected a change – and not just (re)state the current value (which is in effect no change, so no need to broadcast about it).

[rorywalsh]

This topic was brought to life again recently. It turns out that it might have been something to do with @Samo’s setup. So I think the issue is more or less resolved.

[Samo]

Hi!

I just wanted to mention that apart from the particularities of my setup, the feedback issue is illustrated also by other Cabbage plugins, as described recently. Rory introduced the reserved channel CHNSET_GESTURES to resolve this.

Now we can either have DAW automation playback working while internal parameter changes (by chnset) are not broadcast to the host (default, chnset 0, "CHNSET_GESTURES") or we can broadcast changes, e.g. triggered by a preset change, but no automation playback enabled (chnset 1, "CHNSET_GESTURES"). Perhaps one could refer to the two states as the automation playback and record/performance modes. For me, this works fine since I don’t need playback and record/performance modes simultaneously. I’d refer you to this Rory’s example: AutoTest.csd (889 Bytes)

I have some issues with AUs (which might be particular to my setup) but it works perfectly with VSTs.