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

[baconpaul]

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...

right you retrigger them when a new note comes in or something? or just stack until a poly limit?

the voice end message for the various surge mono modes also required a bit of thought. And we probably have the latch mode wrong.

[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...

right you retrigger them when a new note comes in or something? or just stack until a poly limit?

I might or might not add a 'draft' or 'eco' mode eventually, but it's a project where I want it to "feel" like an analog polysynth and suspending voices doesn't play very nice with a signal path that's in constant motion. It's not a very "commercial" design in general, so I just figured I'd go with sound first, second and third and convenience be damned.

That said.. I don't see a huge problem supporting the current CLAP note spec.. I can just send a NOTE_END whenever a voice gets assigned to a new note, no big deal.

ps. For monophonic modes there's the question of whether you should wait for the NOTE_OFF though? For lowest/highest/last note priority to work correctly, you really need the NOTE_OFF message even if technically the note itself is no longer relevant .. and I wonder if host is still required to send the NOTE_OFF anyway even if you've previously sent a NOTE_END already?

[baconpaul]

That said.. I don't see a huge problem supporting the current CLAP note spec.. I can just send a NOTE_END whenever a voice gets assigned to a new note, no big deal.

This is exactly what I did in surge mono modes. Basically decide whether the continued voice uses the old or new voice id (depending on portamento mode basically) and terminate the other.

[Jeff McClintock]

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).

It's a great feature, but it's a little on the nose to claim CLAP did it first when VST3 has had note-expression and GMPI has had polyphonic parameters since at least 2012.

[S0lo]

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).

It's a great feature, but it's a little on the nose to claim CLAP did it first when VST3 has had note-expression and GMPI has had polyphonic parameters since at least 2012.

I didn’t know GMPI had poly params so thanks for correcting me . As far as note-expression. MIDI itself had poly after touch (and channel after touch) since ever. so it’s not like VST3 was the originator of the concept. Some people may think that MPE is what brought poly after touch for MIDI, it’s not true. But of course MIDI is not a plug-in standard, so yeah there is that for VST3 I guess.

[S0lo]

Any idea what the count variable refers to in the clap_plugin_note_ports struct. I assume it's the maximum number of virtual ports that the host/plugin can use to allow the user to send/receive multiple different streams of notes input/output to the plugin/host. Am I right?

Or does this in any way relate to the getNumMidiInputChannels() and getNumMidiOutputChannels() in VST2 ? probably not.

[robbert-vdh]

Any idea what the count variable refers to in the clap_plugin_note_ports struct. I assume it's the maximum number of virtual ports that the host/plugin can use to allow the user to send/receive multiple different streams of notes input/output to the plugin/host. Am I right?

Or does this in any way relate to the getNumMidiInputChannels() and getNumMidiOutputChannels() in VST2 ? probably not.

Yes, you can have multiple note input and output streams, just like you can have multiple audio input and output streams. Whether a host uses any beyond the first one is up to the host of course.

[S0lo]

So after a bit of poking around. I think it's possible to make a single plugin dll that could work as both clap and VST. Using two entry points, doing the necessary mapping/wrapping invisibly inside the plugin. Is that a dumb idea? implications? Any one tried it?

File extension would have to be "dll" probably. would clap hosts scan that? What does the standard say?

[baconpaul]

File extension would have to be "dll" probably. would clap hosts scan that? What does the standard say?

https://github.com/free-audio/clap/blob ... ap/entry.h

ending in '.clap'

You could solve it with a hard link though between the same file in two locations

[baconpaul]

and its not a dumb idea.

[Urs]

We do this. All our plug-ins are the same binary with different entry points for AAX, AU, VST2/3 and now also CLAP. Mind you, on Mac we currently alter the binaries to avoid namespace collisions (Cocoa...) before we do the codesign process (build->duplicate->sed->codesign), and of course we have different info.plists for each format.

[mystran]

So after a bit of poking around. I think it's possible to make a single plugin dll that could work as both clap and VST. Using two entry points, doing the necessary mapping/wrapping invisibly inside the plugin. Is that a dumb idea? implications? Any one tried it?

No, it's not a dumb idea. I compile binaries that have entry points for VST, CLAP and AUv2 and you just rename the bundle and place it into a different directory and it works just fine.

[mystran]

We do this. All our plug-ins are the same binary with different entry points for AAX, AU, VST2/3 and now also CLAP. Mind you, on Mac we currently alter the binaries to avoid namespace collisions (Cocoa...) before we do the codesign process (build->duplicate->sed->codesign), and of course we have different info.plists for each format.

I think you could mostly just have identical info.plist as well, the extra stuff for AU doesn't matter ... but yeah .. there's a potential weirdness with Cocoa if the user tries loading multiple copies of the same extra same binary (even if you generate unique Cocoa prefixes with something like 'uuidgen' for each build).

[Architeuthis]

Looking for a straight answer on this, and I think I already know the answer, but:

I am creating a series of plugins that basically just have parameters for controlling the sound but absolutely no modulation options. No envelopes, no LFOs, etc.

Doesn't clap make this kind of design extremely useful? You get little modular plugins that you can connect together with outside envelopes and LFOs, it becomes very flexible, like, modular out of the box. So I'm thinking... why not continue to just create single standalone "modules"? I even have a new style of ADSR that excels in pluck sounds and has a more organic slope than a traditional ADSR, resulting in a more acoustic sound. I think people will really like to use it on many synths.

Then I also have my analog-imitative standalone filter plugin coming in that would benefit from being able to connect modularly with a synth so you can use the filter as if it was built into a synth.

[baconpaul]

Looking for a straight answer on this, and I think I already know the answer, but:

I am creating a series of plugins that basically just have parameters for controlling the sound but absolutely no modulation options. No envelopes, no LFOs, etc.

Doesn't clap make this kind of design extremely useful? You get little modular plugins that you can connect together with outside envelopes and LFOs, it becomes very flexible, like, modular out of the box. So I'm thinking... why not continue to just create single standalone "modules"? I even have a new style of ADSR that excels in pluck sounds and has a more organic slope than a traditional ADSR, resulting in a more acoustic sound. I think people will really like to use it on many synths.

Then I also have my analog-imitative standalone filter plugin coming in that would benefit from being able to connect modularly with a synth so you can use the filter as if it was built into a synth.

The answer is “kinda mostly but not fully” I think. Or at least my answer would be. Here’s why

First audio is not polyphonic. The back of a synth plugin is a stereo out or what not. So if you want a traditional oscillator into a filter and have two modules the filter will not be polyphonic correctly since it will treat the sum of the voices. Polyphonic audio is hard. Rack does it with a polyphony cap or 16 channels per wire but Clap would have to show channels and multi out multi in.

On the ADSR the problem today is that you cant generate clap param events without knowing the param id. I think about this a lot and have an idea for a channel strip extension which could resolve it. But it means defacto today your ADSR could send note expressions or could send clap param events but generating the coordinates for those events would be a bit cumbersome.

So I think with clap today you can generate much smaller synths. Think of it as a clap is a complete voice but a voice is bigger than a single eurorack module. The clap saw demo works this way. There is no filter envelope. Just a cutoff param. But the voice (Osc + filter) is a single addressable unit.

Helpful?