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

[baconpaul]

Installed Bitwig demo to see if the clap-wrapper I wrote a while ago would work... and it doesn't seem like Bitwig wants to send me any MIDI? The same synth happily plays stuff in MultiTrack Studio (loaded as CLAP) so... I'm puzzled? That wrapper only advertises DIALECT_MIDI.

edit: Ok.. so after some debugging and figuring out where my debug prints go (redirected to engine.log) ... it looks like Bitwig is calling note_ports->count twice (once for input, once for output) .. but it literally never calls note_ports->get to actually fetch the info.. and just blindly assumes DIALECT_CLAP is fine..

Yes I think this is a bitwig bug and I see the same.

can you add it here:

https://github.com/free-audio/interop-tracker

[S0lo]

1. Most plugins already have some form of internal modulation capabilities that don't change the state of the preset. So, is another layer from the host really adding something?

If you read the other KVR Clap forums you can find lots of places where people can accomplish things using the augmented modulators they can't with the internal mod matrix. With the clap saw demo, for instance, i didn't even code a filter envelope I just made the cutoff and resonance poly-mod.

Come on, be fair with me. I've already mentioned this in the pros number 3 !!

3. Host modulation may allow some types of modulation that the plugin is not capable of.

[baconpaul]

Come on, be fair with me. I've already mentioned this in the pros number 3 !!

Ah yea. But doesn't your pro 3 then answer your con 1? I guess your list wasn't MECE!

[S0lo]

Come on, be fair with me. I've already mentioned this in the pros number 3 !!

Ah yea. But doesn't your pro 3 then answer your con 1? I guess your list wasn't MECE!

I could also say that con 1 answers pro 3 . That is, If I argue that Internal modulation is usually capable enough that it's not worth it for host modulation to exist.

This is highly subjective, argumentative and opinionated subject. No one can come and say with a straight face and absolute certainty that host modulation is an essential must have. (Edit: specially when host automation and internal plugin modulation exist)

There is no reason to be so defensive.

[ThomasHelzle]

After using Bitwig since 2013, I can, with a straight face and absolute certainty say, that host modulation, done like in Bitwig, is the most brilliant thing in any DAW ever.

And everybody is welcome to disagree, since yes, it's subjective.

In your modular that may be not the case or in VCV, but I do not have a single "normal" plugin that doesn't lack some kind of modulation or other that Bitwig offers.

So yeah, I think the dual Automation/Modulation concept is brilliant from a user perspective.

But it may not be needed in a modular.

Cheers,

Tom

[S0lo]

3. Some plugins may support only automation, others may support only modulation. Some may support both. Host vendors, Be prepared for customer complaints like "Why is modulation not working?" , "Why is automation not working?". "Whats the difference between this and that?". etc.

This is why the CLAP spec requires a plugin to advertise exactly what it supports on a per parameter basis. A host which allows a user to configure polymod on a param which doesn't support it has a bug.

Even if the host doesn't allow it. That may not stop the user from complaining. Why? Because he is used to it working with other plugins.

[S0lo]

BTW: Just skimming through VST3 ... they use a noteID as well attached to their Events, i.e. NoteEvent and NoteExpressionValueEvent. Seems like a common succesful pattern.
So let's say Bitwig sends 5 NoteEvents, pitch is A4, tuning is from -20cents to 20 cents in 10 cents steps and gives them ids A4_1 up to A4_5 ...

Yeah, before clap, DAW automation of parameters was only monophonic (except for MPE). clap introduces polyphonic param automation/modulation which is a brilliant concept that no format has done before (AFAIK). This means that each note_id can be modulated differently. Which brought the debate about using voice_id instead.

[baconpaul]

There is no reason to be so defensive.

Written text is hard to interpret. I was simply trying to answer your questions and didn’t mean to appear defensive.

Best

[baconpaul]

BTW: Just skimming through VST3 ... they use a noteID as well attached to their Events, i.e. NoteEvent and NoteExpressionValueEvent. Seems like a common succesful pattern.
So let's say Bitwig sends 5 NoteEvents, pitch is A4, tuning is from -20cents to 20 cents in 10 cents steps and gives them ids A4_1 up to A4_5 ...

Yeah, before clap, DAW automation of parameters was only monophonic (except for MPE). clap introduces polyphonic param automation/modulation which is a brilliant concept that no format has done before (AFAIK). This means that each note_id can be modulated differently. Which brought the debate about using voice_id instead.

One thing I wish we had done but we didn’t was distinguish more between note (note on off) and voice (voice choke voice end voice id) rather than use the word note everywhere

One way to think about it is: the daw has an expected model of voices which is: a note on creates one, but a note off doesn’t destroy one. That’s why a note on comes with an address to refer to the imputed voice and why the plugin not the daw terminates the voice

Using note in the variable and event names for both requires you to know “note as keypress” (on, off, expression) vs “note as voice” (end, maybe choke, modulation).

Too late to rename now I guess although maybe we could add alias names for the events at least. And my colleagues may not agree with me of course but when I coded up surge I had to have the two types of note in my head

[baconpaul]

Even if the host doesn't allow it. That may not stop the user from complaining. Why? Because he is used to it working with other plugins.

My experience shipping audio software is that optimizing for no user complaints has only one solution, which is not compatible with shipping audio software.

But I do agree that the user experience needs to be robust and clear - bitwig does a nice job with this distinguishing poly from mono - and for some synths users are already starting to request polymod features in synths where they don’t exist. We’ve been doing a lot of work on the juce extensions to make this easier recently also.

But a project like clap spans years not weeks. It will take time for these features to arrive in plugins and daws even in the most optimistic success scenarios. I hope users can be enthusiastic and polite!

[S0lo]

One thing I wish we had done but we didn’t was distinguish more between note (note on off) and voice (voice choke voice end voice id) rather than use the word note everywhere

One way to think about it is: the daw has an expected model of voices which is: a note on creates one, but a note off doesn’t destroy one. That’s why a note on comes with an address to refer to the imputed voice and why the plugin not the daw terminates the voice

Using note in the variable and event names for both requires you to know “note as keypress” (on, off, expression) vs “note as voice” (end, maybe choke, modulation).

Too late to rename now I guess although maybe we could add alias names for the events at least. And my colleagues may not agree with me of course but when I coded up surge I had to have the two types of note in my head

I may need to reread that again to fully get your point

The thing that I find hard to explain, which I tried to do earlier in this thread. Is that if the plugin runs out of voices (i.e all voices are playing), and a new note comes in, the plugin's only option is to stop one of the playing notes in one of the voices and use that voice to play the new incoming note. While doing so, it may or may not choose to reserve that stopped note in a memory stack. So that if the new note that just came in ends, while the older not didn't, the plugin can return back the old note to be played by that voice. (similar to what happens in monophonic synths)

This, when understood, essentially means that there is a one to many relation ship between playing voices and notes. So one voice can identify multiple notes, but one note can identify only one voice. This means that a voice will not stop playing until all notes that are associated with it stop playing and release times fully passes.

Again, this is only true when the plugin chooses to reserve the old note in memory. If it doesn't then there is obviously a one to one relation ship between notes and playing voices. In this case the voice will stop when the associated single note stops playing and it's release time passes.

Add to all this, that release times aren't always easy to predict even from the plugin point of view.

Because of all this complexity, I've suggested earlier that an option should be provided to simply allow the user to choose the release time at the host. The user is really the best one who can hear when the note really ends and consequently should be able to manually decide when the mod ends. May be the user even wants to end the mod before release ends!! That should be his choice. I think.

But I understand that it's hard now to change things after release of CLAP. So these are just my humble thoughts.

[mystran]

I think it's important to keep in mind that the more complicated you make a spec, the less likely it is that people are actually going to support it. That's why 90% solutions for things like these can be better than the 100% solution that's three times more complicated.

[S0lo]

I think it's important to keep in mind that the more complicated you make a spec, the less likely it is that people are actually going to support it. That's why 90% solutions for things like these can be better than the 100% solution that's three times more complicated.

I agree. It is for this very idea, that I suggested to hand out the control to the user and not deal with the complexity of it. As an option, not a must. (Edit: talking about when to stop the mod)

[baconpaul]

I think it's important to keep in mind that the more complicated you make a spec, the less likely it is that people are actually going to support it. That's why 90% solutions for things like these can be better than the 100% solution that's three times more complicated.

I agree. It is for this very idea, that I suggested to hand out the control to the user and not deal with the complexity of it. As an option, not a must. (Edit: talking about when to stop the mod)

I personally think that would be a really inferior experience in an environment like bitwig or others, but there is absolutely nothing stopping a host manufacturer doing that rather than listening to plugin voice end messages!

The reason it seems natural to do polymod on polysynths in bitwig is because the voice lifetimes match up. If the internal modulators didn't need hand-configured releases and the external ones did, that obvious asymmetry seems a bummer.

But also voice end management really isn't that complicated in polysynths! If you are a polyphonic instrument you already have code to end voices. Otherwise you wouldn't end voices. It took me a couple of hours to wend the message from the surge voice manager out to the clap layer, and that involved writing the clap layer at the same time.

[mystran]

But also voice end management really isn't that complicated in polysynths! If you are a polyphonic instrument you already have code to end voices. Otherwise you wouldn't end voices.

I don't end voices in one of my current projects...

ps. It's still a polysynth project.