CLAP: The New Audio Plug-in Standard (by U-he, Bitwig and others)
- KVRian
- 1158 posts since 17 Feb, 2010
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...
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...
Last edited by xhunaudio on Wed Jun 15, 2022 6:50 pm, edited 2 times in total.
-
- KVRAF
- 2194 posts since 18 Mar, 2006 from Plymouth, UK
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.
-
- KVRian
- 874 posts since 25 Dec, 2018
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.xhunaudio wrote: ↑Wed Jun 15, 2022 6:12 pm 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...
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) Zaphod (giancarlo) https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=111268
- KVRAF
- 2596 posts since 23 Jun, 2006
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
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
-
- KVRist
- 123 posts since 13 Oct, 2018
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...
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...
- u-he
- 28108 posts since 8 Aug, 2002 from Berlin
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.Zaphod (giancarlo) wrote: ↑Thu Jun 16, 2022 4:04 am 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
-
- KVRAF
- 2194 posts since 18 Mar, 2006 from Plymouth, UK
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.
-
- Chief Tracktioneer
- 532 posts since 14 Nov, 2002 from London
If it wasn't for ROLI's "shenanigans" then we wouldn't have had an excuse to go off and create something even betterEvilDragon wrote: ↑Wed Jun 15, 2022 6:05 pm 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.
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.
- KVRian
- 1074 posts since 26 Nov, 2007
i always thought having 'the clap' was a bad thing lol
"There is no strength in numbers... have no such misconception... but when you need me be assured I won't be far away."
- u-he
- 28108 posts since 8 Aug, 2002 from Berlin
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.
- KVRAF
- 7954 posts since 12 Feb, 2006 from Helsinki, Finland
Isn't the Fortran vs. C++ thing mostly a matter of littering code with __restrict?jules wrote: ↑Thu Jun 16, 2022 1:24 pm 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)
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.
-
- Chief Tracktioneer
- 532 posts since 14 Nov, 2002 from London
- KVRAF
- 7954 posts since 12 Feb, 2006 from Helsinki, Finland
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 ... ]
Last edited by mystran on Thu Jun 16, 2022 2:41 pm, edited 1 time in total.
- KVRAF
- 23115 posts since 7 Jan, 2009 from Croatia
(Over here: 4, and Allman braces ftw.)
- KVRian
- 1339 posts since 15 Nov, 2005 from Italy
same here