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

[Architeuthis]

Does CLAP have a "default interface" thing like VST? And if so... uhh... how do you make a parameter in C? Looking through the code, I can't find a "first step" kind of project, taking the `plugin-template.c` and then adding one parameter to, for example, control gain. Is there something in the repository like this?

[mystran]

So I was trying to map some VST timeinfo/transport into clap and vise versa,

I noticed that clap_beattime and clap_sectime are defined as int64_t. Shouldn't these be double/float. I guess there has to be some sort of scaling? or these count in nano seconds? nano beats ?

The conversion factors are in *fixedpoint.h. They're fixed-point numbers to avoid rounding errors.

It does not avoid rounding errors in general, it just makes them independent of the magnitude of the integer part. In fact, it results in more rounding errors than doubles when the integer part fits to less than ~22 bits (=less than 4 million beats/seconds).

The beattime increases by tempo/(60*samplerate) per frame and sectime increases by 1/samplerate per frame. For almost all values of tempo, this will not have a finite fixed (or floating) point representation (since 60=3*5*2 and samplerate usually has plenty of prime factors too), so practically speaking even if you had the exact time for sample 0, you can't really compute the exact time for sample 1.

There might be some special cases where fixed point (if you're actually computing in fixed point) would allow you to be slightly more consistent, but unless you specify how every single computation involving these values should be done by both host and plugin, there's basically no obvious advantage to fixed point that I can see... not that it really matters one way or another, because it's not exactly hard to convert back and forth.

[S0lo]

So I was trying to map some VST timeinfo/transport into clap and vise versa,

I noticed that clap_beattime and clap_sectime are defined as int64_t. Shouldn't these be double/float. I guess there has to be some sort of scaling? or these count in nano seconds? nano beats ?

The conversion factors are in *fixedpoint.h. They're fixed-point numbers to avoid rounding errors.

It does not avoid rounding errors in general, it just makes them independent of the magnitude of the integer part. In fact, it results in more rounding errors than doubles when the integer part fits to less than ~22 bits (=less than 4 million beats/seconds).

The beattime increases by tempo/(60*samplerate) per frame and sectime increases by 1/samplerate per frame. For almost all values of tempo, this will not have a finite fixed (or floating) point representation (since 60=3*5*2 and samplerate usually has plenty of prime factors too), so practically speaking even if you had the exact time for sample 0, you can't really compute the exact time for sample 1.

There might be some special cases where fixed point (if you're actually computing in fixed point) would allow you to be slightly more consistent, but unless you specify how every single computation involving these values should be done by both host and plugin, there's basically no obvious advantage to fixed point that I can see... not that it really matters one way or another, because it's not exactly hard to convert back and forth.

hmm, I'm assuming significant errors may only arise from accumulative addition over a long track?

What if we assume a different fixed point counter (call it beat_counter) that counts in integers of beattime. So when beat_counter=1 thats a beattime of tempo/(60*samplerate). When beat_counter=2 thats 2*tempo/(60*samplerate). I think, this would handle whatever tempo and irrationality errors we have. So whenever we want an actual value, beattime = beat_counter * tempo/(60*samplerate). Edit: Nah, won't work for tempo changes.

[mystran]

hmm, I'm assuming errors may only arise from accumulative addition over a long track?

The fixed point representation in CLAP starts to become more accurate when your track is over 2-3 weeks long (depending a bit on tempo).

What if we assume a different fixed point counter (call it beat_counter) that counts in integers of beattime. So when beat_counter=1 thats a beattime of tempo/(60*samplerate). When beat_counter=2 thats 2*tempo/(60*samplerate). I think, this would handle whatever tempo and irrationality errors we have. So whenever we want an actual value, beattime = beat_counter * tempo/(60*samplerate)

This doesn't work because tempo in general is not a constant, which is the whole reason beat_time (aka. ppqTime) exists in the first place. It measures musical time, not actual real-time.

What you could do is compute in rational arithemetics with a denominator of 60*samplerate and then restrict your tempo to integers only... but seriously this is so academic it just doesn't matter at all. It's not hard to write code to deal with (very very slightly) inexact computations, it's just that you shouldn't pretend that everything magically becomes exact if you use fixed-point.

[S0lo]

This doesn't work because tempo in general is not a constant, which is the whole reason beat_time (aka. ppqTime) exists in the first place. It measures musical time, not actual real-time.

Yeah, tempo changes would wreck the whole thing.

[baconpaul]

Does CLAP have a "default interface" thing like VST?

Default Interfaces are properties of DAWs not plugins. But yes bitwig has a default interface for CLAPs as does the example host and others.

And if so... uhh... how do you make a parameter in C? Looking through the code, I can't find a "first step" kind of project, taking the `plugin-template.c` and then adding one parameter to, for example, control gain. Is there something in the repository like this?

https://github.com/free-audio/clap/blob ... ams.h#L190

you implement that function and the associated count method near it.

A example (though the C++ wrapper, but its' really no different) is https://github.com/surge-synthesizer/cl ... mo.cpp#L63

[MirkoVanHauten]

This parameter index is just used for the initial parameter description and everywhere else the id is used, right? So the plugin could reorder or add parameters without messing up automation?

[robbert-vdh]

This parameter index is just used for the initial parameter description and everywhere else the id is used, right? So the plugin could reorder or add parameters without messing up automation?

Exactly.

[baconpaul]

Yeah you will note the clap saw demo uses non contiguous parameter ids just to make sure this point is clear

[Markus Krause]

This parameter index is just used for the initial parameter description and everywhere else the id is used, right? So the plugin could reorder or add parameters without messing up automation?

Exactly.

That's awesome! It allows you to add additional parameters easily in later updates without messing the logical grouping of parameters.
Clap is a really well-thought plug in format. Things like this is what the industry really needs.
Thanks to all involved in this

[baconpaul]

This parameter index is just used for the initial parameter description and everywhere else the id is used, right? So the plugin could reorder or add parameters without messing up automation?

Exactly.

That's awesome! It allows you to add additional parameters easily in later updates without messing the logical grouping of parameters.
Clap is a really well-thought plug in format. Things like this is what the industry really needs.
Thanks to all involved in this

Parameters also have modules (basically a / separated path) which a daw could use to group basically just as another string. The demo clap host actually gives you a tree view using these!

Thanks for the kind words

[Urs]

In the meantime we assembled a few pages about a couple of things we find important:

https://cleveraudio.org

More to come, sure, yet maybe a good start to get past fragmented information in a dozen forum threads.

[S0lo]

In the meantime we assembled a few pages about a couple of things we find important:

https://cleveraudio.org

More to come, sure, yet maybe a good start to get past fragmented information in a dozen forum threads.

I devoured the whole text in half an hour lying on bed. Exciting and well thought of.

[moss]

Meanwhile the 3rd part of my "Developing with CLAP" tutorial series is online:
https://youtu.be/oko5xJDY39E

Full Playlist:
https://www.youtube.com/playlist?list=P ... AqNQhcwF4W

[S0lo]

Did any one experience an issue where the host automatically ends sending modulations for an active note_id when another note_id gets triggered for the same musical note?