[markofthew]

Most are quite similar, which is why the vast majority of commercial plug-in developers gravitate to using something like JUCE (or, to a lesser extent, iPlug). Such a framework makes it easy to target a single API and output cross-platform versions for AAX/AUv2/AUv3/VST2/VST3/etc... I have no doubt that JUCE will support CLAP, and therefore make it easier for developers to spit out yet another format.

Alternatively, CLAP could end up as the intermediate format, with bindings supplied for presentation within other native plug-in formats.

VST3 is the one that sticks out like a sore thumb, because it represented a radical change in how the user interface classes interact with the audio processor class. This created a massive problem because you had to assume that the UI and the processor were essentially running in separate processes and communicated via message passing through a specific interface or just plain text. It's the reason why VST3 didn't ever gain the traction and support of VST2, since Cubase was for many years the only VST3 host, and since more complex plug-ins like, say, Kontakt, would require a huge amount of developer time to upgrade, a stalemate existed for too long. So it's hard to see everyone getting behind yet another format to support and test, especially if the core code has to conform to the lowest common denominator, as it were.

On closed vs. open, although AU is controlled by Apple, and VST by Steinberg, they are both open to the point that anyone can download required SDKs and develop for them. Avid traditionally kept their SDKs through application forms and NDAs, so not everyone had access. Even now, IIRC, JUCE doesn't come with the AAX bindings necessary to build such a plug-in, they have to be copied in from the official distribution.

[PaulDavisThe1st]

> VST3 is the one that sticks out like a sore thumb, because it represented a radical change in how the user interface classes interact with the audio processor class. This created a massive problem because you had to assume that the UI and the processor were essentially running in separate processes and communicated via message passing through a specific interface or just plain text.

Adding VST3 support to Ardour/Mixbus, we did not experience this as a notable issue at all.

Far more problematic from a hosting perspective in VST3, though it has also been present in AU since the start, is multi-bus output. At the "processing audio" level, it's still pretty simple, but "allow the user to connect stuff" level, its far from simple, unless you just do what reaper has done and flatten all the busses.

VST2 was not "open" in a way that made it usable by libre software developers. AU doesn't really matter much since it's single platform.

I think it is also important to stress again that most plugin developers that do this stuff for anything close to a living have not targetted specific plugin APIs for years. As you noted, many will use a framework like JUCE, others have their own in-house equivalent, which lets them create the DSP and GUIs in a plugin-API agnostic way.

[markofthew]

> Adding VST3 support to Ardour/Mixbus, we did not experience this as a notable issue at all.

Not as a host; but this was a major stumbling block for more advanced plug-ins like, say, Kontakt. Given that VST3 was based on VST-MA (largely the work of one of the original Studio One authors), which is derived from Steinberg's COM-like interpretation, there were some genuine pain points for plug-in developers.

But I think your point about the framework approach is a reason against having yet another API to spit out. As you say, developers who do make a living out of this, aren't going to be able to dig their heels in and say "it's CLAP or nothing if you want to run my wares." I imagine it would be suicide for smaller developers like Fabfilter or Valhalla. And if CLAP is just another API supported in branch of a framework, where is the "killer application/plug-in" going to come from?

I think VST3 shows how well this is going to be received. Nobody was keen on VST3 from the start, and AFAIK this wasn't to do with philosophical objections to commercial licensing. It was largely due to the fact VST2 worked well enough, was understood, supported, and nobody saw the point in adopting it. The fact Steinberg had to deprecate 2.4 and then announce they were going to end-of-life support for it in their own applications to convince market forces says it all. Even when Doric came out a few years ago, in v1.0 only VST3 was supported. But they quickly backtracked and added whitelist support for VST2 plug-ins.