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

[ahribellah]

I really like that this is a C API and not a C++ API. Writing bindings is going to be much easier. I'll probably look into this more when/if Reaper gets support for it.

[Artie Fichelle]

Great. I wish all the success that it may be the Midi of pluqgins.

[Urs]

Urs (and any other devs) - are there any suggestions for the best scalable/vector UI to look into, for new CLAP development, that would be suitable for cross-platform and license-free/open-source ? I am looking at the IMGui demo, but just wondering if there's something else folks would recommend.

IMGui might be a tad limited for something you'd wanna ship.

The people who have contributed to CLAP in the past year are currently concentrating on two ends:

- things I call "Clappers" and "Palcers", as in wrappers like CLAP-as-AU (a Palcer, with CLAP spelled backwards) or AU-as-CLAP (Clapper)
- a modern open source GUI toolkit that binds to something cool and hardware accelerated

Apart from JUCE there's also iPlug2, where we hope to pick up threads now that CLAP is 1.0, and other toolkits have expressed interest as well. Also, I heard rumours that the official example plug-ins are moving from Qt to Flutter. That would be an awesome toolkit right there.

So I think there'll be plenty of solutions, and of course everyone is welcome to contribute to these efforts!

[Urs]

No telling how wide the support with CLAP will be [...]

I think the list at the bottom of the announcement is a very good indicator of CLAP's outlook. And it's been outdated for a few hours already as more and more developers express their interest.

Sure, the work has just begun, but look where we start!

[EvilDragon]

And it's been outdated for a few hours already as more and more developers express their interest.

We need live updates on that list!

[Music Engineer]

Great news! Thanks for all your efforts! This is what the industry/community has desperately needed since at least a decade...maybe more like two.

Some plugins seems to work well using https://github.com/free-audio/clap-juce-extensions

Thanks, but we don't use CMake and it would be better to have an official implementation by the JUCE team.

Yes, same here. I'm still using Projucer but I think, I'll take that as an opportunity to finally make the switch to CMake which may come with a bunch of other benefits as well (I assume). I have no idea how hard or easy that will be. Probably very fiddly in the process and seemingly easy in hindsight I think, I'll look into the Surge codebase for reference. That said, I would also expect that sooner or later it will get official support from JUCE, too...but that may take a while.

[baconpaul]

Great news! Thanks for all your efforts! This is what the industry/community has desperately needed since at least a decade...maybe more like two.

Some plugins seems to work well using https://github.com/free-audio/clap-juce-extensions

Thanks, but we don't use CMake and it would be better to have an official implementation by the JUCE team.

Yes, same here. I'm still using Projucer but I think, I'll take that as an opportunity to finally make the switch to CMake which may come with a bunch of other benefits as well (I assume). I have no idea how hard or easy that will be. Probably very fiddly in the process and seemingly easy in hindsight I think, I'll look into the Surge codebase for reference. That said, I would also expect that sooner or later it will get official support from JUCE, too...but that may take a while.

So I’ve done - what - 8 or 9 ports to cmake in the last year or so? Something like that. I have a few tips but probably hit me up in the clap chatter room on the surge discord

The short version though is

1: Alains “FRUT” tool if you build it has a jucer2cmake that gets you most of the way there
2: add a pic and macos flag and you are further
3: then figure out how you want to structure your cmake

Bstep for instance is a pretty direct port from frut but we rewrote Bespokes since it is much trickier softeware.

And cmake is great!

[Music Engineer]

I have a few tips but probably hit me up in the clap chatter room on the surge discord

The short version though is ...

That's great! Thanks in advance!

[mystran]

I'm definitely not interested in this, what a stupid idea. Who on their right mind would want an open standard. The market needs competition and the only way to ensure proper competition (ie. to ensure that it's unfair to most players) is to build closed platforms, not open standards.

On a more serious note.. are there any adapters yet that can run CLAP plugins in non-CLAP hosts? That'd open the possibility of development for those of us that don't run Bitwig and are too lazy to try to write plugin-side support without any host to support it.

[Urs]

Re Wrappers - we are about to consolidate efforts in one Github. There‘ll be links…

[mystran]

Re Wrappers - we are about to consolidate efforts in one Github. There‘ll be links…

How long will it take? Is it better to go order some coffee while waiting?

[koalaboy]

Re Wrappers - we are about to consolidate efforts in one Github. There‘ll be links…

How long will it take? Is it better to go order some coffee while waiting?

[xhunaudio]

Congrats to its creators, I wish all the best with their CLAP format, but I think this happened too late. In my opinion it was something which could have a chance something like 15 years ago, normalizing the multi-format "war".

Not to be prophet of doom, but I think if it is based on the same "pre-compiled binaries" approach used until now, it may not have a future, unfortunately. But who knows...

The "pre-compiled plugins" approach made a great job in the last 20-25 years, but I think the future of pro audio / plugins is related to JIT.

[koalaboy]

The "pre-compiled plugins" approach made a great job in the last 20-25 years, but I think the future of pro audio / plugins is related to JIT.

I'm not convinced on this. Whilst JIT is really powerful (I work mainly in Java as a day-job) and advances have been made, there's a reason that C/C++/Rust are still leading the way in performance when necessary.

Equally, I'm sure the ABI could transition to an API if deemed necessary and encompass a JIT-based approach should the opportunity arise. Remember, we're only just seeing MIDI 2.0.

This is a fantastic step in the right direction. It's a beginning, not a final endpoint.

(I also think the developments in GPU-based processing hold potential, as an aside)

[EvilDragon]

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.