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

[mystran]

The host should lookup those values and cache those after activation anyway (latency, tail).
If it doesn't get picked up, host bug.

Hm, might be worth clarifying for host implementers somewhere. I can't get Reaper to pick up my latency without the plugin calling host_ext_latency->changed(). But maybe I'm doing it wrong.

That's actually how I'd interpret the spec: the host can fetch the latency once and cache, then if the plugin wants it changed it should tell the host about it by calling host_ext_latency->changed().

Also keep in mind that any plugin changing it's latency is a potentially (moderately) expensive operation for the host, because it will likely have to recalculate it's whole PDC graph and perhaps reallocate buffers and what not... which is why it's also not allowed without suspending the plugin (and realistically that might typically also mean temporarily suspending the whole processing graph in the host).

[diroxe7660]

If you exit Reaper before that, changes will be lost.

Yeah, this is really confusing for anyone who's setting up a bunch of sends/receives for their templates or FX chains. They can't get parameters to stick no matter how hard they're trying to save.

I don't think hosts should flush() just when exiting or saving. Many plugins will want to change their parameter labels depending on parameter value, so the host needs to keep pumping out PARAM_VALUE or the user will be forced to dial in their plugins blind with the DAW editor.

(Unless I absolutely need the GUI, I use the DAW editor exclusively)

That's actually how I'd interpret the spec: the host can fetch the latency once and cache, then if the plugin wants it changed it should tell the host about it by calling host_ext_latency->changed().

Exactly! The spec leaves room for interpretation. 'can' fetch. I'd be super happy if the spec said 'if your host supports the latency extension, it must fetch the initial and correct latency value from the plugin at exactly this point and nowhere else'.

Right now we have a bunch of options:
- Hope the host picks up your initial latency by itself. I can't get Reaper to do this.
- Tell the host your latency with a changed() right after checking for the host supporting the latency extension. This works in Reaper.
- Have your plugin start with an invalid latency and request_restart() in your first process(). This should always work but is a hack.
- Combine all three to cover your bases across DAWs

[mystran]

Right now we have a bunch of options:
- Hope the host picks up your initial latency by itself. I can't get Reaper to do this.
- Tell the host your latency with a changed() right after checking for the host supporting the latency extension. This works in Reaper.

Oh... so the problem is that Reaper doesn't fetch the latency at all if you don't report it changed?

If that's the case then ... yeah it should be clarified in the standard whether or not the host is allowed to default to zero latency and expect plugin to call changed() even at startup. That might actually not be a terrible choice overall though, 'cos otherwise there's the risk that host queries the latency at startup before the plugin actually knows it ('cos it could change based on things like the host samplerate or whatever).

- Have your plugin start with an invalid latency and request_restart() in your first process(). This should always work but is a hack.

That doesn't sound like a great idea, because it'll probably lead to a situation where the host starts processing and then immediately has to stop everything again and recompute PDC and perhaps reallocate buffers and whatever.. where as if simply calling changed() as soon as you know how to compute the latency should be less problematic if it happens before the plugin is first activated (just one round of PDC computation).

[diroxe7660]

Oh... so the problem is that Reaper doesn't fetch the latency at all if you don't report it changed?

I've been tinkering some more and I've finally found a place where Reaper will pick this up - activate()!

Apologies for the false alarm!

Edit: Or maybe not after all

[Leslie Sanford]

I'm enjoying getting my feet wet again with audio programming using CLAP. I'm currently working on a simple delay effect that I hope to release soon along with the code.

I'm working on synchronizing the delay time to tempo and time signature changes. Is there an extension you're supposed to implement to get CLAP_EVENT_TRANSPORT events? I know you can grab the transport data inside the process function from the process structure, but I haven't figured out how to receive transport events.

Thanks for any help.

[abique]

You have the transport info at time 0 right here: https://github.com/free-audio/clap/blob ... cess.h#L45

Then it depends on the host, for example Bitwig Studio won't produce transport event within a block as of today.

[Leslie Sanford]

Is the tail extension something that would be appropriate for a delay effect to implement?

[defiantnerd]

Is the tail extension something that would be appropriate for a delay effect to implement?

Yes. Absolutely.

[stoopicus]

Late to the party but just starting to take a look at this now.

clap-wrapper looks like exactly how I would want to approach multiformat support but what are people who use it doing for AAX? Ignoring it or wrapping manually I guess?

[Marvinh]

was wondering about AAX myself

[poonna]

CLAP is on the roadmap to be supported in JUCE 9.0. I guess that's something to look forward to for a way to support both CLAP and AAX, but probably a bit too far ahead.

[stoopicus]

Developing only to CLAP and then having an option like clap-wrapper seems pretty ideal to me, really, especially if using something like imgui.

[baconpaul]

Defiantenerd is starting to look at AAX but no date yet for it in the wrapper. It’s entirely possible but it’s not done.

And yes clap plus wrapper is the strategy we are moving to. Shortcircuit will almost definitely use that architecture as the production architecture when we release

[Leslie Sanford]

Here is my first attempt at a CLAP plugin; it's a simple delay effect:

https://www.lesliesanford.com/clap/plugins/delay.zip

It's Windows only and uses Win32 controls for the GUI.

If anyone has time to try it out, please let me know what you think or if you run into any problems.

My plan is to put the code on GitHub if this modest attempt isn't completely embarrassing.

Thanks.

[diroxe7660]

Nice job! The plugin's working fine mostly and I've only observed minor issues:

- When turning off sync and enabling the HPF/LPF, changes to the filters sometimes take a really long time (several seconds) to apply.

Edit: I somehow managed to break the filter or the cutoff slider by rapidly changing cutoff freq.

- Undo does not work with the generic editor UI in Reaper - but this might be a Reaper or spec issue. I've seen this happen with other CLAP plugins in Reaper, including my own.

If you find fixes, please let me know!