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

[baconpaul]

Is the CLAP documentation in the works? So far, it seems to only be the comments in the source at github.

The headers are really well commented and organized. Just download the whole thing and open in some editor with a directory view on a sidebar (eg. VSCode would work) or add them to the project (if you'we using something like Visual Studio proper) and it's really quite easy to use them as a reference.

yes the comments in the header are carefully structured to comprise the spec now. Would be lovely to extract them to a more document-style format, but having them directly in the IDE has been invaluable. We really did work carefully on that documentation (and are still updating it in point releases)

We are also starting to collect more and more (and more) examples of devs successfully porting. There's a bunch of juce plugins in the open source world which have worked with the extensions (I just head paulxstretch release tonight has a CLAP for instance); we have the demo host and plugin at free-audio GitHub; and we have several demo programs with good documentation at surge-synth land.

[mystran]

(yeah, a nice debuggable host would be wonders now...)

So I've done quite a few CLAP ports in the last month. Bootstrapping was really the trick. To make my life easier I wrote a little command line host that anyone else can use to get started which is at https://github.com/surge-synthesizer/clap-info - that will load, scan params, print port configuration, etc... and if you want it to do more we are happy for PRs

The "how to build" instructions seem to have the clone URL wrong (says free-audio/clap-info instead of surge-synthesizer/clap-info, so can't just copy-paste to shell).

There's also the demo clap host at https://github.com/free-audio/clap-host which shows the GUI and interacts with midi also.

Dependencies look too scary ... waiting for binary release.

edit: Looks like Multitrack Studio just didn't like the fact that I didn't have any audio ports yet.

[baconpaul]

(yeah, a nice debuggable host would be wonders now...)

So I've done quite a few CLAP ports in the last month. Bootstrapping was really the trick. To make my life easier I wrote a little command line host that anyone else can use to get started which is at https://github.com/surge-synthesizer/clap-info - that will load, scan params, print port configuration, etc... and if you want it to do more we are happy for PRs

The "how to build" instructions seem to have the clone URL wrong (says free-audio/clap-info instead of surge-synthesizer/clap-info, so can't just copy-paste to shell).

Thanks - fixed!

[Markus Krause]

I plan to add CLAP support to our plugins.

CLAP does NOT suffer from the problems that Steinberg's proprietary VST3 format has:
- Arrogant and unhelpful developers that ignore the demands of the industry
- No proper Midi support
- A bloated, messy and buggy SDK that fails compiling in many places

I think that CLAP is a well-designed and elegant plugin format with a developer friendly licensing. It should be easy to add to our existing projects.

[wrl]

https://twitter.com/wrl/status/1537125901917372417
This just popped up in my feed. Dude's doing a Twitch stream of him porting his plugin framework to Clap.
https://www.twitch.tv/wrlight

ah hey, hello!

did the first part of the stream earlier tonight. got from "zero mentions of CLAP in the source tree" to "bitwig loads the plugin and processes audio through it" in a little under three hours. no parameters yet though! i reckon that parameters and UI will take another ~2 hours, give or take.

i'm planning on streaming an LV2 port as well, possibly next week. we'll see.

i have a slight bias here in that i provided feedback and some specification work on a few pieces of CLAP (and am happy with the result) but had not sat down with the API as a whole to write a plugin. my thoughts are: CLAP is a Pretty Good API. solid 7.5/10, maybe 8/10 (we'll see when I'm finished with the port).

in my opinion, CLAP strikes a very good balance between familiarity and capability. the API is thoughtful, coherent, and sensible. if you've implemented a plugin API before, CLAP will not throw you any major curveballs.

[koalaboy]

did the first part of the stream earlier tonight. got from "zero mentions of CLAP in the source tree" to "bitwig loads the plugin and processes audio through it" in a little under three hours. no parameters yet though! i reckon that parameters and UI will take another ~2 hours, give or take.

i'm planning on streaming an LV2 port as well, possibly next week. we'll see.

Any chance of VODs (or youtube uploads) of that (and subsequent) stream ? Would be really great to watch.

[wrl]

Any chance of VODs (or youtube uploads) of that (and subsequent) stream ? Would be really great to watch.

unfortunately didn't save a VOD of that stream but have enabled it for streams in the future.

implemented parameter handling yesterday off-stream and it took about an hour. so we're at around ~4 hours for this CLAP implementation so far (I'm keeping track and keeping notes).

[koalaboy]

implemented parameter handling yesterday off-stream and it took about an hour. so we're at around ~4 hours for this CLAP implementation so far (I'm keeping track and keeping notes).

It's always great to have more development examples (especially videos/walkthroughs), especially when the overall approach is so 'simple', as with CLAP.

I think now is probably the best time to get more people who have ever wanted to try and write plugins involved, as the learning curve (at least before getting into maths and performance) is pretty low.

[adammonroe]

I wish CLAP the best of luck, it would be nice to have an open-source plugin format. I just spent a couple weeks figuring out how to port my VST2 plugins to VST3 and it does seem to be as bad as they say - pushing MIDI CC stuff into the parameter change queue but still keeping Midi Note On/Off as separate events...what the hell were they thinking?

However:
*Cubase never adopted the AU format.
*Logic never adopted VST.
*Avid does not support anything besides AAX.
*Lots of people still use Cubase, Logic, and Protools, even though DAWs like Ableton, Reaper, and Digital Performer exist that support both formats.

I'd like to believe that these companies would gradually adopt an open-source alternative but...nah, I'm pretty sure they believe proprietary formats are major selling points of their software, for some reason. As long as these three big companies exist and people continue to use their popular hosts, I don't see widespread adoption of an open-source plugin alternative being possible, but we can dream The push would have to come from users, and users don't much care: most Cubase users don't even seem to care that much about using VST2 and possibly a bunch of older plugins no one is around to update.

...and I have serious doubts that Protools can adopt a 3rd-party format without self-imploding .

[Urs]

I wish CLAP the best of luck, it would be nice to have an open-source plugin format. I just spent a couple weeks figuring out how to port my VST2 plugins to VST3 and it does seem to be as bad as they say - pushing MIDI CC stuff into the parameter change queue but still keeping Midi Note On/Off as separate events...what the hell were they thinking?

Indeed. Plug-ins have to zip all events back from different sources into a single queue, but they can not know the order of events with the same timestamp. It's buggy. It really is. Same for Audiounits btw.

CLAP has everything in a single event queue. No need to zip, therefore better performance. And free of ambiguity because the order is established, hence fewer bugs right there.

I'm preparing a blog post that'll explain this in detail.

[audiothing]

Ok, for anyone interested, this repo https://github.com/free-audio/clap-juce-extensions has just been updated so that people using JUCE with Projucer (and not just CMake) can easily port their plugins to CLAP.

After fighting a bit with CMake, I successfully ported one of my plugins to CLAP on both macOS and Windows. It's just a quick test for now, and hopefully, JUCE will add support for CLAP in the future (you should vote here if you are interested).

EvilDragon kindly tested it on Windows and it seems to be working fine!

image_2022_06_18T22_23_36_935Z.jpg

[baconpaul]

Ok, for anyone interested, this repo https://github.com/free-audio/clap-juce-extensions has just been updated so that people using JUCE with Projucer (and not just CMake) can easily port their plugins to CLAP.

Awesome!!

[Music Engineer]

Ok, for anyone interested, this repo https://github.com/free-audio/clap-juce-extensions has just been updated so that people using JUCE with Projucer (and not just CMake) can easily port their plugins to CLAP.

Great - thanks! ....ahh...damn....no reason to learn to CMake anymore

hopefully, JUCE will add support for CLAP in the future (you should vote here if you are interested).

Done.

[antto]

i've been in a sort of stall in the past bunch of years, and i sorta slept thru the stupid things that happened to vst2.x so i practically don't (think) i have a valid vst2 license, which additionally discourages me
besides that i've been trying to switch to linux as a main OS

if a similar (or better) plugin format pops up, and if it's usable on linux, that could bring me back at making plugins, possibly just for my own use (as usual)
so this CLAP thing is looking highly interesting at first sight

big DAWs will support it if there are enough plugins, so even if a few DAWs only support it at first - if that's enough to make devs to write or port plugins to that format, then people will see it as an option and will expect more DAWs to support it

i think programs like SynthEdit could speed that up, since they allow making "plugins" much quicker and doable by the folks who can't code well or at all

so, CLAP seems like a spark of light in this tunnel
thanks to everyone involved...

i should find time to look into it and might have questions
perhaps the first one would be: any hosts for linux?

[Urs]

any hosts for linux?

Bitwig Studio, Qtractor (in development, not sure if it's public yet), the official example host in the sister repository at cleveraudio.org and more to come soon, I'm sure!