About CLAP

[EvilDragon]

CLAP is actually an old(er) language, it's written in C, predecessor of C++.

[SeBaer]

This probably sounds a little abstract, because it is.

That's why it's called an abstraction layer... SCNR

[tony10000]

I listened to an interview with Mr. Bill and Steve Duda on Bill's podcast and he explained that he develops for VST2 and uses a wrapper to create the Mac Audio Unit version of Serum and his other apps. I am assuming that the same can be done with CLAP. I wonder if CLAP will ever be a target option for JUCE/ProJUCER?

[Urs]

Question from a layman end user.

Obviously, in abstract I want things to be as easy for developers as possible, but as an end user the main point for me that sounds appealing is Polyphonic Modulation.

As a Bitwig user, it sounds like my host is going to support this no matter what, but presumably if people start wrapping their CLAP plugins to formats like VST3 that don't currently support this, they will lose that benefit right?

Basically, while CLAP adoption is limited and plugin developers make choices that result in the widest possible market share for them (essentially wrapping to some kind of VST format), will we lose (or more accurately through insufficient incentive for developers, not see them take advantage of) some of the more out there / powerful features that the platform provides?

Apologies if this has been answered and I've just misunderstood how any of this has worked.

First of all, all advanced features of CLAP are optional. Nobody is required to implement them in order to port their stuff to CLAP.

Polyphonic parameter modulation is certainly the most advanced feature of all. While we think we found a way to do it in our software, it's neither proven that it works for us nor will we support it from the start. But we wish to add it later on.

Other features are almost no brainers to support, and they solve real world problems with ease.

Let me put a different angle to it:

What I'm saying is that the status quo (i.e. "before CLAP") is that developers often develop for the common denominator between plug-in formats. Such that, because VST3 is limiting, the whole species of MIDI processors is endangered. We think that CLAP can change that.

We think that even if other formats don't support the thread pool or parameter modulation (poly or global) or categorisation or file reference consolidation or MIDI output, it is still worth it for developers to support it in CLAP, if it makes sense for them. Because the other formats have to either draw even or they will lose market share.

There is a lot more to say about this, particularly about the implications that current formats are maintained by host developers with a conservative product philosophy. A very short conclusion here is that some of the people who support CLAP want to switch from the back seat to the steering wheel of what a host/plug-in environment could make possible. And I'm absolutely certain that the hosts and plug-ins which do the switch - not just adoption, but also implementation - will gain market share.

[Urs]

Which announcement are you referring to?

The one that VST2 will be dead in Cubase on all platforms soon. It coincides with the increased post rate here, and it aligns with some of the topics ("can CLAP help to let me use my VST2 plug-ins if the host doesn't support VST2 anymore?").

Maybe also because some of those threads have linked to this thread.

(many more people are thus waking up to what it means to invest in things that corporate interest can take away from them. And yes, our investment in VST2 is giant, having to refactor vast parts of our codebase and do yet another round of otherwise useless updates at some point is a financial loss that is fully attributable to competitive decision making at the owners of the standard. It's absolutely not about the time we had to prepare. It's also because there was no viable alternative, so we had to come up with one of our own. One that solves the issue for good.)

[tony10000]

I have been discussing this situation with Steve Duda on Discord. He has stuck with VST2 because some of his apps (Cthulhu and Nerve) need it for its MIDI capabilities. He said he will look at CLAP if and when Ableton is on board. Any chance that Ableton and NI may support it?

I can't disclose who we're talking to. First off, there's no way to get a commitment at this point. Hence, if I told you "XY signalled interest in CLAP", there's no guarantee that it's going to happen. To the contrary, they might become uneasy if I was talking about them.

I'd love to get Steve on board, naturally. I think we ran into each other only once, almost 20 years ago, during a night out with Angus, Andy and pretty much everyone else. Steve knows where to find me, or Alexandre fwiw.

What Steve shared publicly on his Discord when I asked him about supporting CLAP:

steve_xfer — Yesterday at 2:29 PM
I think it's {VST3} a poorly designed plugin spec for so many reasons, which I'd rather not start the gradient of complaints on since it goes deep on many facets
[2:30 PM]
I'm pretty aware, but a plugin format which one DAW supports is not a better option IMO
[2:31 PM]
VST2 is not broken, only abandoned
[2:31 PM]
VST3 selling points (e.g. sample accurate automation) are not implemented by 99% of plugins (JUCE built ones)
[2:32 PM]
I spend more time chasing moving goalposts than on creative/developing (well, actually not, but it feels like it sometimes). Like an artist spending more time on promo than on production (edited)
[2:32 PM]
(I spend no time on promo, short a couple interviews every few years)
[2:34 PM]
I should have VST3 plugins by the time it's actually needed its just a shame for the users who will not be able to open their old projects, or use legacy software, from a totally artificially imposed reason

[Urs]

We're in the same boat here. Only, VST2 is not abandoned, which implies "just left there idly sitting around". It is actively being removed from products by people who wish to support VST3, which does include DAWs and which thus will become concern for Steve.

[tony10000]

We're in the same boat here. Only, VST2 is not abandoned, which implies "just left there idly sitting around". It is actively being removed from products by people who wish to support VST3, which does include DAWs and which thus will become concern for Steve.

I agree. That is why I think it is important for all the DAW and plugin developers get together to adopt an open plugin standard the same way the major manufacturers go together in the early 80s to create MIDI.

[Compyfox]

Well, if Steinberg's announcement was an attempt to slow down CLAP development by pouring people into our forum, it has not succeeded (I'm not remotely involved in CLAP development atm)

I think if anything, they just dug yet another feet (1,8m) for the VST3 aversion grave.


I might be too optimistic here, but if people are just fed up with Steinberg's constant shenanigans, and now with the "forced purge" while asking users to "pester developers to finally move on" without fixing their SDK and(!) their licensing...

...yeah I feel like a boycott is rolling along. And if big companies are at the helm, then there is even more leverage to this.



Also... to those saying in the other threads "U-HE will go under if they don't adapt"... there is still VST2, AU and AAX... and wrappers (thankfully) will be a thing for those hosts that are like "no looking back" (currently: Steinberg). U-HE won't go away anytime soon. And who knows what will change, if the "regular" PC industry (AMD and Intel) fully starts to go Hybrid or even ARM as well. Then the game changes yet again.

And by then, I assume "CLAP" is already at a huge adaption rate.
It's a win-win-win no matter how you look at it.

[Urs]

"U-HE will go under if they don't adapt"

Huh? Do you have a link for that?

Funny because I do think we have great VST3 support.

[Compyfox]

If you want to go into that drama hole (I paraphrased after all), you can follow-up here if you want to. This is where plenty of the new posters in here heard about CLAP the first time as well.

Tread with caution. Although knowing you and your team, it's rather a cup of coffee and a small chuckle.

[shaboogen]

First of all, all advanced features of CLAP are optional. Nobody is required to implement them in order to port their stuff to CLAP.

Polyphonic parameter modulation is certainly the most advanced feature of all. While we think we found a way to do it in our software, it's neither proven that it works for us nor will we support it from the start. But we wish to add it later on.

Other features are almost no brainers to support, and they solve real world problems with ease.

Let me put a different angle to it:

What I'm saying is that the status quo (i.e. "before CLAP") is that developers often develop for the common denominator between plug-in formats. Such that, because VST3 is limiting, the whole species of MIDI processors is endangered. We think that CLAP can change that.

We think that even if other formats don't support the thread pool or parameter modulation (poly or global) or categorisation or file reference consolidation or MIDI output, it is still worth it for developers to support it in CLAP, if it makes sense for them. Because the other formats have to either draw even or they will lose market share.

There is a lot more to say about this, particularly about the implications that current formats are maintained by host developers with a conservative product philosophy. A very short conclusion here is that some of the people who support CLAP want to switch from the back seat to the steering wheel of what a host/plug-in environment could make possible. And I'm absolutely certain that the hosts and plug-ins which do the switch - not just adoption, but also implementation - will gain market share.

Appreciate you taking the time to answer the question.

I agree with you that having more and better features available to end users with zero or little friction for them is not just a net positive for production overall, but certainly something that has the capacity to drive market share if the features are a significant benefit.

I suppose the part that I have some trouble with is the idea that people will spend time on building in features that are (for now) exclusive to a challenger format with a smaller potential return on investment. I'm not a dev, but I've project managed enough things where a million ideas were buried in Phase 2s that never happened and minimum viable products limped over the line due to budget / time constraints. I wonder if the same kind of thing might happen here, which might hinder adoption of the best features the format has to offer (at least to end users, it sounds like there are dev-specific benefits here too) early on.

Of course, everything I could have said just then could be complete bullshit if the CLAP specific stuff is either relatively easy to build or there's a significantly higher rate of adoption than one might expect, which given the way you guys have talked so far sounds increasingly likely.

No offense meant with any of this obviously, and also none of what I've said comes from a desire to not see CLAP happen. On the contrary, this sounds like one of most revolutionary moves we've seen in this space for a while, and I hope it delivers. Hell, I hope the CLAP spreads like wildfire.

Based on what everyone who has anything to do with the project is said, it sounds like you've all dotted the I's and crossed the T's already.

[zvenx]

I am not sure how you read jamcat's post and paraphrased it into: ""U-HE will go under if they don't adapt"..

rsp

[Urs]

If you want to go into that drama (I paraphrased after all), you can follow-up here if you want to. This is where plenty of the new posters in here heard about CLAP the first time as well.

Tread with caution. Although knowing you and your team, it's rather a cup of coffee and a small chuckle.

Ah, ok, lol.

No worries.

What we (speaking as u-he) have in mind may require a lot of imagination and out-of-the-box thinking, which any doomsday predictions seem to lack. Maybe I should start a thread in the dev channel to see if someone can guess what our plan is to establish CLAP. That's probably a good idea, maybe someone has even better concepts.

[prokoudine]

Which is why, and exactly why, I propose this challenge, namedrop and proximity to Paul, included. For all the diehard dinosaurs clinging to the old and flawed, the time is almost here to

'pics, or stfu'.

If clap is worse than the other formats, the dinosaurs can surely prove it in public. Code now, or forever hold your peace. And try to make yast years profits stretch...

Well, first off, I'd rather not refer to living people as to dinosaurs. Secondly, I don't see the point. Ardour developers already made it pretty clear they will accept patches adding support for CLAP, which basically means they are ready to join the show however they feel about CLAP.

When Reaper, Bitwig, Ardour, and Mixbus are out all with official CLAP support, isn't that a bit like winning for you?

And since you probably don't expect Paul to write anything like Diva or Zebra (not when he can emulate a goddamn SOLAR-50 with VCV Rack), what else do you expect them to do about CLAP?

When clap takes off, which format do you think coders under age 30, (aka 'the future') and tight on cash, will trend to first?

I don't think about it in terms of "when". I'm old enough to have seen all sort of wonderful promising things go up in flames (often regrettably so). But I'm keeping an open mind and I'm reserving my seat in the front row, no popcorn involved

You completely misunderstood me or maybe my response wasn't clear, it doesn't really matter, what I was saying is that most commercial closed-source devs not providing Linux VST3 do so not because of how hard is to port, as many use Juce, but because of being afraid of having to support a very sparse ecosystem; lots of distros, versions of stuff, etc.

Which is precisely my point: there is very little need to be afraid.