CLAP... thoughts?

[Ploki]

this is probably the only time in my life i can say: i hope i get the clap ... (in logic)

has anyone made that joke already

[sQeetz]

has anyone made that joke already

You’re the first. *Pat on your back

[sQeetz]

Anyway… u-he and Bitwig are two companies I greatly admire and I would like them to succeed in that.

[vurt]

which doesn't really effect you, unless you are sat around waiting specifically for "new thing" rather than using all the stuff you already have. in which case, i would suggest clap is not the problem.

Not true. No need to imply other people are having a problem when it's blatantly obvious you're having one - adding development and testing time to a team can affect bug fixes, updates, ticket response time, etc. It's pretty simple. The negativity here - in the best cases - has been well explained, so I'm not sure why you're having such a problem understanding it.

If someone believes the premise that this will create a significant workload for developers it's not unreasonable at all to be concerned with how that would affect them. If these companies were adopting an additional 10 formats do you think they'd be able to magically do this without it affecting any customer-touching aspect of their business? 100? Ridiculous and thoughtless perspective if the premise is accepted. Maybe one additional format is doable without much effort; I don't have enough plugin programming experience to know myself. I doubt you do.

I would suggest you have a problem - the negativity has been clearly explained a number of times and you can't appear to comprehend it. Sounds like a reading comprehension problem, I would suggest getting that checked out.

just because they "explain" it, doesn't mean it makes sense.

and no, i don't have any programming experience, which is why im putting my trust in the words of those who do, rather than people who don't, who "think" this is an issue, when the programmers don't, this is why the negativity makes no sense to me.
if the actual programmers see clap as a positive.

[donkey tugger]

and no, i don't have any programming experience, which is why im putting my trust in the words of those who do, rather than people who don't, who "think" this is an issue, when the programmers don't, this is why the negativity makes no sense to me.
if the actual programmers see clap as a positive.

Come on, "people have had enough of experts", you know.

[vurt]

[donkey tugger]

fryingpan.jpg

If only Rickenbacker hadn't turned people's heads with his electrickery nonsense, think how good the acoustic guitars would have been now.

[Urs]

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)

[Urs]

Let me quickly chime in on the workload argument again.

We have to differentiate between two groups of developers:

- those developers who code their own internal glue to plug-in formats
- those developers who use frameworks like iPlug or JUCE

Latter have very, very little extra work. The work is being done for them, either with the open source drop in that is available from the Surge XT repository for JUCE, or by the maintainers and contributors to those frameworks. Those developers can either just move to CLAP once CLAP is supported there, when they upgrade the framework in their codebase, which they hopefully do on a regular basis anyway. It is almost literally no work.

For the others developers, those who glue to plug-in formats directly, I have permission to post a screenshot which was shared with me by one of these:

CLAP_Limitless.jpg

This is a screenshot made on the same day DMGAudio joined our team. Same day.

Now, what I'm saying is that the transition to CLAP will surely be a lot less rocky than any previous transition from one format to another in the audio plug-in industry.

Once the transition is done, yes, people have one more format to support. However the concept of CLAP goes further than that.

There are efforts to provide wrapper technology: CLAP-as-VST3, CLAP-as-AU etc. this technology will be a community effort, and everyone who uses it will contribute their experience in testing and perfecting these tools. Therefore, any company who decides to do CLAP as their main format and then wrap to AU/VST3 will have a lot less work testing and maintaining these arguably harder-to-maintain formats. And if these formats get new features, they will again be implemented collaboratively.

Let me recap:

- those developers who code their own internal glue to plug-in formats have most of the work done for them on other formats

- those developers who use frameworks like iPlug or JUCE have most of the work done for them on CLAP

And this fellow KVRians, is the future.

[VicDiesel]

until Unicode came along; A universal standard that covers everyone's use cases.

Unicode is only half of the solution. It's the cleverness of UTF-8 that makes it a workable solution.

I'll have to think how Urs' distinction between standard and platform figures in this.

Meanwhile I just like to say how much amused I am about the "C ABI" in that diagram. Programming languages may change, but when push comes to shove you better conform to an ?early 1970s? binary convention.

V.

[Urs]

Meanwhile I just like to say how much amused I am about the "C ABI" in that diagram. Programming languages may change, but when push comes to shove you better conform to an ?early 1970s? binary convention.

I think it's commonly accepted that pure C ABIs are *the* standard way to interoperate with different programming languages. That's why you can code a CLAP plug-in or host in Rust and Delphi today, and why it's easy to write a CLAP host directly in Python. One can not do any of this easily with formats that depend on C++. Therefore, it is a step forward, even if it uses a language that seems backward.

[VicDiesel]

One can not do any of this easily with formats that depend on C++.

Hey I remember the day that my C++ compiler was a source-to-source translator to C. That's still my mental model: `foo<bar>::baz` translates to `foo123bar456baz` as a linker symbol. Not sure why they never standardized that.

Victor.

PS ok, so that's not how you do in-line code in this forum. Sue me.

[VicDiesel]

almond milk

Big waste of resources. Please switch to oat EDIT: or flax.

V.

[melomood]

fryingpan.jpg


If only Rickenbacker hadn't turned people's heads with his electrickery nonsense, think how good the acoustic guitars would have been now.

I've always said guitars have been nothing but trouble since,with all that extra gear complicating things for the customer

[vurt]

almond milk

Big waste of resources. Please switch to oat of flax.

V.

can i use this opportunity to state, potato milk is a step too far.