CLAP... thoughts?

[pdxindy]

What if they believe, that plugins properly coded for vst3 as is today, and host not encumbered with keeping vst2 compatibility, will already be able to do all of this?
#GrassIsGreener
rsp

That they could believe that even with all the evidence to the contrary shows exactly why developers are frustrated with Steinberg's attitude. Steinberg doesn't listen and stubbornly sticks to their ideas no matter how many developers explain why it doesn't work for them.

I've read more enthusiasm from developers for CLAP in the last week than I have in over a decade of VST3.

[zvenx]

Time will tell eh?
rsp

[Urs]

Belief offers no protection from reality.

[EvilDragon]

What a statement!

[Urs]

(well, I'm sorry, but we have not spent all this time and money on a bland copy of what exists. We went further, by a far, far margin)

[fisherKing]

Belief offers no protection from reality.

sadly, this doesn't stop people from clinging to their beliefs, even in the face of a conflicting reality...

[zvenx]

But there is as yet no conflicting reality.. There is no publicly released vst3 Host unencumbered with vst2 compatibility.
rsp

[pdxindy]

Belief offers no protection from reality.

So very true...

[mystran]

I've read more enthusiasm from developers for CLAP in the last week than I have in over a decade of VST3.

It's because the moment you start looking at the clap headers, you are delighted by the number of small things that it improves over the existing APIs where as with VST3 you have this huge pile of poorly organized garbage where you don't even quite know which parts you should bother looking at and which parts are there simply so that Steinberg can try to teach you poor development practices.

When some developers spend 10+ years adopting VST3, you can rest assured it's not because it takes 10+ years to write a VST3 implementation, but rather because in the process many of the need 9.5 years worth of therapy to process the trauma caused by even looking at it.

[_leras]

First off, simply every plug-in that comes in more than one flavour is already wrapped. The performance overhead of wrappers and adapters was next to nothing in 2002, and with today's computers it will be very difficult to reliably measure *any* performance impact.

Featurewise CLAP can not magically add anything when there's nothing there. A VST wrapped to CLAP will only ever offer what a VST offers. Also a CLAP wrapped to VST will also only ever offer what a VST offers. Unless of course, maybe, VST gets updated with a feature that CLAP does not offer, and then we'd first have to add the corresponding extension to CLAP and the wrapper to get back to what I said before.

The main benefit of CLAP-as-SomeFormat is that CLAP has inherent stability testing for many common bugs. Hence, fewer crashes are a very likely outcome of using CLAP somewhere in the development process of a plug-in or host.

Thanks so much for sharing your knowledge of this. And of being part of pushing for better technology. The more I read, in this thread, about CLAP, the more I appreciate it!

Regardless of per note, threading etc. This seems like a really great exercise in making life easier for DEVs.

Would you say that CLAP is a replacement for Juce for people wanting to start plug in development?
(given it seems it can/will be fairly straightforward to wrap it for other formats and be cross host/platform)

[mystran]

Would you say that CLAP is a replacement for Juce for people wanting to start plug in development?
(given it seems it can/will be fairly straightforward to wrap it for other formats and be cross host/platform)

It's not a replacement for JUCE (and most of this also applies to iPlug, etc). It's a different kind of thing on a different level of abstraction, so to speak. CLAP is more of a language for a host and a plugin to talk to each other, while JUCE is a complete "toolkit" or "framework" for building software (not limited to plugins, even though it's popular for plugin development) that takes care of talking to the operating system and provides you with all kinds of utility functionality.

CLAP and JUCE (or some other toolkit) solve very different problems and there are apparently already unofficial modules that add CLAP support into JUCE.

[Urs]

Would you say that CLAP is a replacement for Juce for people wanting to start plug in development?

Not really, it depends on what a developer wants to do. JUCE is a lot more than just a way to create a plug-in, and we certainly hope that it picks up CLAP officially.

[Funkybot's Evil Twin]

Time will tell eh?
rsp

Hasn't it already though? It's not like the VST3 adoption has been fast.

[vurt]

i really don't understand the negativity through the thread?
if you don't see the benefit, don't use it, it won't effect you in any way!!!

id understand if it's existence caused issues with vst, but it doesn't, it's just a separate choice, for those who do see the benefit

(sorry, i don't do memes)

[zvenx]

Time will tell eh?
rsp

Hasn't it already though? It's not like the VST3 adoption has been fast.

It wasn't about adoption it was about capability and functionality (and specifically on a host that can soar without vst2 compatibility with properly coded vst3 plugins (not wrapped)), my post that is.
rsp