CLAP... thoughts?

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

Post

EvilDragon wrote: Sat Jun 18, 2022 9:20 pm It is no secret many, many devs had issues with VST3 implementation. And you can read a bunch of such commentary right here in the developer subforum. Many from "leading audio software developers", too.
But that is mostly in the past now, isn’t it? There were bugs to work out and features to be implemented for years with VST3. Isn’t CLAP going to be the same (as is ALWAYS the case in software), or after 3 harrowing days, is CLAP immaculately conceived? (It would seem there is a cult of u-he disciples on KVR who believe that. :hihi: )
THIS MUSIC HAS BEEN MIXED TO BE PLAYED LOUD SO TURN IT UP

Post

jamcat wrote: Sat Jun 18, 2022 9:10 pmSo without a tangible incentive to port to CLAP, such as a major DAW going CLAP-only, the way Logic went AU-only (and Cubase went VST only before DX finally died hard), why would retroactive CLAP support have a different fate?
Aren't the incentives that have been brought up multiple times (legal hazards, etc.) tangible enough?
I think that if Bitwig and u-he really believe in CLAP this much, and are so opposed to the draconian practices of Steinberg and Apple, and are so sure they’ve got the audio industry on their side, then they should drop VST and AU support completely. That’s the only thing that will force a change.
Why would they do such a thing? It's exactly the other way around: if the advantages of the new format are convincing enough (and I happen to think that they are), noone needs to force-feed anything to anyone. The transition will just happen naturally. Maybe we will see a permanent coexistence but it may also be, that we will indeed see a sort of phasing out of the other formats...but this will then happen slowly and gradually over many years, maybe a decade.
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

jamcat wrote: Sat Jun 18, 2022 9:29 pm But that is mostly in the past now, isn’t it?
No. VST3 still has plenty of issues and hoops to jump through. Features that don't work properly even in Cubase itself (program lists for example)!
jamcat wrote: Sat Jun 18, 2022 9:29 pmThere were bugs to work out and features to be implemented for years with VST3.
And there are still bugs to work out and there are still features Steinberg is not implementing after over a decade of requests from developers. Yay!

Post

Music Engineer wrote: Sat Jun 18, 2022 9:30 pm
jamcat wrote: Sat Jun 18, 2022 9:10 pmSo without a tangible incentive to port to CLAP, such as a major DAW going CLAP-only, the way Logic went AU-only (and Cubase went VST only before DX finally died hard), why would retroactive CLAP support have a different fate?
Aren't the incentives that have been brought up multiple times (legal hazards, etc.) tangible enough?
No because as I have pointed out multiple times, those legal hazards will still exist so long as they continue to support VST, which they all will continue to do.

If you are speaking about wrapped VST2 plugins specifically, that doesn’t apply to the myriad developers who have already coded proper VST3 plugins from the ground up.
THIS MUSIC HAS BEEN MIXED TO BE PLAYED LOUD SO TURN IT UP

Post

"Myriad". Yeah, right. There are way more developers doing wrapped VST2 than those who have properly coded VST3 from the ground up (using JUCE counts as wrapped).

Post

jamcat wrote: Sat Jun 18, 2022 9:10 pm
I think that if Bitwig and u-he really believe in CLAP this much, and are so opposed to the draconian practices of Steinberg and Apple, and are so sure they’ve got the audio industry on their side, then they should drop VST and AU support completely. That’s the only thing that will force a change. Of course, the industry may also shrug at Bitwig and u-he, which is what I think is stopping them.
But then they would also be adopting 'draconian practices' by forcing this on developers and users, it seems to me they want to do this the friendly and collaborative way, carrots not sticks.

Post

jamcat wrote: Sat Jun 18, 2022 9:29 pm
EvilDragon wrote: Sat Jun 18, 2022 9:20 pm It is no secret many, many devs had issues with VST3 implementation. And you can read a bunch of such commentary right here in the developer subforum. Many from "leading audio software developers", too.
But that is mostly in the past now, isn’t it? There were bugs to work out and features to be implemented for years with VST3. Isn’t CLAP going to be the same (as is ALWAYS the case in software), or after 3 harrowing days, is CLAP immaculately conceived? (It would seem there is a cult of u-he disciples on KVR who believe that. :hihi: )
I haven't seen anyone yet arguing against VST, I only see people arguing-fighting against CLAP, and act like it's an authoritative regime coming to take over our freedom.

If it was a vst thread or something, and people where insisting that CLAP is better, etc, I would say yes we are having a cult situation here.

Post

jamcat wrote: Sat Jun 18, 2022 9:35 pm No because as I have pointed out multiple times, those legal hazards will still exist so long as they continue to support VST, which they all will continue to do.
I was talking about a situation, where a company has built their entire codebase around VST and then all of a sudden, Steinberg terminates the license. That would be a very bad situation indeed - they would need a complete rewrite. If, on the other hand, the codebase is primarily based on CLAP and Steinberg terminates the VST license, you'd just lose the ability to export to one format out of a handful. That's a *lot* less hazard.
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Actually, with the right wrapper and the right friends, people can do CLAP-to-VST3 or CLAP-to-VST2 without ever signing any legal document.

In case that hasn't been clear yet.

Post

Urs wrote: Sat Jun 18, 2022 10:01 pm Actually, with the right wrapper and the right friends, people can do CLAP-to-VST3 or CLAP-to-VST2 without ever signing any legal document.

In case that hasn't been clear yet.
How would wrapping work in CLAP? Will there be a class member function in the SDK that does all of the intermediate conversion?
THIS MUSIC HAS BEEN MIXED TO BE PLAYED LOUD SO TURN IT UP

Post

jamcat wrote: Thu Jun 16, 2022 3:12 am It's all politics
Yeah - well - maybe 80% of it. But in a good way. You say that as if that would necessarily be a bad thing. It's about liberation. But there are substantial technical improvements, too - but to be honest: I think, they are just the icing on the cake...soo....like the remaining 20%. But that's just my totally subjective perception of the situation.

And as for my thoughts about this (as per the thread title) - this is what immediately jumps into my head:

My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Urs wrote: Sat Jun 18, 2022 12:04 pm
mustgroove wrote: Sat Jun 18, 2022 7:27 am 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?
What Mystran says. However, if developers use the CLAP paradigm and wrappers such as CLAP-as-VST3 implement their own multithreading, there's a good chance that this will simplify multithreaded processing for heavy plug-ins. There might have to be a discussion as to when to do this or not, and maybe there need to be tools to test this on as many machines as possible.

Developers who wish to try this feature are welcome to contribute!
- 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?
CLAP does what a plug-in standard can do. It offers methods to translate values into meaningful metrics. As a developer who is guilty of having neglected this in the past, I surely hope we can do better with CLAP, but it really is up to us to do the work, not the format.

(I do think though that formats which - unlike CLAP - are restrictive of how parameters are scaled and/or presented may have a lesser chance of us doing this)
Thanks for that Urs!

I know it's probably an edge case for most people, but anything that makes it easier for parameter automation to include units, and work consistently across DAWs, would be a huge step forward. I don't want to call out any particular developer or plugin, but there's a lot of inconsistency I've experienced across the board:

- VST2 only ever supported a range of 0.0-1.0 for parameter automation - not great, but you knew what you were getting, and it was the same across the board.

- 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)

- VST3 supports automation with units as well, but it has a ton of other, weird, and often developer-specific issues (e.g. in Ableton automation will *display* with units on the automation curve itself, but when you manually type values it only accepts inputs of 0.0-1.0; another one I've seen only with 1 specific developer's VST3s in Ableton is where all automation points will incorrectly show the value of the parameter at the playback cursor position, rather than showing their actual value - e.g. if you click at a part of the song where that parameter's value is 0, *all* other points on the curve will show a value of 0 while the cursor is in that position, and if you move the cursor to somewhere where that value is 0.2, now every point shows a value of 0.2)

- A specific plugin (or a specific developer's plugins) can show different behaviour between AU and VST3 plugin formats, both in the same DAW and across DAWs.

I dream of a world where all automation has units and behaves consistently across DAWs, and anything that can be implemented in CLAP to help out would be a godsend IMO

Post

jamcat wrote: Sat Jun 18, 2022 9:15 pm
EvilDragon wrote: Sat Jun 18, 2022 8:50 pm
jamcat wrote: Sat Jun 18, 2022 8:34 pmwere 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.
Can i just ask, so i know if your comments come with any authority, have you ever programmed any audio plugins or even done any proper programming at all?
Mac mini m4 pro, Reaper, too many plugins, Modal Argon8, Novation Circuit Mono Station and now a lovely Waldorf Blofeld.

Post

hi I’m a dude who likes to play devil’s advocate because other people’s struggles are theoretical to me it’s fun to debate their right to dissent while we’re here I would like to center my voice and perspectives about a cause that means nothing to me. I’m here let’s engage
The vibes I get from some posts here
dedication to flying

Post

mustgroove wrote: Sun Jun 19, 2022 1:10 am - 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.

Post Reply

Return to “Instruments”