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

[otristan]

So allocate buffers on per-thread basis, let voice tasks use the buffers of whatever thread happens to run the task, then merge per-thread rather than per-voice at the end?

This is indeed what I do with my current thread pool implementation.
What I could have is a lock free buffer pool with enough to handle all the concurrent thread to match the CLAP idiom.

I don't think there's a sane way to do this with the current API. As you say, knowing the number of threads in the pool and having sequential indexes for them that are passed to the task function would enable these kinds of schemes where tasks "borrow" per-thread resources.

With the current API the sane thing to do is just alloc per-voice, but I'd support revision of the API for these extra bits of information; implementation cost should be low, performance benefits should be real even if not necessarily huge and really the only downside is that it'd be a breaking change to API.

That was my point and the API I use for my own thread pool

[dellboy]

I think this has gone under the radar that the DAW, "EnergyXT", has in recent months been updated to 64bit and now has Clap support. Its currently in Alpha.

https://www.xtsware.com/?page_id=6

[moss]

I think this has gone under the radar that the DAW, "EnergyXT", has in recent months been updated to 64bit and now has Clap support. Its currently in Alpha.

https://www.xtsware.com/?page_id=6

WOOOOT? This lives again?

I used it quite a lot back in the days. Who is behind it now?

[gruust]

Anyone aware of what's up with https://github.com/schwaaa/clap-imgui ?

I've built it under Windows 11/x64. Bitwig won't even load it (plugin immediately crashes), and Reaper crashes when bringing it back online after having offlined it.

[Urs]

Anyone aware of what's up with https://github.com/schwaaa/clap-imgui ?

I've built it under Windows 11/x64. Bitwig won't even load it (plugin immediately crashes), and Reaper crashes when bringing it back online after having offlined it.

it was a dead end because it uses GFLW, which isn't suited for plug-in development (there can only be 1 window).

We have completely replaced GFLW with our own Metal/DirectX layer for the ImGUI support here:

demo: https://github.com/free-audio/clap-saw-demo-imgui
ImGUI support layer: https://github.com/free-audio/clap-imgui-support

That again has been sitting there for a while, it would be great if someone used it and gave us some feedback.

[gruust]

it was a dead end because it uses GFLW, which isn't suited for plug-in development (there can only be 1 window).

If we are talking about the same issue here, I have suggested a preliminary "solution", but it's not clear how far you get with that (see commit comments): https://github.com/glfw/glfw/issues/1395

However, I don't think window handling is THAT complicated and frameworks always introduce other issues (as experienced here). Just having a working example that rolls that stuff on its own is the best way IMO.

We have completely replaced GFLW with our own Metal/DirectX layer for the ImGUI support here:

demo: https://github.com/free-audio/clap-saw-demo-imgui
ImGUI support layer: https://github.com/free-audio/clap-imgui-support

That again has been sitting there for a while, it would be great if someone used it and gave us some feedback.

Nice. But Imgui (let alone QT ffs) is IMO the same error as Steinberg did with its AGain plugin and the UI editor: adding overhead that no one wants and obfuscating more optimal solutions. The UI looks like crap and it doesn't necessarily answer the question how to get more basic to get better results. I'd make an example plugin that simply provides window handling + 3D accel initialization. Plus one where NanoVG is plugged in.

In other words: you have a nice, lean and mean, permissively licensed API, but are copying the UI insanity from Steinberg in a way.

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

[Urs]

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

CLAP is a collaborative effort. You're welcome to contribute such a project. Our Metal/DirectX layer should be quite helpful here. We simply chose Dear ImGUI to illustrate the possibility with a simple and lightweight framework. If you have something better, please go for it!

Btw, no audio plug-in format comes with a ready-to-use UI engine, and CLAP is not an exception here. This is not by mistake but by necessity. host and plug-in developers are free to use whatever they want. Typically they go for high level frameworks.

We have therefore focussed our effort on making JUCE, iPlug2 and DFW compatible, which are already used by many plug-in developers. We also provide sample code for VSTGUI which should help most people who need to transition from VST2 to CLAP. More work is currently done towards Qt, which arguably is the most commonly used framework of all, but for which there was no example code at all for any plug-in format.

[gruust]

We have therefore focussed our effort on making JUCE, iPlug2 and DFW compatible, which are already used by many plug-in developers. We also provide sample code for VSTGUI which should help most people who need to transition from VST2 to CLAP. More work is currently done towards Qt, which arguably is the most commonly used framework of all, but for which there was no example code at all for any plug-in format.

Wait, are you telling me that there are commercially successful plugins based on VSTGUI? Are devs actually managing to make that thing look good?

[Urs]

We have therefore focussed our effort on making JUCE, iPlug2 and DFW compatible, which are already used by many plug-in developers. We also provide sample code for VSTGUI which should help most people who need to transition from VST2 to CLAP. More work is currently done towards Qt, which arguably is the most commonly used framework of all, but for which there was no example code at all for any plug-in format.

Wait, are you telling me that there are commercially successful plugins based on VSTGUI? Are devs actually managing to make that thing look good?

You must be kidding - Pretty much everyone used VSTGUI before JUCE became popular. Like, pretty much that vast majority of plug-ins published before 2012 or so were based on VSTGUI, and many of those that have survived since probably still are.

One of the initial priorities of CLAP development was giving those developers a future outlook for their existing work. That was available the day we went public with CLAP 1.0

[Music Engineer]

Wait, are you telling me that there are commercially successful plugins based on VSTGUI? Are devs actually managing to make that thing look good?

Serum. See here at 56:26:

https://www.youtube.com/watch?v=Cp0rtLaXBio

[gruust]

holy f. kudos to those who endured.

When I looked at that VSTGUI stuff, I was completely convinced no one would ever use it...

[S0lo]

holy f. kudos to those who endured.

When I looked at that VSTGUI stuff, I was completely convinced no one would ever use it...

May be you looked at VSTGUI 4 which is very different than the much simpler VSTGUI 3. VSTGUI 3 is the one that comes with VST 2. VSTGUI 4 complicated things, and is not backward compatible with VSTGUI 3.

The nice thing about VSTGUI is that it comes with a readily made C++ class hierarchy of UI controls. Knobs, switches, buttons, containers, sliders, text labels, menus, etc.. With relevant functionality to each. VSTGUI is also completely detachable from VST. Infact, it literally says on the title of documentation "Graphical User Interface Framework not only for VST plugins"

Unfortunately, if you want some hardware acceleration (who doesn't) You have to go with VSTGUI 4. But I don't personally know how well that performs, as I've only used VSTGUI 3

[baconpaul]

Surge (up until version 1.9) used VSTGUI 4.

After a moment of irritation with a missing component in the library mid pandemic, i spent a month and ported it to juce instead, which is how we got Surge XT. If any other devs out there want to go on this journey, happy to chat. (I implemented chunk of the VSTGUI API in juce as a staging plan) then started removing the port layer bit by bit.

[Alien Brother]

Compare with the Aether LV2 plugin.

I've been experimenting with ImGui for the last few weeks, and this is the kind of UI that ImGui is suitable for. I think it was a good idea that CLAP examples suggest trying it. There's a place for a whole second UI framework on top of ImGui (layout, styling, pre-rendering textures, font substitution, and so on) and it has its issues (context management boilerplate, incorrectly handling gamma, no built in X11 backend), but "start with ImGui" sounds like less work than "write your own UI framework from scratch on top of NanoVG" (which is an abandoned project from what it seems).

[IllusionCatalyst]

Hello, apologies if this is not the right place, but since I see baconpaul among the posters, I'll give it a shot.

I set up a VisualStudio 2019 solution to build clap-saw-demo-imgui (https://github.com/free-audio/clap-saw-demo-imgui).

I everything is up and running: it compiles and I can load and play the CLAP plugin in Bitwig 5.1.5.

I found a possible bug: when I adjust any parameter value (i.e.: Resonance) from the Bitwig Device interface by mouse click and drag, everything works correctly. If I change any parameter value by double clicking and typing, the parameter is always set to the default value (i.e.: 0.7 for Resonance), disregarding the input.

I checked the `process->in_events` queue and it indeed contains the default value rather than the typed one.

Given that the sample uses clap, clap-helpers, clap-imgui-support, I am not sure about where the issue may be coming from.
To exclude that it could be a Bitwig issue, I did the same with Diva CLAP, and it works correctly in every case.

Any help is much appreciated.

Cheers
Enrico