Cool new plug in format on the way -- CLAP

[tony10000]

More here from Urs of u-he:

viewtopic.php?p=8296134#p829613

[Music Engineer]

interesting news! let's hope, this takes off!

[karrikuh]

I was following the development over the last couple of months in anticipation of an official announcement, glad to see it's finally happening.

I have serious plans to support CLAP in the future and already playing with it. Not that I'm a relevant player in the industry by any capacity, but I'll do my best to support it's adoption, given the sad state of currently established "standards".

I already started diving into the current API spec and overall everything looks well thought-through and straight-forward.

One thing I noted and was wondering about is the number of initialization steps required to create a plugin instance and make it ready for processing audio. There is:
clap_plugin_entry->init()
clap_plugin_entry->createPlugin()
clap_plugin->init()
clap_plugin->activate()
clap_plugin->start_processing()

Any rationale why all these steps are needed? It sure would help to describe their use case in the API docs. Right now, it's not clear to my why anything beyond, say, just createPlugin() plus activate() is needed. At the very least, it might be a good idea to make some of these optional. Current reference host impl unfortunately assumes everything to be there and crashes if it isn't.

[Urs]

I'm not 100% certain, but the steps have certain meanings and useful side effects.

I'll try to explain:

After clap_plugin_entry->init() you can query the number of plug-ins and meta data. This way hosts can scan plug-ins quickly without actually instantiating them.

clap_plugin_entry->createPlugin() creates an instance. At this time it can't call the host, because the host has no pointer to the plug-in yet.

clap_plugin->init() tells it to allocate its resources, and from here on it can query the host.

clap_plugin->activate() is the point of time where sample rate, buffer size etc. are known. One can re-activate() a plug-in if the host changes those environmental variables. This happens on the user thread. We can expect further resource allocation here for buffers etc.

clap_plugin->start/stop_processing() is solely to inform the plug-in of its processing state. It may want to reset some state on start(). This happens on the audio thread, so it needs to be realtime compliant.

So the ideas behind those steps are

- one extra step to allow for fast plug-in scanning (similar to what at least one other plug-in format does)
- one (extra) step (as opposed to some formats) to prevent that a plug-in has to be unloaded/reloaded when environmental things change
- one extra step to clearly cut between user and realtime threads for plug-in processing maintenance

[Trader One]

I don’t think it’s good idea to make an another plugin format. VST3 works well.

[rasmusklump]

No it doesn't.

[tony10000]

I don’t think it’s good idea to make an another plugin format. VST3 works well.

Read the link at the top of the thread to discover why they are doing it.

[EvilDragon]

VST3 works well.

That's a good one.

[] Peter:H []

VST3 works well.

That's a good one.

So how can any plugin-vendor do any plugin in VST3 if it does not work well? There's amazing plugins done in VST3. I've often learnet that if I don't like things (Pro SW Dev here, not plugins) it could be as well an OSI Layer 8 problem.

I followed the "threadpool" discussion a little and actually I think it is weird and btw. the link on gh is broken https://github.com/free-audio/clap/blob ... ead-pool.h
Why is it weird. Not plugins should be in control of threads or ask for threads and potentialy cause side-effects or suffer from side-effects of other plug-in doing weird stuff.
The DAW is the single point of truth for the processing graph and it should build the graph in a meaningfull way and map it onto resources in an optimal way because we have to deal with cache coherence and stuff.
So a plug-in should somehow contribute to the graph, but when a graph consists of per-unisono-voice chains of like the synth-unisono-voice --> a voice specific filter --> a voice specific EQ --> voice specific crusher --> voice specific compressor I wouldn't want all that spread over different threads but pack the whole chain on one thread ... but anyway ... only my two cents and why I strongly beleive in "new" is not always "better".

[Urs]

I followed the "threadpool" discussion a little and actually I think it is weird and btw. the link on gh is broken https://github.com/free-audio/clap/blob ... ead-pool.h

It's not draft anymore (see the "draft" in the path?). Concept is proven and reduces multithreading overhead dramatically. Just go to the head of the path and click your way through.

(it's still linked as draft on the gut hub main page readme, but you'll find it through the path clap/include/clap/ext/ in the sources)

Not plugins should be in control of threads

Exactly. That's what it does.

[EvilDragon]

VST3 works well.

That's a good one.

So how can any plugin-vendor do any plugin in VST3 if it does not work well?

It's far from a pleasant development experience dealing with VST3 SDK directly. That's what I meant.

VST3 is overengineered instead of simple. All the things it does could have been done in a far more efficient manner, but nope.

[Urs]

Or things that could have been done but weren't. Which slowly are added as bandaids. Which aren't supported in hosts until dog knows when...

[mystran]

Why is it weird. Not plugins should be in control of threads or ask for threads and potentialy cause side-effects or suffer from side-effects of other plug-in doing weird stuff.

All that extension does is allow plugins to optionally tell the host "please process these things in parallel."

If you're the host, you benefit by having full control over multi-threading. If you're a plugin, you benefit by being able to take advantage of multi-threading without having to manage your own threads. If you're a plugin that couldn't care less about multi-threading, you benefit by having less threads compete for CPU resources and trashing your caches. If you're the user, you benefit from having better (and almost certainly more predictable) performance.

In other words, it's a pure win-win-win for everyone over the status quo.

[Markus Krause]

We plan to support the new format (CLAP) and will collaborate. It's open-source, it's simple, it's free for all and there are no unfair licensing conditions.
We Indy developers should have been getting rid of Steinberg and Apple already a decade ago.

[AnX]

But you didn't, instead you used their formats to make a business and earn money.... oh those evil companies