This highlights a big problem in the world of music and audio software: everyone likes the idea of standards, just so long as they control the standard. And while this problem no doubt exists in other domains, it's painfully apparent in music and audio applications because the market is too small.
Clap won't succeed longterm because of many of the factors outlined in so many of these posts. Notably, Apple aren't going to support it in Logic because Audio Units work just fine, and AUv3 spans both iDevice and Mac markets. Steinberg almost certainly won't support it; they aren't even allowing VST 2.4 plug-ins to run in the Apple Silicon version of Cubase -- and this isn't for technical reasons. Ironically, Steinberg have been trying to push VST 3 since the release of Cubase v4.1 back in 2006, and it's still a giant pain 16 years later. If you look back at VST 1/2, part of the allure was the simplicity of the API; VST 3 tried to change the game too much towards MVC given that it looked at the time you might want to run the processing part of the plug-in on a different system than the user interface part.
Pro Tools doesn't get a mention in this thread, for the most part, but for better or worse it remains something of standard in audio post-production in the US. AAX isn't a bad re-imagining of what what RTAS/TDM-based plug-ins pre v10, and Avid aren't going to relinquish any control to third parties. Not least because the need for AAX (such as it is) resolves around support for the company's hardware control surfaces. EuCon was originally envisaged as an agnostic hardware controller protocol by Euphonix, but Avid purchased Euphonix, released the S6 and associated controllers and made EuControl into something of a tolerated illegitimate child.
Plug-in developers will have to follow the money, and I would to see the results of a survey correlating money spent on plug-ins based on the main host software used. My guess is that Pro Tools AAX on the Mac probably is the most lucrative, followed by Cubase and Logic. Depressing, but for all the moaning musicians tend to indulge in regarding fair compensation against any company they feel exploited by, there's a reason why music and audio applications and plug-ins remain the most heavily copy-protected software.
I don't know of anyone who's ever ditched their host application because of a plug-in format, and I highly doubt the CLAP is going to harm Apple, Steinberg, and Avid in the longterm.
> Pro Tools doesn't get a mention in this thread, for the most part, but for better or worse it remains something of standard in audio post-production in the US. AAX isn't a bad re-imagining of what what RTAS/TDM-based plug-ins pre v10, and Avid aren't going to relinquish any control to third parties.
To everyone’s surprise (yours included, I’m sure) Avid is mentioned in the announcement as a company already involved with the project and working on using it for something. There’s a nonzero chance they could adopt it in Pro Tools and drop AAX.
True. But Avid are largely terrible at implementing new technologies in a timely manner, especially since they started off-shoring development as more and more of the old timers went to recreate Pro Tools as Luna for Universal Audio! I mean, although a Windows version of Pro Tools is available, the core of their professional user base is on the Mac, and they haven't even managed to get an Apple Silicon-native version out the door yet -- over two years since Apple provided DTKs for that purpose. (Meanwhile, Logic Pro, Cubase, Studio One, Live, Bitwig, and others have all managed it.)
Avid is not exactly transparent and it's extremely difficult to see what their long-term plans are. We can only speculate. The most convincing theory I've heard regarding Apple Silicon is that they may need a new hardware interface to work with Macs that lack expansion slots. Developing hardware is of course a much slower process than developing software, and it may take them several more years to get such a product out the door. In the meantime, Pro Tools has limited usefulness on machines that can’t talk to the hardware it’s designed to drive, so why bother releasing a port?
That's not quite the case... HDX cards can be used on Apple Silicon with Rosetta 2 via the Avid-branded chassis from Sonnet, and I've personally not had a problem with that. Of course, some driver-level work would be required to fully support HDX natively in Apple Silicon. Also, the Carbon interface works fine on Apple Silicon under Rosetta 2 as it uses AVB. More and more, HDX is less important for DSP, although remains vital for large I/O configurations. On the other hand Pro Tools 2022.x supports Core Audio (or ASIO) hardware with more I/O. And if you're running the Dolby Renderer on the same machine as Pro Tools, for example, you have to run native audio hardware in any case, using the Pro Tools Aggregate I/O option (or any other Core Audio device). So I wouldn't say these are cases of limited usefulness; during Covid I had to do a whole movie soundtrack album that way at home, running Pro Tools on a 27-inch iMac with the Dolby Renderer. But when that 27-inch iMac (the last Intel 2020 model) can easily outperform a Mac Studio when it comes to running a full Atmos Netflix dub, you kind of feel it wouldn't hurt for Avid to kind of hurry up!
It is not intended to harm Apple or Steinberg, the aim is to be less dependent of them by having a free and non-bloated common plugin api that has basically all the features of VST/AU/AAX/LV2 etc. All these proprietary apis can then be addressed with a bit of wrapping code when needed.
Right now, the de-facto most important standard is VST3, which is owned by Steinberg/Yamaha who can decide to revoke the license of any developer at their will. They have shown these last years that they can be really aggressive with their license. If clap takes over, then they won't have the same position of power on audio developers. This is good for the industry.
Even if there wasn't this licensing issue with VST3, none of the current plugin formats deserve to be the "default plugin format" , they are all terrible: very large codebases, bloated architectures, c++ api, unclear threading specifications... (exception: VST2 which is simple, with a c api, but Steinberg is not allowing it anymore for new developers).
I'm not sure how you become less dependent on Steinberg or Apple by promoting another standard that really needs them to support it to fulfill its logical destiny. If Steinberg can revoke a developer's license at will (I've never heard of them actually doing this, though, although I'd love to know examples of such behaviour) they could therefore do just that if they smell any wrapping code needed to bridge into the VST domain. Avid used to, for example, although I don't know if it's still the case, have a clause in the developer's agreement that prevented RTAS/AAX host plug-ins... I guess I'm old enough to remember when FXpansion! had such a plug-in to host other formats within another.
I do agree with you on the state of the current plug-in APIs. But unless CLAP plug-ins are hosted natively, they will still have to piggy back on top of all the crud you describe. So unless a product comes out that truly takes the lead away from Pro Tools, Logic, Cubase, et al... I feel like this is going to be a massive uphill struggle. Plug-in developers will gravitate towards where the money is; and unless users place serious pressure on Apple (that thought is amusing in and of itself!), Steinberg, and so on... It's hard to see CLAP making a dent. On the other hand, if it aims to replace JUCE as the intermediary development platform to make life easier for developers, that could be good. Although, that would seem to diminish the long term goals...
So if you need users to apply pressure on large companies, you're doomed. Even famous Cubase users like Hans Zimmer aren't going to get onboard this fight, despite his close relationship to Urs.
CLAP does not need to supplant all other plugin formats to succeed. Its real goal (arguably more ambitious) is to expand the set of features in the "least common denominator" of plugin formats. To do that, it only needs to win a race with one other format, which, as it happens, is officially already dead.
Plugin developers don't just pursue the largest revenue streams. They also try to take the lowest-effort paths to those markets. CLAP is carefully designed to be a low-effort path for porting old plugins to an SDK compatible with modern feature sets, which can then be automatically wrapped in comparable formats such as VST3. There are other such SDKs, such as JUCE, but they almost all require a much larger investment of effort to work with old codebases. The fact that CLAP also specifies a well-defined plugin format further enables developers to write automatic test suites, or adapt such test suites that were originally designed for other formats. In a certain subset of the market, CLAP has already been adopted for these reasons, and as far as its creators are concerned, it has therefore already accomplished its goals.
As you suggest, there is a certain possibility that Apple or Steinberg would somehow prohibit the use of third-party SDKs in plugin development, but in reality this would be an absurd thing to try. It would accomplish nothing, alienate the entire market, and promptly result in a flurry of lawsuits and perhaps even an antitrust investigation.
I think this is a very negative and old-fashioned opinion, especially within HN that is usually focused on 'disrupting the industry' and 'innovation'.
Every day we see a new project written in the latest 'cool' language, and it receives praise and encouragement, yet try to suggest that a new audio plugin format has value and it's knocked back because 'industry standards'.
Just to give one simple example, if Native Instruments were to add CLAP to Kontakt player, and suddenly orchestral samples could have more variance per note, making the realism better - there would be huge demand from composers.
Would they switch DAW ? Maybe not for their current work, but you can guarantee it would have a lot of interest and they would be pressuring companies to add it.
For too long, audio software has been stuck in the monopoly of a few big companies. It's absolutely time to disrupt that even more and open it up to more independent developers, in the same way open source has helped in other industries.
Rather than doom CLAP to not being adopted, perhaps look to the benefits and help encourage diversity and change.
It is negative, but you have understand how niche the music and audio market really is to put some of my comments in context. I'm all for new and cool and all the rest of it, but the end users here--composers, musicians, producers, engineers--tend to not care so much about pioneering in what you might call the HN way.
To speak to your simple example, Native Instruments could do what you suggest, but they could have done what you suggest by adopting the cool and new VST3 standard back in 2006. This would have set them up for Cubase 5, which introduced VST Expression (3.5) to provide exactly that variance within orchestral samples on a per-note basis. So this has been possible for nearly a decade and a half, and, so far as I can tell, while most composers agree it's a neat idea, by Native Instruments controlling the sampler market (and Vienna to a degree) and not supporting VST3.5, the adoption never materialized.
Also, how many keyboards support polyphonic aftertouch? This would be the MIDI message that would need to be generated in order to perform polyphonic note-based expression. But almost no keyboards support it, and ROLI created the MPE standard to provide a workaround by splitting messages across multiple MIDI channels. Interestingly, MPE has received quite a bit of attention, but this doesn't require a new plug-in format to support it. And ROLI, the company, has been disastrous in the marketplace by adopting Silicon-Valley-esque approaches, raising capital, growing too fast with needless acquisitions, filing for bankruptcy, rising more money, and it even has a leader who thinks he can walk on water!
So if I sound old-fashioned and against new ideas, nothing could be further from the truth. But to pretend musicians would jump on disruptive innovation just isn't what has happened in the past. Maybe this time it'll work, but I don't see that industry has changed all that much. In fact, in many ways it's worse. More and more sample library creators have created their own sampler for playback, so whereas Kontakt used to power most libraries, now Spitfire, Cinesamples, 8dio, Orchestral Tools, and others, have their own engine. The phrase herding cats comes to mind.
Diversity and change is the one thing that just hasn't happened in the music and audio world. For example, Steinberg introduced Nuendo 22 years ago with the intention of it disrupting Pro Tools... However, go to Skywalker Sound, for example, or any other high-end audio facility, and they won't be running Nuendo -- at least in the US. And as for open source, listen to Paul Davis talk about Ardour... For some reason, open source music and audio software has just never become a thing. And sure, it would be cool for there to be a kind of Red Hat model adopted in the audio industry, where money could be made from supporting an open-source-based ecosystem, but I think CLAP has more chance of succeeding than this reality.
I see the proliferation of bespoke sample players as both a good thing - it drives innovation, as can be seen in some aspects of Orchestral Tools SINE player - and a reflection that Kontakt just hasn't kept up (perhaps as NI has spread itself too thin across many interests).
I also think that the industry could change - After all, Hans Zimmer has been instrumental (!) in bringing more plugin instruments into the mainstream scores, and may well be one who'd appreciate the potential (especially being fond of u-he instruments).
I'm sure that everything won't suddenly change, and indeed I doubt the landscape will change much over the next 12 months. However, everything has to start somewhere and CLAP is well designed and connected to be able to make a difference.
I also think that a realistic approach needs to be taken with the open source aspect. It opens more doors, rather than closing them - that's what's important.
The business side will need more work, but just bringing the ecosystem to more people with less barriers to entry, as well as looking to progress the status quo and allow for more innovation without being dependent on a single vendor, is a fantastic start.
I don't disagree with your current view of the world. I just believe that it's just as ripe for change as other tech industries - perhaps more. Blender is another example of how sentiment can change - it may not be an Industry Standard yet, but it's gaining a lot more use and respect, and even the industry at large is now funding research and development into it.
There is change happening. It just needs encouragement.
The proliferation of bespoke sample players has solely been for commercial reasons, though. For example, a company receives outside money, say Spitfire; the investors ask if the company owns all their own IP; a discussion ensues that the company's products require a per-license fee to be protected with the Kontakt Player realm; the investor raises their eyebrows. What follows is pain for the user as developers who've never built a sampler player download JUCE and see what they can do, all making the same mistakes, and taking versions to iron them out much to the annoyance of end users. Plus, there's really not that much innovation that comes out of this... And some of the seemingly innovative aspects of SINE were simply stolen at the behest of one of the celebrity names they have behind some of their products.
I would love to see more change in music and audio, but when the main applications in use are all over 30 years old, you have to wonder. Cubase started in 1989 on the Atari and became reborn as Cubase SX 1.0 in 2002, Logic was released by Emagic (after the separation with C-Lab) in 1990/91 and purchased by Apple in 2002, Pro Tools also came in 1991, based on the earlier Sound Tools products, and so on...
Also, it's depressing to think how much exciting research existed in this field in the 80s that still hasn't come to fruition. Look back at Stanford and CCRMA, the close ties to Lusasfilm Computer Division, NeXT, etc... Michael Hawley who is sadly no longer with us, even talked about creating a MusicDroid (like SoundDroid and EditDroid) for John Williams to be able to prototype orchestral scores.
Surely for something truly innovative to happen, we need bigger truly revolutionary thoughts along these lines, not just another plug-in format. That's kind of boring, to be honest. Surely with developers like Urs and others can think of something bigger; CLAP seems motivated by developers wanting to unshackle themselves from the hosts they ultimately need to support them, either via wrapper code or native support. It's hard to articulate why this changes the world for the better for an end user who just wants a cool new synth.
I totally agree with most of what you have said, and it would be crazy to expect the world to just change overnight because of a new plugin format.
However, this is another opportunity to allow change - to break the "chicken and egg" situation and unlock the potential for others to come along and ride on that change.
As with any change, it needs support and nurturing to grow and become something that will have a greater impact. It's a foundation to allow more innovation to sit upon without being constrained by licensing and legacy.
This discussion is an excellent point as to why things need to change. The situation as you have so eloquently summarised, is locked-in and controlled by a few big companies, with little space for innovation in the first place.
It may not be a big or rapid change, but it has the potential to make a difference. In the spirit of your sentence:
> I would love to see more change in music and audio
Encourage the change, and don't decide there's no point because of how it's previously been.
> And as for open source, listen to Paul Davis talk about Ardour... For some reason, open source music and audio software has just never become a thing.
Uh, what? When did I say that? That just isn't true.
Apologies, Paul. When I saw your 2017 keynote (https://www.youtube.com/watch?v=dk2AMwc4e2k) from the Linux Audio Conference, you seemed less enthusiastic than in other talks you've given. Maybe I was reading too much into the message you were trying to convey; as I say, apologies if that was the case, I have nothing but respect for your work.
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.
> 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.
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.
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.
Most are quite similar, which is why the vast majority of commercial plug-in developers gravitate to using something like JUCE (or, to a lesser extent, iPlug). Such a framework makes it easy to target a single API and output cross-platform versions for AAX/AUv2/AUv3/VST2/VST3/etc... I have no doubt that JUCE will support CLAP, and therefore make it easier for developers to spit out yet another format.
Alternatively, CLAP could end up as the intermediate format, with bindings supplied for presentation within other native plug-in formats.
VST3 is the one that sticks out like a sore thumb, because it represented a radical change in how the user interface classes interact with the audio processor class. This created a massive problem because you had to assume that the UI and the processor were essentially running in separate processes and communicated via message passing through a specific interface or just plain text. It's the reason why VST3 didn't ever gain the traction and support of VST2, since Cubase was for many years the only VST3 host, and since more complex plug-ins like, say, Kontakt, would require a huge amount of developer time to upgrade, a stalemate existed for too long. So it's hard to see everyone getting behind yet another format to support and test, especially if the core code has to conform to the lowest common denominator, as it were.
On closed vs. open, although AU is controlled by Apple, and VST by Steinberg, they are both open to the point that anyone can download required SDKs and develop for them. Avid traditionally kept their SDKs through application forms and NDAs, so not everyone had access. Even now, IIRC, JUCE doesn't come with the AAX bindings necessary to build such a plug-in, they have to be copied in from the official distribution.
> VST3 is the one that sticks out like a sore thumb, because it represented a radical change in how the user interface classes interact with the audio processor class. This created a massive problem because you had to assume that the UI and the processor were essentially running in separate processes and communicated via message passing through a specific interface or just plain text.
Adding VST3 support to Ardour/Mixbus, we did not experience this as a notable issue at all.
Far more problematic from a hosting perspective in VST3, though it has also been present in AU since the start, is multi-bus output. At the "processing audio" level, it's still pretty simple, but "allow the user to connect stuff" level, its far from simple, unless you just do what reaper has done and flatten all the busses.
VST2 was not "open" in a way that made it usable by libre software developers. AU doesn't really matter much since it's single platform.
I think it is also important to stress again that most plugin developers that do this stuff for anything close to a living have not targetted specific plugin APIs for years. As you noted, many will use a framework like JUCE, others have their own in-house equivalent, which lets them create the DSP and GUIs in a plugin-API agnostic way.
> Adding VST3 support to Ardour/Mixbus, we did not experience this as a notable issue at all.
Not as a host; but this was a major stumbling block for more advanced plug-ins like, say, Kontakt. Given that VST3 was based on VST-MA (largely the work of one of the original Studio One authors), which is derived from Steinberg's COM-like interpretation, there were some genuine pain points for plug-in developers.
But I think your point about the framework approach is a reason against having yet another API to spit out. As you say, developers who do make a living out of this, aren't going to be able to dig their heels in and say "it's CLAP or nothing if you want to run my wares." I imagine it would be suicide for smaller developers like Fabfilter or Valhalla. And if CLAP is just another API supported in branch of a framework, where is the "killer application/plug-in" going to come from?
I think VST3 shows how well this is going to be received. Nobody was keen on VST3 from the start, and AFAIK this wasn't to do with philosophical objections to commercial licensing. It was largely due to the fact VST2 worked well enough, was understood, supported, and nobody saw the point in adopting it. The fact Steinberg had to deprecate 2.4 and then announce they were going to end-of-life support for it in their own applications to convince market forces says it all. Even when Doric came out a few years ago, in v1.0 only VST3 was supported. But they quickly backtracked and added whitelist support for VST2 plug-ins.
> there's a reason why music and audio applications and plug-ins remain the most heavily copy-protected software.
This is sadly true. I used to make a bit of music and I knew several people who would simply hoard pirated plugins and sample libraries, even if they'd never use them. I think it's an extension of "gear acquisition syndrome".
When even Kanye has been caught pirating plugins, what hope do vendors have.
Are you the same kibibu who made a bunch of Buzz plugins? Because I used them. Somewhat on topic, the Buzz audio plugin format is some single-header sweetness.
Disagree. Musicians like their platforms, but they also go where the good sounds are. There will be third party wrappers for CLAP plugins that will allow them to work in Logic or Cubase, and if high quality CLAP plugins are available (highly likely given U-he's stellar DSP record) then people are going to want to use them.
> ...if high quality CLAP plugins are available (highly likely given U-he's stellar DSP record) then people are going to want to use them.
And with Arturia onboard as well, who besides their V Collection are now making officially licensed Korg virtual instruments. (This week's Arturia user survey questions suggest that more official Arturia Korg collaborations are on the way.)
And of course there's TAL & Valhalla as well, who both make fantastic stuff, but Arturia is a much larger company.
If they could convince iZotope, Native Instruments, Waves & IK Multimedia to migrate to CLAP, I think that would cover everything else I need.
Yes for some reasons the audio world doesn't speak much about figures: cost of development, revenue etc.
There is a huge market of let's say $25-$50 plugins that serve the amateurs just as well the pros and the former have been pushed out of ProTools for a while now, so I'm not so sure AAXs beat VSTs nowadays, but hard to argue volume or revenue without the data.
Clap won't succeed longterm because of many of the factors outlined in so many of these posts. Notably, Apple aren't going to support it in Logic because Audio Units work just fine, and AUv3 spans both iDevice and Mac markets. Steinberg almost certainly won't support it; they aren't even allowing VST 2.4 plug-ins to run in the Apple Silicon version of Cubase -- and this isn't for technical reasons. Ironically, Steinberg have been trying to push VST 3 since the release of Cubase v4.1 back in 2006, and it's still a giant pain 16 years later. If you look back at VST 1/2, part of the allure was the simplicity of the API; VST 3 tried to change the game too much towards MVC given that it looked at the time you might want to run the processing part of the plug-in on a different system than the user interface part.
Pro Tools doesn't get a mention in this thread, for the most part, but for better or worse it remains something of standard in audio post-production in the US. AAX isn't a bad re-imagining of what what RTAS/TDM-based plug-ins pre v10, and Avid aren't going to relinquish any control to third parties. Not least because the need for AAX (such as it is) resolves around support for the company's hardware control surfaces. EuCon was originally envisaged as an agnostic hardware controller protocol by Euphonix, but Avid purchased Euphonix, released the S6 and associated controllers and made EuControl into something of a tolerated illegitimate child.
Plug-in developers will have to follow the money, and I would to see the results of a survey correlating money spent on plug-ins based on the main host software used. My guess is that Pro Tools AAX on the Mac probably is the most lucrative, followed by Cubase and Logic. Depressing, but for all the moaning musicians tend to indulge in regarding fair compensation against any company they feel exploited by, there's a reason why music and audio applications and plug-ins remain the most heavily copy-protected software.
I don't know of anyone who's ever ditched their host application because of a plug-in format, and I highly doubt the CLAP is going to harm Apple, Steinberg, and Avid in the longterm.