About CLAP

[Urs]

I have no idea what it really was, but Zebra didn't work as LV2. We dropped it and deemed it "not sufficient" even though we had an otherwise working implementation. That's when we ported VST3 to Linux instead.

[EvilDragon]

I remember in Surge 1.7 we disabled LV2 port because the spec was not compatible with certain things Surge did - namely, LV2 assumes that plugins never modify their control input port. Actions like ‘changing parameter types when an oscillator or an effect changes’ are not compatible with this design constraint. As a result, the LV2 - especially in Ardour - unreliably saved and restored state.

I think LV2 added some things to their spec that allowed this, but we didn't pursue that further, we moved to JUCE instead. Now there's a JUCE LV2 fork that may work better than the old hand-rolled implementation we had. I don't know for sure.

[Tj Shredder]

Does CLAP permit plugins to be formatted as bundles?
in form similar to vst3, where the plugin can be either dll alone, or directory with resource files.

Yes of course.

Would this principle, which is supported by VST3 allow to create a wrapper that automatically expose all CLAP plugins to a VST3 host? I bet this would propel CLAP very fast into the market. If it is easier for a dev to create a CLAP plugin than a VST3, you would do so and let the exposition to any VST3 host be automated…
A bit like the Wave shell, but a CLAP shell…

[Urs]

Does CLAP permit plugins to be formatted as bundles?
in form similar to vst3, where the plugin can be either dll alone, or directory with resource files.

Yes of course.

Would this principle, which is supported by VST3 allow to create a wrapper that automatically expose all CLAP plugins to a VST3 host? I bet this would propel CLAP very fast into the market. If it is easier for a dev to create a CLAP plugin than a VST3, you would do so and let the exposition to any VST3 host be automated…
A bit like the Wave shell, but a CLAP shell…

That is a concept I'd very much support.

[glokraw]

There are probably some fine coders being wasted at steinberg, who could be creating
great instruments and effects, that thousand could enjoy using, but are stuck in the dungeon futzing with endless cycles of kontrol freakery. Even if a coder had to study
dsp and etc etc for long hours, if I were young, I'd rather be able to look back someday, and say, 'I helped us kompete against the invincible Zebra, with x, y, and b, instead of mumbling about making tools for locking out small-shop developers.

[zvenx]

As someone who beta tests for SB and has to interact with developers there almost daily, I can assure you that is NOT the atmosphere at SB.

I definitely don't ever get the impression that they are frustrated with working with and developing for vst3 at all. And just in case you think oh of course they wouldn't say that there cause that is who pays them, I have seen other criticism of SB by some of them on the beta forum.

rsp

[glokraw]

I have no reason to doubt your experiences, but I still believe talent there at SB, and in many audio businesses, would be better used making creative products, rather than protecting and propagating restrictive formats.

That doesn't mean you can't find people appropriate for the positions. But bottom line, needing to eat makes one very appropriate, and even in that position, being happy and productive at work is healthier than the alternatives.

I doubt Howard will be applying for a job coding infrastructure, as long as there is demand for creative sound designers. ( )
Cheers

[okmog]

Will it be possible to write MIDI effects with CLAP?

[dawhead]

This is pretty depressing (even though of course in some other ways it's sort-of good news).

Above, we can see two plugin developers who ran into issues (doesn't really matter what they are) with LV2, a license-free, open, community-developed, cross-platform plugin API developed on the back of the cross-industry GMPI effort for more than a decade, and what happened? They just gave up.

Now we have a new license-free, open, community-developed, cross-platform plugin API and the only reason this one is getting some traction on non-Linux platforms is because, it would seem, that plugin developers feel (or think, or both!) that they are somehow going to be more in control of how CLAP works and evolves.

Is this NIH-ism? Is it a genuine reflection of problems with the LV2 "process"? Is it both? I don't know. I'm just really depressed that someone like Urs would simply embrace CLAP while having given up on LV2, when there is every chance that problems of similar magnitude will arise (for someone) with CLAP. What are they supposed to do then, say "we tried to release PluginMatic with CLAP but it just didn't work, so we're now supporting the CLOP effort!"

Like I said, good news is some respects, but so depressing in so many others.

[mystran]

Last time we discussed LV2 just about every real problem that people brought up was met with "the LV2 way of doing things is the only true way and will never change" and nobody wants to fight that kinda of API.

[dawhead]

Last time we discussed LV2 just about every real problem that people brought up was met with "the LV2 way of doing things is the only true way and will never change" and nobody wants to fight that kinda of API.

I would regard that as a major mischaracterization of those discussions (which I was a part of).

In addition, it's misleading in another, rather important way, too.

There's "the LV2 way" and there's the "meta-LV2 way". By the former, I mean the nuts and bolts of how current LV2 plugins and hosts interact with each other, the sort of thing that is present in any plugin API. By the latter, I mean the way in which LV2 supports arbitrary extensions that allow to support just about any dumb or great idea out there (assuming that at least one host and one plugin agree on the extension).

There's no particular attachment to "the LV2 way" within the LV2 community, because we're as aware as anyone of the tradeoffs that come with the design decisions made in any particular plugin API. However, it is in part because we've seen those plugin APIs play out over time that there is quite a lot of attachment to an extension system that is a formal part of the overal API, and that's something about which there there is some real resistance to being told "this is wrong".

You will not get it all right in one go, and what is needed/desired will change over time. The extension mechanism in LV2 is much better designed and conceived of than any equivalent in any other plugin API, but it's also the thing that tends to cause plugin devs who have only seen VST(2) and AU to run away screaming. It just doesn't fit their worldview/prior API "models".

There's also resistance to the use of Turtle to define plugin metadata - that's a more legitimate objection, even though it's really 6-of-one, half-dozen-of-the other with respect to any actual alternative. Sure, more people know JSON these days (because the Semantic Web effort failed), but is it actually better for the purpose?

There are some legitimate criticisms of versioned extensions too, something that we've learned over many years probably wasn't a great idea after all. It made sense in comparison to the way that shared libraries (DLL's) tend to do things, but in reality, it's a lot of extra complexity for not much gain (just rename the extension already, dammit).

[machinesworking]

Is this NIH-ism? Is it a genuine reflection of problems with the LV2 "process"? Is it both? I don't know. I'm just really depressed that someone like Urs would simply embrace CLAP while having given up on LV2, when there is every chance that problems of similar magnitude will arise (for someone) with CLAP. What are they supposed to do then, say "we tried to release PluginMatic with CLAP but it just didn't work, so we're now supporting the CLOP effort!"

Like I said, good news is some respects, but so depressing in so many others.

CLAP starts off already addressing Mac OS, Windows and Linux, it's already addressing a larger more inclusive audience with all kinds of requirements. There's real money involved in getting it right. As in time = money, "we set up a better plug in format and it saves us days of time". I'm pretty confident that if this is done right it will be better than LV2.

[dawhead]

CLAPs audience is no different than LV2's. LV2 came about after the cross-industry GMPI effort, and specifically attempted to address the dozens-to-hundreds of design points that came up as part of GMPI. It was always cross-platform, but most (not all) plugin developers who did not think that Linux was worth their attention just ignored it.

CLAP does cover a few things that LV2 does not (and vice versa), but the distressing part is that LV2 could easily cover them too, if people had not simply done the NIH thing, and reinvented yet another plugin API.

In addition, there are already on the order of a thousand working cross-platform plugins that are available in LV2 format; while that doesn't prove that there are no issues with the API, it certainly proves that it is capable of supporting a wide variety of plugin/processing requirements, across platforms, without a license, with source, and with an extension mechanism.

Finally, most plugin developers (not all, for sure) don't really give a damn anyway. They use JUCE or an equivalent, tick the right boxes, and get plugins in whatever formats they want. The existence of CLAP will make approximately zero difference to that style of plugin of development.

[Dewdman42]

I think its pointless and stupid to have an LV2 vs CLAP debate. I say both teams should continue doing what they do and let the best format win.

I personally think LV2 has had its chance and for reasons having little to do with the tech, will never see wide adoption. They made some decisions that make it more difficult to adopt into mainstream DAW's. I think the authors of it don't really care about wide mainstream adoptionn (sound familiar?). So... For that reason, it probably won't.

There is still a chance that CLAP may navigate some of these logistical issues in such a way that it can penetrate the market and become a standard, because behind it DO care about wide adoption. Or hey...maybe LV2 will still surprise us all! its all good. there is no reason to become tribal about this. I just want something other than Steinberg-controlled nonsense running in my very non-Steinberg DAW.

[dawhead]

I think its pointless and stupid to have an LV2 vs CLAP debate.

I agree with this, which is why I tried to stay away from saying anything remotely like "CLAP is crap" (because it's not!). I was expressing regret that instead of unifying around a single plugin API, people who care about all the things that LV2 and CLAP are about are now going to be split into two communities.

And sure, what will happen will happen, but I'd rather not see people making false claims about LV2 as part of an explanation of why CLAP must exist.

I think the authors of it don't really care about wide mainstream adoption

This is categorically untrue.