Audio Plugin API

Related tags

Audio audio plugin daw clap
    _______      .---.         ____     .-------.
   /   __  \     | ,_|       .'  __ `.  \  _(`)_ \
  | ,_/  \__)  ,-./  )      /   '  \  \ | (_ o._)|
,-./  )        \  '_ '`)    |___|  /  | |  (_,_) /
\  '_ '`)       > (_)  )       _.-`   | |   '-.-'
 > (_)  )  __  (  .  .-'    .'   _    | |   |
(  .  .-'_/  )  `-'`-'|___  |  _( )_  | |   |
 `-'`-'     /    |        \ \ (_ o _) / /   )
   `._____.'     `--------`  '.(_,_).'  `---'

CLever Audio Plugin.

Learn about CLAP

To work with clap, include clap/clap.h.

The two most important objects are clap_host and clap_plugin.

Entry point

The entry point is declared in entry.h.


Most features comes from extensions, which are in fact C interfaces.

extension(plugin, CLAP_EXT_PARAMS); if (params) { uint32_t paramsCount = params->count(plugin); // ... }">
// host extension
const clap_host_log *log = host->extension(host, CLAP_EXT_LOG);
if (log)
   log->log(host, CLAP_LOG_INFO, "Hello World! ;^)");

// plugin extension
const clap_plugin_params *params = plugin->extension(plugin, CLAP_EXT_PARAMS);
if (params)
   uint32_t paramsCount = params->count(plugin);
   // ...

The extensions are defined in ext folder.

Some extensions are still in the progress of being designed and they are in the draft folder.

An extension comes with:

  • an header #include
  • an extension identifier: #define CLAP_EXT_XXX "clap/XXX"
  • host interfaces are named like: struct clap_host_xxx
  • plugin interfaces are named like: struct clap_plugin_xxx
  • each methods must have a clear thread specification

You can create your own extensions and share them, make sure that the extension identifier

  • includes versioning in case the ABI breaks
  • a unique identifier

All strings are valid UTF-8.

Fundamental extensions

This is a list of the extensions that you most likely want to implement and use to get a basic plugin experience:

  • log, lets the host aggregate plugin logs
  • thread-check, check which thread you are currently on, useful for correctness validation
  • audio-ports, define the audio ports
  • note-ports, define the note ports
  • params, parameters management
  • latency, report the plugin latency
  • state, save and load the plugin state

GUI extensions

Extra extensions


Community related projects

  • MIP2, host and plugins
  • clap-sys, rust binding
  • schwaaa's plugin, basic example for prototyping CLAP audio plugins using Dear ImGui as the user interface
  • Structure packing

    Structure packing

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

    help wanted question ABI 
    opened by sagamusix 37
  • Change VERSION macros to allow compares

    Change VERSION macros to allow compares

    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
    opened by baconpaul 30
  • Standardized user-local Linux plugin search path

    Standardized user-local Linux plugin search path

    (moving from the conversion on

    For user-local plugins, the two options currently considered as mentioned in 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.

    specification need more info 
    opened by robbert-vdh 20
  • Define rules for plugin Id

    Define rules for plugin Id

    The id of a plugin as seen in 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?

    question specification 
    opened by falkTX 16
  • A couple small observations and questions regarding forward compatibility

    A couple small observations and questions regarding forward compatibility


    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!

    opened by robbert-vdh 15
  • Accepting CLAP_EVENT_TRANSPORT events or not has side effects elsewhere

    Accepting CLAP_EVENT_TRANSPORT events or not has side effects elsewhere

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

    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.

    opened by robbert-vdh 14
  • reverb tail length

    reverb tail length

    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.

    specification later adapter support 
    opened by Bremmers 14
  • Golang feasibility

    Golang feasibility

    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.

    opened by NorbertHauriel 11
  • Provide an installation target with CMake and pkg-config package files

    Provide an installation target with CMake and pkg-config package files

    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.

    opened by robbert-vdh 10
  • Provide pkg-config integration for system's packaging

    Provide pkg-config integration for system's packaging

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

    opened by dvzrv 10
  • enable clap in Bitwig? (what works?)

    enable clap in Bitwig? (what works?)

    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.

    opened by stream-punk 9
  • Build compatibility with older C/C++/cmake tools

    Build compatibility with older C/C++/cmake tools


    cat /etc/os-release
    NAME="openSUSE Leap"
    ID_LIKE="suse opensuse"
    PRETTY_NAME="openSUSE Leap 15.4"

    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

    CMAKE version:

    cmake --version
    cmake version 3.20.4
    CMake suite maintained and supported by Kitware (
    bug help wanted cmake 
    opened by sadko4u 7
  • Is there any built-in program support?

    Is there any built-in program support?


    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.

    opened by AnClark 3
  • Clap messaging: what's the difference?

    Clap messaging: what's the difference?

    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.

    opened by sadko4u 2
  • Input and output event queue clarification

    Input and output event queue clarification

    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.

    opened by sadko4u 4
  • Add sidechain flag to the audio port

    Add sidechain flag to the audio port

    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.

    opened by sadko4u 9
PortAudio is a portable audio I/O library designed for cross-platform support of audio

PortAudio is a cross-platform, open-source C language library for real-time audio input and output.

PortAudio 786 Jan 1, 2023
An OBS plugin that allows capture of independant application audio streams on Windows, in a similar fashion to OBS's game capture and Discord's application streaming.

win-capture-audio An OBS plugin based on OBS's win-capture/game-capture that hooks WASAPI's audio output functions (rather than the various graphics A

Joe Kaushal 3k Jan 9, 2023
vintage - a declarative API for C++ audio plug-ins

This is an experiment in seeing how far modern C++ features allow to write purely declarative code and introspect this code through various reflection-like features.

Jean-Michaël Celerier 29 Sep 29, 2022
A simple C++ library for reading and writing audio files.

AudioFile A simple header-only C++ library for reading and writing audio files. Current supported formats: WAV AIFF Author AudioFile is written and ma

Adam Stark 683 Jan 4, 2023
A C library for reading and writing sound files containing sampled audio data.

libsndfile libsndfile is a C library for reading and writing files containing sampled audio data. Authors The libsndfile project was originally develo

null 1.1k Jan 2, 2023
C library for cross-platform real-time audio input and output

libsoundio C library providing cross-platform audio input and output. The API is suitable for real-time software such as digital audio workstations as

Andrew Kelley 1.6k Jan 6, 2023
C++ Audio and Music DSP Library

_____ _____ ___ __ _ _____ __ __ __ ____ ____ / \\_ \\ \/ / |/ \| | | | \_ \/ \ | Y Y \/ /_ \> <| | Y Y \ | |_|

Mick Grierson 1.4k Jan 7, 2023
Single file audio playback and capture library written in C.

A single file library for audio playback and capture. Example - Documentation - Supported Platforms - Backends - Major Features - Building - Unofficia

David Reid 2.6k Jan 8, 2023
SimplE Lossless Audio

SELA SimplE Lossless Audio A lossless audio codec which aims to be as simple as possible while still having good enough compression ratios. Code Quali

Ratul Saha 207 Sep 13, 2022
Easy and efficient audio synthesis in C++

Tonic Fast and easy audio synthesis in C++. Prefer coding to patching? Love clean syntax? Care about performance? That's how we feel too, and why we m

null 482 Dec 26, 2022
An audio mixer that supports various file formats for Simple Directmedia Layer.

An audio mixer that supports various file formats for Simple Directmedia Layer.

Simple Directmedia Layer 198 Dec 26, 2022
Explore fractals in an audio-visual sandbox

Fractal Sound Explorer Explore fractals in an audio-visual sandbox Download executable on my page:

null 983 Jan 4, 2023
Audio out with an FTDI UART cable

Audio out with an FTDI UART cable This encodes audio as either PDM (using a first order sigma-delta stage), 32-bits PWM or 64-bits PWM and sends it as

Konrad Beckmann 42 Jun 23, 2022
Sexy, audio-responsive effects on LED strips.

Striptease Sexy, audio-responsive effects on LED strips. For Teensy 4 with Audio Adapter Board, by PJRC. Quick demo Shooting video of LEDs is very tri

Luca Paolini 35 Jun 19, 2022
audio monitor filter for OBS Studio

Audio Monitor dock and filter for OBS Studio Plugin for OBS Studio to add Audio Monitor dock and filter. It allows you to put the audio of a OBS sourc

Exeldro 222 Dec 18, 2022
Lightweight Embedded Audio Framework

LEAF (Lightweight Embedded Audio Framework) is a C library for audio synthesis and processing created by Jeff Snyder, Mike Mulshine, and Matt Wang at Princeton University's New Instrument Research Lab. It was originally called OOPS when we started writing it in 2017, so you may see references to it under that name as well.

Jeff Snyder 110 Dec 27, 2022
An Audio Steganography Tool, written in C++

HiddenWave Hide your personal Data inside The Audio wav file Written in C++ by Gaurav Raj [TheHackersBrain] Hiddenwave is an audio steganography tool

Gaurav Raj 48 Dec 27, 2022
C++ audio time-stretching implementation

Time Stretcher C++ audio time-stretching implementation, based on the algorithms presented in: Audio Time Stretching with an Adaptive Phase Vocoder, N

null 59 Nov 13, 2022
Block all ads in vídeo, áudio, banner, anti-skip

NoAdSpotify Block spotify ad This is an updated and simplified version of the project: BlockTheSpot Last updated: 6th June 2021 Last tested version: 1

null 14 Nov 5, 2022