search

free-audio / clap

Audio Plugin API
https://cleveraudio.org/
MIT License
1.71k stars 98 forks source link

Trying to wrap my head around polyphonic automation (not modulation) #399

Closed sjoerdvankreel closed 2 months ago

sjoerdvankreel commented 2 months ago

Hi!

I'm having some trouble trying to grasp the concept of polyphonic automation. Regular destructive automation (CLAP_PARAM_IS_AUTOMATABLE), I understand. It's also easy to see how it maps to a per-voice parameter. Non-destructive modulation, either global or per-voice, I get that too. The key concept (at least to my mind) here is that both the synth voice and the modulation signal are short-lived and their lifetimes align.

The trouble starts with destructive polyphonic automation (CLAP_PARAM_IS_AUTOMATABLE_PER_NOTE_ID). Let's say i have a regular 8-voice polyphonic synth plugin with 1 per-voice filter control. Obviously the per-voice filter cutoff is just a single value in the plugin state, is saved/loaded as such from the patch file etc. Now what do I do when the host sends me different values for the cutoff param for different voices?

Do I completely misunderstand what poly-automation is about? Appreciate if anyone can shed some light on this.

baconpaul commented 2 months ago

So I’ll start by saying I have never written a plugin with per voice automation but here’s how I think of it

modulation is a diff. The resulting Param value is the base value + diff. The tool needs two values per Param (or per Param per voice perhaps)

automation is a statement of value.

So monophonic automation is the destructive case we know and love

polyphonic automation then ends up - at least to me - being a bit wierd. It is for the case where you can set a value per voice but not consume a diff from base. I suppose such cases exist and formally I’m glad we cover it but I’ve never used it

the confusing moment comes with the word “destructive”. Monophonic automation dirties the patch and sets the value. Polyphonic automation is ambiguous in this regard I agree. I certainly would propose it is non destructive in a “patch” sense but I bet I could be convinced of the somewhat pedantic argument that it is destructive in the voice scope (it is a restatement not a diff)

but don’t take this as authoritative. I agree the question is tricky so I shared my thoughts not definitive answers

sjoerdvankreel commented 2 months ago

Thanks. That kind of confirmed my suspicion, so I will just forego implementing it alltogether.

Just figured one (maybe?) valid use case for IS_AUTOMATABLE_PER_PORT which is for multi-timbral plugs, in which case it might be valuable to store a copy of all params per port? Don't know, just guessing here.

Anyway, it's clear to me that this stuff is probably of no interest for your regular-run-of-the-mill plugin. I'll leave the topic open just a little bit longer, see if anyone else wants to chip in.

baconpaul commented 2 months ago

Yeah I am sure some massive library sampler might want to have params-per-channel one day that makes sense.