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

[Urs]

Dear Enrico,

I've notified Frank and baconpaul, maybe they can chime in. I think the best place to raise such issues is the main Discussion section:

https://github.com/free-audio/clap/discussions

Also, it would be great if you could contribute the missing "Build on Windows" message for the README.md

Thanks,

- U

[baconpaul]

I’m not sure if frank has pulled e various fixes from the clap saw demo into the imgui variation, but in this particular instance

https://github.com/surge-synthesizer/cl ... emo.h#L123

This comment explains what you are seeing. The clap saw demo just doesn’t implement string to param.

[baconpaul]

Yeah Enrico so I added the function needed to both the VSTGUI and the IMGUI forks of clap-saw-demo. I also ported all the changes to the VSGUI synth into the IMGUI one, upgraded both to clap 1.2.0, and got the CI working (win, mac, lin on vstgui; win, mac on imgui). I tested both in bitwig mac and they work as expected. (I don't have a running win with me now so if you want to test and report back that would be appreciated)

The behavior you see with 'reset to default' is I think a bitwig behavior which is confusing when a plugin returns 'false' on paramTextToValue so I also opened an interop tracker issue

But if you pull the project at head, do a submodule update, and clean build, you should be good.

[IllusionCatalyst]

Thank you very much for your extremely quick help, I deeply appreciate it.

Urs, I'll write to the CLAP github forum if I have further questions from now on. About adding to the sample, I would need to prepare a better setup, possibly updating the CMAKE config and make it handle Windows graciously. I don't have a lot of experience with it, but I can certainly give it a go.
To get to the coding as quickly as possible I used premake to generate a solution with two projects, one includes all the source code from clap/clap-helpers/clap-imgui-support/imgui/readerwriterqueue, and the other includes the source of the clap-saw-demo-imgui. As you can imagine, not the prettiest setup, but it works.

Baconpaul, thank you very much for the explanation, and for updating all the code. I built it in VS2019 and it runs perfectly in Bitwig 5.1.5 on Windows 10. Also having your sample, along with Frank's fork, is extremely useful, thanks again for writing it.

Cheers
Enrico

[baconpaul]

Great. The cmake build does run on windows just fine - I checked it in the ci stage I added - but didnt have windows to see if the resulting windows plugin from that build works! So appreciate the confirmation

[baconpaul]

However, I don't think window handling is THAT complicated and frameworks always introduce other issues (as experienced here).

...

I'd make an example plugin that simply provides window handling + 3D accel initialization. Plus one where NanoVG is plugged in.

...

Compare with the Aether LV2 plugin. A port of that to CLAP and adding MIDI support would be a great example plugin.

So I read these three thoughts and it made me wonder "how does Aether actually manage to make a high performance cross platform ui with window handling and state management and stuff without a framework". And the answer is: it doesn't! But since I actually read the code thought I'd share one thought

Aether LV2 uses pugl (https://github.com/lv2/pugl) which is a framework for writing OpenGL based plugin and application uis. It has some of the problems with frameworks you mention (it couples to meson for builds, for instance) but also solves some of the problems we had with imgui (specifically it seems that the Pugl_World concept is a per-ui state so you don't get the shenanigans frank had to do to make imgui work in two windows at once).

But most importantly you can see in the Aether code base that at the end of the day the framework does a reparent on the native window (here: https://github.com/Dougal-s/Aether/blob ... .cpp#L2621) and that native window pointer looks to me like the native embedded window object that you get in set parent in clap gui (here: https://github.com/free-audio/clap/blob ... gui.h#L175)

And so this is sort of urs' point: The role of *clap* is to have a way that your host can hand you an HWND, NSView *, xwnd* etc... and then the plugin can do whatever it wants. In JUCE-land we use the Juce component reparenting code (and then we get all the useful stuff which comes with JUCE like accessibility and so on); in vstgui we used the vstgui reparent code on Mac and win but had some hoops on linux; in imgui we wrote a state wrapper to make a MetalKit NSView or DX12 surface. With PUGL you would do the same thing, and end up with a line of code like the above from aether LV2, just in your clap.

If you were at a lower level (using nanovg directly or whatever) you do have to deal with events, and so get the glfw / glut / window state issues we all know and love. But should be relatively easy to bang together if you want.

Hope that helps!

[IllusionCatalyst]

Hello Baconpaul, I can confirm that the clap-saw-demo-imgui.clap built in VisualStudio 2019 on Windows 10, by opening the CMAKE config directly is working correctly.

- I did a fresh clone of the repository with: `git clone --recursive https://github.com/free-audio/clap-saw-demo-imgui.git`.
- In Visual Studio, chose: `Open a local folder` and selected the cloned repository.
- Run: `Build > Build All`.
- Found the built plugin at: `/clap-saw-demo-imgui/out/build/x64-Debug/clap-saw-demo-imgui.clap`
- Loaded in Bitwig, works perfectly.

Cheers
Enrico

[baconpaul]

Hello Baconpaul, I can confirm that the clap-saw-demo-imgui.clap built in VisualStudio 2019 on Windows 10, by opening the CMAKE config directly is working correctly.

- I did a fresh clone of the repository with: `git clone --recursive https://github.com/free-audio/clap-saw-demo-imgui.git`.
- In Visual Studio, chose `Open a local folder` and selected the cloned repository.
- Run Build > Build All.
- Found the built plugin at: `/clap-saw-demo-imgui/out/build/x64-Debug/clap-saw-demo-imgui.clap`
- Loaded in Bitwig, works perfectly.

Cheers
Enrico

Wonderful thank you!

[Music Engineer]

This ADC talk by Angus Hewlett:



might be interesting to the followers of this thread. The part about audio plugin APIs starts at 27:00. ...the slide at 29:47....I wonder, if - just maybe - he was thinking of two specific examples for the left and right hand side of the slide

Oh - and this document may also be of interest:

https://github.com/angushewlett/plugnpain

so we can have informed rants about which format rocks and which one doesn't

[diroxe7660]

Hello.

I was hoping someone could clarify a couple of things for me:

- What is the very first time I should inform the host of my latency and tail values? .init -> right after checking for extensions? If so, this doesn't get picked up by clap-info.

- When there's nothing to process and if I've advertised the TAIL extension to the host (Reaper), the host stops sending CLAP_EVENT_PARAM_VALUE altogether after the tail has run out, even when the user keeps changing params in my GUI-less plugin. Is this intended behaviour, or rather: how can I fix this to have both a tail and param changes?

- I've implemented the STATE extension and saving, loading and applying states stored in DAW projects is working correctly, clap-validator isn't complaining. But: DAW undo (Reaper) is broken in all sorts of ways with the STATE ext. I have observed that out of the 11 CLAP plugins I have, 7 behave in exactly the same way (parameters set to seemingly random values when undo'ing) and only 4 (that use the STATE ext - all JUCE) seem to work correctly.

So there seems to be a correct way (JUCE?) to use states and an incorrect way and further clarification, more examples might be needed?

[Jeff McClintock]

- When there's nothing to process and if I've advertised the TAIL extension to the host (Reaper), the host stops sending CLAP_EVENT_PARAM_VALUE altogether after the tail has run out, even when the user keeps changing params in my GUI-less plugin. Is this intended behaviour, or rather: how can I fix this to have both a tail and param changes?

That sounds like the intended behavior. process() is not called when the plugin is idle and therefore the parameter change events are not communicated via the process() function.
However, CLAP has a workaround, which is that the DAW can call the plugin's 'flush()' method to send parameter updates in this situation.
I believe these are called on the real-time thread, so you would need to communicate those events to the UI in a safe manner.

[diroxe7660]

I agree! But I don't have a UI, so I'm at Reaper's mercy for flush()ing changes in Reaper's generic UI back to the plugin. But Reaper doesn't seem to do so past the tail's end, so parameter changes are purely visual and never actually happen.

Ideally I'd want clap_process_status or clap_plugin_tail to clarify that the host should continue to flush parameter changes in the generic UI back to the plugin after the tail's end so I don't get sent around in circles by the Reaper devs because "no processing means no processing".

[abique]

Hello.

I was hoping someone could clarify a couple of things for me:

- What is the very first time I should inform the host of my latency and tail values? .init -> right after checking for extensions? If so, this doesn't get picked up by clap-info.

- When there's nothing to process and if I've advertised the TAIL extension to the host (Reaper), the host stops sending CLAP_EVENT_PARAM_VALUE altogether after the tail has run out, even when the user keeps changing params in my GUI-less plugin. Is this intended behaviour, or rather: how can I fix this to have both a tail and param changes?

- I've implemented the STATE extension and saving, loading and applying states stored in DAW projects is working correctly, clap-validator isn't complaining. But: DAW undo (Reaper) is broken in all sorts of ways with the STATE ext. I have observed that out of the 11 CLAP plugins I have, 7 behave in exactly the same way (parameters set to seemingly random values when undo'ing) and only 4 (that use the STATE ext - all JUCE) seem to work correctly.

So there seems to be a correct way (JUCE?) to use states and an incorrect way and further clarification, more examples might be needed?

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

Though, tail is not the right way to do it with CLAP, you want to indicate the host if you can go to sleep or not via the process() return value. Tail is just for making it easier to get your port started from VST/VST3 plugins.

[diroxe7660]

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.

Though, tail is not the right way to do it with CLAP, you want to indicate the host if you can go to sleep or not via the process() return value. Tail is just for making it easier to get your port started from VST/VST3 plugins.

Ooooh, okay. Thanks. I'll do this differently then.

[Alien Brother]

(Reaper), the host stops sending CLAP_EVENT_PARAM_VALUE altogether after the tail has run out

What I see in Reaper 7.14 is if the plugin is not processing, Reaper will not send you CLAP_EVENT_PARAM_VALUE, from it's own parameter editor nor from "show in track controls". But, it will buffer the changes internally and send them all when you either start processing or call request_flush() yourself. If you exit Reaper before that, changes will be lost. Or, in a plugin with a gui extension there's another way to lose changes: when the plugin is not processing, edit something in Reaper's parameter editor, switch to the plugin's gui, then immediately back to Reaper's editor. I see this when the audio device is closed, but this seems consistent with what you see with the tail extension.