Add a draft meters extension

[linuxnow]

This adds clap.meters/1, a draft extension that lets a plugin expose its meters to the host. It follows up on #520.

Today a host can read one value, from clap.gain-adjustment-metering, and only on the audio thread. A compressor often has more than that: gain reduction, input and output level, sometimes per channel. Those stay inside the plugin's GUI, so a host mixer or a control surface can't show them.

With this extension the plugin lists its meters. Each one has an id, a name, a kind (gain reduction, level, or other), a channel count and a display range. The host reads the latest values with get_values(), from any thread, at whatever rate it draws. Gain reduction uses the same negative dB as gain-adjustment-metering.

How a host uses it:

1. Once the plugin is created, call count() and get_info() on the main thread and build its meter widgets.
2. While the plugin is active, call get_values(plugin, id, buf, capacity) from the GUI or network thread at the display rate. A return of 0 means there is nothing to show yet.
3. When the plugin calls host_meters->changed(), scan the list again. That only happens while the plugin is deactivated, so get_values() never sees the list change under it.

We run this today in our live mixing console, under a vendor id. Once a draft id exists we will switch to it.

Builds with -DCLAP_BUILD_TESTS=ON. All six compile tests pass (C11, C17, C++11, C++14, C++17, C++20). The header also builds on its own with -Wall -Wextra -pedantic -Werror as C11 and C++11.

[CLAassistant]

All committers have signed the CLA.

[baconpaul]

So I like this idea but get values being thread safe and multi valued and lock free means you could get channel tearing (you don’t guarantee the same state left and right) since really the only way to implement it would be to do loads of atomics in order

that’s fine but I think the documentation should say it

it think also get values might need an activated or processing tag but I’m not sure. If it doesn’t it should document whether the intent is to return zero or last known or such.

[linuxnow]

That's a nice idea and easy to deliver :)

On tearing: you are right that a multi-channel read can give you left from one block and right from the next. For level bars that is fine, a mixer smooths them anyway, and synchronizing on the host side would be overkill for metering.

But a value derived from several channels, a correlation or a balance, does need them together, so the plugin should give that itself: it fills one of a few copies of the value array off the reader's path and publishes it with one atomic index, so both threads stay wait-free. I added flags to clap_meter_info with CLAP_METER_IS_COHERENT` so a plugin can promise this and a host can tell which meters keep it; the comment on the flag describes the scheme.

On the lifecycle: documented in get_values(). Before the first process() after activation it returns 0; once processing has stopped it keeps returning the last values it computed, until deactivate().

Pushed!

[baconpaul]

Yeah that makes sense. Use a long ring buffer of size N and an atomic index if you are coherent. good change.