CLAP... thoughts?

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS

Post

pdxindy wrote: Sat Jun 18, 2022 2:00 am Lots of developers have used VST2 for their development framework. They then use a wrapper to make a VST3, AU, AAX, etc. from the VST2.

Since Steinberg appears to be determined to get rid of VST2, those developers have to move their codebase to another framework anyway. That is the situation with u-he for example.

Developers are not just going, hey, let's spend a bunch of time switching from one to the other for the hell of it. No, many feel like they have to because they cannot depend on what they had previously been doing. That is why there is a lot of interest in CLAP at the moment.

And if CLAP is well designed and makes that transition easier than some other option, then it ends up as less work since a move is needed anyway. It is a bonus that CLAP offers cool functionality that VST doesn't.
Thanks, pdxindy. The reception of VST3 being what it is, it sounds perfect timing for CLAP. The conversations around multi-threading in VST3 terrify me. Steinberg being owned by Yamaha - once companies sell out like that...I can't remember seeing that play out well. It seems like soon afterward there's an immediate race to the bottom in a vapid quest for efficiency at the expense of value creation and a slow deterioration of the core principles that made the company a success in the first place, so I'm not too surprised the defacto VST2 has turned into an apparently hideous monster in the form of VST3.

Post

Wow, this thread produced 20 pages in two days. Something big is happening…

Post

10bd01 wrote: Sat Jun 18, 2022 12:24 amadding development and testing time to a team can affect bug fixes, updates, ticket response time, etc. It's pretty simple.
I fail to see why someone would blame CLAP form this. CLAP is the answer, not he cause.

Post

Urs wrote: Sat Jun 18, 2022 5:38 am
10bd01 wrote: Sat Jun 18, 2022 12:24 amadding development and testing time to a team can affect bug fixes, updates, ticket response time, etc. It's pretty simple.
I fail to see why someone would blame CLAP form this. CLAP is the answer, not he cause.
It could be. Again, I'm not versed in the implications here as much as developers would be. The basic concept is - if your new format were to cause an additional heavy workload on development teams, that it could have effects on aspects of the business that are not directly related to CLAP, and this is why people are expressing concern (whether warranted or not is another question).

Again - if FabFilter were to implement 100 new formats we may see delayed bug-fixes, delayed updates, delayed responses to customer support tickets because the heavy workload is putting a general strain on their business. Are those 100 new formats to blame for those "effects"? Indirectly, yes, they are. If implementing CLAP was to produce these types of "effects" it would also be indirectly responsible, and it WOULD have an impact on end-users. I'm not saying this is the case; I do think others are concerned this could be the case and I don't think it's unreasonable especially as most of us are less informed than the developers - I don't know how much work it requires to implement a new format across a publishers entire product line, and neither do a lot of the people here, hence why I believe they're expressing concern and also maybe a bit of frustration that this is even a topic. I, for one, wish developers would eat their egos and their politics and just agree on a standard like midi so we can all get on with our lives, use whatever DAW we want without penalty, and be able to load our instruments and tools and move on. CLAP may very well turn into this, and I'm all for it!

In general I'm impressed with the effort, with your thoughtfullness and your willingness to put your time and digital sweat behind a solution that's an improvement both in functionality and licensing that the whole industry may benefit from.

Post

It sounds great but I don’t see Logic ever implementing it, to be honest. As long as it’s just an alternative, I’m all for another format I’ll check the box out at installation. Already do it for VST2, VST3, AAX and whatnot
MacMini M2 Pro MacOS Tahoe ……… Reason 14

Post

sQeetz wrote: Sat Jun 18, 2022 6:39 am It sounds great but I don’t see Logic ever implementing it, to be honest. As long as it’s just an alternative, I’m all for another format I’ll check the box out at installation. Already do it for VST2, VST3, AAX and whatnot
From what I've read and seen so far it's not just an alternative - not only is there additional functionality but there also appears to be considerable thought put behind multi-threading which - if well-implemented - is valuable.

If so, Logic gains that additional functionality and also effective thread handling by incorporating CLAP. Functionality can be potentially huge - all U-he and Bitwig needs is one hit that's made with a significant sound that can only be generated using the functionality in CLAP and it could quickly become in-demand and widely implemented. When we're talking about new functionality we're also potentially talking about new (implicitly "fresh") sounds - that's no small thing in an over-saturated market where standing out can be crucial.

Post

10bd01 wrote: Sat Jun 18, 2022 6:35 am
Urs wrote: Sat Jun 18, 2022 5:38 am
10bd01 wrote: Sat Jun 18, 2022 12:24 amadding development and testing time to a team can affect bug fixes, updates, ticket response time, etc. It's pretty simple.
I fail to see why someone would blame CLAP form this. CLAP is the answer, not he cause.
It could be. Again, I'm not versed in the implications here as much as developers would be. The basic concept is - if your new format were to cause an additional heavy workload on development teams, that it could have effects on aspects of the business that are not directly related to CLAP, and this is why people are expressing concern (whether warranted or not is another question).
i'm not a developer or coder.. but the way i understood the general lay of the land w/CLAP is there would be some initial time investment early on then after that period a developer could just make the CLAP plug in and compile/export/wrap (whatever the term is) that as a VST/AU.. but i think the idea is that CLAP has a potentially less bumpy future or more stable more certain future since it will be more open in every way.. as well as more capable..

reading through the various threads there's all kinds of info about the state of VST2/3 and where the dead ends are in terms of features and development.

Post

If Bitwig would just put some effort into their mouse cursor handling situation in macOS when it is at full screen, I would switch back to it in an eyeblink and give CLAP a serious chance. But I seriously doubt that’s gonna happen.
MacMini M2 Pro MacOS Tahoe ……… Reason 14

Post

I've been super stoked about this since it came out. A collective of extremely talented (not to say cutting-edge) developers is behind this - developers that have years of experience with what exactly is wrong with VST. That's the best starting point to get to something better.

Aside from all that, it's just a terrible idea to use a 'standard' that is held by a single for-profit company and Steinberg has more than proven that any worries about that were far from unfounded. The faster we move on from VST the better.

Post

Very excited about the possibilities with CLAP! Couple of questions:

- If a plugin is developed in CLAP and then wrapped to another format, do the multithreading performance gains still end up in the wrapped plugin?

- One huge pet peeve at the moment is having units attached to automation - e.g. a filter cutoff in hz, volume in db, envelope times in milliseconds. I could give specific examples, but it's a mess out there. Does CLAP make this easier / more reliable, and would it also translate to CLAP plugins wrapped to other formats?

Post

dayjob wrote: Sat Jun 18, 2022 7:01 am .. but i think the idea is that CLAP has a potentially less bumpy future or more stable more certain future since it will be more open in every way.. as well as more capable..
Agreed. IMO, even if there is considerable work involved its worth it in the long run. I wish the other companies would just drop their formats and use this (provided CLAP does in practice everything it's promising in concept). Give the developers and end-users a break and stop this mayhem. I'd like to see industry wide agreement to go with it, drop everything else and kumbayas all around, right after renaming CLAP TOP ("The Only Plugin" format). And then - after the heavens open and we all ascend - race conditions will no longer exist and aliasing will be but a dark memory of our distant past.

Post

So much work involved for so little back investment. I don’t want to sound like a pessimist, but I don’t really see this one going anywhere but obsolescence.

I would really love to be proven wrong, though…
MacMini M2 Pro MacOS Tahoe ……… Reason 14

Post

mustgroove wrote: Sat Jun 18, 2022 7:27 am - If a plugin is developed in CLAP and then wrapped to another format, do the multithreading performance gains still end up in the wrapped plugin?
Only if the other format had support for similar threadpooling (ie. if some other standard adds it too, then it can probably be wrapped). The improvement here come from better co-operation between the host and the plugins and you can't really have co-operation with just one party.

Post

This is the developers who can make CLAP widely used in the future, because it’s more convenient for them. As for users, couple of YouTube videos, some simple free marketing (for example, this forum), then Ableton will add CLAP implementation, Studio One on the way and boom - we all have CLAPs and get used for it. Some stuff in this world needs some time to naturally move from “obsolete” to “irreplaceable”.
sQeetz wrote: Sat Jun 18, 2022 7:42 am So much work involved for so little back investment. I don’t want to sound like a pessimist, but I don’t really see this one going anywhere but obsolescence.

I would really love to be proven wrong, though…

Post

sQeetz wrote: Sat Jun 18, 2022 7:42 am So much work involved for so little back investment. I don’t want to sound like a pessimist, but I don’t really see this one going anywhere but obsolescence.
It will work because it has to work. No company wants to be beholden to a third party for their very existence, if they can help it and that's the situation a significant majority of developers find themselves in right now. I can't imagine many devs turning a blind eye and carrying on as normal, so at the very least continued VST3/AAX/AU development will be supported by CLAP in the background. Since CLAP will be at the heart, it stands to reason that supporting it as an end-user format probably won't be too taxing and since it offers real world, easily marketable benefits to end-users, why wouldn't they try to sell it?
Always Read the Manual!

Post Reply

Return to “Instruments”