[teilo]

Your very first sentence is why CLAP is going to succeed in the long term. It is why CLAP was developed. It it an open standard that gives developers what they need in a way that LV2 never will. For many devs, it will be their primary CI/CD target of choice. It is not unlikely that the plugin devs with huge legacy code bases, such as NI, will begin to realize that CLAP provides a path forward to VST3/4/? support that will insulate them from Steinberg and Apple's decisions in the long term and save the a lot of money, and keep their legacy code bases profitable.

Avid is already evaluating CLAP support. So is Presonus. Reaper is nearly there. So in my opinion it's only a matter of time before Pro Tools, the industry mastering standard, supports CLAP. Other DAWs will follow.

I think you are underestimating just how much of a problem that Steinberg has created for the industry as a whole with their draconian limitations on the VST development. Pulling VST2 out from under everyone has created huge issues for plugin developers (like u-he) who rely on VST2 as their primary development target. Developers hate VST3, and nobody trusts Steinberg. Nor should they. VST3 is a dumpster fire that people target only because they have no choice.

CLAP may or may not succeed as a plugin format that users will use. But its greatest chance of success will be as the primary development target for developers, with all other formats wrapped around CLAP. It's a dream to develop on with its simple ABI, and a dream to wrap to other formats. This means that, over time, a large number of developers will produce CLAP plugins just to end the nightmare of maintaining VST2/3/AU/AAX versions that are feature complete.

With Avid, Bitwig, and Presonus already on board, and Reaper soon to follow, and with developers like Fabfilter and Xfer announcing interest, I think you vastly underestimate its chance of long term success.

This is even before considering what CLAP gives you. MIDI 2.0 is coming. Rich per-note expression is presently poorly supported in all DAWs except for Bitwig, (but until now, only on its internal instruments). CLAP has it, out the door, and Bitwig now supports it with its per-note modulation system. Other DAWs want this feature, but don't want to roll their own version of it. But the entire equation changes when you have major plugin developers already supporting it via CLAP.

My gentleman's bet is that CLAP will gain momentum, and the rest of the DAW world, save for Apple and Steinberg, will support it.

[PaulDavisThe1st]

> It it an open standard that gives developers what they need in a way that LV2 never will.

This is false. The biggest issue with LV2 from the perspective of the people most responsible for CLAP was the governance model and/or what is required to shape an already decade-old open source API/library project. LV2 is 100% capable of doing anything CLAP can do, but the most significant CLAP players didn't want to go through the process that would have been required to make that happen.

Also: per-note expression is not a problem caused by plugin APIs. It requires a completely different data model for musical performance (whether MIDI is involved or not) than has traditionally been the case. Adding it to a plugin API possibly makes it just a tiny bit easier, but compared to the challenge of providing the user with a way to edit this, that's a nothing burger. If you want a more technical analogy: any DAW can record and playback MPE already, because it's nothing more than MIDI data. But allowing the user to control the evolution of CC43 and CC57 for the 85th note ... that's a totally different ball of wax.

[teilo]

I think you made my point for me.

LV2 has multiple issues, and its technical capabilities don't even enter the picture. First, it has a very complex API, and many developers who attempted it found that it was not worth the effort. Too little gain for little to no return. Second, the maintainers do not listen to the needs of the community. This is not an issue with the CLAP developers. This is an issue with the entire community. CLAP exists specifically because of the problems in the LV2 community, and with the LV2 architecture. This is why LV2 has not gone in any significant way beyond open source projects.

You need to ask yourself why it is that CLAP immediately has industry support upon teaching ABI stability, while LV2, so many years later, still has almost none. It's not random chance. It is because it meets a need that LV2 does not for both technical and governmental reasons.

As for per-note expression, you again made my point for me. It is indeed a completely different ball of wax that no current plugin standard can address in a way that is consistently addressable by a DAW. Sure, any plugin can implement MPE, but the implementation is plugin-specific, with no practical way to have a consistent DAW interface. There needs to be an API for it, and no API for it exists in the world of VST/AU. But it does exist with CLAP. This is yet another areas where Steinberg shot themselves in the foot. By killing MIDI in VST3, they also killed MIDI 2.0 per-note expression.

[PaulDavisThe1st]

I know many LV2 developers, and I have never seen a coherent argument that it is "very complex". I do know that people without CS backgrounds find it intimidating because it tends to use more CS-y concepts than APIs like VST (and now CLAP). In addition, to be honest, 75% of all the criticisms I've seen of LV2 come from people who seem unable to understand some of these basic concepts.

> CLAP exists specifically because of the problems in the LV2 community, and with the LV2 architecture.

This is false, or at best misleading. CLAP exists because when abique and Urs made a minimal level to engage with the people involved with LV2, they didn't like what they saw, and quickly disengaged with it. Neither of them were or are willing to deal with the relatively normal stuff that goes on in open source API/library development, and have explicitly said that they would rather create their own API than deal with what they perceived would be involved.

The supposed "problems" with the LV2 architecture are all resolvable, or would be by people who (a) had a stake in them (b) were willing to participate in the process that an open source API/library project tends to involve in 2022. The people behind CLAP match (a) but not (b).

> Sure, any plugin can implement MPE, but the implementation is plugin-specific,

This is false, or meaningless. It's like MIDI itself. What does CC33 do with a particular synth? Could be this. Could be that. MPE is just the same, it differs in no way from vanilla MIDI 1.0. The same issue is true for CLAP, though CLAP does at least acknowledge that it's an issue. Any given plugin that implements "polyphonic expression" may have wildly different parameters and responses to controls than any other. CLAP does not address this (and cannot).

You also miss my point entirely. For hosts, the hard part of MPE/PE/MIDI 2.0 is providing a way for the user to view and edit a time-series of events connected to a particular note. This is so totally different from what happens with regular MIDI 1.0, where other than polyphonic aftertouch, all controls are per-channel. There's absolutely nothing a plugin API (CLAP or anything else) can do to assist with this.

> By killing MIDI in VST3

There are lot of audio software developers who are painfully aware of the horrible limitations of MIDI it and would prefer to avoid it. This generally does not include the hundreds of plugin developers who have churned out VST2 after VST2, often doing cool things but generally unaware of the problems that MIDI creates as a representation of musical performance. Did Steinberg jump the gun on believing they could create a new standard representation/protocol for this? Why yes, yes I think they did (after all, academia has been trying to do this for decades, without much success). But there's nothing really about MIDI 1.0 to be salvaged, except that it was simple and a lot of people think they already know it. In theory, what Steinberg did was to create a much more flexible system (than even MIDI 2.0). In practice, a bunch of developers didn't want that because they have existing code that just works, and another bunch didn't want that because they think Steinberg didn't get it quite (or even close to) right.