About CLAP

[_gl]

in terms of automatic migration of different format plugins to their clap counterparts: does (or can) the API specify a way for the host to pass all the identifying information of other plugin formats to a clap plugin, so that (if the user has opted into this) a compatible clap plugin can automatically replace them?

For example, if a VST plugin used in the project matches the name of a clap plugin, the host could pass all VST-specific identity strings to the clap version (through an official mechanism), which can signal back if it is compatible to replace the VST with itself. That would make auto-migration seamless.

of course some hosts would not want to encourage auto-migration (eg. Steinberg), but the 'cool' DAWs may.

[Music Engineer]

i think, such a feature would have to be primarily implemented by the DAW itself. there could perhaps be some support from the plugin API, to help the DAW to figure out, if the state data that it has stored for the plugin is compatible with the new version or not (and if it isn't, maybe provide a conversion pathway). but without direct support from the DAW, i currently don't really see, how such an auto-migration could be done. the decision, which plugin format to instantiate, is not up to the plugin - that's up to the host. if the host chooses to instantiate a vst version, a clap version cannot just self-instantiate itself instead - that's just not how it works. a plugin doesn't plug itself into the signal path or determines its own identity (i.e. format, in this case). it is created and plugged in by the host. so, it's not about "encouraging" - it's about "allowing"

edit:

if a VST plugin used in the project matches the name of a clap plugin, the host could pass all VST-specific identity strings to the clap version (through an official mechanism), which can signal back if it is compatible to replace the VST with itself.

...ah - wait - maybe i misunderstood you. if you are asking whether there could be some mechanism for the host to ask a clap plugin, if it is ready to replace a given vst plugin (identified by the identity strings, etc.) - such a thing should certainly be possible (and is basically what i meant when talking about state-data compatibility). but of course, the host must first instantiate the clap version instead of the vst version in the first place, which is completely under the host's control

edit2: but wait - such an inquiry mechanism could enable a host to build up the "plugin database" that i was previously talking about itself. and it wouldn't have to be a complete database containing all plugins that ever existed - just those that the users actually have installed on their systems - which are the only relevant ones anyway. this database of relevant plugins would have to be updated (requiring a sort of "re-scan") whenever new clap plugins have been installed and whenever an as-of-yet unknown vst plugin is encountered in loading a legacy project

[carrieres]

Do we have a better handling of MIDI Program Change ?
For example, in diva there is a special folder called ‘MIDI Programs' for PC, do CLAP gives to the end user something better or easier ?

[Urs]

Do we have a better handling of MIDI Program Change ?
For example, in diva there is a special folder called ‘MIDI Programs' for PC, do CLAP gives to the end user something better or easier ?

The general issue that MIDI events happen on time critical threads and therefore a plug-in cannot access the filesystem persists. That accounts for MIDI Program Changes as well as MIDI Learned preset navigation buttons.

We still need to refactor this big time to run in an independent thread, which then means a little latency between event and program change. Then, the plug-in can access the filesystem and the MIDI Programs folder would become editable, and to some degree browsable via MIDI, on all platforms.

[Urs]

(CLAP otoh has a method to expose the plug-in's presets to the host, so maybe that is a thing that might change things for the better in some hosts)

[carrieres]

(CLAP otoh has a method to expose the plug-in's presets to the host, so maybe that is a thing that might change things for the better in some hosts)

voila

[_gl]

The general issue that MIDI events happen on time critical threads and therefore a plug-in cannot access the filesystem persists. That accounts for MIDI Program Changes as well as MIDI Learned preset navigation buttons.

Does clap have a solution for plugin initialisation (samples, lookup tables etc) to happen asynchronously too? DAW projects take far too long to load with many plugins present. It's annoying in the studio, but it's deadly when running a project live that you cannot pre-render. I've had several times where an issue meant I had to reload all my song Reaper projects on stage, and you lose the audience very quickly when it takes minutes.

If plugin initialisation can happen on a background thread, then you can use all your CPU cores to massively speed up the process.

[Urs]

That's beyond my knowledge. I don't see why it wouldn't be doable with any format, as long as multiple instances of the same plug-in get instantiated on the same thread.

[_gl]

edit2: but wait - such an inquiry mechanism could enable a host to build up the "plugin database" that i was previously talking about itself.

I don't see the need for a database. If the host can query if a same-named clap plugin installed on the user's system is compatible with a matching (say) VST plugin in the project, they can negotiate between themselves, on-demand. The host is already aware of all the installed plugins, so it just has to match names, or another agreed upon identifier that allows plugin format matching.

as I said, this would require host support, but if there's an official mechanism for it in the clap interface, then hosts and plugin devs are encouraged to implement this. I doubt Steinberg ever would with their vested interest in VST, but I'm sure hosts like Reaper would.

[_gl]

btw, I saw mention earlier in the discussion that normalized parameter values can be an issue if a plugin decides to change parameter ranges down the line. I haven't released any audio plugins (though I'm working on one), but I've written video editor plugins with the same issue.

my solution to this is to have a hidden parameter that stores the plugin version, which is saved with the project. when a new version of the plugin changes a parameter range, it checks the saved version information, and can then interpret the saved values correctly. it then updates the hidden parameter with the new plugin version, which is saved with the project.

this way you transparently maintain backwards compatibility, and can change parameter ranges at any time.

any reason why this won't work with audio plugins?

[mystran]

my solution to this is to have a hidden parameter that stores the plugin version, which is saved with the project. when a new version of the plugin changes a parameter range, it checks the saved version information, and can then interpret the saved values correctly. it then updates the hidden parameter with the new plugin version, which is saved with the project.

The main problem is not with storing parameter values in presets (which one can easily handle with versioning), but rather with automation. Essentially if you want to preserve whatever automation might have been stored in the host (and you generally can't tell if there's any), then you'd have to put the parameter permanently in a compatibility mode, which kinda defeats the purpose of changing the range and makes everything rather confusing (eg. now you have a different parameter range in an instance loaded as part of an existing project vs. an instance you added with the new version).

[_gl]

The main problem is not with storing parameter values in presets (which one can easily handle with versioning), but rather with automation. Essentially if you want to preserve whatever automation might have been stored in the host (and you generally can't tell if there's any), then you'd have to put the parameter permanently in a compatibility mode, which kinda defeats the purpose of changing the range

right, shortly after posting automation did occur to me too. I guess if a plugin already exists in a project, you could have an 'update' button on it, with a warning that any existing automation will no longer be correct. but unless there's another elegant solution, clap could have some mechanism for that as well, some way to communicate versioning information with the host related to automation. or to indicate to the host that a parameter range has changed, and let the host deal with the translation?

as we're designing a new format, it would be good to address issues like this for everyone's benefit (including end users').

[mystran]

or to indicate to the host that a parameter range has changed, and let the host deal with the translation?

Even if you had a way to convert old values to new values in the plugin API, it still wouldn't really solve the automation issue, because the automation can be in the form of parameteric curves which might have the flexibility to match your new parameter mapping.

That said, as was noted earlier in this thread, the primary problem is not so much with continuous parameters which are the primary candidate for normalized values (since having to change those is not that common if you did your design and beta-testing properly), but rather more so with discrete selections (eg. menus when you add new options), which .. I guess are best solved by just extending the range (which was already cited as one of the reasons for CLAP to allow the plugin to describe it's parameter ranges)

[Music Engineer]

I don't see the need for a database. If the host can query if a same-named clap plugin installed on the user's system is compatible with a matching (say) VST plugin in the project, they can negotiate between themselves, on-demand. The host is already aware of all the installed plugins, so it just has to match names, or another agreed upon identifier that allows plugin format matching.

hmm...but is there such a thing as an "agreed upon identifier" that works cross-format and reliably so? i don't really think so, due to the different identification mechanisms used by different formats. as per the specs, plugins are not supposed to be identified by their name but rather by this "uniqueID" integer in vst and an URI string in clap, so if a host indeed implemented the identification of vst plugins that way (which it probably didn't because of the potential non-uniqueness of uniqueIDs), it would have to know which vst-IDs map to which clap-URIs. but generally, yes, a host could negotiate the replacement on demand with the installed clap plugins, when a project file is loaded. i think of the database more as a cache of these negotiation results because doing it always on demand requires instantiation of all potential replacements (and a database could also support replacements for plugins that don't implement the replacement negotiation if those plugins are added to the database by some other means (like manually or however)). ...but yeah - that's perhaps an unimportant implementation detail of the host and perhaps also a pointless sort of optimization, if we assume that the auto-migration is only invoked once per project and then the migrated project is re-saved.

[_gl]

hmm...but is there such a thing as an "agreed upon identifier" that works cross-format and reliably so? i don't really think so, due to the different identification mechanisms used by different formats.

I see your point. I guess a clap mechanism could optionally allow a clap plugin to register the various VST, AAX etc. identifiers it used in its other format plugins with the host, and then the host can automatically match those.