Structure packing isn't necessarily standardized between all compilers targetting the same platform. The VST SDK enforces the same alignment for all supported compilers on each system. CLAP doesn't do this yet, so structs like clap_event_note end up with a packing that might end up differently on different compilers (as the natural placement of a double value cannot be at byte 12, which would be the next free space after 3 32-bit integers). In practice this means the double will be placed at offset 16 instead.

I'd suggest to have a well-defined structure packing for all structs in CLAP (doesn't even have to be different from what is currently being done, it just needs to be defined at all), and/or avoid structs with non-natural alignment to begin with (in this particular example double could be replaced by float if the reduced precision is agreeable, but for other structs that may not always be possible, especially as soon as pointers are involved).

1. Add a CLAP_VERSION_x_DIGIT which is just 1, 2, 3
2. Make CLAP_VERSION_x be the uint cast of that
3. Add a CLAP_VERSION_NUMBER which is MAJOR << 16 + MINOR << 8 + REV so you can do a #if CLAP_VERSION_NUMBER <= 0x010105
4. Update CMakeLists to use DIGIT definitions

(moving from the conversion on https://github.com/free-audio/clap/commit/b902efa94e7a069dc1576617ebd74d2310746bd4)

For user-local plugins, the two options currently considered as mentioned in https://github.com/free-audio/clap/commit/b902efa94e7a069dc1576617ebd74d2310746bd4 are ~/.clap and ~/.local/lib/clap.

The arguments for ~/.clap are that it's in line with what users would expect (as ~/.vst, ~/.vst3 and ~/.lv2 will likely also exist on their system), while the argument against it is that it clutters up the home directory. My personal argument against ~/.local/lib/clap is that it's not a standardized directory, and there's no associated environment variable defined in the XDG Base Directory specification for controlling its location. And a third option is $XDG_DATA_HOME/~/.local/share which is meant for program data that can be shared across systems, but that may of course also not be a very discoverable location for users that try to install CLAP plugins from downloaded archives.

The id of a plugin as seen in https://github.com/free-audio/clap/blob/main/include/clap/plugin.h#L17 seems to be quite an important value. It does not have any documentation or rules whatsoever though, only an example.

What values are valid here? Is this meant to be a global, unique id? Should hosts use this value to refer to plugins? (or is binary name preferred?) What happens if 2 different plugins end up with the same id?

Hi!

I was looking through the APIs (lots of changes since the last time I did that), and everything looks very clean. I just had a couple small notes I wanted to mention. Because who knows, maybe one day I'll have to implement clap support in yabridge. ;) Feel free to not do anything with this if it's not useful or of it goes against clap's design goal.

For future reference, this was written for clap 0.15.0/commit 24a3df699319f3b2828e47db7313875c7ccc40b4.

• The channel maps currently only support predefined sets of channel layouts. I actually quite like this because 99.9% of the use cases will involve processing either mono, stereo, 5.1, or 7.1 surround audio, but a long-standing complaint for VST3 (and one of the few places where VST2 still offers more functionality) is the inability to support exotic ambisonic setups or other non-standard channel layouts. See VST3 SDK issue #28 and this thread on their forum. I'm not actually sure what the best approach would be where you can have both clap's current simple model and a way for plugins to support exotic channel layouts, but I thought it might be worth mentioning since this is one of the complaints against VST3 clap has not solved yet.

• The second thing I wanted to ask about is forward compatibility. This is a tough one because forward and backward compatibility is often where APIs get most of their complexity from. What is the current plan for extending functionality to an existing interface? For instance, if at some point after clap 1.0's release it's deemed necessary to add another flag or more information to the audio port info, then how will this work? The usual options are to either completely replace the extension by a _v2 version of the extension, to add padding at the end of the structs in the hope that any new fields will fit in there, or to begin every struct with a version field so you can cast the pointer to that struct to a newer version of the struct depending on which version you support. But none of those options are ideal. So I was just wondering, are there already plans for how clap will handle this?

Anyways, I'm excited for clap's future, and I was very happy to see initial clap support added in Bitwig 4.1's betas. The polyphonic automation and modulation alone is going to be a game changer for sure. So let me know what you think!

According to ext/event-filter.h, this is the only event where accepting it has side effects:

https://github.com/free-audio/clap/blob/a80522ef56c2cdaab9f9dfc8dcf206ceb75d60a1/include/clap/ext/event-filter.h#L18

If you don't accept events for inter-buffer transport changes (which not all plugins might want to support), then you risk not getting any transport information at all. The alternative would be to falsely advertise that you support and to just ignore the events, but that feels very wrong.

AFAICS there's no way for a plugin to report reverb tail length like kAudioUnitProperty_TailTime (AU) / effGetTailSize (VST2) / IAudioProcessor.GetTailSamples (VST3). A host may use this to calculate the duration of a song. Could be implemented similar to clap_plugin_latency.

Hello CLAP community,

Since Go is a popular and relatively easy language to pick up, how feasible is it to develop CLAP plugins with it?

What makes go a great language for CLAP plugin development:

• Both Go and CLAP follow the same mindset: open source, KISS, efficient development workflow.
• Go has native parallel processing (goroutines & channels) that is amazing when implemented in a performant way.

What worries me is:

• The garbage collector's overhead. It's being optimized all the time, but still...
• Whether Go's parallel processing can be taken advantage of in the API and DSP.

If the worry points are not blockers according to experts, I could try implementing a Go API binding.

This makes it easier to consume CLAP using build systems that rely on either CMake's find_package() mechanism or on pkg-config to find package dependencies. For this to work smoothly, the main library target has been renamed to clap so it matches the project name. A clap-core alias has been provided so projects can still refer to it by that name and no existing code will break. The CMake project now also contains the CLAP version number so that applications that include the CLAP library package can check whether that version matches their supported versions.

This has been verified to work with CMake's find_package(), with Meson's dependency() (both when using the .pc file and the CMake config+config-version files). I've also built Surge XT against these headers to make sure nothing changes for existing projects (there shouldn't be any reason to think it would, but you never know).

This resolves #198.

Hi! I'm packaging things for Arch Linux and inevitably clap will have to be packaged soon (yabridge requires it now).

It would be really cool, if there was a pkg-config file, so that build systems can make use of system-wide installations of clap.

In the current setup I can only e.g. package the files below include to /usr/include/, but no build system (e.g. meson, cmake, autofools) would know about its existence and version without a pkg-config integration.

It would be great to have a clap.pc.in file which gets configured by your cmake setup and then gets installed alongside the header files to the default integration location (e.g. something like /usr/lib/pkgconfig/clap.pc on Arch Linux).

I am trying to enable clap in Bitwig. There is no config.json in the described location on macOS and clap : true is not valid json. So I don't know how to create config.json. Should it exist somewhere? Should it already contain the clap key? I have Bitwig 4.2.2.

System:

cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.4"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.4"
PRETTY_NAME="openSUSE Leap 15.4"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.4"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"
LOGO="distributor-logo-Leap"

Command: cmake .. -G Ninja -DCLAP_BUILD_TESTS=ON

Actual output:

-- CLAP version: 1.1.6
-- The C compiler identification is GNU 7.5.0
-- The CXX compiler identification is GNU 7.5.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Including CLAP tests, compile tests, and versions
-- Configuring done
CMake Error at CMakeLists.txt:55 (add_executable):
  C_STANDARD is set to invalid value '17'
Call Stack (most recent call first):
  CMakeLists.txt:75 (clap_compile_cpp)

GCC version:

gcc --version
gcc (SUSE Linux) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

CMAKE version:

cmake --version
cmake version 3.20.4

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Hello!

Some plugin standards supports built-in programs. Users can directly choose a built-in program in host's preset picker. As far as I know, VST, VST3 and LV2 (via external TTL file) support it.

I wonder if CLAP supports this feature as well.

When I look at message types, it is pretty unclear for me, what's the difference between CLAP_EVENT_NOTE_ON, CLAP_EVENT_NOTE_OFF and CLAP_EVENT_MIDI and CLAP_EVENT_MIDI2 messages which also can be suitable for sending NOTE ON and NOTE OFF events.

What's the difference? When I will receive the MIDI NOTE ON event and when I will receive CLAP_EVENT_NOTE_ON?

What's the port_index field responsible for in event structures like clap_event_midi and clap_event_midi2?

I think it will be nice to have more details about the difference in the comments to the headers.

In the description of both clap_input_events and clap_output_events, there are remarks:

// Input event list, events must be sorted by time.
// Output event list, events must be sorted by time.

The description is missing the side that is responsible for providing sorted events. When we talk about the input event list, then probably the host is responsible for sorting out the events. When we talk about the output event list, then it is not clear who is responsible - the host or the plugin? Should the plugin care about sorting the events or is the host responble for sorting the events that come from the plugin?

I think this clarification should be added to the comments.

The audio port flags are pretty poor at this moment and define the main role and some 64-bit float capabilities. There could be a good idea to add the CLAP_AUDIO_PORT_IS_SIDECHAIN flag which will indicate this audio port as a default side-chain port. This could be a good hint to the DAW like Ardour to connect the corresponding audio port to the sidechain input of the track/bus.