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

[Urs]

Also, wrappers for CLAP from and to other formats seem to be shaping up nicely. That'll resolve the issue during the transition time, while people catch up.

[koalaboy]

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

It really is. I was in much the same position, although I'd hardly looked at even VST2. I was thinking about diving into audio plugins, and then hit the VST3 license shenanigans, saw other problems and just about gave up. A week or two later, CLAP arrived, and it's a complete change

i should find time to look into it

Really, it's much easier to get started than VST ever was. I've been working from the awesome example by baconpaul here but there are also other clap example plugins linked on the main page here. I've no idea which are easier for Linux, as I'm currently playing with them on Windows and am too engrossed to fire up my Linux box and try a build there also

I would think that anyone with basic C++ knowledge could get going to a simple level fairly easily.

[baconpaul]

The examples work all oses but the vstgui attachment on linux in my demo isn’t documented yet. Will do that tonight

[mystran]

I would think that anyone with basic C++ knowledge could get going to a simple level fairly easily.

From what I've looked at it so far, it's actually quite a nice API to use directly from C as well. While many similar APIs really benefit from having a "thick" abstraction layer even if you're working in raw C, the CLAP API actually feels perfectly usable directly as-is.

In a sense, if you implement all the relevant interfaces directly in C you should end up with something that feels like modern high-level C code that actually feels good in plain C as well (ie. if you're used to C programming, you don't feel like you're being treated as a second-class citizen here), rather than something that feels like you had to wrap it in C++ to actually keep your sanity. It's not hard to wrap, but it's also not hard to use it directly as-is.

Personally I mostly do C++ these days, but I've done a fair bit of plain C as well.. and honestly this feels like actual C rather than "some glue for C++ code to interop with lesser languages."

[S0lo]

This was fun to watch.

[Urs]

Thank you! I seem to enjoy this, but really I've been a mess inside. Running on auto pilot.

[Audiority]

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.

I'm trying porting a plugin, on Mac, using that repository. I have XCode 12.5, with clang 12.0

I issue these commands:

Code: Select all

cmake -Bbuild-clap -GXcode -DPATH_TO_JUCE="/path-to-juce/JUCE" -DPATH_TO_CLAP_EXTENSIONS="/path-to-ext/clap-juce-extensions" -DPLUGIN_LIBRARY_PATH="/path-to-plugin/MyPlugin" -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" -DCMAKE_BUILD_TYPE=Release
cmake --build build-clap --config Release

It fails during the linking process due to undefined symbols:

Code: Select all

Undefined symbols for architecture x86_64:
  "createPluginFilter()", referenced from:
      ClapAdapter::clap_create_plugin(clap_plugin_factory const*, clap_host const*, char const*) in clap-juce-wrapper.o
  "juce::BigInteger::BigInteger(juce::BigInteger const&)", referenced from:
      ClapJuceWrapper::audioPortsInfo(unsigned int, bool, clap_audio_port_info*) const in clap-juce-wrapper.o
      ClapJuceWrapper::defineAudioPorts() in clap-juce-wrapper.o
  "juce::BigInteger::~BigInteger()", referenced from:
      ClapJuceWrapper::audioPortsInfo(unsigned int, bool, clap_audio_port_info*) const in clap-juce-wrapper.o
      ClapJuceWrapper::defineAudioPorts() in clap-juce-wrapper.o
      ...(continues with a lot more undefined symbols)

Any hints?

[Audiority]

Are spaces allowed for TARGET, paths and plugin file name?

[mystran]

Are spaces allowed for TARGET, paths and plugin file name?

Given that the standard install path on Windows is %CommonFilesFolder%/CLAP/ and generally speaking %CommonFilesFolder% typically expands to "C:\Program Files\Common Files" by default.. I don't think spaces are avoidable.

[wrl]

From what I've looked at it so far, it's actually quite a nice API to use directly from C as well. While many similar APIs really benefit from having a "thick" abstraction layer even if you're working in raw C, the CLAP API actually feels perfectly usable directly as-is.

In a sense, if you implement all the relevant interfaces directly in C you should end up with something that feels like modern high-level C code that actually feels good in plain C as well (ie. if you're used to C programming, you don't feel like you're being treated as a second-class citizen here), rather than something that feels like you had to wrap it in C++ to actually keep your sanity. It's not hard to wrap, but it's also not hard to use it directly as-is.

am developing against CLAP in C and can confirm all of this. very pleasant to use without any sort of higher level wrapper.

[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.

I'm trying porting a plugin, on Mac, using that repository. I have XCode 12.5, with clang 12.0

I issue these commands:

Code: Select all

cmake -Bbuild-clap -GXcode -DPATH_TO_JUCE="/path-to-juce/JUCE" -DPATH_TO_CLAP_EXTENSIONS="/path-to-ext/clap-juce-extensions" -DPLUGIN_LIBRARY_PATH="/path-to-plugin/MyPlugin" -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" -DCMAKE_BUILD_TYPE=Release
cmake --build build-clap --config Release

It fails during the linking process due to undefined symbols:

Code: Select all

Undefined symbols for architecture x86_64:
  "createPluginFilter()", referenced from:
      ClapAdapter::clap_create_plugin(clap_plugin_factory const*, clap_host const*, char const*) in clap-juce-wrapper.o
  "juce::BigInteger::BigInteger(juce::BigInteger const&)", referenced from:
      ClapJuceWrapper::audioPortsInfo(unsigned int, bool, clap_audio_port_info*) const in clap-juce-wrapper.o
      ClapJuceWrapper::defineAudioPorts() in clap-juce-wrapper.o
  "juce::BigInteger::~BigInteger()", referenced from:
      ClapJuceWrapper::audioPortsInfo(unsigned int, bool, clap_audio_port_info*) const in clap-juce-wrapper.o
      ClapJuceWrapper::defineAudioPorts() in clap-juce-wrapper.o
      ...(continues with a lot more undefined symbols)

Any hints?

hmmm that would happen only if the links on clap-juce-wrapper didn't transfer.

Can you try, if you don't mind, with the unix makefile or ninja generator just to rule out the Xcode generator first?

[baconpaul]

Are spaces allowed for TARGET, paths and plugin file name?

TARGET maybe not. I didn't think CMake targets could contain spaces.

Surge has a space in the plugin name ("Surge XT") but the actually *target* name in cmake is surge-xt

[Audiority]

For other readers: jadin fixed and updated the clap extension repository. Now everything works as expected and the CLAP builds without any issues!

Schermata 2022-06-21 alle 09.38.05.jpg

[Urs]

Yay!

[Markus Krause]

Thanks for your efforts. I already built a relieably working working vst2 to vst3 adapter in Juce. I will definitely try to add CLAP support to my existing products in the next months which should not big a big deal. Either by extending Juce or VST 2.4.