Tracking CLAP hosts and plugins

[moss]

Another one for the list from the new Bitwig newletter:

"AudioThing Wires is a popular tape machine-emulation software developed in collaboration with German composer and Youtuber Hainbach. It now supports CLAP, a new open source plugin standard which we just announced — and today we're throwing a housewarming party to celebrate! For a very limited time, you can purchase Wires at a discount from the Bitwig webshop."

[Funkybot's Evil Twin]

Another one for the list from the new Bitwig newletter:

"AudioThing Wires is a popular tape machine-emulation software developed in collaboration with German composer and Youtuber Hainbach. It now supports CLAP, a new open source plugin standard which we just announced — and today we're throwing a housewarming party to celebrate! For a very limited time, you can purchase Wires at a discount from the Bitwig webshop."

Got mentioned already a few posts back and is already on the CLAP tracking site.

https://clapdb.tech/

[Pinku Eiga]

We have just released Wires v1.2 with CLAP support: https://www.audiothing.net/effects/wires/

Congratulations for the release. And I'm glad to see that Bitwig has sent a newsletter to all their users, informing of the release.

This will be an advantage of CLAP for the early adopters: free promotion.

And also congratulations to @teilo for another fantastic database. Your contributions to the music community are greatly appreciated

[Compyfox]

Subscribing to this thread as well.


Steinberg will... ignore this for years to come. Pretty sure about that. If anything, Apple/Emagic will implement CLAP prior to Steinberg (still waiting for the mess that will be the drop of VST2 support in all their DAWs ).

But if "Palcer" (Clap>VST/Clap>AU wrappers) are on the menu anyway (maybe also offering something like jBridge once did for x86 to x64 -- only this time for CLAP-to-XYZ, or even VST-to-CLAP-to-AUv2/VST3)... maybe this means that certain old VST plugins remain alive / can be revived at way less headaches. At least this is what I understood to be possible at Superbooth 2022. However, we're but at the start of this journey. Yet I'm pretty sure certain keyboards are already running hot.


I mean... look at AudioThing... they didn't plan to "join", but were ambitious. Just to see how easy it will be. Within 6 days (announcement of #CLeverAudioPlugin / CLever Audio Plug-in API, and actual plugin update), they released a CLAP version of Wires, and with an unofficial add-on for the Juce Framework no less.

The future is looking bright.

[mabian]

I think a VST2 -> CLAP bridge/adapter could in fact be a genius idea to allow keeping all "old" VST2 plugins alive in modern DAWs that will hopefully integrate CLAP timely (except Cubase and Logic of course, that as mentioned will be the last ones if ever - not considering at all Avid here)

- Mario

[mabian]

Ah, and not sure if that was already mentioned, Audiority is already working on CLAP support and Tone2 owner, Markus, is almost enthusiastic as well about it (he several times blamed the VST3 format to be simply not mature enough still).

- Mario

[elnn]

Steinberg will... ignore this for years to come. Pretty sure about that. If anything, Apple/Emagic will implement CLAP prior to Steinberg (still waiting for the mess that will be the drop of VST2 support in all their DAWs ).

Sometimes it's best to just start fresh.

[Pinku Eiga]

Technically nothing barring CLAP from running on other operating systems right? FreeBSD, Haiku, etc.

CLAP is a simple pure C API.

Wasn't it an ABI?

iOS is different for all the reasons that make iOS what it is, none of them to do with a chip (I developed most of my clap work on an M1) or a compiler.

Can you elaborate a bit? Is it only due to the restricted app store (agreements)?

It is an api and abi both but yes abi is a higher bar

Yes it is because the plugin architecture to get on the device is auv3. As tj shredder notes below we can imagine an auv3 wrapper kit which contains a clap and wraps it in a case by case basis but the entire App Store infrastructure requires that outer layer. We haven’t written that out layer yet but that’s the path to get clap into auv3 on iOS and au in logic.

This means a “clap on iOS” will be an auv3 perhaps with a clap inside, given current iOS constraints.

The opposite implementations of this will be more interesting.

A CLAP plugin that can host AUv3s inside MacOS, exposing the parameters to the DAW.

Indeed, you can already use a VST3 wrapper to load AUv3 units inside hosts not supporting AUv3 like Bitwig. Moog is offering these wrappers in its web, so you can load Animmog Z or Model 15 in any DAW without AUv3 support.

There are a lot of iOS AUv3 plugins that can be installed on iOS, they are offered as Universal Builds in the App Store. The most recent ones tend to have this option implemented.

So a MacOS user using an iPad for music production will already have a vast collection of AUv3 plugins.

[baconpaul]

The opposite implementations of this will be more interesting.

A CLAP plugin that can host AUv3s inside MacOS, exposing the parameters to the DAW.

Yeah I wrote one of these that hosted an AUv2 inside bitwig last night. Didn't get it finished before my vaca, but we've been talking about wrappers as XYZ-to-CLAP and CLAP-to-XYZ both.

[Pinku Eiga]

The opposite implementations of this will be more interesting.

A CLAP plugin that can host AUv3s inside MacOS, exposing the parameters to the DAW.

Yeah I wrote one of these that hosted an AUv2 inside bitwig last night. Didn't get it finished before my vaca, but we've been talking about wrappers as XYZ-to-CLAP and CLAP-to-XYZ both.

If you're able to finish this, even having only AUv2 support, it will be greatly appreciated for MacOS Bitwig users.

There are a lot of interesting tools that are distributed only as Audio Units on MacOS, like the Faded Instruments plugins or the GR-8 synth by Phuretone.

I have tried every Audio Unit host to load them on Bitwig, and none of them is reliable or a perfect solution. Kushview Element only lets you to expose 8 parameters to the DAW for automation, but at least is rock solid, and the only one that I have tried without nasty bugs in the sound. Carla requires to load an external app that isn't M1 native, and a lot of times fails to remember the parameters between sessions. DDMF Metaplugin and Superplugin aren't reliable to host Aundio Units loaded under Rosetta, crashing with most of them. Bluecat's Patchwork is giving me problems with Puremagnetik effects on the latest Monterey.

Plus all of them are overkill. I only want the simplicity of a host loading a single Audio Unit or AUv3 unit for instance. Automatically exposing all the parameters to Bitwig for automation. Or at least with an option to make them visible manually, selecting each parameter. Without the absurd 8 parameters limit of Kushview Element.

[baconpaul]

The opposite implementations of this will be more interesting.

A CLAP plugin that can host AUv3s inside MacOS, exposing the parameters to the DAW.

Yeah I wrote one of these that hosted an AUv2 inside bitwig last night. Didn't get it finished before my vaca, but we've been talking about wrappers as XYZ-to-CLAP and CLAP-to-XYZ both.

If you're able to finish this, even having only AUv2 support, it will be greatly appreciated for MacOS Bitwig users.

There are a lot of interesting tools that are distributed only as Audio Units on MacOS, like the Faded Instruments plugins or the GR-8 synth by Phuretone.

I have tried every Audio Unit host to load them on Bitwig, and none of them is reliable or a perfect solution. Kushview Element only lets you to expose 8 parameters to the DAW for automation, but at least is rock solid, and the only one that I have tried without nasty bugs in the sound. Carla requires to load an external app that isn't M1 native, and a lot of times fails to remember the parameters between sessions. DDMF Metaplugin and Superplugin aren't reliable to host Aundio Units loaded under Rosetta, crashing with most of them. Bluecat's Patchwork is giving me problems with Puremagnetik effects on the latest Monterey.

Plus all of them are overkill. I only want the simplicity of a host loading a single Audio Unit or AUv3 unit for instance. Automatically exposing all the parameters to Bitwig for automation. Or at least with an option to make them visible manually, selecting each parameter. Without the absurd 8 parameters limit of Kushview Element.

the rosetta question is an interesting one. I will need to make a non-universal wrapper to wrap the non-universal AU. There's also a signing question that I'm grappling with. but i did get all the params from an AUv2 exposed in bitwig as a device last night through indirection. No audio or midi yet, no ui yet, and there may still be real blockers, but its just one point in the wrapper strategy where we have increasing confidence in team CLAP

[Pinku Eiga]

The opposite implementations of this will be more interesting.

A CLAP plugin that can host AUv3s inside MacOS, exposing the parameters to the DAW.

Yeah I wrote one of these that hosted an AUv2 inside bitwig last night. Didn't get it finished before my vaca, but we've been talking about wrappers as XYZ-to-CLAP and CLAP-to-XYZ both.

If you're able to finish this, even having only AUv2 support, it will be greatly appreciated for MacOS Bitwig users.

There are a lot of interesting tools that are distributed only as Audio Units on MacOS, like the Faded Instruments plugins or the GR-8 synth by Phuretone.

I have tried every Audio Unit host to load them on Bitwig, and none of them is reliable or a perfect solution. Kushview Element only lets you to expose 8 parameters to the DAW for automation, but at least is rock solid, and the only one that I have tried without nasty bugs in the sound. Carla requires to load an external app that isn't M1 native, and a lot of times fails to remember the parameters between sessions. DDMF Metaplugin and Superplugin aren't reliable to host Aundio Units loaded under Rosetta, crashing with most of them. Bluecat's Patchwork is giving me problems with Puremagnetik effects on the latest Monterey.

Plus all of them are overkill. I only want the simplicity of a host loading a single Audio Unit or AUv3 unit for instance. Automatically exposing all the parameters to Bitwig for automation. Or at least with an option to make them visible manually, selecting each parameter. Without the absurd 8 parameters limit of Kushview Element.

the rosetta question is an interesting one. I will need to make a non-universal wrapper to wrap the non-universal AU. There's also a signing question that I'm grappling with. but i did get all the params from an AUv2 exposed in bitwig as a device last night through indirection. No audio or midi yet, no ui yet, and there may still be real blockers, but its just one point in the wrapper strategy where we have increasing confidence in team CLAP

Do you plan to release this as a free product, or as a paid product? If you manage to include AUv3 support and it's a paid product, this is a day one purchase for me

Regarding the AUv3 hosting, Rosetta is not as important, because most of the iOS apps that can be downloaded on Mac are M1 native. There are some exceptions, thought, specially for those marked in the App Store as Mac TESTED and compatible, that can also run on Intel Macs. Some of them aren't native.

But by simply supporting ARM native AUv3s, this will cover most of the use cases. Becoming an essential tool for Bitwig users coming from iOS.

[baconpaul]

Do you plan to release this as a free product, or as a paid product? If you manage to include AUv3 support and it's a paid product, this is a day one purchase for me

All the audio work I do is free and open source software. There are no license constraints with AU which would preclude that in this case. If I manage to make this work, it will be too. But I'm not sure I can make it work as an end-user vs a dev-time tool yet. Or even that I can make it work.

[teilo]

Rumor has it we will see a major CLAP release from TAL very soon.

[Compyfox]

... DAWs that will hopefully integrate CLAP timely (except Cubase and Logic of course, that as mentioned will be the last ones if ever - not considering at all Avid here)

Here is the thing...

AVID (AAX), Presonus, Cockos, Bitwig, Image Line... all big players in the league, and they reached out to U-HE/Bitwig themselves, they weren't pressured. Then we still have Ableton, who thought of adapting something new. In fact, IIRC the whole thing started on the Ableton forums. That alone already puts heat on to the Steinberg and their SDK -- because the competition is "trying something new".

Now imagine Apple/Emagic being like "oh yeah, makes sense", although this would go against their sand boxing and what have you. Then this is the final nail in the coffin for Steinberg's VST SDK.

And let's be honest for a minute, Apple were quite innovative lately. In fact, no paid upgrades, implementation of "Dolby Atmos" mixing for free, then the whole iOS and M1 topic. That just as a sidenote. While we're at it, let's throw Black Magic into the pool with "Davinci Resolve" as well, which has quite the extensive feature set with their "Fairlight engine" (who knows what will happen - this thing is constantly evolving - and since Epic Games also wants a piece of the action, and Davinci Resolve is currently the top-dog in the video editing realm with VST support, I wouldn't be surprised if they say "wait a minute...")


I mean, imagine the following (and here I'm only speculating)...

At first, AVID and Apple/Emagic might only "support" the general idea, try something new, implement CLAP as additional option. But what if it really fixes all the shortcomings that a lot of people had throughout the last decade (incl. stuff like MPE woes, multi-core handling, the nonsense with "only VST3 can do native side-chaining", not to mention all the licensing drama incl. insane yearly fees and super crazy NDA's, etc)?

What if this is finally "the" unified API/SDK that unites the whole audio realm, and things can move further -- just like people tried to do early 2000s (I mean, look at how long it took for people to finally agree on a MIDI 2.0 roadmap!). What if this would mean less bloat and/or code fixes for xyz amount of hosts, therefore hosts can also drop redundant code and things can be snappy again? Wouldn't that be amazing?


In this case, the company that always insists on being innovators and being at the nick of time (which they really aren't, if we really look under the hood in places), they don't see the forest from the trees. If they are the last to adapt - if ever - then this whole endeavor did it's purpose - a more than overdue wake-up call.




Again... we're merely at the beginning of this journey, but we already talk "adapters in active development" in here. Honestly, this whole thing is way more exciting than MIDI 2.0