FR: VST3? How about CLAP

[mystran]

So that's fine. You can still have portable installations, of course. Just make a symlink at C:\Program Files\Common Files\ that targets your portable destination, name that symlink CLAP, and it's all gonna work.

The point of a "portable installation" is that you plug an USB stick into any random system and stuff works without having to touch the system drive at all... but on the bright side, if some host supports portable installations there's no obvious reason why it can't support additional search paths, because CLAP is a free (as in freedom) standard and nobody's going to revoke your license for implementing extra functionality.

[EvilDragon]

Yes, that's true as well! Just adding another path to the host to search within, and you're portable.

[sl23]

The point of a "portable installation" is that you plug an USB stick into any random system and stuff works without having to touch the system drive at all...

[fde101]

It looks like there's some controversy on forums about CLAP not letting the user select where they install pluggins (like vst3 does).

VST3 evidently does NOT permit alternative plugin installation paths. The standard explicitly forbids it.

The CLAP standard does not initially appear to forbid it, so it should be allowed to use alternative installation paths, but evidently the currently-released plugin installers do not provide the option, so there is some question as to what level of support different vendors will provide for doing so.

[heks]

(like vst3 does) I was rushing and didn't check what I'd written,, yes fde101 your correct, it should have been
(like vst3 doesn't)

[mystran]

The CLAP standard does not initially appear to forbid it, so it should be allowed to use alternative installation paths, but evidently the currently-released plugin installers do not provide the option, so there is some question as to what level of support different vendors will provide for doing so.

CLAP is an open standard ("free as in freedom") which means that it literally cannot forbid anything in any meaningful sense (ie. beyond "please do it this way"), because if you don't like something, you're free to fork a new version that strikes over the rule you didn't like. You'll need to include the original copyright statement as acknowledgements somewhere, but other than that there's no meaningful restrictions on what you can do.

There is obviously little incentive for anyone to make a CLAP fork that's incompatible with everyone else's CLAP versions, but even that's not forbidden. Fortunately, in the case of allowing additional install paths, literally nothing will break.

[fde101]

it literally cannot forbid anything in any meaningful sense (ie. beyond "please do it this way"), because if you don't like something, you're free to fork a new version

If you do that, it won't be CLAP any more. The whole point of a standard is to be standard - to make sure that everyone follows a specific set of rules so that they can communicate effectively. Any deviation from those rules is a potential break with the standard, so yes, it can forbid anything in that if someone does something the standard says not to do, it is not in compliance with that standard.

If someone "forks" the standard to create a new version, then it is in effect a new standard. Something may well comply with the forked standard, but that does not mean they comply with the original one.

[pljones]

Indeed. There are many implementations of the open RFC standards, all competing. So long as they comply with the RFCs, they're "standard". Some are open/free software, some are not. If someone forks one of the free implementations of IPv4 and changes it not to comply with the defining RFC, they're likely to find the choice of compatible Internet sites... somewhat limited. Just as an example.

[mystran]

If you do that, it won't be CLAP any more. The whole point of a standard is to be standard - to make sure that everyone follows a specific set of rules so that they can communicate effectively. Any deviation from those rules is a potential break with the standard, so yes, it can forbid anything in that if someone does something the standard says not to do, it is not in compliance with that standard.

If you don't introduce an actual incompatibility, then you can call you changes an extension for which there is a mechanism anyway (so you can do it without introducing incompatibilities).

Let me specify one: The "alternative install path" extension allows users to optionally choose alternative install paths and hosts to opt into searching such path as configured by host specific configuration. There are no runtime interfaces associated with this extension.

There.. now you can install your plugins where you want.

The point though is that with a free (as in freedom) standard you literally don't need to give a crap about "compliance" as long as you don't break anything. Not breaking anything is obviously on you if you go changing something on your own, but at the end of the day, nobody's going to revoke your license if you do, you'll just have angry users until you fix it. There is absolutely incentive for developers not to change things unnecessarily, but that's not for any silly normative reason, but literally just so that we can have many pieces of software work together nicely.

This is fundamental to anything open source: it's not about rules, it's about getting things done.

[mystran]

Indeed. There are many implementations of the open RFC standards, all competing. So long as they comply with the RFCs, they're "standard". Some are open/free software, some are not. If someone forks one of the free implementations of IPv4 and changes it not to comply with the defining RFC, they're likely to find the choice of compatible Internet sites... somewhat limited. Just as an example.

Actually this is a perfect example, because for an IP stack it isn't really important to exactly comply with an RFC, but rather it is important that your IP stack will properly interoperate with one that complies with the RFCs. This is quite a subtle difference as interoperability requires a fairly high degree of compliance, but if your IP stack supports RFC 3514 and the other one doesn't .. then for the most part they can probably still talk to each other just fine.

edit: On a more serious note, I'm pretty sure graylisting is a direction violation of the SMTP RFCs (you're reporting an error when there is none), yet because it abuses a feature that compliant SMTP implementation can deal with and happens to work pretty well for dealing with spam (some of it anyway), it's very common.

[viceverser]

+1 I'm not a Dev, and I'm sick of the lumbering VST3... I fully support this new standard, and having previously (before discords freedom abuse policy when I deleted my discord account) frequenting the Surge teams group, baconpaul is a really cluey dude, and knowing he and Evil are chipping away at it too, gives me much hope. Exciting to see freedom surviving this hellish technocratic regime.