About CLAP

[AnX]

What a stupid question

I didn't realise there was such a thing, pardon me all over the place....

[AnX]

a subsidiary of u-he

isn't everything

[Urs]

WrapClap Inc, a subsidiary of u-he.

Not very likely... it's not as if we haven't got enough on our plate. Maybe someone else can chip in for this.

[baconpaul]

WrapClap Inc, a subsidiary of u-he.

Not very likely... it's not as if we haven't got enough on our plate. Maybe someone else can chip in for this.

And for AU you can should be able to do it as an MIT licensed adapter; don't even need a co selling it for that!

[Dewdman42]

unfortunately for me, until all the important hosts support CLAP, I would have to wrap as VST2, without license. The reason is because I am mainly interested in developing and distributing midi plugins.

[Music Engineer]

Any of the plugin vendors that have a VST2 license could make a closed source wrapper for VST2 that you could use, AFAIK.

i actually think, the wrapper could be open source as well as long as it doesn't redistribute the original vst sdk files. it could include the notorious "paste the vst sdk files into this folder" or "add your vst sdk folder to the compiler's #include search path" stuff - as frameworks like juce or iplug do. of course, only people who happen to have these files around could actually build the wrapper then (i'm assuming a runtime wrapper, btw.). or maybe it could use the fst or vestige replacement headers...which might be a bit risky, though

[Urs]

WrapClap Inc, a subsidiary of u-he.

Not very likely... it's not as if we haven't got enough on our plate. Maybe someone else can chip in for this.

And for AU you can should be able to do it as an MIT licensed adapter; don't even need a co selling it for that!

Hehehe, we're actually developing a CLAP-2-AU workflow. But because the AU requires an info.plist which is part of the code signature and notarisation process, the plug-in developer needs to put their CLAP in there, edit the plist, codesign, notarise, ship. Or so is the plan.

[Urs]

unfortunately for me, until all the important hosts support CLAP, I would have to wrap as VST2, without license. The reason is because I am mainly interested in developing and distributing midi plugins.

Woah. I feel your pain.

[Jeff McClintock]

Are you interested in hearing suggestions for tweaks to the ABI to make CLAP a little more efficient?

Is the indirection providing value?

Most plugins are written in C++, however it's a big advantage to be able to write plugins in other languages. The most common technique to achieve this aim is to expose the plugin via a plain 'C' ABI (not C++).

So the indirection in CLAP's SDK serves this purpose of 'translating' the C++ plugin into a plain 'C' facade to the DAW. This is called 'thunking' (redirecting) the methods of the C++ plugin.

So basically every call to the plugin, or back into the DAW, requires at least 2 function calls, sometimes 4 (because if the DAW is written in C++, it's probably 'thunking' it's 'side' of the API also).

Does this add value? Yes, it allows developers more freedom to use languages other than C++ to write plugins. Like RUST for example. But what if there is there more than one way to provide the 'thunking'?

The question is: why design an API such that it requires 4 nested function calls, when one would suffice? Perhaps efficiency is not so important to plugin developers, but if you have the golden opportunity of a clean slate, and two similar options for your 'C' ABI, and one is 4 times less overhead per render call, which would you choose?

[EvilDragon]

From what I understood, CLAP enabling plugins to have access to DAW's thread pool is providing some actual CPU savings.

[rafa1981]

...

I thought that thunking was jumping onto a code section on the memory area with custom generated code.

Anyways, probably you meant that the indirection was done through a function pointer table? I looked at the code and this one seemed unusual:

https://github.com/free-audio/clap/blob ... p/plugin.h

Normally these kind of function pointer tables are used for having them point at different functions at runtime. Plugins seem to be link time stuff.

Probably what is going on is that hosts internally still need to have these kind of tables with function pointers to the different the functions on each plugin (dynamically loaded libraries), obtained with e.g. dlopen/dlsym.

With Clap you provide the full table to the host, so it only needs one call to find all the library functions (better load/scan times?).

Just an hypotheses, I don't know the library, but this seems likely the reason.

[Urs]

The most common technique to achieve this aim is to expose the plugin via a plain 'C' ABI (not C++).

This is what CLAP does. It's purely a C ABI. There is no C++ code at all in the foundation of CLAP.

There is glue code for C++ in the helper section for convenience so that people can start with a C++ skeleton. More glue layers have been mentioned, one project provides a glue to Rust while someone else has announced a glue to Pascal IIRC.

Furthermore, the provided examples use the C++ glue for the host and the plug-ins.

[Urs]

Normally these kind of function pointer tables are used for having them point at different functions at runtime. Plugins seem to be link time stuff.

It's an object, but in plain C (i.e. not C++).

[camsr]

Can someone elaborate on clap_process_status type (in process.h)? What might this be used for.

[baconpaul]

Can someone elaborate on clap_process_status type (in process.h)? What might this be used for.

It’s the return type of the plugin profess method. If everything worked and you want to be called again you return the CLAP_PROCESS_CONTINUE and otherwise return the other values. So you can indicate an error or silence or sleep or what not too