It brings a certain amount of pain to my head to think that we are adding yet another format to the pile that has to be debugged and maintained along with all the others.
VST2 is not completely dead yet which tells me that for the next 10+ years we will probably still need to support some VST2, VST3, AU, AAX and now, CLAP.
As a plugin user I really wish developers would spend their time fixing what’s already out there rather than be distracted by supporting a new format. I have purchased many existing format plugins that don’t work right!
For those of you who jumped into the CLAP pool - what is the cost/benefit and why do we need it?
It’s a little unclear whether your concerns are about the cost to individual users, or to the iPlug2 project here, but hopefully the below might give some context to both, as I am the person who has done the vast majority of the CLAP work.
CLAP has some interesting features that are not available in other formats, such as per-note or channel modulations. To start with iPlug2 will not support some of those features, because the focus has been on parity with other formats. It also has a clear system for adding extensions, with the expectation that software can choose to support particular extensions or not.
The main objectives of it’s core developer and other interested parties is to have a sustainable fully open source format that is not controlled by a commercial entity who can dictate when formats should be changed.
IPlug2 has gained (or rather will gain as there are a few things to review before it is merged into the main branch) CLAP support through direct funding - it is contract work paid against hours that adds another option to iPlug2 - unusually I don’t normally know how much work any particular aspect of iPlug2 has taken, but in this case it is a relatively modest number of hours. There are currently no DAWs supporting CLAP that do not support other formats. In terms of whether to build for CLAP with iPlug2 it should be a small amount of work to get the same level of functionality to the other formats, but you don’t need to add that format to your builds if you don’t want to. Therefore, I would see it as non-issue for those that wish to ignore it. For others it gives an additional possibility.
What do you mean by “adding extensions”? What is an example of an “extension” to a plugin?
That sounds like a good idea but how does anyone know today what will be required tomorrow that may require a format change? Seems like that problem isn’t solved. Next there will be a “CLAP 2”, etc.
BTW - I know we don’t have to include CLAP versions of plugins - or any other format - but if people start asking for it then we kinda do have to or they’ll go somewhere else.
If people ask you for CLAP plugins then the work to produce them should be minimal if you are just using core iPlug2 functionality. This format has been written more or less “in-one-sitting” (conceptually if not in actual time) with the benefit of experience of the other formats, and using a glue layer provided by the CLAP main developer, and it so is relatively clean. I am fairly confident that the code is at least as consistent and well-reviewed as other formats, and probably more so.
Effect plug-ins can also make use of modulations - as I mentioned the focus of iPlug2 so far is not on the new features so I have not spent lots of time with those things that are new, because the first step is to have CLAP support that equals other formats.
I would say that is where the extensions come in - these are not extensions to a plugin - these are extensions (added features) for the CLAP format. In fact in CLAP many things that you might consider basic to plugin development are extensions (examples are things like plugin channel configs / latency reporting / custom state etc.) Because of the way the format has been written it is fairly trivial to add further extensions in future - so the format is designed more around extensibility than other formats (which have tended to hive off extensions into a small part of the API). I would not argue that CLAP solves all the issues of plugin formats in the past, but it is more open - and the main developer has been active in engaging with outside thoughts on its development. The API/ABI are also modern C for the maximum interoperability (rather than C++ which has more features as a language but might exclude some developers).
As with many things software-wise I personally am not (mostly) in the business of trying to convince people to use certain things - but hopefully that is a bit more info about how CLAP works and what it is trying to do that might be useful.
Reaper 6.71 is now released with CLAP support. You can now try the Martinic Kee Bass CLAP Edition v1.2.0 alpha6 build with an IPlug fork that supports CLAP.