several simultanius notes on the same key?

[logos-maker]

Is the thought that you also should be able to play several simultaneous notes on the same key, for voice stacking for example with different settings for each note?

Why then does CLAP allow to not specify the note ID for CLAP_EVENT_NOTE_ON and CLAP_EVENT_NOTE_OFF ? but a generic -1 for unspecified note_id ?

If a note_id was given for a CLAP_EVENT_NOTE_ON why then do you not need to sent it for CLAP_EVENT_NOTE_OFF ?

Should you kill all notes with that key if you get a LAP_EVENT_NOTE_OFF with a note_id of -1 ?

[baconpaul]

You absolutely can play several notes on the same key. The port channel key noteid tuple is the unique address of a note with -1 meaning wildcard.

In practice this means either rotate channels and have at most 16 stacked notes or use note ids on all notes

moreover bitwig activates voice stacking right now only if you implement the voice info draft extension and set the flag about stack is possible

If I get a note off with a -1 as my id I will kill every note which matches that port channel key.

Note ids are also very important because the plugin has to send a note end event with the note id for polymod

does that help answer your question?

[logos-maker]

I get a voice stack spread setting in bitwig even if I turn of the voice info draft extension in my plug. Maybe the have changed it?

I was trying to get Bitwig to modulate per note_id and didn't get it to work. It looks like you must turn on both the flags...
CLAP_PARAM_IS_MODULATABLE and
CLAP_PARAM_IS_MODULATABLE_PER_NOTE_ID

Just setting the flag CLAP_PARAM_IS_MODULATABLE_PER_NOTE_ID is not sufficient.

And it's not sufficient to set...
CLAP_PARAM_IS_MODULATABLE and
CLAP_PARAM_IS_AUTOMATABLE_PER_KEY

How should the CLAP_PARAM_IS_MODULATABLE flag be interpreted? Is it some what redundant or what is it for?
And what is CLAP_PARAM_IS_AUTOMATABLE_PER_KEY for?

[baconpaul]

So CLAP has two channels

Automation - this sets the value for a patch. It is ‘destructive’ in some sense, and is akin to changing a slider in your GUI

Modualation - this presents a transient and additive value for a parameter to the engine which doesn’t dirty the patch. it is kind of like a synths internal LFO

Not all plugins support either or both mechanism, so they are distinct.

“CLAP_PARAM_IS_AUTOMATABLE” is baslically the feature set that VST2/3/AU give you for params.
“CLAP_PARAM_IS_MODULATABLE” is new.

So then what is the address for automation and modulation. If a param is automatable or modulatable at all it must be able to accept a global value. But some tools can accept finer values, per note or per key.

So a common pattern is, say, to have a param which is AUTOMATABLE | MODULATABLE | MODULATABLE_PER_NOTE_ID which means automation (destructive) events are per plugin only but modulation events can either be monophonic or polyphonic by note id.

AUTOMATABLE_BY_NOTE_ID allows polyphonic ‘automation’. This is a bit odd but would work - it means a modulator could set exact values onto params for each note. A plugin would have to decide what the display does with that fact of course. And more importantly, if a user drags a slider which has that automation the user action and the automation would conflict (like they do in VST2/3/AU etc…)

As well as by note id you can be mod/automatable by other coordinates. Key is one,but has the problem of not being possible to stack notes unless you channel rotate.