CLAP... thoughts?

[] Peter:H []

- AU (AFAIK) is the format that introduced the idea of automation having units attached, but there's plugins where this works in Logic but not elsewhere (e.g. in Ableton, you only get 0.0-1.0)

Fun anecdote: In 2003 (or as it 2004?) I had beers with Steinberg devs and I told them straight away that their plans to keep parameters 0-1 in VST3 would be a failure.

Yes, CLAP has non-normalised parameter values, just like AU.

If a host renormalises those to 0-1, they're doing it wrong.

Normalizing has one big advantage - at least that's why you do it in ML when using many inputs for instance into linear regression model. A parameter my easily "trump" another when it's larger by some magnitudes ... and I think combining values which are normalized might be easier.

To generalize it - the claims about CLAP that CLAP is XYZ can be seen from a different view point as well. I'm still skeptic that a concept like a thread pool will solve any mt issue it can help to solve some, but it will never solve any general issues with it. I think that bad behaving plugins written by devs that don't get mt before CLAP will be bad behaving CLAP plugins ported to CLAP by devs that don't get mt. I work with thread pools for a really long time ... Plugins that push tasks to your threadpool which are prone to deadlocks because the devs don't get how to properly avoid deadlocks by a resource aquisition protocol ... wil eat up all treads over short time.

So Urs, sorry, CLAP is not the solution to everything. I would not try to make it look like. It might fail to meet expectations. It's a good API compared to VST with respect to many viewpoints.

Nevertheless I believe in CLAP from my experiments with Surge XT ightly and Bitwig 4.3 beta.
But I think there are decision ahead that are really crucial. If for instance each and any DAW will introduce it's onw extensions then the "standard" (which CLAP by the way is not, in terms of a standardization body like ISO) will disintegrate and it will create islands of different CLAPs, because the exact opposite of "One Company controls everything" (VST, AU,...) is "everybody is free to do whatever she wants" is not favourable for the sole sake of being different to VST.

So kind of crunch time. Don't promise too much (it some times already looks like pure marketing claims), get DAWs on board and get the "standard" thing right.

[BenfordLaw]

were coded competently and correctly from the start.

That would include most every plugin that any of us already own from top-tier developers.

That's reaching quite a lot, considering what a mess VST3 is and its idea of "correct" is extremely, shall we say, open to interpretation.

Oh come on now. That may be clever and snarky, but really you’re impugning the work of the leading audio software developers, which is neither fair nor credible.

LOL. Appeal to authority fallacy. As if no software company has ever come up with a bad idea before, and then refused to admit they were wrong... (Windows 8's Start Menu, for example? Microsoft's 'Ribbon'? etc.)

[sacer]

If I record midi mapped via CC every value moved by a midi controller starts at zero.
so I have to start playing and reset the preset to hear the recorderded automation again.
Does CLAP facing this issue ?

I contacted ableton beta sugesstion to early adapt CLAP. In the past they have been very late with vst 64 bit support and VST3- so this could be a chance to win some Steinberg / logic customers but they can also lose some customers to Bitwig, if they join CLAP too late. CLAP sounds very nice on the paper.
Congratulation to Bitwig and U-he

[Urs]

Normalizing has one big advantage - at least that's why you do it in ML when using many inputs for instance into linear regression model. A parameter my easily "trump" another when it's larger by some magnitudes ... and I think combining values which are normalized might be easier.

If the values represent abstract data that interacts, yes, normalising makes sense. In plug-ins where e.g. +/- 24 dB for a gain parameter represent actual, meaningful values, normalising is counter productive.

To generalize it - the claims about CLAP that CLAP is XYZ can be seen from a different view point as well. I'm still skeptic that a concept like a thread pool will solve any mt issue it can help to solve some, but it will never solve any general issues with it. I think that bad behaving plugins written by devs that don't get mt before CLAP will be bad behaving CLAP plugins ported to CLAP by devs that don't get mt. I work with thread pools for a really long time ... Plugins that push tasks to your threadpool which are prone to deadlocks because the devs don't get how to properly avoid deadlocks by a resource aquisition protocol ... wil eat up all treads over short time.

How exactly is there a chance for deadlocks in the API? It would be stupid of developers to embrace CLAP's thread pool and still add mutexes - because those are exactly the thing that's not need in the model. If you can prove such a flaw in the design, you're welcome to report it in our discussion on Github.

If for instance each and any DAW will introduce it's onw extensions then the "standard" (which CLAP by the way is not, in terms of a standardization body like ISO) will disintegrate and it will create islands of different CLAPs, because the exact opposite of "One Company controls everything" (VST, AU,...) is "everybody is free to do whatever she wants" is not favourable for the sole sake of being different to VST.

That's a bit of a slippery slope argument here. CLAP defines core extensions that will always be valid, and the issue of Governance will be decided later this year. I highly doubt that adding private CLAP extensions without publishing them will help anyone (except petri dish sized environments), nor will the have a chance to water down the standard part.

[mystran]

Normalizing has one big advantage - at least that's why you do it in ML when using many inputs for instance into linear regression model. A parameter my easily "trump" another when it's larger by some magnitudes ... and I think combining values which are normalized might be easier.

If the values represent abstract data that interacts, yes, normalising makes sense. In plug-ins where e.g. +/- 24 dB for a gain parameter represent actual, meaningful values, normalising is counter productive.

I feel like this is somewhat of a matter of taste and personally I very much prefer to have all my (continuous at least) parameters in normalized ranges, but rather than arguing for or against the merits of one or the other, I'd argue that it's really not the host's business to care. The host needs to know the minimum and maximum obvious (eg. for editing automation curves graphically and things like that), but the user really shouldn't ever have to see the actual numerical values at all.

The right thing to do is to let the plugin do all conversion to and from textual representations (which is all that the user should ever see) and that's where VST2 really fails, because it has no interface to convert anything beyond getting the current value as text. AU has proper interfaces, CLAP has proper interfaces.. so really the user shouldn't ever see the raw numeric values if both plugin and host play by the book... but I suspect some of the issues even with AU come down to "wrapped VST2 plugins" again... so getting rid of that is probably going to solve a number of issues here as well.

[Urs]

A CLAP plug-in wrapped as VST3:





So yeah, this is gonna happen. All open source, available to download on GitHub, MIT License, ready for anyone to adopt and build upon right now.

[zvenx]

That was quick .

I am missing an element.. One needs a vst3 license to output vst3 plugins on juce right?
How is it different for Clap plug in wrapped as VST3?

thanks in advance.
rsp

[fisherKing]

this has turned into an amazing discussion (some posts notwithstanding), and i have learned a hell of a lot. who knew the lunatics on the kvr forums were also this smart?

for me... i'll watch CLAP development, see where it goes. see if it affects me (as a logic user) down the line.

but am glad to be learning so much. thanx ppl

[baconpaul]

Normalizing has one big advantage - at least that's why you do it in ML when using many inputs for instance into linear regression model. A parameter my easily "trump" another when it's larger by some magnitudes ... and I think combining values which are normalized might be easier.

Peter - the clap parameters are required to advertise a min and max and also whether they are continuous or stepped (stepped ones implying integer steps from min to max). With this information a model could easily regularize to make sure values aren’t outsized. (I presume if you can do gradient descent on a model you can divide )

There is a subtlety in setting up your params that the interaction should feel right and modulate properly. For instance in my clap saw demo I represent filter cutoff in midi note from 0…127. This means a bipolar modulator of size 12 does an up down octave sweep - the param is linear in experienced outcome. If you made another choice your external modulation could be funky since the plugin has full control on value to meaning.

Hope that helps!

[baconpaul]

this has turned into an amazing discussion (some posts notwithstanding), and i have learned a hell of a lot. who knew the lunatics on the kvr forums were also this smart?

for me... i'll watch CLAP development, see where it goes. see if it affects me (as a logic user) down the line.

but am glad to be learning so much. thanx ppl

I am also a logic user for a lot of my music (but am considering switching some but not all of it to bitwig (and also to another environment I have in mind which doesn’t exist yet)) so the au wrapper is important to me too. I would have been hesitant to invest as much time in clap as I did if I didn’t think the wrappers will bear fruit.

[Urs]

That was quick .

I am missing an element.. One needs a vst3 license to output vst3 plugins on juce right?
How is it different for Clap plug in wrapped as VST3?

thanks in advance.
rsp

There are different models.

Firstly, any developer who does open source CLAP plug-ins does not need any proprietary license to use this. Secondly, any developer who has a proprietary license can release closed source CLAP plug-ins as VST3 with this.

Thirdly, an open source project can create an adapter without the proprietary license which users can download to adapt their collection of CLAP plug-ins to VST3. The developers of CLAP plug-ins would not be involved in the process at all, hence do not need any proprietary license.

And then, any company with a proprietary license can create an an adapter which either lets users adapt their CLAP plug-ins to VST3, or which CLAP developers can resell as add-on to their plug-ins. Latter again works without the necessity of signing any proprietary license.


JUCE has nothing todo with this, but if JUCE supported CLAP, the implications to VST3 and the proprietary license are the same, if people did compile their JUCE for CLAP, but not VST3.

[koalaboy]

How exactly is there a chance for deadlocks in the API? It would be stupid of developers to embrace CLAP's thread pool and still add mutexes - because those are exactly the thing that's not need in the model. If you can prove such a flaw in the design, you're welcome to report it in our discussion on Github.

Perhaps Peter's point (I'm guessing, but have worked with lots of 'bad' thread ideas) was more that the API isn't at fault, but it's not a silver bullet unless used properly. Of course, this would make sense, but there will always be folk claiming that CLAP didn't solve their thread problems - because they were doing stupid things, but that won't come out.

Peter mentioned resource acquisition, so that would make indicate the problems are outside of the API, but you know some developers will still claim it wasn't their fault. There are cases when correct pooling can expose other bugs that never happened in the 'wrong' setup, and I'm sure there will be some claims that CLAP 'broke the threading' as well.

I fully believe that CLAP is taking the correct approach, and it shouldn't try to fix all of the problems that are more to do with core development - leave that to frameworks for folks that want it. I guess it's just to be careful around how some benefits are worded such that they can be taken the wrong way ?

Of course, I could be completely wrong as to the intention here as well, and would also welcome to see scenarios where CLAP will cause more problems, as I've not noticed them from an engineering perspective yet.

[Urs]

Well the alternative to CLAP's thread pool is the "each plug-in minding their own business". It's not like multithreading is going away or anything. It's just that the way it's solved in CLAP is infinitely better than the alternative.

[10bd01]

That's a bit of a slippery slope argument here. CLAP defines core extensions that will always be valid, and the issue of Governance will be decided later this year. I highly doubt that adding private CLAP extensions without publishing them will help anyone (except petri dish sized environments), nor will the have a chance to water down the standard part.

Doesn't the MIT license permit distribution with modification? In this case, couldn't "another CLAP" be created by alterations to the core? I'm interested in seeing how the governance plays out - how this is going to be maintained through time has a big impact on how successful it's going to be IMO.

I'm having flashbacks of many visits to caniuse.com, trying to figure out what features are available to me in the multiple implementations and interpretations of "universal standards".

[Urs]

Sure, people can just copy it and make their own version of CLAP. I just don't see any point in doing that.