[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.