Skip to content

CLAP implementation notes

Jump to bottom
p0nce edited this page Nov 19, 2024 · 64 revisions

Was asked to do a report while implementing a CLAP client for a plug-in framework. Ticket = https://github.com/AuburnSounds/Dplug/issues/670

General

  • Appreciate all the help gotten on the Discord! Thanks to everyone who endured my inquiries.

  • Obviously a well-done format, that emphasize and discover very nice patterns of communication for plugin <-> host that will be useful to anyone searching common semantics. In almost all cases the semantics are exactly what I would expect or better. In many cases I want to steal the semantics for Dplug.

Top concerns

  • There is no mention I've seen of binary compatibility, can something ABI-breaking happen outside a major version? I would hope for none. I probably have missed that. This seems like an evolving format but I tend to do format once and forget about it, it better not be a project (EDIT: so I've seen it in one header file, very nice, I feel it should be a bit more obvious. I don't want to work in CLAP all my life and want guarantees and actually following that promise).

  • No host seems to implement CLAP_PRESET_DISCOVERY_LOCATION_PLUGIN apart from MultiTrackStudio and clap-validator. For us that means getting more emails and well selling less plug-ins in practice.

  • I was told to implement audio-ports-config but apparently it is getting replaced by configurable-audio-ports. This is a bit messy. Extensions should point to their replacement. audio-ports-config makes a lot of hosts crash in practice.

Specifics

  • In clap_audio_port_info_t, the purpose of port_type is obscure. No explanation is given to why it exists. What happens if that field contradicts channel_count? Only reading configurable-audio-ports.h extension seems to enlighten.

  • clap-validator handles neither TODO: Handle 'clap_host_params::rescan()' nor TODO: Handle 'clap_host_params::request_flush()', it seems to me it makes some of our tests not pass.

  • In clap_preset_discovery_provider_descriptor_t it's not immediately clear that the .id returned should be globally unique. Are those identifers namespaced by the plugin? My understanding is that no, they should be globally unique like plugin IDs. We use com.company.Plugname.factory.

  • For categories, I'd suggest to change "pitch correction" to "pitch", as the effects are often quite related.

  • Honestly have no idea what exactly CLAP_PROCESS_CONTINUE_IF_NOT_QUIET, CLAP_PROCESS_TAIL and CLAP_PROCESS_SLEEP imply, they look extra dangerous to use. We have internal tail and silence detection for other formats anyway.

  • Should I declare 1 location for N factory presets (inside plugin binary) or N location of each 1 preset? I assume, the former. Wasted a bit of time on that.

  • clap-validator and clap-info do not test audio-ports-config properly, and send bad pointers to adress 0x1. Might be a bug with the D compilers though IIRC.

  • Sometimes for an unexplainable reason, clap-validator and clap-info has zero output. To reproduce, return very long strings without terminal zero for your plugin descriptors. This will crash something in clap tools and make them have no output, while still performing tests.

  • There are two ways to pass transport events, and one of them is redundant.

Clone this wiki locally