About CLAP

[Music Engineer]

CLAP got news coverage in the German CT magazine:
https://www.heise.de/select/ct/2022/4/2 ... 2792772664

that's great! the CT is germany's number one general computer magazine (at least in my perception), so this coverage there will certainly help to spread the word (at least in germany)

[jalex]

Greetings!
This is an incredibly cool idea to create a truly open and independent standard, I hope you succeed and in the near future we will see this as a matter of course.

I have a question: since I'm not a programmer at all, I'm wondering, in addition to the standard interaction, is there a possibility where some tools control others? as an example of a meta device in renoise.

Thank you for your work!

[Urs]

Greetings!
This is an incredibly cool idea to create a truly open and independent standard, I hope you succeed and in the near future we will see this as a matter of course.

I have a question: since I'm not a programmer at all, I'm wondering, in addition to the standard interaction, is there a possibility where some tools control others? as an example of a meta device in renoise.

Thank you for your work!

I am not familiar with the concept of meta devices.

CLAP plug-ins can send MIDI and audio rate "Control Voltages", so it's ups to the host to offer routing options, and to other plug-ins to receive either. They could for instance offer to turn either into parameter modulation (don't expect this to be polyphonic though).

I also think that, because hosting is so easy - and I know an abundance of examples -, maybe plug-ins that host plug-ins might become more common with CLAP than with standards where writing a host is more tedious (or impossible, as some standards have licenses which forbid that).

[jalex]

for example, I meant a scenario where one tool binds to a third-party delay parameter, for KarplosStrong synthesis. that is, a certain modularity that allows you to extend or create tool interactions. but not like in vcvrack or reason, but on a more elegant version of simple tabs.

the task is quite simple to be able to assemble your own synthesizer from different plug-ins or expand the possibilities.


thanks for answers.

[_gl]

pleased to hear about CLAP today (via Airwindows).

elegant open community standard plugin interface that is governed and can easily translate/wrap to other formats? great.

plugins that a host can enumerate without them initialising a ton of crap, causing obscene and unnecessarily long project load & plugin discovery times? worth the price of admission alone.

take it out of Steinberg's hands? check

cool extra features? great.

the name is fine - BUT searchability matters. I often Google '<plugin name I just heard about> VST' to limit searches usefully, I'm sure most end-users do. That doesn't work with 'CLAP', too generic.

So, just acronymize it to CLP. It sits nicely along VST, AAX etc. and the official pronunciation can still be 'clap'. win/win.

[Tj Shredder]

ClAMP might also work Clever Audio Midi Plugin. It should support natively Midi 2.0 anyway…

[MrJubbly]

Automatic Migration - VST/VST3 to CLAP (Feature Request)

How incredible would it be for users if some specific framework was implemented within CLAP which could allow DAW hosts to 'auto migrate' existing instances of plugins that were previously saved within users projects as VST or VST3, to 'automatically substitute' those for their CLAP equivalents? (wherein those Steinberg audio formats have since been removed/uninstalled from the host devices).

This would allow existing users to simply remove existing Steinberg VST/VST3 formats and replace them directly with matching CLAP equivalents and have the DAW automatically substitute the former for the latter within our existing projects.

This kind of behaviour already exists between VST and VST3 formats within certain DAWs that can 'combine' association between these two plugin formats (so long as the third-party plugin developers have used 'matching' internal plugin IDs within the plugin for both audio plugin formats). For example, developers like Valhalla DSP, Sonic Academy, Applied Acoustics Systems' plugins already support this functionality between VST2 and VST3.

If possible, such implementation could make a mass switchover from Steinberg to CLAP relatively quick and easy for most users. Which is something that the CLAP format will likely need in order to help drive the adoption rate of CLAP from these longstanding rival plugin formats.

[crickey13]

One can dream.

[Music Engineer]

How incredible would it be for users if some specific framework was implemented within CLAP which could allow DAW hosts to 'auto migrate' existing instances of plugins that were previously saved within users projects as VST or VST3, to 'automatically substitute' those for their CLAP equivalents?

that would certainly be very convenient. i think, this is perhaps not necessarily something specifically related to vst -> clap but rather a feature that any daw could implement for any format1 -> format2 mapping, if only it would know the appropriate mapping. maybe such a thing could be realized if someone would set up some sort of plugin database that the daw could tap into to figure that mapping out. different plugin formats use different mechanisms to identify plugins* and after the mapping between different format versions of a given plugin has been figured out, there could still be problems in the next step, namely the state recall, if the format of storing the state data happens to be format-dependent. in vst2 there were two ways of storing state: as a list of parameter values or as an amorphous blob of binary data (called "chunk"), which the plugin itself must know how to interpret. if the plugin in question used the latter (and continues to do so in all other formats), it's probably no problem and state recall will probably just work out of the box. if it uses the former (parameter list), some additional conversion steps for the state data may be required.

(*) for example, clap uses a string (a "URI"), vst2 was supposed to use a 32bit integer (a "uniqueID") to be registered at steinberg, but many not-so-professional plugins didn't actually register their IDs , so the IDs weren't guaranteed to be as unique as intended, so hosts started to use additional information such as vendor- or filenames to uniquely identify plugins - which was a bit messy. so, such a database should store the URIs, the IDs, the filenames, the vendor-names and probably a bunch of other stuff and allow a DAW to look up one (or more) of those things in terms of some others. with this information, a DAW could in principle know what to replace with what

[Urs]

If you browse the Github, I'm sure there is an extension or two that allows hosts to open a project saved with one format (or plug-in) to open with another.

This allows not only the transition from a format to another, it also allows for changes of plug-in name/vendor. It even allows for one plug-in to open the document format of another in existing projects. Think of an abandoned but popular plug-in. If a similar plug-in (e.g. a successor under new name/ID) can open the abandoned plug-in's preset format, projects can be transitioned as well.

This concept is rooted in the idea that the data created by the user belongs to the user, not the companies who provide the tools they used to create them. Document formats are not protected by copyrights for a reason. If a tool can make sense of a document, the user can process that information any way he wants with it.

CLAP fits in with a much larger initiative within the industry to support open standards and exchangeable formats. This goes well beyond plug-in formats.

[Music Engineer]

This concept is rooted in the idea that the data created by the user belongs to the user, not the companies who provide the tools they used to create them. Document formats are not protected by copyrights for a reason. If a tool can make sense of a document, the user can process that information any way he wants with it.

CLAP fits in with a much larger initiative within the industry to support open standards and exchangeable formats. This goes well beyond plug-in formats.

indeed! i also like it a lot when a DAW stores its project files in a human-readable format as opposed to some cryptic proprietary binary format that only the DAW itself knows how to interpret. tracktion/waveform uses some xml-based format, for example (at least, it did, when i last checked - which is more than a decade ago). this allows at least potentially to migrate projects from one DAW to another, perhaps with an automated converter tool, which may be written with reasonable effort. naturally, the "from" DAW will not be too keen on allowing the user to do such a thing. on the other hand, the "to" DAW may actually welcome such a migration option. so, making migration of projects harder or easier (by choosing a (un)readable file format) may actually tell you something about whether a DAW vendor sees themselves more likely to be in the "from" or "to" camp

...and i really don't want to imagine what a maintenance nightmare it would be, if IDE projects for visual studio, xcode, etc. could not be generated by tools like cmake or projucer

[_gl]

i also like it a lot when a DAW stores its project files in a human-readable format as opposed to some cryptic proprietary binary format that only the DAW itself knows how to interpret.

absolutely. Reaper uses XML style project files. I've text-edited projects many times, eg. when I accidentally used a 32bit bridged plugin, and wanted to transparently change to the 64bit version without losing settings. but apart from stuff like that, it also means that a long time into the future these files may still be usuable.

[Music Engineer]

absolutely. Reaper uses XML style project files.

aha - good to know! another thumbs-up for reaper!

[MrJubbly]

If you browse the Github, I'm sure there is an extension or two that allows hosts to open a project saved with one format (or plug-in) to open with another.

This allows not only the transition from a format to another, it also allows for changes of plug-in name/vendor. It even allows for one plug-in to open the document format of another in existing projects. Think of an abandoned but popular plug-in. If a similar plug-in (e.g. a successor under new name/ID) can open the abandoned plug-in's preset format, projects can be transitioned as well.

I know a lot of people here are themselves perhaps developers or industry insiders and so likely have more business-oriented reasons and industry-based perspectives motivating such a switch over to a new audio plugin format. And there is nothing wrong with that. However, from a purely consumer and musician perspective, I can tell you, that it is such user-friendly features as this 'automatic migration' functionality which will be of most practical benefit to customers who actually use your products day-in, day-out. And as such, I believe these kind of compatibility/useability issues should also be afforded a top priority when developing and introducing the newer plugin format to mass market.

After all, we customers simply want to be able to buy our plugins and then use them to make music. The less hassle involved with changing over from one plugin format to another, the better. And what could be more painless than something which helps eliminate most/all of the potential hassles for those users?

For example, when a user loads their projects containing dozens of plugin instances of for example: Zebra, Hive, Diva, etc. The user is likely just thinking about those plugins themselves and are not even that concerned about which particular plugin format happens to be employed.

However, if the proposed CLAP solution can really help developers out, by freeing them from Steinberg's unreasonable control and dictates, more so than continuing to use Steinberg's VST3 or (even) VST would do, then so be it, let's all do that together and let consumer support (i.e. by requesting all our DAW hosts to also support this format) also help push drive adoption rates of that new standard to help out the plugin developers.

And in return, I believe those developers should also go out of their way to make the transition impact as seamless and painless as possible for those end users, who are willing to use the new format to side with the developers' cause. This is why I really hope such 'automatic migration' features and functionality can be implemented. Please give it serious consideration (both DAW and plugin) developers, as it could really help all sides out, to rally around a common cause.

[_gl]

it's a good point, that's why I also suggested CLP to make it searchable for end-users. after all if they don't support the format, it dies, so end-user convenience and perception does matter, not just the development issues.

EDIT: more precisely, without end-user support it might still be useful as the 'root' development format which can still be translated to the others by devs. but full user-adoption would be better, to truly have an open alternative ecosystem that avoids VST altogether in the long run.