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

[S0lo]

BTW, This maximum number of notes (1000 above) doesn't have to be the same as maximum polyphony. polyphony can be lower, because notes can overlap on the same voice as in mono with note priority.

[ThomasHelzle]

So after a few tests with PCK. both PORT and CHANNEL are always zero in bitwig. Why is that? The Key is midi note. If I hit the same key with a long release multiple times. Multiple voices do take the same midi note successfully. But modulation is not poly. It will modulate all voices with one mod source.

This is clearly because neither port nor channel are used to differentiate between a mod targeted at this or that voice. This is not the way I understand how MPE works. MPE manipulates the channel.

Sorry if you tried that already, but devices in Bitwig can have "MPE" enabled or disabled in the inspector on the left. That may lead to different behaviours.

But having the same note sound multiple times is an old discussion point in Bitwig, so it's actually possible that they haven't embraced fully independent polyphony as discussed here yet either.

Back to lurking to see if one day I'll write a CLAP-only plugin myself (probably a note device)...

Cheers,

Tom

[pdxindy]

I guess you'd need an MPE controller to automatically iterate through channels.

(disclaimer: I don't know how Bitwig works)

You can use a Note FX Selector device and each layer with Channel Map, to iterate through channels

[baconpaul]

Right so here’s how you would do that

1: add a host side extension that the okugin can probe and call to set the note id range
2; if that extension is there then do what you say
3: if it is not then take one of these defensive measures in the plugin
- disable note id addressing for all parameters or
- handle arbitrary note id

[pdxindy]

But having the same note sound multiple times is an old discussion point in Bitwig, so it's actually possible that they haven't embraced fully independent polyphony as discussed here yet either.

For Bitwig Instruments, over in the Inspector is the option 'Steal same key'. Uncheck that and repeated notes with long release are polyphonic.

[baconpaul]

So after a few tests with PCK. both PORT and CHANNEL are always zero in bitwig. Why is that? The Key is midi note. If I hit the same key with a long release multiple times. Multiple voices do take the same midi note successfully. But modulation is not poly. It will modulate all voices with one mod source.

This is clearly because neither port nor channel are used to differentiate between a mod targeted at this or that voice. This is not the way I understand how MPE works. MPE manipulates the channel.

Sorry if you tried that already, but devices in Bitwig can have "MPE" enabled or disabled in the inspector on the left. That may lead to different behaviours.

But having the same note sound multiple times is an old discussion point in Bitwig, so it's actually possible that they haven't embraced fully independent polyphony as discussed here yet either.

Back to lurking to see if one day I'll write a CLAP-only plugin myself (probably a note device)...

Cheers,

Tom

I don’t know what bitwig internal devices do but the poly mod works great with overlapping notes with surge clap in bws 43. Voice stacking works well also

If you want to see some note only claps I have some started for some more advanced microtuning. They tickle a bitwig bug right now but surge-synthesizer/tuning-note-claps on GitHub may help?

[ThomasHelzle]

So after a few tests with PCK. both PORT and CHANNEL are always zero in bitwig. Why is that? The Key is midi note. If I hit the same key with a long release multiple times. Multiple voices do take the same midi note successfully. But modulation is not poly. It will modulate all voices with one mod source.

This is clearly because neither port nor channel are used to differentiate between a mod targeted at this or that voice. This is not the way I understand how MPE works. MPE manipulates the channel.

Sorry if you tried that already, but devices in Bitwig can have "MPE" enabled or disabled in the inspector on the left. That may lead to different behaviours.

But having the same note sound multiple times is an old discussion point in Bitwig, so it's actually possible that they haven't embraced fully independent polyphony as discussed here yet either.

Back to lurking to see if one day I'll write a CLAP-only plugin myself (probably a note device)...

Cheers,

Tom

I don’t know what bitwig internal devices do but the poly mod works great with overlapping notes with surge clap in bws 43. Voice stacking works well also

If you want to see some note only claps I have some started for some more advanced microtuning. They tickle a bitwig bug right now but surge-synthesizer/tuning-note-claps on GitHub may help?

Ok, then please ignore me

And thanks for the link - I'd probably create generative note devices, your presentation about CLAP where you showed the code encouraged me, I could follow it easily and the CLAP source is very well documented indeed. VST and the other formats always felt like too much pain for my needs - and I'm an old C guy...

Back to lurking for now,

Cheers,

Tom

[baconpaul]

Ok well if you get stuck you know how to find us! But yeah that code is algos like dup note events in to out and add note expressions. A different sort of dup is same code different algo. Have fun!

[robbert-vdh]

So after a few tests with PCK. both PORT and CHANNEL are always zero in bitwig. Why is that? The Key is midi note. If I hit the same key with a long release multiple times. Multiple voices do take the same midi note successfully. But modulation is not poly. It will modulate all voices with one mod source.

This is clearly because neither port nor channel are used to differentiate between a mod targeted at this or that voice. This is not the way I understand how MPE works. MPE manipulates the channel.

If you don't have the MPE switch enabled on the device, you will get the notes as is. That was part of the reasoning why note/voice IDs are necessary. If I as a user draw in three notes, one on channel one, another on channel three, and another on channel 6 (maybe I'm using Bitwig's note effects to process each of those notes individually based on the channel before they are summed into a single stream again), then I want those channels to be preserved when they hit a plugin or device. Having the DAW always rotate channels means that you lose functionality. So if you enable the MPE switch, Bitwig will rotate between channels 1 and 15. But that does mean that you can only have 15 individually addressable voices at a time. And you still need to send the CLAP_EVENT_NOTE_END event to Bitwig to tell it that your voice has ended.

[S0lo]

Thanks for the details @baconpaul, @Urs, @ThomasHelzle and @pdxindy

If you don't have the MPE switch enabled on the device, you will get the notes as is. That was part of the reasoning why note/voice IDs are necessary. If I as a user draw in three notes, one on channel one, another on channel three, and another on channel 6 (maybe I'm using Bitwig's note effects to process each of those notes individually based on the channel before they are summed into a single stream again), then I want those channels to be preserved when they hit a plugin or device. Having the DAW always rotate channels means that you lose functionality. So if you enable the MPE switch, Bitwig will rotate between channels 1 and 15. But that does mean that you can only have 15 individually addressable voices at a time. And you still need to send the CLAP_EVENT_NOTE_END event to Bitwig to tell it that your voice has ended.

The MPE switch was ON by default. Yet there is no automatic channel rotation sent to the plugin. note here that I'm not using MPE hardware, I'm just using a poly LFO. I admit, I don't know how to use Bitwig.

[robbert-vdh]

Thanks for the details @baconpaul, @Urs, @ThomasHelzle and @pdxindy

If you don't have the MPE switch enabled on the device, you will get the notes as is. That was part of the reasoning why note/voice IDs are necessary. If I as a user draw in three notes, one on channel one, another on channel three, and another on channel 6 (maybe I'm using Bitwig's note effects to process each of those notes individually based on the channel before they are summed into a single stream again), then I want those channels to be preserved when they hit a plugin or device. Having the DAW always rotate channels means that you lose functionality. So if you enable the MPE switch, Bitwig will rotate between channels 1 and 15. But that does mean that you can only have 15 individually addressable voices at a time. And you still need to send the CLAP_EVENT_NOTE_END event to Bitwig to tell it that your voice has ended.

The MPE switch was ON by default. Yet there is no automatic channel rotation sent to the plugin. note here that I'm not using MPE hardware, I'm just using a poly LFO. I admit, I don't know how to use Bitwig.

You're right, seems like Bitwig just doesn't do the MPE channel rotation at all for CLAP plugins right now. Pretty sure that's a regression. And that must also be the same issue TAL was running into. I confirmed that it's not just my own lousy programming with Hive, and I only get a single modulation voice per key there (so same key retriggers with long release times also cause the modulation for earlier voices to change). Bitwig currently doesn't check the preferred and supported note dialects at all, so that may be part of it.

[mystran]

Which events should a plugin be prepared to receive in params->flush?

[robbert-vdh]

Which events should a plugin be prepared to receive in params->flush?

Be prepared to receive? Every event and the kitchen sink. But realistically only CLAP_EVENT_PARAM_VALUE events make sense to send and receive here, at least from the current set of core events.

[mystran]

Which events should a plugin be prepared to receive in params->flush?

Be prepared to receive? Every event and the kitchen sink. But realistically only CLAP_EVENT_PARAM_VALUE events make sense to send and receive here, at least from the current set of core events.

Urgh.. in the original spec where this was not allowed when processing is active would mean that it's enough to mostly just parse CLAP_EVENT_PARAM_VALUE (since most of the other stuff is meaningless) ... but with current spec it would seem valid for host to always send parameters with a flush() separate from process() and one should be prepared to parse everything?

Perhaps the spec got "fixed" into a broken state that now brings us the same mess as VST processEvents?

[baconpaul]

A host will never call flush if processing is active - if it does that’s a host bug.

If you get a note on in flush what should you do? I dunno. Ignore it probably.