About CLAP

[Music Engineer]

A new code language, or just a format that is essentially a wrapper, that can also be wrapped.... or something completely different?

a new audio plugin format that will soon replace vst2. wrappers for other formats will be available. what we are talking about here is to wrap it into a plugin framework (like juce) that abstracts away the details of particular formats, such that code can be written once and compiled for all formats - which works in juce already for vst2, vst3, au, aax and soon also lv2 - but support for clap is not yet planned by the juce team, so someone else has to do it - for the time being, at least

[Urs]

so does that mean that the code is not open yet and will only be revealed once it's finished? or do you mean, it wouldn't make much sense to look at the code just yet?

The code for CLAP is publicly available on Github. It makes a lot of sense looking at it now, because if you have an absolutely great idea or if you spot a flaw/bug, there's still a moderate chance to change it.

[AnX]

Ok, still none the wiser, but it won't affect me, so I'll let it fly right over my head...

[audiojunkie]

For the non coding ignoramus users here, ie me, what exactly is clap?

A new code language, or just a format that is essentially a wrapper, that can also be wrapped.... or something completely different?

In simplest terms, it's a new plugin format. As far as you'll be concerned, as long as you have a host that supports CLAP, you'll be able to use CLAP supported plugins just like you do now with VST3 instruments. From your end, you'll notice very little difference.

CLAP is more of an open source developer response to the greatly disliked Steinberg VST3SDK and the fact that Steinberg killed off the liked VST2SDK.

[perpetual3]

For the non coding ignoramus users here, ie me, what exactly is clap?

A new code language, or just a format that is essentially a wrapper, that can also be wrapped.... or something completely different?

In simplest terms, it's a new plugin format. As far as you'll be concerned, as long as you have a host that supports CLAP, you'll be able to use CLAP supported plugins just like you do now with VST3 instruments. From your end, you'll notice very little difference.

Except for polyphonic modulation compatible hosts and bar aware plugins (if you actually need that functionality).

[baconpaul]

so does that mean that the code is not open yet and will only be revealed once it's finished?

Everything is on GitHub in the links urs shared at the top of the thread but if you code to it today it might not work tomorrow and it’s not api or Abi stable yet

So status this week is “open but changing”

[audiojunkie]

Edited

[audiojunkie]

For the non coding ignoramus users here, ie me, what exactly is clap?

A new code language, or just a format that is essentially a wrapper, that can also be wrapped.... or something completely different?

In simplest terms, it's a new plugin format. As far as you'll be concerned, as long as you have a host that supports CLAP, you'll be able to use CLAP supported plugins just like you do now with VST3 instruments. From your end, you'll notice very little difference.

Except for polyphonic modulation compatible hosts and bar aware plugins (if you actually need that functionality).

Simplest terms, Man! Simplest terms!

[EvilDragon]

Ok, still none the wiser, but it won't affect me, so I'll let it fly right over my head...

You'll still be able to run CLAP plugins via a CLAP-to-VST2 wrapper in Orion.

[Music Engineer]

The code for CLAP is publicly available on Github. It makes a lot of sense looking at it now, because if you have an absolutely great idea or if you spot a flaw/bug, there's still a moderate chance to change it.

yes, i know and i had a semi-closer look at it over the weekend already. i was actually referring to this post:

viewtopic.php?f=31&t=574861&start=68

and was just wondering, what these synths are. the api looks good. one can read it and think: oh yes - that makes sense! at the moment, i have only two minor questions:

1: it seems to me that notes have their own event type which is separate from midi-events. does this mean that note events are not supposed to be communicated as midi events anymore? normally, i would expect note events to be just a particular type of midi event

2: what about versioning of extensions? it may be conceivable that one has a given extension and wants to extend that - by an additional callback, say. maybe it could be a good idea to reserve the first field of the extension struct for a version number? that way, we could later add more callbacks to an extension struct and simply bump up the version number. the host could inquire this number after querying the extension to figure out, which callbacks are legal to call. but actually, this doesn't even need to be prescribed in the standard. each extension could just do it, if it wants to. but maybe it should be encouraged as a sort of good practice

[mystran]

2: what about versioning of extensions? it may be conceivable that one has a given extension and wants to extends that - by another callback, say. maybe it could be a good idea to reserve the first field of the extension struct for a version number? that way, we could later add more callbacks to an extension struct and simply bump up the version number. the host could inquire this number after querying the extension to figure out, which callbacks are legal to call. but actually, this doesn't even need to be prescribed in the standard. each extension could just do it, if it wants to. but maybe it should be encouraged as a sort of good practice

No, please don't. We don't need 50 different versions of the same extension and dealing with version numbers is particularly annoying. Better try to get them right, set them in stone and if it turns out later that some extension really needs to be extended, just define a new extension (either additive, or a replacement).

[Music Engineer]

Better try to get them right

isn't that what we always do - and fail? but maybe i'm projecting too much. anyway, i have no strong opinion about this. just a stupid idea that happened to jump into my mind. replacing the extension when it needs to be extended is fine with me as well. i just thought, it would lead to more inquiry work on the host side: query extension supertimestretcher...not found...query fallback-extension timestretcher...

[mystran]

i just thought, it would lead to more inquiry work on the host side: query extension supertimestretcher...not found...query fallback-extension timestretcher...

Yes, that's exactly the point. Because it requires more work, it'll create some natural resistance to change, which is a good thing when you're trying to avoid having 50 different versions of the same thing.

[EvilDragon]

The whole extension principle of CLAP is kind of a replacement for versioning of the plugin format, I think.

[Urs]

One host developer and a developer at a major plug-in manufacturer expressed great dislike of a MIDI-only solution for note events. That was at an early point and hasn't been questioned since. So we simply offer both, as e.g. has always been the case with AU, without too much struggle there at all. Hence I don't see this as a problem.

A bigger problem would be "no MIDI at all" which may at first sound like a good idea ("hosts take care of things") - but in the end it means everyone has to reimplement the little there is again and again to support multiple formats. So we think that it should be up to the plug-in developer to decide whether they wish to go low level (MIDI, MPE) and stay consistent, or high level (Note events, NoteExpressions etc.) and do several specialised implementations (and MIDI again for the things that aren't available in the respective format...)