Skip to content

CLAP implementation notes

Jump to bottom
p0nce edited this page Nov 4, 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.

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?

  • Parameter min_value and max_value must be isfinite(), but this isn't strictly specified.

  • In clap_gui_resize_hints_t: aspect_ratio_width/ aspect_ratio_height only make sense if preserve_aspect_ratio is true, but this isn't written in the comments.

  • "floating" windows have little support, and aren't really expected to implement for a plug-in. But I wondered if I MUST support that.

  • Specify that custom CLAP events should be self-contained / copyable, and interior pointers are thus disallowed (should be stored as relative offsets). This part is basically oral lore, but I feel an important detail to maintain. (EDIT: and I really wonder, should their free method be mentionned?)

  • 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. DAW name probing allows to support them...

  • clap-validator needs a new release, and haven't seen too much action in the last 2 years.

  • Sometimes for an unexplainable reason, clap-validator and clap-info has zero output.

Clone this wiki locally