CLAP... thoughts?

[Kalamata Kid]

Not sure if this can be implemented in the CLAP spec but always liked a single click to update a plugin.

[DRMR]

Not sure if this can be implemented in the CLAP spec but always liked a single click to update a plugin.

This has nothing to do with the plugin format. The format defines how plugins and hosts interact, nothing more and nothing less.
How a vendor packages, distributes, installs, and updates a plugin is their business and is done irregardless of which formats they ship.

[Urs]

There's a draft for a "check for updates" extension. Plug-Ins can not access the internet per sé, so that's something that might make sense to add to the format, because the host can.

[EvilDragon]

IMHO Would be great if the plugin had developer keywords for what it does.
Compressor, reverb, delay, midi fx, arp, sample based instrument, utility.
But then also allow for the user to add keywords.

CLAP already has such metadata. User keywords is something DAW should handle, not the plugin.

[baconpaul]

Not sure if this can be implemented in the CLAP spec but always liked a single click to update a plugin.

This has nothing to do with the plugin format. The format defines how plugins and hosts interact, nothing more and nothing less.
How a vendor packages, distributes, installs, and updates a plugin is their business and is done irregardless of which formats they ship.

We have actually thought about this and have a draft `check-for-update` extension here

https://github.com/free-audio/clap/blob ... r-update.h

This allows a plugin a uniform way to advertise that it has updates available, and allows the host to redirect you to an appropriate URL when they are. With that you could result in a single host action to ask your plugins (1) do you know about updates and (2) if so do you have any then offer to take you to the location advertised by the format

[DRMR]

Interesting. This requires some "phone-home" functionality on the plugin side though (which not all users appreciate). It at least makes the discovery of such updates a shorter path, even though it still requires several manual steps from the user.

(the request specifically was about single-click-updates integrated with the plugin, which doesn't make much sense. but what you propose would be a kind of "minimal" way to at least provide update information)

[vurt]

Interesting. This requires some "phone-home" functionality on the plugin side though (which not all users appreciate). It at least makes the discovery of such updates a shorter path, even though it still requires several manual steps from the user.

(the request specifically was about single-click-updates integrated with the plugin, which doesn't make much sense. but what you propose would be a kind of "minimal" way to provide update information)

a lot of plug ins already have this as an option, you choose when to update, bit the button is there on the plug in "check for updates".

[Urs]

This requires some "phone-home" functionality on the plugin side though

This functionality actually requires *no* phone home functionality on the plug-in side.

Instead, it offers a very transparent process for hosts doing this work through an open source API, which should create confidence that no personal data is sent through this channel of communication.

Therefore it removes the necessity of a plug-in "to phone home" when checking for updates.

[Tim Janik]

There's a draft for a "check for updates" extension. Plug-Ins can not access the internet per sé, so that's something that might make sense to add to the format, because the host can.

The current draft version seems to imply that the plugin accesses internet locations on its own:

Code: Select all

// host queries:
clap_plugin_check_for_update->check(plugin,include_preview=true);
// plugin replies:
clap_host_check_for_update->on_new_version(host, update_info);

It'd be nice if internet traffic was left to the host, but then the spec would get a lot more complicated, since it'd have to specify *how* the host has to contact an update server and how to parse replies, etc.

[DRMR]

It'd be nice if internet traffic was left to the host, but then the spec would get a lot more complicated, since it'd have to specify *how* the host has to contact an update server and how to parse replies, etc.

This was my point as well. I don't see how a Host could do all such communication. Many plugins require all kinds of custom licensing and authentication schemas with external resources (now, these already have such "phone home" functionality. integration with the host is then just an extra way to unify behaviour and notifications).

[wuworld]

Maybe Steinberg will take some ideas to use in VST 3 or a future product from clap?

[Funkybot's Evil Twin]

I would have rather named it CRAP ( CReative Audio Plug-in API )

That thread is here: viewtopic.php?t=583507&start=30

[donquixote]

one day one file to load on any system, my wish, thanks

[rasmusklump]

Ffs is it so hard to understand?

[fisherKing]

one day one file to load on any system, my wish, thanks

don't hold your breath. that's like wishing for a microsoft/apple merger (well, maybe in a hundred years).

it's a nuisance (more for the developers than than the enduser), but we seem to manage with the formats we have now. still, hopefully, clap will be everywhere (except, sigh, in logic).