CLAP: The New Audio Plug-in Standard (by U-he, Bitwig and others)

[moss]

So, here we go. First part of "Developing with CLAP" is online focusing on the license discussion, frameworks and tools:

[S0lo]

Whats the difference between those two (in params.h):

// Does this param supports per note automations?
CLAP_PARAM_IS_MODULATABLE_PER_NOTE_ID = 1 << 11,

// Does this param supports per note automations?
CLAP_PARAM_IS_MODULATABLE_PER_KEY = 1 << 12,

[EvilDragon]

You can have a parameter modulated per key (single value per channel, key) or per actually played voice (press a single key with long release multiple times = you get multiple voices, each tracking its own modulation).

[S0lo]

Ok, so I'm assuming the ...._PER_NOTE_ID is the one thats polyphonic (i.e per voice). While the _PER_KEY is the usual all voices modulation we're used to as in VST ?

[Urs]

Port/Channel/Key ("PCK") works with MIDI, MPE-like - it's the way MIDI 2.0 identifies voices. A Note_ID is a step up - it is only given through actual Note Events from the host, like in AU and VST3. A Note_ID can be any integer, like running number, or whatever the host choses it to be.

These are two parallel concepts of identifying a voice/note for modulation. You can choose what suits you best, and I think that PCK (or only CK, or only C, or only K) is probably easier for anyone who supports MPE already. It has the advantage that it'll work with any MIDI/Note dialect.

Note_IDs have the advantage that even two voices playing the same note on the same channel can be distinguished from each other, e.g. overlapping notes. It won't work if the host has no concept for this, e.g. a live host.

The idea is that PCK is relatively easy to get started with, and moving to Note_ID is the next step. With Note_ID it's also possible to support NoteExpressions which I think of as a macro of polyphonic parameter modulation.

We currently only support Channel/Key, but we plan to support Channel/Key and Note_ID simultaneously, whatever the host throws at us.

[EvilDragon]

Well no, per key can still be polyphonic. It's just one modulation channel per key, rather than per voice. At least that's my understanding.

EDIT: Urs swooped in

[Urs]

Ok, so I'm assuming the ...._PER_NOTE_ID is the one thats polyphonic (i.e per voice). While the _PER_KEY is the usual all voices modulation we're used to as in VST ?

No, both are polyphonic.

One gives you "hey, modulate every voice playing a C4 now". The other one gives you "Hey, modulate only the Note with ID #648736428 now - even if another voice with a different Note_ID has the same pitch"

[Urs]

Yeah, Note_Id is more precise, while PCK is more general.

Implementation-wise it's not such a big step. For us it's a dgatdgffaz-load of refactoring and testing. So we do it some time later.

[S0lo]

Starting to make sense Yeah. thanks!! for both.

No, both are polyphonic.

One gives you "hey, modulate every voice playing a C4 now". .......

So in _PER_KEY mode. If voice 1 is playing a C4, and voice 2 is playing a E5. And the host sends say cutoff modulation for C4. It would only modulate cutoff for voice 1 ?

[Urs]

Starting to make sense Yeah. thanks!! for both.

No, both are polyphonic.

One gives you "hey, modulate every voice playing a C4 now". .......

So in _PER_KEY mode. If voice 1 is playing a C4, and voice 2 is playing a E5. And the host sends say cutoff modulation for C4. It would only modulate cutoff for voice 1 ?

yes

[S0lo]

Starting to make sense Yeah. thanks!! for both.

No, both are polyphonic.

One gives you "hey, modulate every voice playing a C4 now". .......

So in _PER_KEY mode. If voice 1 is playing a C4, and voice 2 is playing a E5. And the host sends say cutoff modulation for C4. It would only modulate cutoff for voice 1 ?

yes

So this means that if the host wants to modulate cutoff for all voices no matter what the key (which is arguably a common case). Then it has to repeatedly send the same modulation for each voice and indicate the correct playing key for it. hmm, No problem, but if the voice count is high then there will be some considerable modulation traffic there. Or am I missing something else.

[baconpaul]

-1 is the global address. Send pck and id to that and you address every voice

If a single param has both poly and mono mods inbound the host has to sum them to poly. But for mono only use use the voice glob.

[baconpaul]

https://github.com/surge-synthesizer/cl ... o.cpp#L522

That code shows how the little demo synth does it. Basically voice lookup depends on the coordinates you are giving. That synth (and surge too) support mono, pck, and noteid based modulation

[mystran]

The headers don't seem to specify anything about modulation range? Is the host supposed to clip it into the parameter range? Personally I wouldn't mind accepting modulation range that's like WAY more than the standard parameter range (which is usually chosen for HCI factors more so than technical reasons), but most importantly it'd be nice to know what to expect.

[robbert-vdh]

The headers don't seem to specify anything about modulation range? Is the host supposed to clip it into the parameter range? Personally I wouldn't mind accepting modulation range that's like WAY more than the standard parameter range (which is usually chosen for HCI factors more so than technical reasons), but most importantly it'd be nice to know what to expect.

Modulation is simply an offset for the parameter's current value. So the sensible range would be [-(max_value - min_value), (max_value - min_value)]. Of course, like with regular automation you should always clamp internally when handling these events.