CLAP... thoughts?

[10bd01]

Just sent a note to UVI support asking them if they're intending on working with CLAP. I'd love to see them on board, and intend on sending out messages to other developers whose tools I use in the upcoming week.

[liquidsound]

A good interview by sonicstate:

[trackbout]

they both make horrible technology decisions frequently,

Being involved in a standards body I wonder how you are going guard against doing just that. Yes, an open standard can be forked (or whatever you do with standards) but that will just lead to XKCD'ing. Are you going to form a standards committee with some vendors to make sure that everyone stays on board, and it's not just the two of you doing things that seem reasonable to you?

Just to be clear: I trust you but I'm curious about the principle.

V.

Just to be clear, I am not part of the team behind CLAP at all. I’m learning about it as you are. I had obviously heard rumblings about it for the past few years but I didn’t pay much attention because there are such significant obstacles to something like CLAP ever existing that I figured it never would.

To your question, there’s no doubt that it’s hard to make technology decisions that in hindsight are consistently viewed as smart. Open source projects are just as likely to get things wrong as companies.

There is a long list of things that gives me confidence that CLAP will consistently reflect better technology decisions than AU or VST, but I’ll just pick a few:

- Perspective. CLAP has the benefit of learning from all of the mistakes that Apple and Steinberg have made over the years, without being blinded or handcuffed by entrenchment within either organization.

- Green fields. CLAP began with all of this historical knowledge, but a blank slate for a codebase. That results in much higher odds of getting things right from the outset, which in turn sets the codebase up for continued good decision making.

- Enthusiasm. Anyone that contributes code to CLAP is spending their own valuable, unpaid time because they, as an individual, actually care about crafting an ideal version of a plugin format, in terms of developer experience and user experience. You cannot buy that from an employee.

- Pace. The best hedge against bad technology decisions is the pace at which you ship code. When a wrong turn is made despite best efforts, even if there is a willingness to course correct, the outcome is ultimately determined by how long it takes you to ship new code. Once again, Steinberg and Apple’s mountain ranges of technical debt work against them here.

- It’s already better.

[pdxindy]

- It’s already better.

As a user, this is the part that matters most to me. My favorite synths (u-he) all just became significantly better thanks to CLAP

[baconpaul]

Is it possible to tunnel CLAP through CORBA?

I don’t know if this is a serious question but the answer is yes. The clap api could easily be held behind a socket or what not. Since corba doesn’t have a ui it would t really even be hard,

The current gui extension assumes you have a window reference but Alex made that work with remote guis. If you really wanted full remote communication of non parameter information you could add a custom removing extension. I was just thinking this morning about this in a different context.

But with current core you could write an idl that mapped no problem

[fmr]

that means a 50% increase in resource allocation, which translates to fewer new plugins, more bugs, and longer wait times between updates for your preferred standard, whatever it may be.

Seems you are using a Mac, right? How much resources have been wasted over the years because of Apple policies and decisions? Yet you are still using a Mac. And even changed to an M1

Again - if FabFilter were to implement 100 new formats we may see delayed bug-fixes, delayed updates, delayed responses to customer support tickets because the heavy workload is putting a general strain on their business. Are those 100 new formats to blame for those "effects"? Indirectly, yes, they are. If implementing CLAP was to produce these types of "effects" it would also be indirectly responsible, and it WOULD have an impact on end-users.

However, Apple forced developers to basically stop developing to concentrate in coding to support their new platform, and I didn't see many concerns raised about that. And that for the only benefit of Apple and a bunch of users that ran to buy M1 laptops.

[sQeetz]

As a user, this is the part that matters most to me. My favorite synths (u-he) all just became significantly better thanks to CLAP

How so? Please help me understand. If one uses Logic as a main sequencer. How does CLAP improve my experience?
Of course, using Bitwig and u-he's new plugins, there are obvious advantages. But for the commoners?

[vurt]

As a user, this is the part that matters most to me. My favorite synths (u-he) all just became significantly better thanks to CLAP

How so? Please help me understand. If one uses Logic as a main sequencer. How does CLAP improve my experience?
Of course, using Bitwig and u-he's new plugins, there are obvious advantages. But for the commoners?

sadly at the moment only bitwig as a host is supporting it. but the new features clap offers will be available if and when other hosts offer support too.
im in the same boat at the minute, but hope at some point more hosts do offer it, and as plogue are onboard at least, i should see support there in bidule soon enough.

but for now, no, we are all outside of the clap market if not bitwiggers

per note expression is the big plus so far

[sQeetz]

sadly at the moment only bitwig as a host is supporting it. but the new features clap offers will be available if and when other hosts offer support too.
im in the same boat at the minute, but hope at some point more hosts do offer it, and as plogue are onboard at least, i should see support there in bidule soon enough.

but for now, no, we are all outside of the clap market if not bitwiggers

per note expression is the big plus so far

Seriously, do you really see Apple adopting this for Logic? I sure hope so, but I'm seriously doubtful.

[vurt]

sadly at the moment only bitwig as a host is supporting it. but the new features clap offers will be available if and when other hosts offer support too.
im in the same boat at the minute, but hope at some point more hosts do offer it, and as plogue are onboard at least, i should see support there in bidule soon enough.

but for now, no, we are all outside of the clap market if not bitwiggers

per note expression is the big plus so far

Seriously, do you really see Apple adopting this for Logic? I sure hope so, but I'm seriously doubtful.

logic perhaps not
but, if it is successful, and offers new features that tempt uses away from logic, you never know!
apple are smart people, so never say never!

[sQeetz]

Maybe... we'll see

[jamcat]

So much work involved for so little back investment. I don’t want to sound like a pessimist, but I don’t really see this one going anywhere but obsolescence.

I would really love to be proven wrong, though…

As Urs has begun to explain it better, it seems like CLAP could present a way for fast development and prototyping for new plugins, and wrapping them to established formats under the hood.

We could even see several hosts eventually incorporate direct support of CLAP plugins. But the major hurdle that I’ve been trying to discuss, which I’m still seeing, is that there is really no incentive for existing 3rd party plugins to be ported. That means everything everyone here has ever bought or currently uses, aside from the handful of developers who are CLAP stakeholders.

So if you already own most of the plugins you need, what are the chances they will ever support CLAP, and how long will you be waiting for that? Will we see yet another round of mass plugin extinction if CLAP eventually takes over?

The people talking up CLAP only seem to be talking about future development. No one is addressing the substantial investments we’ve already made.

[EvilDragon]

is that there is really no incentive for existing 3rd party plugins to be ported.

If those plugins were created from VST2 core then wrapped into other formats, as majority of plugins out there really are, coupled with the fact that Steinberg can force devs to remove every trace of VST2 code from their build systems if they sign an updated VST3 license agreement (which they would have to do in order to be able to produce VST3 plugins!), the incentive is more than sufficient to replace that VST2 core with CLAP.

This really shouldn't be that difficult to understand, how huge ramifications of something like this could be. It almost happened once for real, Steinberg backtracked. That's not to say they wouldn't want to attempt the same move again later.

[pdxindy]

As a user, this is the part that matters most to me. My favorite synths (u-he) all just became significantly better thanks to CLAP

How so? Please help me understand.

I didn't say it benefits you. I said it benefits me cause I use Bitwig and the Bitwig modulation system is freakin awesome (but previously limited to Bitwig instruments for per voice modulation)! Unlimited per voice modulation in the u-he synths (ACE, Diva and Hive now and RePro and Bazille to follow) was an absurd fantasy, but just became a reality. Today I have been making these slow, gorgeous, textural pads in ACE cause now I can modulate various parameters that cannot be modulated directly in ACE (with a far wider range of modulators) which opens up a new sonic landscape.

[jamcat]

that means a 50% increase in resource allocation, which translates to fewer new plugins, more bugs, and longer wait times between updates for your preferred standard, whatever it may be.

Seems you are using a Mac, right? How much resources have been wasted over the years because of Apple policies and decisions? Yet you are still using a Mac. And even changed to an M1

Again - if FabFilter were to implement 100 new formats we may see delayed bug-fixes, delayed updates, delayed responses to customer support tickets because the heavy workload is putting a general strain on their business. Are those 100 new formats to blame for those "effects"? Indirectly, yes, they are. If implementing CLAP was to produce these types of "effects" it would also be indirectly responsible, and it WOULD have an impact on end-users.

However, Apple forced developers to basically stop developing to concentrate in coding to support their new platform, and I didn't see many concerns raised about that. And that for the only benefit of Apple and a bunch of users that ran to buy M1 laptops.

So the answer to the bottleneck created by Apple’s move to ARM (and the moves to VST3 and 64-bit before them) is… to create another bottleneck?