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

[robbert-vdh]

I don't know what original spec you're referring to, but you indeed cannot get a flush call while you're processing audio (and that w ouldn't make any sense, since the host could just send parameter changes or let you output parameter changes through the process function).

[mystran]

I don't know what original spec you're referring to, but you indeed cannot get a flush call while you're processing audio (and that w ouldn't make any sense, since the host could just send parameter changes or let you output parameter changes through the process function).

Commit 5723b7c0d7b7ffc1a8e53b712e53f59ec0855552 changed clap/include/clap/ext/params.h:

Code: Select all

 /// There are two options to communicate parameter value changes, and they are not concurrent.
 /// - send automation points during clap_plugin.process()
-/// - send automation points during clap_plugin_params.flush(), this one is used when the plugin is
-///   not processing
+/// - send automation points during clap_plugin_params.flush(), for parameter changes
+///   without processing audio

Code: Select all

    // Flushes a set of parameter changes.
    // This method must not be called concurrently to clap_plugin->process().
-   // This method must not be used if the plugin is processing.
    //
-   // [active && !processing : audio-thread]
-   // [!active : main-thread]
+   // [active ? audio-thread : main-thread]
    void (*flush)(const clap_plugin_t        *plugin,
                  const clap_input_events_t  *in,
                  const clap_output_events_t *out);

This was after this specific part was discussed on github, so perhaps it should be discussed there some more, because honestly I think this part of the original spec (before the above diff) was arguably less open for interpretation.

edit: Also just to clarify, I'm not confused about how this is supposed to work, but rather I'm playing devil's advocate and specifically trying to find loop holes in the specification.

[S0lo]

.... but rather I'm playing devil's advocate and specifically trying to find loop holes in the specification.

@clap team

We want CLAP to succeed. So please bear with us if we sound a little too nit picky at times (talking about myself). And at other times I'm simply trying to understand it. The CLAP team has done a great job, as it's obvious from the code we're reading

Also my special thanks to the surge team for that clap-saw code, very useful in my case. It is the one I was able to successfully compile here.

[S0lo]

Is there a specific reason why clap separates automation from modulation? I mean if the final value of the param is the sum of both, Then why can’t we just rely on the host to give us that final summed value?

[Urs]

Automation is destructive, modulation is temporary. If Automation was abandoned, concepts that are supposed to alter plug-in state would not be possible anymore.

[mystran]

Automation is destructive, modulation is temporary. If Automation was abandoned, concepts that are supposed to alter plug-in state would not be possible anymore.

I guess the idea is that you can record (or generate) modulation.. and then you can still tweak the base value? On the other hand, using a host-provided interface to weak parameter values doesn't work if you can't also change the actual base value (by automation).

[Markus Krause]

Did someone succeed to make the juce-clap adapter work in Visual Studio on PC? I can't make it build.
https://github.com/free-audio/clap-juce-extensions

[Urs]

In reply to mystran: Well, they’re related but different concepts. The main differences are, one is relative, the other isn’t. One is destructive, the other is not. The implications are bigger than first meets the eye. Completely new concepts are possible as to what plug-ins and hosts can do. Like baconpaul‘s example synth which completely relies on parameter modulation for its filter.

[baconpaul]

Did someone succeed to make the juce-clap adapter work in Visual Studio on PC? I can't make it build.
https://github.com/free-audio/clap-juce-extensions

Yes. Our CI pipeline uses msvc to build, and most of the surge devs on windows use visual studio and it builds.

Perhaps start a discussion on the GitHub with the particular problem you are seeing?

[baconpaul]

In reply to mystran: Well, they’re related but different concepts. The main differences are, one is relative, the other isn’t. One is destructive, the other is not. The implications are bigger than first meets the eye. Completely new concepts are possible as to what plug-ins and hosts can do. Like baconpaul‘s example synth which completely relies on parameter modulation for its filter.

The way i've described it to folks also is:

Eurorack modules often have knobs and cv inputs next to them. The knob is the value absent input, the cv input is the modulation relative to the knob.

Monosynths like the minimoog have knobs and modulator routings. Assign the envelope to the cutoff and the knob doesn't move but the filter changes.

Polysynths like surge have mod matrices. Set a value and assign a relative change based on events and generators.

Before CLAP, the plugin apis didn't have that distinction on parameter values. There was "only" a knob available to the DAW which had to reach in and move the knob. With a second channel (and with polyphonic addressing on that second channel), you can bring that voice architecture to the parameter stream so daws can participate in the polysyngh mod matrix and so on.

[ThomasHelzle]

@Solo: It was discussed on other threads some more in depth, but if you aren't familiar with the concept, the gist is:

Automation changes the actual parameters in the GUI of the Plugin. So if you dial in a cool sound, automate it, then for some reason remove the automation, depending on where you are in the timeline at that point in time, you get a different sound as a result. And the values you set are "absolute". This is what destructive means in the context.

If on the other hand you modulate parameters in Bitwig, your modulation amount starts from where that actual parameter is set to and moves around it. So it's relative to that initial position, which is beneficial in many cases. And you can still change that parameter and the modulation will then affect it from that new possition.
Also you can have multiple sources modulate a single parameter without them fighting, they are simply added together.
But most of all, if you remove all your modulation, you are back to exactly the same sound you started with.

I hope this makes sense

Cheers,

Tom

Edit: Ah, Baconpaul beat me to it

[S0lo]

It does make sense to me now after all the explanations above.

So this also entails that after the modulation is done. Either the host or the plug-in should set the mod amount to zero, otherwise the final value is destructive. Who is responsible of that?

This also brings the thought whether or not to immediately set it to zero (which may or may not be desirable for some parameters) or to lag/slide it slowly to zero. Edit: I guess the plug-in can decide this since most of us already do parameter smoothing.

[S0lo]

On second thought, I guess the plug-in is responsible for setting to zero since it is the one who’s responsible of sending that NOTE END message to the host?

[mystran]

So this also entails that after the modulation is done. Either the host or the plug-in should set the mod amount to zero, otherwise the final value is destructive. Who is responsible of that?

I'd imagine you zero global modulation on reset() and per-voice modulation when you start a new voice (or end the previous in case there's a distinction).

[S0lo]

So this also entails that after the modulation is done. Either the host or the plug-in should set the mod amount to zero, otherwise the final value is destructive. Who is responsible of that?

I'd imagine you zero global modulation on reset() and per-voice modulation when you start a new voice (or end the previous in case there's a distinction).

Thing is, with a modular synth, all voices are always ON and free running. It's the VCAs that close the sound. Plus, figuring out when a sound actually ends can be very hard to impossible with complex patches and feedback loops, it might never end.

I could end the mod when a new note comes in though, but haven't thought of the implication yet.