About CLAP

[glokraw]

but because of being afraid of having to support .....lots of distros, versions of stuff, etc.

If you're smart like u-he devs, your products work in any linux. I've used them in 6 distinct distros, and probably 15 or 20 spinoffs of those. Drag and drop two folders, .u-he, and .vst Then drag and drop a linux reaper folder, and a .config/REAPER folder, and you have a world-class setup, and the same one across multiple systems, which vary for reasons other than plugin support. CLAP coming to fruition just means more and better products will end up in my .u-he folder And I'll update mixbu$ when it's fully supportive and on sale.

Your profanity attached to the Solar-50 comment distracts from your credibility. Profanity is best saved for live performances. Typing it is weak.

[dawhead]

If you're smart like u-he devs, your products work in any linux.

it takes a fairly uninformed plugin developer to create audio or MIDI plugins that are not portable across Linux distros. Plugins are supposed to be almost entirely self-contained binary blobs, and their dependence on system shared libraries should be zero or as close to it as possible.

This applies regardless of the plugin format in use, and to a large extent across OS platforms too.

[Urs]

Hehe, you just prove the point I made before. I, as a plug-in developer, have no such limitation as to what “a plug-in is supposed to be”.

We have also been doing plug-ins for Adobe AfterFX for instance, and those get to be first class citizen in the application, very much unlike the situation in audio.

[glokraw]

If you're smart like u-he devs, your products work in any linux.

it takes a fairly uninformed plugin developer to create audio or MIDI plugins that are not portable across Linux distros. Plugins are supposed to be almost entirely self-contained binary blobs, and their dependence on system shared libraries should be zero or as close to it as possible.

This applies regardless of the plugin format in use, and to a large extent across OS platforms too.

A lot of the new commercial linux plugins come as debian packages, ubuntu-itis, if you will. Which keeps packagers for suse, fedora, arch, and pclinuxos, busier than happier. Giving your speech to such commercial plugin developers could have a positive impact on them, if you rinse the snark off first. It's hard enough being in the minority using linux, having to stay clear of the superiority complexes near the top doesn't make it easier.

[audiojunkie]

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.

[dawhead]

Hehe, you just prove the point I made before. I, as a plug-in developer, have no such limitation as to what “a plug-in is supposed to be”.

We have also been doing plug-ins for Adobe AfterFX for instance, and those get to be first class citizen in the application, very much unlike the situation in audio.

If you try to load a DLL into a running application, and that DLL contains symbols that either (a) clash with those of the host (b) cannot be found on the system, then the load will fail. Ergo, the plugin had better make it is as self-contained: it cannot leak symbols and cannot require symbols not provided by the host/plugin API.

That's all I mean. What the plugin API allows the plugin to do *within* the host is an entirely different matter, and I wasn't making any comment about that.

[mystran]

Hehe, you just prove the point I made before. I, as a plug-in developer, have no such limitation as to what “a plug-in is supposed to be”.

We have also been doing plug-ins for Adobe AfterFX for instance, and those get to be first class citizen in the application, very much unlike the situation in audio.

If you try to load a DLL into a running application, and that DLL contains symbols that either (a) clash with those of the host (b) cannot be found on the system, then the load will fail. Ergo, the plugin had better make it is as self-contained: it cannot leak symbols and cannot require symbols not provided by the host/plugin API.

I guess this situation theoretically exists (to a certain extent) on macOS and even Windows as well, but it's less of a problem when the vendor dictates a certain set of symbols, so whatever you import from "standard platform libraries" is at least safe... where as on Linux if you're really conservative then the most you can expect is the raw system call API.

[Urs]

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.

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", was what VST1 and AU1 represented. With version 2, these APIs became a tad better in terms of freedom for plug-in developers, but either version 3 seems to be "let's close that can of worms that we opened", which I strongly oppose for being too restrictive, hence, CLAP.

[Garrincha]

Funny because I do think we have great VST3 support.

From a user point of view (what I actrually am) this is really true. My VST3 versions of your synths run as good as the vst2 ones.

How did you actually managed to get there? Over the years I got the impression VST3 is a major PITA and doesn't support things a developer of VSTis actually need. How did you do it?

I recently needed to reprogram my Mode Machines Professor for the use with Repro-5 and much to my surprise even the VST3 version supports MIDI-learn now. I could have sworn there was a time when that didn't work in VST3, no?

[EvilDragon]

Yes because Steinberg advised u-he not to use the 16*128 hidden parameters workaround to get MIDI learn working. And then they do that same thing themselves in their own plugins...

[Urs]

Funny because I do think we have great VST3 support.

From a user point of view (what I actrually are) this is really true. My VST3 versions of your synths run as good as the vst2 ones.

How did you actually managed to get there? Over the years I got the impression VST3 is a major PITA and doesn't support things a developer of VSTis actually need. How did you do it?

I recently needed to reprogram my Mode Machines Professor for the use with Repro-5 and much to my surprise even the VST3 version supports MIDI-learn now. I could have sworn there was a time when that didn't work in VST3, no?

That's a long story.

Cutting it short, we have almost completely rewritten our VST3 layer several times. To be clear, I'm sure it's somewhat our own fault because resources are sparse, always. Anyhow, it originally worked in the hosts that were available, we were happy for a short time, until it didn't. Nobody ever found out what went wrong, but our initial VST3 layer gradually broke over time, with more hosts becoming available and SDK updates published. Hence rewrites.

After we issued warnings along with the recommendation to use VST2 instead back then, the first major rewrite was then "stick to the specs", and we consulted Steinberg people who were helpful to point out some things we might have overlooked. That however included "No MIDI Learn", as was the spec of VST3 at that time (and unlike how Steinberg's own plug-in were implemented).

From then on we have been refactoring and bug fixing every now and then. After Steinberg rejected a proposal for MIDI Learn that we co-sponsored, and because there was public pressure to implement it, we gave up on "stick to the specs" and implemented it like apparently everyone else does. It's a hack, but nothing else was available at the time. [Addendum: Exactly as EvilDragon describes]

In the meantime Steinberg has added some form of MIDI learn to latest VST3 specs, which I presume no host (other than Steinberg's maybe) currently supports. It's a good example that, if a plug-in format is incomplete and requires a bandaid, it's in the same position as a new standard: It takes time until hosts adopt it. Every new feature starts at square one.

[schwa]

In the meantime Steinberg has added some form of MIDI learn to latest VST3 specs, which I presume no host (other than Steinberg's maybe) currently supports

REAPER does fwiw. Not that it changes your point which is that the only workaround for this previously was fairly horrible.

[Urs]

So then Bitwig and u-he and Tone2 will have to drop VST support completely to try to force the industry to adopt CLAP in an “us or them” move (that’s why I asked if they are going to.) But that’s a power play that only Steinberg or Apple can afford to make. So in the end, the CLAP ends up becoming yet another proprietary plugin format, and VST3 remains the one and only universal format.

I think your misconception is that you believe they will support CLAP only. That is not the case. They will support CLAP and VST3. Why do you think they would drop VST3 altogether?

I’m saying that without an incentive, no major DAW is going to add support for a redundant format, and very few plugin developers will either.

The only thing that would entice a professional DAW to invest the time and money into incorporating a new format would be if that was the only way their customers could use a bunch of really popular and significant plugins. That means someone of consequence would have to make the bold move of only offering CLAP versions of their plugins. It won’t be enough if just a bunch of students and hobbyists make free CLAP plugins the way VST 1.0 started out, because the free plugin market is already oversaturated with VST plugins.

Likewise, the only way professional plugin developers would invest the time and money developing for yet another plugin format is if that was the only format a popular DAW accepted, as is the case with Logic and AU, or ProTools and AAX. So once again, some DAW maker who is onboard with CLAP would need to make CLAP their exclusive format.

Think about it: if every DAW and every plugin supports VST3, then why would anyone outside of those few True Believers/anti-Steinberg crusaders bother? It would be redundant and just more work with no upside.

So if not even the True Believers believe in CLAP enough to put some skin in the game and drop VST support, why would anyone else?

They wouldn’t. And that’s why CLAP is ultimately a waste of time that is destined to fail.

I'm taking the liberty to answer these points here, as I do not wish to drag things out in the thread they were originally made.

Let's see:

- CLAP could easily have more example code, easier examples and more comprehensive tools to develop than other standards. I'd say hosting in particular will be easier to implement than other standards I've seen, and I'm sure that CLAP plug-ins and hosts will generally be more stable than some others.

- it is not about dropping support for other formats (why would you think that?). It is about making sure investment is not lost when one or more of these technologies vanish. Each company maintaining the currently dominating standards has completely deprecated standards before, hence there's ample precedence that this could happen again. CLAP otoh can never be taken away, particularly from commercial developers, as it's liberally licensed.

- CLAP plug-ins will very likely run in non-CLAP-hosts via adapters.

Hence my counterquestion: Why would any developer invest in a possibly lesser format, which is more difficult to develop for, which is a moving target api and license wise and requires vetting processes or a lawyer to get into - if CLAP is bliss to develop for, has serious feature advantages and fewer conceptual restrictions and will just run in any host available?

[Urs]

In the meantime Steinberg has added some form of MIDI learn to latest VST3 specs, which I presume no host (other than Steinberg's maybe) currently supports

REAPER does fwiw. Not that it changes your point which is that the only workaround for this previously was fairly horrible.

Great! I hope we can drop the workaround one day.

[Urs]

Also, because in "the other thread" it was mentioned that CLAP popularity could be boosted with a CLAP-only freeware offering, I'd go one further and bundle a CLAP-to-X adapter with the download, such that everyone who installs the freeware offering automatically has support for all other CLAP plug-ins on their machine, regardless of what their hosts support.

(that's unfortunately not possible for AU due to code signing and notarisation, which is why we're working on a CLAP-to-AU wrapper which we've planned to make available for free to all plug-in developers who wish to support CLAP)