Windows Installer criticism

[zvenx]

Baconpaul, I do not know what your day job is, but you have to be great at it i am sure....
If there was a person on the internet vote you would get one of my votes.

you are always:
courteous, patient, logical, knowledgeable, and timely.

Thanks for this clear explanation.
rsp

[Funkybot's Evil Twin]

Thanks baconpaul! I echo zvenx's sentiments.

So to summarize to make sure I'm understanding this correctly. Just sticking to Windows for now:

1. The "pre-defined" CLAP paths are:

// - %CommonFilesFolder%/CLAP/
// - %LOCALAPPDATA%/Programs/Common/CLAP/

2. Users can create an additional CLAP_PATH variable that can be a different folder.

Question: is that a registry entry on Windows?

3. A host should always read the 2 pre-defined paths and also ideally the variable CLAP_PATH folder (if not reading the clap path, file a bug report with the host)

4. If a CLAP_PATH is not set, plugin installers will use one of the default directories. Though they have the option of allowing a custom install location, but if they do that, they should write that custom location into the CLAP_PATH variable.

Question: I imagine that's a "best practice" and there's no way to actually enforce that. Is that right?

5. If a CLAP_PATH is set, plugin installers should...

Question: what should they do here? Should they default to the CLAP_PATH, use the default path, or offer options? Or can each developer chose what their installers will do? Again, I'm assuming there's no way to enforce things when it comes to individual developers installers.

I imagine some installers will just use one of the default paths and ignore CLAP_Path entirely.

...please correct any of that as needed. What I could see as a minor nuisance is that some CLAP plugins will be in CommonFiles\, some will be in AppData\Programs\, and some might end up in the user's variable CLAP_PATH folder. Which I'm concerned is going to result in "where the fudge is this plugin installed to"? It's not the world's biggest problem, there's one of three places it can be, but I think I'd actually prefer more restrictions around install paths if it works how I think it will above. Like why not ditch AppData\ on Windows? That would at least narrow it down.

I'm just thinking out loud here. Definitely hope this doesn't come across as being a stick a mud as I'm 100% on the CLAP train. Just want to avoid some of the common pitfalls I've run into with various places a plugin can end up on Windows based on my VST experiences. It's not uncommon for me to end up in the Reaper Project Bay -> FX tab just to figure out where a plugin.dll is residing on Windows when it's not where I expected it to be. But of course, VST2 has a history of ever changing paths and developers often do their own things.

[baconpaul]

Thank you for the kind words and thoughtful replies.

Clap path is an environment variable yes. That’s the mechanism used to store paths on all our oses and is portably readable. The clap path is not a single path but a list of paths using the os path separator (in windows case ; and in unixes : )

The spec is silent on what installers should do, and only talks about a valid system state. I propose that a good installer leaves your system in a valid state!

So what does that mean? Well it means a forced directory installer is correct (in that it leaves your system in a valid state according to the spec) but other methods are also correct (for instance updating clap path)

If we had a windows user who knew innosetup really well I bet we would merge a change to the surge installer to show a screen where you set paths for installing assets which lets you edit the standalone location (since it is just an exe), let’s you edit the clap but if you do would update clap path (and would seed the default with c:pf if clap path isn’t set and the last element of clap path if it is), make the vst3 non editable (per the spec), put our resources in app data, and provide an option to make portable hard links for each of the plugins. But there’s other choices too.

But the only thing an installer would conclude from the spec is: if you finish an install with the clap in a directory which isn’t either one of the standard directories or in a directory which is enumerated in the clap path environment, you have not done a correct install.

Does that help?

[D-Fusion]

I'm really curious as to why people put VSTs on separate drives ?

I absolutely put samples and other large datasets elsewhere (I have a 4TB SSD that's almost full), but I leave my VSTs on the C: drive for a couple of reasons:

1) If I reformat the C: drive / re-install windows, most VSTs will also need to be reinstalled as they will have registry entries or other specific system ties, so I'll need to re-install or restore a backup anyway.

2) They're generally small, and I don't have much else on the 1TB boot SSD

I guess I can see a use if the boot drive is small, but these days it's hard to find disks that small.

I'm not saying that the installation should be fixed - I agree it should be user-selectable if possible - but I'm wondering what the use-case is when the install size is not particularly large. I know I've likely missed a scenario.

I put Vsts on it's own hdd because i make a disk image so i don't have to reinstall anything if something goes wrong with my System and i only have to do a Recovery which takes under 1 Minute.

Adding More Plugins on my C: Drive will create a bigger Backup Image that will take longer time to Recover.

[EvilDragon]

Question: is that a registry entry on Windows?

Ultimately, yes, but there's a GUI for editing these. Press Win key, start typing "Env", pick "Edit the system environment variables", and you will be presented with System Properties dialog, focused to Advanced tab, at the bottom of which is Environment Variables button. Click that button. Why this doesn't show up automatically is beyond me. Thanks, Microsoft, I guess.

You add a new user variable (or you could even make it system variable I suppose) called CLAP_PATH, and enter the path to your custom CLAP folder in there. Press OK. Done!

[S9DD]

Thanks people. Read what's there and quoted it here:

// Windows
// - %CommonFilesFolder%/CLAP/
// - %LOCALAPPDATA%/Programs/Common/CLAP/
//
// Additionally, extra path may be specified in CLAP_PATH environment variable.
// CLAP_PATH is formated in the same way as the OS' binary search path (PATH on UNIX, Path on Windows).

Quite ambiguous language here though, is that - "extra path" - as in "an extra path", or "many extra paths"? If following Path on Windows, I would think that meant many. [Edit, clarified above.]

Are directories recursively searched? Or is this a flat folder? It would help if sub-directories like "Synth", "Effect", "MasterBus" and within those "<manufacturer>/<product line>/<product version dll>" were possible, to match tricks we learned with VST32/64 and bridged installs.

[baconpaul]

Yes sorry that is documentation which uses a bit of programmer speak.

It is formatted like the os path which means it is a list of directories. The os path is not recursively searched but you are right that the clap spec is silent and therefore ambiguous in this regard. I will raise a GitHub discussion on that issue for a future dot release of the 1.0 spec.

[EvilDragon]

Are directories recursively searched? Or is this a flat folder? It would help if sub-directories like "Synth", "Effect", "MasterBus" and within those "<manufacturer>/<product line>/<product version dll>" were possible, to match tricks we learned with VST32/64 and bridged installs.

This sort of subfoldering is not required with CLAP because CLAP plugins provide this type of info through metadata, from what I understand.

Of course, the onus is on the plugin developer to supply proper metadata that explains the type of the plugin and so on. This is the same situation as with VST3.

[baconpaul]

https://github.com/free-audio/clap/discussions/102 there's a proposal to update the documented spec in a point release. I made concrete proposals for the answers, but there is no guarantee that's what the spec will end up being when we run through a peer review and conversation.

Thank you for pointing out that ambiguity (recursion) and lack of clarity (assuming a definition of a path is understood).

[S9DD]

"Not required" by a host maybe, assuming one version of a file, standardised file names, accurate meta, and bridged versions, no side by side installs.

Tasks like, remove all products by manufacturer N are not so much fun in flat file system. Since automated maintenance is based upon dll specifics and install locations not meta (and VST has an appalling record where meta and file names are concerned anyway), this is asking for trouble. Seems confused to me. File systems work best as hierachies. "Start here" folder references should only provide a root, not be a ticket to ignore sub-folders as a design intention, surely?

Which is why I flagged it up.

[Aspects of Tone]

I put Vsts on it's own hdd because i make a disk image so i don't have to reinstall anything if something goes wrong with my System and i only have to do a Recovery which takes under 1 Minute.

Adding More Plugins on my C: Drive will create a bigger Backup Image that will take longer time to Recover.

On this topic I agree with D-Fusion. I keep my C:drive as clean as possible for the same disk image reasons.

I really get annoyed when several gigabytes of data is dumped on my C: drive making my disk images much larger than necessary, taking longer to create and, if necessary, to restore.

So, please give us the option to install somewhere other than the OS drive. Thank you.

[Tim Janik]

Yes sorry that is documentation which uses a bit of programmer speak.

It is formatted like the os path which means it is a list of directories. The os path is not recursively searched but you are right that the clap spec is silent and therefore ambiguous in this regard. I will raise a GitHub discussion on that issue for a future dot release of the 1.0 spec.

I have had to implement recursive directory tree scanning (writing the CLAP host part of Anklang here), because e.g. the u-he plugins install into subdirectories:

Code: Select all

~$ ls .clap/*
.clap/u-he:
ACE.64.clap
Diva.64.clap
Hive.64.clap
MFM2.64.clap

Now I'm wondering if "hidden" directories should be skipped, like .samples/ - in order to avoid scanning of all plugin internal resource files...

[baconpaul]

Yeah Tim if you can join the GitHub issue I posted above and post that question. I think hidden directories should be skipped indeed but I would rather the spec was unambiguous

[Tim Janik]

Yeah Tim if you can join the GitHub issue I posted above and post that question. I think hidden directories should be skipped indeed but I would rather the spec was unambiguous

Already did

[ThomasHelzle]

Something totally unrelated to the install path/CLAP, but fitting in with the windows installer criticism theme:

Would you please store the plugin formats I installed the last time and restore that selection the next time I install the plugin?
I never use AAX, I no longer use 32 Bit and it would really speed up installing a round of new versions of u-he plugins if the previous selection of formats would be restored. It's getting pretty tedious to set that to the same thing over and over again if you have many of them and none of the presets fit me.
Many developers do that and it makes updating a breeze

Thank you so much!!!

Cheers,

Tom