nvm

[] Peter:H []

Reaper now supports clap
https://forum.cockos.com/showthread.php?t=273164

Ha ha ha ... quote from the link:

"+ CLAP: support "cockos.reaper_extension", which returns a reaper_plugin_info_t structure for REAPER API access (see reaper_plugin.h)"

Holy clap-crap ... so we have Clap and Clap and btw Clap ... each plugin supports/implements extensions ... selected out of the ignorance of the dev? Vital is Clap which might be good, but the Clap Vital does not offer anything other than the VST3 Vital... And now one of the first DAWs supporting CLAP even starts to add it's own none standard extension!? Wat!? I'd be courious when Bitwig will support "cockos.reaper_extension"... I don't know where that should be leading? Steinberg supporting Clap by providing it's unique "VST3" extension?
The idea of CLap might be good, but I actually don't like how it is executed... and following some of the "discussions" around it ... some of the promoters of Clap have in my eyes a rather funny style of "taking" commnity feedback.

[chk071]

Marketing on a free and open source format?

You're funny. As if they didn't do a big marketing campaign for it.

It's big on u-he's and Bitwig's website, and they approached loads of companies, if you haven't noticed.

Not to talk about the free marketing they get from users who don't even know what the stuff is about, but cheer about everything that is tagged "open source" and comes from the people propagating it.

[Held]

"+ CLAP: support "cockos.reaper_extension", which returns a reaper_plugin_info_t structure for REAPER API access (see reaper_plugin.h)"

Holy clap-crap ... so we have Clap and Clap and btw Clap ... each plugin supports/implements extensions ... selected out of the ignorance of the dev? Vital is Clap which might be good, but the Clap Vital does not offer anything other than the VST3 Vital... And now one of the first DAWs supporting CLAP even starts to add it's own none standard extension!? Wat!? I'd be courious when Bitwig will support "cockos.reaper_extension"... I don't know where that should be leading? Steinberg supporting Clap by providing it's unique "VST3" extension?
The idea of CLap might be good, but I actually don't like how it is executed... and following some of the "discussions" around it ... some of the promoters of Clap have in my eyes a rather funny style of "taking" commnity feedback.

The same REAPER extension is already available for VST as well (since 2015). It would be silly not to offer it for CLAP.

It has this lovely functionality which makes editing envelopes much easier.

effVendorSpecific(effString2Parameter, parm, buf, val)

Converts the user's string to a normalized parameter value, without setting the parameter. Reaper uses this when the user is manually editing an envelope node, for example. Calling with buf="" is a test for function availability.

I think Melda plugins actually use it, but I'm not sure.

You're funny. As if they didn't do a big marketing campaign for it.

It's big on u-he's and Bitwig's website, and they approached loads of companies, if you haven't noticed.

They were actually approached by some of these companies before CLAP was officially announced.

Not to talk about the free marketing they get from users who don't even know what the stuff is about, but cheer about everything that is tagged "open source" and comes from the people propagating it.

The people who complain about it also rarely know what CLAP is about, so that should even out

[chk071]

They were actually approached by some of these companies before CLAP was officially announced.

Well, unless they can mind read, they got to have heard of it somewhere.

[Held]

They were actually approached by some of these companies before CLAP was officially announced.

Well, unless they can mind read, they got to have heard of it somewhere.

It seems you consider every conversation where you mention something you like or work on a big marketing campaign.

[chk071]

Implying that that's where they heard of it.

Anyway, it doesn't matter, what matters is that they, of course, did market and spread the word about CLAP.

[mtelesha]

I think people don't understand what is Clap strengths (multi-processor threading) and what is unique (able to save plug-in settings and or samples within a project file). It also allows for other things I don't think most people care about aka MIDI 2 per note modulation and micro tonal notes.

CLAP would give more power to musicians and to performances. It especially allows much easier collaboration between different people and make switching machines easier.

It's not VST open sourced it goes much deeper and helps us the users.

[Tagirijus]

And now one of the first DAWs supporting CLAP even starts to add it's own none standard extension!? Wat!? I'd be courious when Bitwig will support "cockos.reaper_extension"... I don't know where that should be leading?

Can you maybe elaborate a bit to someone (me) not 100% getting what you are talking about?

I am quite eager to understand, but I might simply just not know about the technical premise here. As far as I might have understood (but not sure): do you mean that this quote from the changelog says that basically Reaper does not really "support" CLAP, but rather having some own extensino going on, wrapped in CLAP or so? I am curious and I want to understand.

Thanks for any upcoming explantion here!

[Hexspa]

I'm looking forward to the nondestructive modulation. To me, that's how it should've been from day one. It always seemed weird to me that, once I modulated a parameter in the daw, I could no longer change that knob without overriding the automation lane. This CLAP feature seems more natural.

[] Peter:H []

And now one of the first DAWs supporting CLAP even starts to add it's own none standard extension!? Wat!? I'd be courious when Bitwig will support "cockos.reaper_extension"... I don't know where that should be leading?

Can you maybe elaborate a bit to someone (me) not 100% getting what you are talking about?

I am quite eager to understand, but I might simply just not know about the technical premise here. As far as I might have understood (but not sure): do you mean that this quote from the changelog says that basically Reaper does not really "support" CLAP, but rather having some own extensino going on, wrapped in CLAP or so? I am curious and I want to understand.

Thanks for any upcoming explantion here!

One of CLAPs USPs is the claim that it is extensible by so called "extensions". CLAP core API contains mechanisms that a plugin can get hold of an extension by "asking" the DAW whether it supports it. Such a extension is "thread pool" for instance.
Problem is that there's no specification what set of extensions a DAW or a plugin must support.
On top DAW and plugin vendors are free to - out of their own ignorance - invent new custom extensions. If then DAW A claims "Best used with CLAP plugins - but very best with extension DAW-A-CLAP-EXT" ... and when they then create "CLAP plugins" which only work, when they have this extesnsion ... wtf ... this means we get a bunch of CLAP sub-standards ... and no CLAP plugin is like the other CLAP plugin.

And sbdy mentioned "threading" as advantage. Ha ha ha funny. they claim that there's exactly one thread pool which can be used by all plugins. And they say they have evidence that it works and provides benefits. I have not seen their documented, reproducible test setup. sure they have some smoke testing ... in their laboratory setups.
a.) when you set plugin isolation to "process per plugin" ... then I bet bitwig will have to create more than one threadpool, i.e. one for each process that hosts a plugin.In such scenarios the DAW thread pool is no better than that of a plugin.
b.) when you get ill behaved plugins which exhaust or block the thread pool by stupid things ... then a single weird plugin might spoil the fun. That means DAWs should have a config "Allow plugin to use DAW Threading" and each plugin must be prepared to not be able to use the DAW thread pool - either because it is on the blacklist or the DAW does not have it - and come with it's own.
c.) when a number of plugins uses different philosophies in their threadpool
d.) when different DAWs behave differently using threading ... The signature of an API is one thing, but the semantics and non-functional properties of different Implementations might be difficult to handle.

Sorry, I work in IT for more than 20 years (companies > 10.000)... "a standard" is a different beast then having a nice idea. it needs good governance otherwise it will not fly. And as I said, the style of discussion of the protagonists is a little looking down from a imagined top ... I personaly don't like it.

] peter:H [

[Held]

One of CLAPs USPs is the claim that it is extensible by so called "extensions". CLAP core API contains mechanisms that a plugin can get hold of an extension by "asking" the DAW whether it supports it. Such a extension is "thread pool" for instance.

VST supports extensions too. So it's definitely NOT a USP.

Doesn't seem to have caused many problems for VST until now. You can use Melodyne, for example, both in DAWs that support ARA and in DAWs that don't. Extensions are great.

Problem is that there's no specification what set of extensions a DAW or a plugin must support.

None of them. That's why they are called extensions.

Extensions are way for vendors to introduce features that can later be adopted into the standard if they prove themselves to be useful. This has worked well for OpenGL/Vulkan, for example.

[] Peter:H []

One of CLAPs USPs is the claim that it is extensible by so called "extensions". CLAP core API contains mechanisms that a plugin can get hold of an extension by "asking" the DAW whether it supports it. Such a extension is "thread pool" for instance.

VST supports extensions too. So it's definitely NOT a USP.

Doesn't seem to have caused many problems for VST until now. You can use Melodyne, for example, both in DAWs that support ARA and in DAWs that don't. Extensions are great.

Problem is that there's no specification what set of extensions a DAW or a plugin must support.

None of them. That's why they are called extensions.

Extensions are way for vendors to introduce features that can later be adopted into the standard if they prove themselves to be useful. This has worked well for OpenGL/Vulkan, for example.

You are sure, you read github carefully!? It lists
Fundamental Extensions: "This is a list of the extensions that you most likely want to implement and use to get a basic plugin experience:" which are audio-ports, note-ports, params, state, ...
Support Extensions: [...]
Extra Extensions: [...]

If all of the fundamental category is "none of them. That's why they are called extensions" .. then implementing a CLAP compatible DAW is easy. Mine does not support any extension, even not the fundamental ones.

[Held]

Some plugins are pretty minimal. If you only want to output a sine wave or noise, you wouldn't need to implement note-ports.

What would be the benefit of forcing a sine-wave generator to handle MIDI?

[masitito]

I don't care if it has any real world advantages right now as long as it is open. VST is as closed as it can go except that it was free for business entities. Who needs those damned for-fun devs in this hard business world?

What I don't know if CLAP is really open. Open not only to be used without license fee by everyone but also open to contribuition for future version.

[mevla]

The Open Source scene has degraded quite a lot since 10, 15 years ago. Sure, as you have the code you can do the modifications you want, eventually. When it's a OS-wide policy it's another matter. If you even remotely ask technical questions about a policy, and you insist, you'll get kicked out. When once there was help and a rel sense of community around, nowadays it's mostly no better than businesses .