CLAP: The New Audio Plug-in Standard (by U-he, Bitwig and others)

[xhunaudio]

Well, when I say JIT / LLVM, I'm talking about high-performance (higher than C++ or on par) DSLs (domain specific languages), ultimately translated to WASM-like and then "JITted".

It seems a very few know that, but it is what (for example) Propellerhead Software (today Reason Studios) started in 2012 with *Rack Extensions*, and the same way was taken by the SOUL prototype (today carried on by Sound Stacks, with a different name, not announced yet).

IMPORTANT : I don't want to be a prophet of doom, eheh ! It was not to understimate CLAP (all my respect to its creators), it was just my consideration on he long-term...

[koalaboy]

When I say JIT / LLVM, I'm talking about high-performance (higher than C++ or on par) DSLs (domain specific languages).

Understood. The thing is, whilst they can work very well in some very specific cases, the usage can often be limited and not beneficial to the wider case. In the same way 'Use threads' isn't a simple win.

I would absolutely like to see more usage of JIT/LLVM and the developments across all areas in the last few years have been great. However, I don't think it's something to build a standard around, until it's commonplace. There's nothing to say it couldn't move in the future, and ideally a standard should be progressive - hopefully that's one of the main benefits of CLAP, in that it's not tied down to the direction of a single vendor.

The more diverse the ecosystem (and the ability to be so), the better for everyone.

[baconpaul]

Well, when I say JIT / LLVM, I'm talking about high-performance (higher than C++ or on par) DSLs (domain specific languages), ultimately translated to WASM-like and then "JITted".

It seems a very few know that, but it is what (for example) Propellerhead Software (today Reason Studios) started in 2012 with Reason Extensions, and the same way was taken by the SOUL prototype (today carried on by Sound Stacks, with a different name, not announced yet).

IMPORTANT : I don't want to be a prophet of doom, eheh ! It was not to understimate CLAP (all my respect to its creators), it was just my consideration on he long-term...

If that works - and it would great if it did - you still need an interface between the jit runtime and daws. Clap could be that without problem.

Personally I hope what you say comes to bear. The progress we’ve seen with llvm and to a lesser extent wasm are amazing, computers are getting faster, and so on. Projects like Faust and soul show what could be also, although hand coded c++ seems to still be best bet today (rust is coming along though and there’s a couple of clap plugins written in rust already)

But don’t think about clap as a plugin. Think about it as a pure c abi for collaboration between a host and an event processor / audio processor. The api is quite thin and that’s one of the reasons it’s a joy to use.

With that in mind if you have a core which is jit based, clap would play a role just for interfacing.

[Zaphod (giancarlo)]

my first random check, it seems like channel management is very simplified in surround.h (compared to vst3).
The reported channels may suffice for the current state of atmos, but I do not understand how complex layouts can be handled.
Maybe I am misunderstanding things

[Calagan]

I'm not technically aware of all the implications of CLAP, but from what I read on the subject and from what I know about Urs Heckmann, I find the project very exciting.
The U-He catalogue is, among other companies, one of the most elegant I know (I mean : bug free, constantly optimized, stable, it sounds great and is easy to use). And U-He seems to be, on the business side, lightyears away from NI, Plugin Alliance and other similars "investments funds ready" companies.
So I trust them in how they manage this project : I'm sure it will deliver and bring something great to the plugin industry...

[Urs]

my first random check, it seems like channel management is very simplified in surround.h (compared to vst3).
The reported channels may suffice for the current state of atmos, but I do not understand how complex layouts can be handled.
Maybe I am misunderstanding things

Well, the issue is that no DAW manufacturer and no plug-in developer with any such needs has thrown their weight into the project yet. Therefore, these extensions are still drafts. This can change quickly: Just join the discussion and make your requirements known - it would be very appreciated by everyone.

[koalaboy]

It will be interesting to see how quickly things also move when software like Synthedit, Bluecat Plug'n'Script, Flowstone (is that still alive ?) and other plugin 'creators' adopt CLAP - empowering others to create plugins that require no additional license to distribute or sell, could re-ignite the indie development scene even more.

[jules]

Yeah we've yet to see how that JIT thing works out in practice, performance-wise. Especially with multicore processing! Let's see what SoundStacks is up to. Shame ROLI's shenanigans so heavily affected SOUL's development.

If it wasn't for ROLI's "shenanigans" then we wouldn't have had an excuse to go off and create something even better

In fact our new JIT performance is looking great - even our pre-release internal benchmarks are beating C++ on many types of test (e.g. matrix operations). (This is for the same obscure reasons that explain why fortran still optimises better than C++ in many situations)

Something that is relevant to JIT-ed plugins is whether hosts can handle a loaded plugin suddenly reconfiguring itself with a new list of parameters or channels, etc. That's a behaviour where the old formats were always terrible, and DAWs were even worse because plugins so rarely do that, and many DAWs will crash if it happens. I've not dug into the CLAP spec to find out whether dynamic changes is something that's already part of the spec, but that feature is the one make-or-break thing that'd be relevant to whether we look into adopting it.

[MadDogE134]

i always thought having 'the clap' was a bad thing lol

[Urs]

I've not dug into the CLAP spec to find out whether dynamic changes is something that's already part of the spec, but that feature is the one make-or-break thing that'd be relevant to whether we look into adopting it.

But of course it is! There's very detailed explanation as to what's expected from plug-ins and hosts, in which order, on which thread, when the plug-in completely changes its parameter layout.

[mystran]

In fact our new JIT performance is looking great - even our pre-release internal benchmarks are beating C++ on many types of test (e.g. matrix operations). (This is for the same obscure reasons that explain why fortran still optimises better than C++ in many situations)

Isn't the Fortran vs. C++ thing mostly a matter of littering code with __restrict?

That said, I feel like the real performance potential with JIT is in run-time specialization, where at runtime you can compile out branches based on settings and then just recompile a new version when the settings change. While one can do similar things by generating multiple specialized codepaths in C++ using templates, there's a limit on how far you can go before combinatorial explosion become unmanageable. No such limits for JIT.

[jules]

I've not dug into the CLAP spec to find out whether dynamic changes is something that's already part of the spec, but that feature is the one make-or-break thing that'd be relevant to whether we look into adopting it.

But of course it is! There's very detailed explanation as to what's expected from plug-ins and hosts, in which order, on which thread, when the plug-in completely changes its parameter layout.

Good stuff, I figured that you might have thought it through properly

[mystran]

My biggest complaint (working through the raw C API for the past couple of hours) is that the code uses 3 spaces instead of 4 spaces for intendation [edit: oh and uses Javastyle brace-placement in C ... ]

[EvilDragon]

My biggest complaint (working through the raw C API for the past couple of hours) is that the example plugin template uses 3 spaces instead of 4 spaces for intendation [edit: oh and uses Javastyle brace-placement in C ... ]

(Over here: 4, and Allman braces ftw.)

[Audiority]

(Over here: 4, and Allman braces ftw.)

same here