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

[baconpaul]

Any news on any wrappers?

Nothing new, other than people still making slow progress.

For an odd reason, I want to do auv2-as-clap; and there's a bunch of chatter about clap-as-vst3. But still no code on public github's which works.

[mystran]

Any news on any wrappers?

Nothing new, other than people still making slow progress.

For an odd reason, I want to do auv2-as-clap; and there's a bunch of chatter about clap-as-vst3. But still no code on public github's which works.

For some odd reason I would just like to load a CLAP plugin in a host that doesn't support CLAP using whatever random API... but apparently for some odd reason people prefer writing such wrappers in secret chambers and progress is slow because it's hard to see in candle light?

Ok... fine. I'll probably see about writing some super-simple single-file wrappers myself tomorrow then (or maybe even later tonight, although not exactly feeling too well right now).

[baconpaul]

Any news on any wrappers?

Nothing new, other than people still making slow progress.

For an odd reason, I want to do auv2-as-clap; and there's a bunch of chatter about clap-as-vst3. But still no code on public github's which works.

For some odd reason I would just like to load a CLAP plugin in a host that doesn't support CLAP using whatever random API... but apparently for some odd reason people prefer writing such wrappers in secret chambers and progress is slow because it's hard to see in candle light?

Ok... fine. I'll probably see about writing some super-simple single-file wrappers myself tomorrow then (or maybe even later tonight, although not exactly feeling too well right now).

Ha! It’s more that the team is small, the work is long, we are still in the first month, etc…

And writing an a-as-b requires you to understand both how to host an a and write a b as well as all the translation.

If you make some simplifying assumptions it isn’t that hard. And depending on your target the problem shrink. (Clap as vst2 is really pretty easy except you need a vst2 license, for instance)

But happy to have more people taking a swing at it of course!

[mystran]

Ha! It’s more that the team is small, the work is long, we are still in the first month, etc…

No need to get defensive, I wasn't entirely serious...

If you make some simplifying assumptions it isn’t that hard. And depending on your target the problem shrink. (Clap as vst2 is really pretty easy except you need a vst2 license, for instance)

That's the thing. The "minimum usable" feature set for a basic plugin is essentially stereo in/out (one of each if you're really lazy), MIDI in (for instruments), basic parameter support, save/load chunks, open/close GUI and perhaps timeinfo... and might just as well report latency, since it's typically not exactly that hard. That's roughly what I was thinking of throwing together and it's absolutely single-file territory for both VST2 and AUv2 (the latter is really only a little bit more boilerplate).

But I get it.. if you want to make a "fully featured" wrapper that actually bridges as many features as possible (rather than the "minimum usable" configuration), then complexity can add up quickly... and I don't suggest anyone ship the type of wrapper that I was planning on writing to any actual customers..

edit: Also when you're wrapping just enough to support what your own plugins need, you get to be sloppy and skip half the calls .. 'cos you know what your plugins just ignore completely.

[baconpaul]

Ha! It’s more that the team is small, the work is long, we are still in the first month, etc…

No need to get defensive, I wasn't entirely serious...

If you make some simplifying assumptions it isn’t that hard. And depending on your target the problem shrink. (Clap as vst2 is really pretty easy except you need a vst2 license, for instance)

That's the thing. The "minimum usable" feature set for a basic plugin is essentially stereo in/out (one of each if you're really lazy), MIDI in (for instruments), basic parameter support, save/load chunks, open/close GUI and perhaps timeinfo... and might just as well report latency, since it's typically not exactly that hard. That's roughly what I was thinking of throwing together and it's absolutely single-file territory for both VST2 and AUv2 (the latter is really only a little bit more boilerplate).

But I get it.. if you want to make a "fully featured" wrapper that actually bridges as many features as possible (rather than the "minimum usable" configuration), then complexity can add up quickly... and I don't suggest anyone ship the type of wrapper that I was planning on writing to any actual customers..

Yeah didn't mean to sound defensive!

And indeed, if you make a minimum viable wrapper it's not that hard especially with the easier formats like Vst2 and AuV2. Single file indeed.

In a way we *do* have a wrapper. The clap-juce-extensions are juce-audio-processor-as-clap. Going the other way (clap-as-foo) requires you to write a micro host but we have a couple of those both in clap-info and the predecessor, my micro-host. hit me up if you need either bit of code

[S0lo]

So I finally found some time to seriously dig into CLAP today. That surge clap example built and ran fine. But then I was trying the clap-plugins rep. Followed the simple instructions, took around half an hour to build on an old Win7 test laptop. But then, what, I couldn't find any *.clap files or VS *.sln or *.vcxproj files that I can open. Well, there were some in the Build folder but.... nothing there. Am I missing something? What am I supposed to do?

Please excuse my utter ignorance regarding the whole git, bash, cmake tools and all that.

Edit: I mean I could try and construct the whole examples file by file manually until dependencies are fulfilled, but there must be a faster way?

[mystran]

In a way we *do* have a wrapper. The clap-juce-extensions are juce-audio-processor-as-clap. Going the other way (clap-as-foo) requires you to write a micro host but we have a couple of those both in clap-info and the predecessor, my micro-host. hit me up if you need either bit of code

I'm about 50% done writing a total hack of a minimal VST2 wrapper that plays fast and loose with CLAP API (ie. skips all the calls, required or not, where I'd ignore them on the plugin side anyway).

ps. I had VST2 and AUv2 wrappers for a custom internal plugin API already .. but I want to try and work with CLAP directly, so I'm writing some totally awful glue adapting the existing wrappers in the most irresponsible way to hopefully get things to load in a non-CLAP host.

[baconpaul]

In a way we *do* have a wrapper. The clap-juce-extensions are juce-audio-processor-as-clap. Going the other way (clap-as-foo) requires you to write a micro host but we have a couple of those both in clap-info and the predecessor, my micro-host. hit me up if you need either bit of code

I'm about 50% done writing a total hack of a minimal VST2 wrapper that plays fast and loose with CLAP API (ie. skips all the calls, required or not, where I'd ignore them on the plugin side anyway).

ps. I had VST2 and AUv2 wrappers for a custom internal plugin API already .. but I want to try and work with CLAP directly, so I'm writing some totally awful glue adapting the existing wrappers in the most irresponsible way to hopefully get things to load in a non-CLAP host.

Hey I did the same - Check out github.com/baconpaul/micro-clap-host which eventually became clap info. May help if you get stuck

My advice is be careful with the threading and check for nulls and you will probably be fine even if sloppy for a first pass.

[mystran]

In a way we *do* have a wrapper. The clap-juce-extensions are juce-audio-processor-as-clap. Going the other way (clap-as-foo) requires you to write a micro host but we have a couple of those both in clap-info and the predecessor, my micro-host. hit me up if you need either bit of code

I'm about 50% done writing a total hack of a minimal VST2 wrapper that plays fast and loose with CLAP API (ie. skips all the calls, required or not, where I'd ignore them on the plugin side anyway).

ps. I had VST2 and AUv2 wrappers for a custom internal plugin API already .. but I want to try and work with CLAP directly, so I'm writing some totally awful glue adapting the existing wrappers in the most irresponsible way to hopefully get things to load in a non-CLAP host.

Hey I did the same - Check out github.com/baconpaul/micro-clap-host which eventually became clap info. May help if you get stuck

My advice is be careful with the threading and check for nulls and you will probably be fine even if sloppy for a first pass.

Oh.. I'm past that point... so let me try to explain...

I have an internal plugin abstraction that basically takes care of all the mundane API details so that a plugin can basically just specify a bunch of parameters and properties (eg. inputs, outputs; these have sensible defaults so you can get really lazy too), then implement reset(), reconfigure() and process() and that's about it. Then I have wrappers for VST and AUv2 (and partially CLAP) that take care of all the boring mundane details of dealing with low-level APIs.

A minimal plugin looks something like this:

Code: Select all

struct Analyser : dust::Panel
{
    dust::NBandGraph<2>  nBand;
    dust::AudioUIStream  stream;

    Analyser()
    {
        nBand.setParent(this);
        style.rule = dust::LayoutStyle::FILL;
        style.minSizeX = 320;
        style.minSizeY = 80;
    }

    void ev_update()
    {
        unsigned total = 0;
        double  buf[256];
        while(unsigned n = stream.recv(buf, 256))
        {
            total += n;
            nBand.update(buf, n);
        }
    }
};

struct TestPlugin : dust::AudioPlugin
{
    Analyser        analyser;

    TestPlugin()
    {
        properties.name = "TestPlug";
        
        // ui
        analyser.setParent(editor);
    }

    void reconfigure()
    {
        analyser.nBand.setSamplerate(config.samplerate);
    }

    void reset()
    {
    }

    void process(dust::AudioBus *ins, dust::AudioBus *outs, unsigned nFrames)
    {
        for(unsigned i = 0; i < nFrames; ++i)
        {
            double in0 = ins[0].channels[0][i];
            double in1 = ins[0].channels[1][i];

            outs[0].channels[0][i] = in0;
            outs[0].channels[1][i] = in1;
            
            analyser.stream.queue(in0 + outs[0].channels[0][i]);
            analyser.stream.queue(in1 + outs[0].channels[1][i]);

        }

        analyser.stream.flush();
    }

};

// this should return an object of a derived class
dust::AudioPlugin * dust::createPlugin()
{
    return new TestPlugin;
}

It looks like this (sorry about the retina scale.. too lazy to fix; renaming the bundle to .component or .clap would make it a valid AUv2 or CLAP plugin too):

Screenshot 2022-07-10 at 12.20.51.png

Yet.. when I was writing the CLAP wrapper, I realized that in some ways the way I work internally is already closer to CLAP than it is to other existing APIs, but in other ways it would make sense to redesign my own abstractions to better align with those in CLAP ... yet because I've never written an actual CLAP plugin, I don't really know what the correct abstractions would be.

So... I want to write an actual "serious" CLAP plugin using just https://github.com/signaldust/clap-glue to see what sort of abstractions I should build... exploratory stuff ... but in order to do "serious" DSP development, I obviously need to be able to do some DSP processing in some development friend host (eg. Reaper, FL, etc). For this purpose the quality of the wrapper is mostly completely irrelevant (ie. as long as it's calling enough functions in the plugin that things more or less work), because it's not really about trying to figure out how to talk CLAP, but rather about trying to figure out how the plugin-side stuff should be organized, what the dataflows should look like and how to wrap them into a baseclass that still allows me to write a basic plugin about as easily as the one above.

Does that make sense?

[baconpaul]

That not only makes sense, but in fact "CLAP as the internal API people use" was one of the design goals. An 'abstraction' which can also be used directly, basically, is how we have been thinking about CLAP.

[mystran]

That not only makes sense, but in fact "CLAP as the internal API people use" was one of the design goals. An 'abstraction' which can also be used directly, basically, is how we have been thinking about CLAP.

Well... yeah ... but the boilerplate is insane if you don't build some helper classes around it. That's obviously not a problem with an API 'cos a public API has to be general and explicit while a private API can rely on 'magic' that can be easily adjusted later if it turns out it's not general enough..

That said.. I have successfully managed to write some truly horrible glue code that violates both CLAP and VST2 specs everywhere... yet somehow loads my test CLAP plugin as VST2 in Reaper and allows it to process audio... and shows the GUI .. next up parameters and perhaps MIDI so that we can proceed towards the evil master plan of releasing totally awesome must-have plugins as CLAP exclusive.

[rafa1981]

... next up parameters and perhaps MIDI so that we can proceed towards the evil master plan of releasing totally awesome must-have plugins as CLAP exclusive.

Looking forward to see/hear your work

[S0lo]

... next up parameters and perhaps MIDI so that we can proceed towards the evil master plan of releasing totally awesome must-have plugins as CLAP exclusive.

Looking forward to see/hear your work

My crystal ball tells me it's going to be...... a spectrum analyzer, named after something that resembles sand

[mystran]

... next up parameters and perhaps MIDI so that we can proceed towards the evil master plan of releasing totally awesome must-have plugins as CLAP exclusive.

Looking forward to see/hear your work

My crystal ball tells me it's going to be...... a spectrum analyzer, named after something that resembles sand

I have absolutely no idea what said plugins would be... but sand?

I suppose a spectrum analyzer might be a cool test plugin though..

[Markus Krause]

I am currently working on a adapter the can wrap any existing vst2.4 plugin into CLAP - without the need of touching or recompiling the vst 2.4 dll. So this should work also for very old plugins as long as they are 64 bit. If there is interest I can share some sources as soon as it is working properly.