CLAP... thoughts?

[Tj Shredder]

As a user, CLAP will simplify my life. Whenever I install a plugin, I usually don’t have information about things like which features of the plugin format are used. As VST2 and VST3 are different in that regard, I don’t know on which of the two the development is based on. As Bitwig can deal with both, I tend to install both to be able to fall back to the other one if something doesn’t work correctly…
With CLAP I can savely ignore VST and just install CLAP… But if the VSTs only eat 50 kB, it doesn’t even hurt to install them as well in case I use a different host than Bitwig…

[Ameyah]

The point for us is that we can use CLAP as our internal format. There are several wrappers in the works that take a CLAP plug-in and make a VST3 from it.

This will improve our internal development process as we won't need to care about other formats "all alone" anymore. The community will care for it in a collaborative approach and we can focus on our own development.

And as I always said, it doesn't matter if Cubase gets CLAP support or not. Here's some work in progress - it needs fine tuning, but it nicely shows a CLAP-only plug-in running in a VST-only host:


CLAPasVST3.png

Wow, if one could should ship their plugin as CLAP and add a wrapper for VST3, this would be game changing for CLAP.

Hopefully JUCE picks up CLAP, but wasnt there a way to integrate CLAP building in JUCE with a few steps?

and 50kb for the wrapper!!!

Very excited for CLAP as VST3 is a nightmare

[Urs]

Well, 50kB is a guess from my side. A simple stub library could be as little as a few hundred bytes, while anything ultra universal might be a full fledged host. As long a sit doesn't need its own UI or link to complex libraries and runtimes, it should be considerably small.

[Scoox]

Maybe a stupid question but I'll give it a shot: What do CLAP plugins look like on a file system? I ask because I have a preference for "portable" plugins, in other words, plugins where all the files required for the plugin to function live in a single, self-contained, folder. I hate plugins that spread themselves all over my C: drive and the registry like it's their property.

I have many VST2 plugins that work the portable way and, to be frank, they are a joy to work with. Recently I upgraded to Windows 11 and all I had to do was point my DAW to my chosen VST2 folder. Nothing to install, and all my plugins were ready to go.

[teilo]

Maybe a stupid question but I'll give it a shot: What do CLAP plugins look like on a file system? I ask because I have a preference for "portable" plugins, in other words, plugins where all the files required for the plugin to function live in a single, self-contained, folder. I hate plugins that spread themselves all over my C: drive and the registry like it's their property.

I have many VST2 plugins that work the portable way and, to be frank, they are a joy to work with. Recently I upgraded to Windows 11 and all I had to do was point my DAW to my chosen VST2 folder. Nothing to install, and all my plugins were ready to go.

They are libraries, and CLAP defines an ABI interface to those libraries. That's it. It does not define a file location standard, though there are best practices.

So nothing prevents a library from referencing whatever resources it wants, wherever it wants to find them. This is a good thing. Almost all plugins store at least user presets in some other location, for example. I would never want those sitting in a VST/Components/CLAP directory. Same goes for samples, 3rd party banks, etc.

[Urs]

CLAPs can live anywhere, but hosts are required to scan some standard locations, including some that can be user defined.

[Scoox]

Maybe a stupid question but I'll give it a shot: What do CLAP plugins look like on a file system? I ask because I have a preference for "portable" plugins, in other words, plugins where all the files required for the plugin to function live in a single, self-contained, folder. I hate plugins that spread themselves all over my C: drive and the registry like it's their property.

I have many VST2 plugins that work the portable way and, to be frank, they are a joy to work with. Recently I upgraded to Windows 11 and all I had to do was point my DAW to my chosen VST2 folder. Nothing to install, and all my plugins were ready to go.

They are libraries, and CLAP defines an ABI interface to those libraries. That's it. It does not define a file location standard, though there are best practices.

So nothing prevents a library from referencing whatever resources it wants, wherever it wants to find them. This is a good thing. Almost all plugins store at least user presets in some other location, for example. I would never want those sitting in a VST/Components/CLAP directory. Same goes for samples, 3rd party banks, etc.

Sure, I don't think plugins should be installed to any particular location. It should be up to users where stuff goes on their machines. However, it would be nice to be able to put all files and resources required by a plugin in a single folder that could be copy-pasted to any machine and have the plugin up and running without having to install it again. The plugin would need to be registered to the new target machine, but that'd be it.

I have my sample libraries on an SSD (i.e. mostly read operations). I don't see any reason not to want to put plugins and plugin resources on that drive, as those are mostly read, not written. Could even be a portable drive that I can plug into any of my machines, if the license was somehow bound to the drive, with the possibility to transfer it to a different drive through my user account on the plugin maker's website.

But anyway, I was just curious if perhaps CLAP plugins were a single monolithic file that contained all necessary resources or something like that.

[rafa1981]

Ummm, funny stuff.
https://github.com/juce-framework/JUCE/issues/1027

A free (as in freedom) format is needed.

[baconpaul]

Maybe a stupid question but I'll give it a shot: What do CLAP plugins look like on a file system? I ask because I have a preference for "portable" plugins, in other words, plugins where all the files required for the plugin to function live in a single, self-contained, folder. I hate plugins that spread themselves all over my C: drive and the registry like it's their property.

I have many VST2 plugins that work the portable way and, to be frank, they are a joy to work with. Recently I upgraded to Windows 11 and all I had to do was point my DAW to my chosen VST2 folder. Nothing to install, and all my plugins were ready to go.

They are libraries, and CLAP defines an ABI interface to those libraries. That's it. It does not define a file location standard, though there are best practices.

So nothing prevents a library from referencing whatever resources it wants, wherever it wants to find them. This is a good thing. Almost all plugins store at least user presets in some other location, for example. I would never want those sitting in a VST/Components/CLAP directory. Same goes for samples, 3rd party banks, etc.

Sure, I don't think plugins should be installed to any particular location. It should be up to users where stuff goes on their machines. However, it would be nice to be able to put all files and resources required by a plugin in a single folder that could be copy-pasted to any machine and have the plugin up and running without having to install it again. The plugin would need to be registered to the new target machine, but that'd be it.

I have my sample libraries on an SSD (i.e. mostly read operations). I don't see any reason not to want to put plugins and plugin resources on that drive, as those are mostly read, not written. Could even be a portable drive that I can plug into any of my machines, if the license was somehow bound to the drive, with the possibility to transfer it to a different drive through my user account on the plugin maker's website.

But anyway, I was just curious if perhaps CLAP plugins were a single monolithic file that contained all necessary resources or something like that.

A clap is a dll. It lives in locations specified in the spec, including default locations hosts much search and ways for users to add locations. The spec says you must recurse from those location looking for clap files (win lin) or bundles (mac). There’s nothing stopping you creating junctions or sub directories with resources side by side with your clap. That’s how surge implements portability.

[audiojunkie]

Ummm, funny stuff.
https://github.com/juce-framework/JUCE/issues/1027

A free (as in freedom) format is needed.

Beautiful!

[Tj Shredder]

Ummm, funny stuff.
https://github.com/juce-framework/JUCE/issues/1027

A free (as in freedom) format is needed.

I guess thats a problem for bean counters…
Its about the trademark VST, not about the license itself. You can publish the code without mentioning VST under GPL3. But if you use the trademark, you need to add the logo…
There is no problem with GPL3, but with commercial licenses…

[mystran]

Ummm, funny stuff.
https://github.com/juce-framework/JUCE/issues/1027

A free (as in freedom) format is needed.

I guess thats a problem for bean counters…
Its about the trademark VST, not about the license itself. You can publish the code without mentioning VST under GPL3. But if you use the trademark, you need to add the logo…
There is no problem with GPL3, but with commercial licenses…

I didn't check the normative licensing terms, but assuming the github thread is correct (emphasis mine)...

Whenever VST® is used or the SDK has been used to create a product or the SDK is included (Open-source GPLv3 case), it is required to add the reference to Steinberg by using the VST compatible logo as supplied by Steinberg. Included in the VST SDK, the VST compatible logo can be found in the folder VST_SDK/VST3_SDK/vst3_doc/artwork.

This is the very definition of "additional restrictions" that GPL forbids, which means that Steinberg's "GPL" VST license is not GPL compatible. Steinberg can do this certainly and you can develop plugins under "Steinberg GPL" but legally you can't combine this with any other GPL code without a special exception to allow Steinberg's additional restriction.

I'm not a huge fan of GPL in general, but that doesn't change the fact that Steinberg's "GPL" license (assuming the quote is actually correct) is incompatible with GNU GPL.

[Arashi]

Ummm, funny stuff.
https://github.com/juce-framework/JUCE/issues/1027

A free (as in freedom) format is needed.

There's always MIT.

[DRMR]

There's always MIT.

How is that relevant? You can't publish a project under MIT license if it uses the Steinberg-GPL license.

FalkTX is btw also working on a Steinberg-less VST3 implementation that is ISC licensed
https://github.com/DISTRHO/DPF/tree/dev ... c/travesty
With that your plugin code could be MIT.

[baconpaul]

There's always MIT.

MIT is the license we chose for CLAP, yes.