About CLAP

[schwa]

Here's my 2c on this whole thing which is worth about 2 cents. API development is hard. There is always tension between factors like simplicity, completeness, extendability, and clarity.

VST2 is a simple interface that is easy to understand, and it's somewhat extendable, but it was originally extremely incomplete. The specification struggled from the beginning to keep up with the zillions of implementations. It was often not clear how to do things, so different developers implemented things differently. It could definitely be saved as an API but it's moot now.

VST3 is a different interface model that is familiar to some programmers (anyone from the Windows COM world) but completely unfamiliar to others. It's a proven model, but if you're not familiar with it, it looks confusing and intimidating. I think that created a barrier to entry for a lot of developers who were comfortable with VST2. VST3 also suffers from overdesign, but imo most of the development friction comes from unfamiliarity with the model.

LV2 is a fine design imo but it's extendible to a fault, and there's development friction from the (well intentioned) separation of metadata and implementation, which means developers need to add a conceptually new step to their existing development process.

CLAP has the advantage of hindsight on the other formats and it's trying to be simple, extendable, and clear. The comparative advantage of CLAP is in the design goals of clarity and extendability. As with LV2, the sacrifice is in completeness, so once the format is stable it will be a challenge to keep new extensions well-defined, because it's so easy for developers to extend. But the design goals are laudable, and Alexandre is doing a good job of collaborating while keeping the project goals well-contained.

What I don't think is worth worrying about is externalities like adoption rate or whether some formats "beat" other formats. A good API will be used if it doesn't create too much development friction, and if enough developers know about it. Urs is definitely doing his best to let people know about it

[Urs]

Lastly for the moment, because it's just in my head and needs out:

What we see industry wide is platforming. Those in control of the standards are trying to make their platform exclusive in order to gain market share, whatsoever. It's certainly sold as "hey this is better", but there's no way that platform specific decisions are made out of pure altruism. There is "this is not only better, it also binds you to us and makes migration to other options more difficult".

The developers who have to adhere to the standards are the ping pong balls for whom it will be more and more complicated to juggle these platforms. In fact, we have great financial losses as we can't keep up with some changes dropped onto us, and we need to find solutions to become independent from at least the technicalities of platforming.

So our strategy is to use CLAP as a go-between the standards. We currently have a build and development process where all platforms (standards, APIs, operating systems) have to be at 100% for us to publish something. We have to modularise that so that our installers can be updated independently if we, say, put AAX for Mac back in. What I mean is, even if we're in the middle of a large refactoring process (worst case: all our plug-ins crash if recompiled) we need to be able to just quickly fix something in an API layer and publish an update.

So we must be able to selectively update parts of the plug-in from different states of our platform support, which requires a stable, simple and comprehensive ABI. This is why we chose CLAP, because it lets us do that once it reaches 1.0 specification.

(and from what I hear, we're by far not the only ones who have to deal with this issue)

[Urs]

Thank you schwa, fully agreed!

[dawhead]

I really don't know much about Linux, I don't even know much about Windows.

However, there are plug-ins which may wish to access the file system, some kind of windowing system, the GPU even, drivers for this or that, network adapters, font services, localisation services, hardware acceleration libraries and frameworks provided by the system and what not. That's what I mean.

As long as you statically link all this stuff into the plugin, and it doesn't leak symbols, you can use whatever you want.

The idea that a plug-in has to be a little piece of executable binary which does all it does through the means of the host and the plug-in API between them, aka be "fully self contained, no dependencies"

The main reason for doing this, historically at least, has been to allow you, as a plugin developer, to write portable plugins without having to decide what portability libraries you would use.

To take your examples above:

• file system access
• GPU
• h/w acceleration (presumably SIMD)
• windowing system
• localization

There are no platform provided versions of these things that are portable across platforms. You can see the same idea happening in webdev these days, where the browser is slowly being outfitted with layers to provide portable, crossplatform access to e.g. USB devices, GPU stuff, audio i/o and lots lots more. the original idea was that plugins should not try to do this stuff without the intermediation of the host. It wasn't about limiting what the plugin could do per se, but more about making sure that the plugin could access a standard, cross-platform set of services, more or less precisely like the web situation these days.

Now of course, the plugin situation is different than the web one: you can in fact choose to (statically) link your plugin to various libraries to provide whatever functionality you want, which is impossible for anyone bound to a webstack. If you don't care about cross-platform issues, you could even choose to use platform-specific libraries ... nobody can or will stop you from doing that.

Again, my observation about "self-contained" didn't refer to capabilities, but something much more technical: static linkage, no leaked symbols, dynamic linkage only with guaranteed low level system libs. This concerns comes from having seen a variety of plugins for Linux built with dynamic linkage against a variety of libraries that either directly conflict with the host, or may not be present on the user's system. Nothing more, or less, than that.

As long as there are clear rules about which threads can be used for what, as a host developer I generally don't care what a plugin does. The biggest problem that we (and other DAW developers) have with a number of plugins is that either they are using a format that has no such clear rules, or they break the rules.

[Urs]

The biggest problem that we (and other DAW developers) have with a number of plugins is that either they are using a format that has no such clear rules, or they break the rules.

Same here (us and other plug-in developers). You’ll be thankful for CLAP then, eventually.

[mystran]

The biggest problem that we (and other DAW developers) have with a number of plugins is that either they are using a format that has no such clear rules, or they break the rules.

Same here (us and other plug-in developers). You’ll be thankful for CLAP then, eventually.

Right. I'd say the only reason VST2 works as well as is does today is because even with all the different hosts and plugins, eventually the community implicitly (mostly) agreed on "house rules" in terms of what is and isn't acceptable behaviour, even though much of it was never properly specced. Today you can generally write a VST2 that mostly "just works" if you follow the common rules, but if you think back some 10 or 15 years, there was a lot more workarounds required to get everything to interoperate properly.

[glokraw]

One of the keys here, when using linux development for commercial products, is that Ubuntu is a conservative distro. The library‘s are approximately two years behind what you will see in arch linux. And since the library‘s are in general backwards compatible, commercial production of binaries based on ubuntu linux works, because bleeding edge distros’ libraries are newer than those used in the conservative distro.

I think old issues between gtk 2 vs gtk3 and both vs qt-xyz still need to be fixed
or transcended. And pulse fully eradicated. Perhaps ubuntu is underfunded, under-staffed, inept, and stubborn, rather than conservative? Conservative and fearful are also different descriptors, fearful glowing brighter as money grows tighter. When I use avlinux, pclinuxos, bodhi, puppy, and last year's garuda-arch, negative synonyms don't come to mind. I see maximized talent thriving with the resources at hand.

I'm counting on 2023 bringing clap and pipewire to modern linuxi, and bringing clap-enabled plugins to recording studios of all sizes and platforms and budgets.
For the music
Cheers

[tulamide]

I understand that this is mostly aimed at professional developers. Nevertheless, I dare to ask, if there is any hope to see a more visual frontend for programming a clap plugin, for hobby developers like me. Something like HISE, SynthEdit or Flowstone do for VST? I know for sure that Flowstone will not be able to support clap in a reasonable amount of time, as it is basically dead, developed just by one person from the user base, who has a fulltime job. HISE, even if it would support clap, is focused on sample based instruments, and SynthEdit also is developed just by one person.
I will accept a clear "no", keep my head low and walk out of this pro discussion, hopefully without being ridiculed. But if there is any, even if tiny, chance that such visual programming frontend would be considered, I'd love to hear it.

[Super Piano Hater 64]

I understand that this is mostly aimed at professional developers. Nevertheless, I dare to ask, if there is any hope to see a more visual frontend for programming a clap plugin, for hobby developers like me. Something like HISE, SynthEdit or Flowstone do for VST? I know for sure that Flowstone will not be able to support clap in a reasonable amount of time, as it is basically dead, developed just by one person from the user base, who has a fulltime job. HISE, even if it would support clap, is focused on sample based instruments, and SynthEdit also is developed just by one person.
I will accept a clear "no", keep my head low and walk out of this pro discussion, hopefully without being ridiculed. But if there is any, even if tiny, chance that such visual programming frontend would be considered, I'd love to hear it.

The facetious response (which I'm sure someone else will give you either way) is that there's already a frontend and it's called Bitwig.

The correct response is that there's no fundamental barrier preventing one of those existing visual programming environments from supporting a new format. It's just up to the maintainers to get the work done, if they can afford it. If there are too many VST-specific assumptions baked into their codebases, then support for other formats might be out of reach for the current maintainers and you might have to look at an alternative.

[Urs]

I do not know of any projects atm which aim at this. It is however extremely early for any project of that magnitude to commit to CLAP at this time.

There are various projects in the works which show examples for CLAP with various GUI toolkits. For some of these toolkits afaik exist visual editors (e.g. Qt), and some such as Dear IMGUI ( https://github.com/ocornut/imgui ) require very minimal work to set up a basic UI.

As you mention HISE, which is open source and based on JUCE if I'm not mistaken, there's a very good chance that a port is possible, and "soonish".

[tulamide]

Thanks a lot for the quick answer!

[Jeff McClintock]

... and SynthEdit also is developed just by one person.

..and anyway, he's a 'dinosaur' I heard. So he won't understand all this new-fangled stuff.

[glokraw]

I've often referred to myself as a dinosaur. Got me a real big T-Shirt.
But some of us dinosaurs saw others sinking in the tarpits, and learned. Saw others moving towards food in the direction of volcanoes, and we went the opposite direction. Untold millions of people "understand" driving cars, and the crashes still happen like clockwork. The market will choose winners, and make sitting on fences very uncomfortable. Better to leap off the turnip truck, then to fall off

[surreal]

... and SynthEdit also is developed just by one person.

..and anyway, he's a 'dinosaur' I heard. So he won't understand all this new-fangled stuff.

Ladies and Gentlemen I present to you the Legendary Jeff!! The Grandfather of all things cool and Freeware!! I still love all my Synthedit based Synths!! They all have that ancient analogue warm vibe which I love!! Everytime I launch an Old fave Synth Edit Synth I can smell the salty smell of capacitors heating up to analogue goodness!!

Jeff I really hope you hop on the Clap Bus too!

[tulamide]

... and SynthEdit also is developed just by one person.

..and anyway, he's a 'dinosaur' I heard. So he won't understand all this new-fangled stuff.

That's what you say
But in all seriousness, it would be pretty awesome to see the 'dinosaur' pull it off. I follow closely all the discussion related to Steinberg's new 'vision' for VST3, especially regarding MIDI, from the musician/producers side of things. And I really think, it is time for an open, free standard, so that nobody can dictate the developers what to do with an api in terms of instruments/effects. But it can only become a standard, if as many DAWs and developers, including those of middleware, hop on the train. For years I was hoping for LV2, as it shares a lot of the thoughts behind CLAP, but it never got the support on the most important platforms. With Urs doing his bit, and a DAW already in with it, this time it is a real chance to establish a better alternative to VST, for both, developers and producers.