Reaper will skip folders set to "hidden" in windows during plugin scan. As far as I remember this works for Blue Cat plugins.Funkybot's Evil Twin wrote: Wed Jun 15, 2022 2:23 pm Every time I launch Reaper for the first time each day, it has to scan each file in the BlueCat resource folders in my VST Plugins folders.
Windows Installer criticism
-
- KVRAF
- 1626 posts since 28 Jan, 2004
-
- KVRer
- 11 posts since 1 Sep, 2014 from UK
Just wanted to chime in on the install paths element of this thread, although I am beginning to think it may be slightly off topic, or worthy a thread in its own right.
I am entirely against manufacturer specified install paths. Some users/devs may like the operational simplicity of that, but the point made earlier is valid - our experience of multiple DAW/editors, and 600+ plugins from devs of all levels of proficiency and user interest, is that pro users NEED this flexibilty, usually to get around all such dev arguments and opinions.
Our studio has multiple networked PCs, so we want one systemised layout of files, folders, automated back ups, hard drive swap strategies, that as much as is possible, which we as the studio choose. I would not trust the dev community as a whole to agree on what's best. It is not possible for a dev to know, understand, accommodate nor care about that system, nor can they - it's regimented and tuned to our specific systems layout.
For example, we have fast 4Tb SSD D: drives specifically for large sample libraries on removeable drives for performance, and in case we need to move the estate of samples between PC platforms, least a PC go over in a session, and we rapidly need to move an install. That is not everyone's need. But a dev insisting an install is in a fixed location on a fixed drive would deny us that strategy as a business. We would, in time, move away from those plugins, because in our case, our failover strategy is more important than any particular dev's insistence on a C: drive installation. The ONLY thing which should be on a system SSD is the system. I would much prefer plugins/licenses/data/libraries were on removeable drives, in case of failure.
Copying DLLs twice a year? That completely disregards the cumulative effect of putting that on a user where large estates are concerned. Plugin maintenance across our networked systems is a major source of pain month to month. It's not two updates per maker, but a monthly scheduled activity across many supplier companies. And the variation in dev approaches (and even attitudes) to install, maintenance, update... is wild.
Simple things, like unassisted installs using a "repeat what I told you last time" would make a big difference. Arturia is a negative case in point, with 8 manual clicks x27 plugins monthly is a royal waste of my time, all because of minor patches to code that probably should have worked in the first place...
Other devs insist you reinstall 500Mb when the DLL has had 2 tweaks. And install everything again, make those manual install decisions again, because the installer app did not save any preferences from last time around, or because somehow there's a license tick needed? Since last time we did this?
So, devs - stick to what you are good at, which is DSP, samples, and GUIs. When it comes to install location, feel free to suggest defaults, but you let me worry about where to put your code, samples, settings files. You're all just plain awful at installers and updates. You can't even agree with each other half the time. How can you possibly know what is best for the spectrum of users who have to live with your choices?
Fixed install locations? Bin.
I am entirely against manufacturer specified install paths. Some users/devs may like the operational simplicity of that, but the point made earlier is valid - our experience of multiple DAW/editors, and 600+ plugins from devs of all levels of proficiency and user interest, is that pro users NEED this flexibilty, usually to get around all such dev arguments and opinions.
Our studio has multiple networked PCs, so we want one systemised layout of files, folders, automated back ups, hard drive swap strategies, that as much as is possible, which we as the studio choose. I would not trust the dev community as a whole to agree on what's best. It is not possible for a dev to know, understand, accommodate nor care about that system, nor can they - it's regimented and tuned to our specific systems layout.
For example, we have fast 4Tb SSD D: drives specifically for large sample libraries on removeable drives for performance, and in case we need to move the estate of samples between PC platforms, least a PC go over in a session, and we rapidly need to move an install. That is not everyone's need. But a dev insisting an install is in a fixed location on a fixed drive would deny us that strategy as a business. We would, in time, move away from those plugins, because in our case, our failover strategy is more important than any particular dev's insistence on a C: drive installation. The ONLY thing which should be on a system SSD is the system. I would much prefer plugins/licenses/data/libraries were on removeable drives, in case of failure.
Copying DLLs twice a year? That completely disregards the cumulative effect of putting that on a user where large estates are concerned. Plugin maintenance across our networked systems is a major source of pain month to month. It's not two updates per maker, but a monthly scheduled activity across many supplier companies. And the variation in dev approaches (and even attitudes) to install, maintenance, update... is wild.
Simple things, like unassisted installs using a "repeat what I told you last time" would make a big difference. Arturia is a negative case in point, with 8 manual clicks x27 plugins monthly is a royal waste of my time, all because of minor patches to code that probably should have worked in the first place...
Other devs insist you reinstall 500Mb when the DLL has had 2 tweaks. And install everything again, make those manual install decisions again, because the installer app did not save any preferences from last time around, or because somehow there's a license tick needed? Since last time we did this?
So, devs - stick to what you are good at, which is DSP, samples, and GUIs. When it comes to install location, feel free to suggest defaults, but you let me worry about where to put your code, samples, settings files. You're all just plain awful at installers and updates. You can't even agree with each other half the time. How can you possibly know what is best for the spectrum of users who have to live with your choices?
Fixed install locations? Bin.
-
- KVRAF
- 24415 posts since 7 Jan, 2009 from Croatia
That is wishful thinking. Many, many programs even outside of audio plugin world don't give you an option where to put them at all. Stuff like Slack, Discord, even Visual Studio, install parts of their dependencies all over C: drive. This is just a tip of the iceberg.
But anyways, and as already mentioned, even in your large estate case, you can just use symlink from your D: drive to the fixed path that i.e. VST3, AAX and CLAP use. Problem solved and it took a whopping minute to do.
-
- KVRer
- 11 posts since 1 Sep, 2014 from UK
The Visual Studio IDE and its libraries are not bound to the C: drive, they merely install there by default, and there are a plethora of options for installing things where you wish. There is nothing preventing you installing it on another drive.
The whole point of .NET was to allow side by side code based on folders, to get away from DLL dependencies. The path and environment variables need to reference the location of the libraries as for any compile/link process. So there is nothing innate about the IDE, or the libs, or development process that forces a dev to make assumptions about the production environment in which an app will run, in fact it is best not to. Creating installs from VS allows you ship your referred libraries along with application code anyway. So not seeing that as limitation where plugins are concerned. if you have such a dependency, politely put, your app is probably not finished.
Yes sample libraries, wavetables. Anything requiring fast sample reads. But also patches where possible too, and settings files, plugin preferences, any user specific customisations. It would simplify back up and failover if they were all just folders on removeable drives, in our use case. There are some performance advantages to having DLL code on the C: drive split away from the data elements, as the idea is to keep streaming and system drive accesses as separate as possible.
If the sym link idea was practical we'd have done it. If the updater/installer ignores it and places code/data where it wants, it creates a maintenance task which would not exist in the first place if installers simply stopped insisting upon C: drive installs and fixed folder paths.
Elephant in the room is that if apps used the registry properly the code and data could live anywhere on the entire network. That would at least allow for uniform and scriptable maintenance.
Speaking to your inner dev, a fixed location is a code smell. Offer a default value, yes, make it law, no.
Bin fixed locations.
The whole point of .NET was to allow side by side code based on folders, to get away from DLL dependencies. The path and environment variables need to reference the location of the libraries as for any compile/link process. So there is nothing innate about the IDE, or the libs, or development process that forces a dev to make assumptions about the production environment in which an app will run, in fact it is best not to. Creating installs from VS allows you ship your referred libraries along with application code anyway. So not seeing that as limitation where plugins are concerned. if you have such a dependency, politely put, your app is probably not finished.
Yes sample libraries, wavetables. Anything requiring fast sample reads. But also patches where possible too, and settings files, plugin preferences, any user specific customisations. It would simplify back up and failover if they were all just folders on removeable drives, in our use case. There are some performance advantages to having DLL code on the C: drive split away from the data elements, as the idea is to keep streaming and system drive accesses as separate as possible.
If the sym link idea was practical we'd have done it. If the updater/installer ignores it and places code/data where it wants, it creates a maintenance task which would not exist in the first place if installers simply stopped insisting upon C: drive installs and fixed folder paths.
Elephant in the room is that if apps used the registry properly the code and data could live anywhere on the entire network. That would at least allow for uniform and scriptable maintenance.
Speaking to your inner dev, a fixed location is a code smell. Offer a default value, yes, make it law, no.
Bin fixed locations.
-
- KVRAF
- 24415 posts since 7 Jan, 2009 from Croatia
This is not my experience at all, with over 400 different plugins installed. Each and every one of them installed just fine through the symlinked location. All VST3s that I have are on D: and any updates install just fine on D:. C: is entirely bypassed (apart from symlink existing in the place of VST3 folder).S9DD wrote: Thu Jun 16, 2022 9:43 amIf the sym link idea was practical we'd have done it. If the updater/installer ignores it and places code/data where it wants, it creates a maintenance task which would not exist in the first place if installers simply stopped insisting upon C: drive installs and fixed folder paths.
It is true though that some plugins absolutely put their resources elsewhere on C: drive (like ProgramData, AppData/Roaming or even AppData/Local sometimes). Guess you could just symlink those as well, if you're really adamant about that (but the whole point of Roaming is that you'd have that one synchronized with a server or cloud backup, anyways).
-
- u-he
- 30208 posts since 8 Aug, 2002 from Berlin
Would anyone be concerned if I moved the Installer-debate into its own topic? It's completely unrelated to CLAP and it just distracts from beta testing our CLAP layer, and its implications.
-
- KVRAF
- 24415 posts since 7 Jan, 2009 from Croatia
Fine by me!
-
- KVRer
- 1 posts since 16 Jun, 2022
After years of lurking, the install path location topic has finally got me to register. It probably should be moved to a split thread though so the actual bug reports don't get buried.
The first answer given regarding customer support I just think is incredibly tone deaf and very business-first orientated. Such a decision being made purely on a customer support basis... You may call people who want to do custom paths as dinosaurs but I can guarantee there is still a considerable number of these and with this decision it just feels like you are gatekeeping them away from this new product. It's like some weird backwards DRM.
Why not just have a predefined install path location but have the option under a checkbox or something to be able to change that? So it's not confusing for the novice user but still there for those who know where to look? This feels like forced-innovation akin to what Apple pulls with their products when it is not needed.
The first answer given regarding customer support I just think is incredibly tone deaf and very business-first orientated. Such a decision being made purely on a customer support basis... You may call people who want to do custom paths as dinosaurs but I can guarantee there is still a considerable number of these and with this decision it just feels like you are gatekeeping them away from this new product. It's like some weird backwards DRM.
Why not just have a predefined install path location but have the option under a checkbox or something to be able to change that? So it's not confusing for the novice user but still there for those who know where to look? This feels like forced-innovation akin to what Apple pulls with their products when it is not needed.
-
- u-he
- 30208 posts since 8 Aug, 2002 from Berlin
I'm starting a new topic to consolidate the discussion of u-he installer paths on Windows.
(gotta figure out how to move posts... will try my best)
(gotta figure out how to move posts... will try my best)
-
- KVRAF
- 2674 posts since 18 Mar, 2006 from The Void
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 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.
-
- u-he
- 30208 posts since 8 Aug, 2002 from Berlin
To the contrary. If anything, the number of people who contact our support is and indicator of how well (or not) a system works. Fewer customer support incidences correlate with more customer happiness.toandfrom wrote: Thu Jun 16, 2022 12:36 pmThe first answer given regarding customer support I just think is incredibly tone deaf and very business-first orientated. Such a decision being made purely on a customer support basis...
Customer happiness is the main goal in pretty much everything we do. It is aligned with our own interest: Happy customers, happy company.
But let's visit pure company interest for the fun of it: I think the general person who checks out a demo does not necessarily contact customer support if the demo doesn't work. Most commonly they delete the demo and will never think about out again. If one only out of 20 people have some crazy outdated registry entry that puts VST in C:\Program Files, many plug-ins will simply crash because (against all odds) Windows has changed over time. From a business perspective, that's one employee less from lost sales. And I believe that it's merely one out of 5 people who have those prehistoric registry entries.
Anyhow. If people really need to move their stuff wherever they want, good, they can do it. If asking them to do it themselves is a burden, we'll happily provide a .bat script that does it for them (I have no idea how these work, and I guess I'll get angry looks from my devs, but d'oh... I guess it should be possible, no?)
Deal?
-
- KVRAF
- 9560 posts since 6 Jan, 2017 from Outer Space
In this case I would call it “never change a winning team”.Teksonik wrote: Wed Jun 15, 2022 4:15 pm So from the end users perspective we've gone from Steinberg telling us where to install VST3 to you telling us where to install CLAP. That's not progress in my opinion.
On mac we had never the choice to move the location to a different place. Which is good! And for those power users who know how to set a symlink its even not a restriction…
Allowing to confuse the normal user with choices wouldn’t be a progress, it would be the opposite…
-
Funkybot's Evil Twin Funkybot's Evil Twin https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=116627
- KVRAF
- 12469 posts since 16 Aug, 2006
Agree, as a Windows user that recently got his first Macbook, I was pleasantly surprised at how tidy and well thought out the file structure was on MacOS. Plugin files and resources just goes where they belong with little to no input from users. This is U-he specific, but I love the Application Support\Themes folder where all themes go regardless of U-he plugin. Whereas in Windows it's under [plugin].data\Support\Themes\. I don't know if there's a technical reason for the difference, but overall, I find that all my Mac applications and plugins are much more well organized than Windows. And I see it as a good thing.Tj Shredder wrote: Thu Jun 16, 2022 1:20 pmIn this case I would call it “never change a winning team”.Teksonik wrote: Wed Jun 15, 2022 4:15 pm So from the end users perspective we've gone from Steinberg telling us where to install VST3 to you telling us where to install CLAP. That's not progress in my opinion.
On mac we had never the choice to move the location to a different place. Which is good! And for those power users who know how to set a symlink its even not a restriction…
Allowing to confuse the normal user with choices wouldn’t be a progress, it would be the opposite…
-
- KVRian
- 1213 posts since 25 Dec, 2018
OK folks. CLAP is an open standard with a spec. That spec explains how it works. It seems like an awful lot of you are saying things about how CLAP works without having read the spec, which is making this thread pretty heated, and full of some rather excited posts which are a bit wrong.
So first things first: here is the CLAP spec on where plugins can live. https://github.com/free-audio/clap/blob ... ntry.h#L12
I implore you to go read that before reading on.
OK so now you've read it you can see a couple of things
A well behaved CLAP host will read a couple of default locations and will also read the list set up in the users CLAP_PATH environment. I do not know if the current hosts do this, but if they don't, you should file a bug report with the host to not ignore CLAP_PATH. A host could, i suppose, let users pick other paths. I might try and make the case that that's a bad behavior, but it's pretty convenient as a dev, so lets leave that aside.
So now what should an installer do
Clearly if the user has not set the CLAP_PATH environment variable, the installer has two options
1. Install in the standard locations, since CLAP_PATH is not set or
2. Ask the user for a custom location and also modify the system environment to add that to CLAP_PATH
Both of those are correct. But just install some place without modifying CLAP_PATH seems wrong. And item 2 is certainly a feature not a requirement.
If CLAP_PATH is set, you could imagine an installer prompting you with the list of choices in your CLAP_PATH and installing there. I don't know if any installers do this yet. I know the Surge installers don't (and moreover I'm a mac user and innosetup confuses me so I'm not sure how to make them do this). But that would be a valid behavior.
But it's certainly not the case the CLAP dictates where to install plugins with no user control. It's been in the spec since day one. As we are, literally, 28 hours post launch it may be the case that some betas need to adopt, and Urs may choose to not read CLAP_PATH in his installers or Surge may not be able to figure it out. But I think some of the (frankly) pretty rude and nasty comments here could have instead been a bit more informed by simply reading the spec.
Which, of course, is one advantage of an open standard.
So first things first: here is the CLAP spec on where plugins can live. https://github.com/free-audio/clap/blob ... ntry.h#L12
I implore you to go read that before reading on.
OK so now you've read it you can see a couple of things
A well behaved CLAP host will read a couple of default locations and will also read the list set up in the users CLAP_PATH environment. I do not know if the current hosts do this, but if they don't, you should file a bug report with the host to not ignore CLAP_PATH. A host could, i suppose, let users pick other paths. I might try and make the case that that's a bad behavior, but it's pretty convenient as a dev, so lets leave that aside.
So now what should an installer do
Clearly if the user has not set the CLAP_PATH environment variable, the installer has two options
1. Install in the standard locations, since CLAP_PATH is not set or
2. Ask the user for a custom location and also modify the system environment to add that to CLAP_PATH
Both of those are correct. But just install some place without modifying CLAP_PATH seems wrong. And item 2 is certainly a feature not a requirement.
If CLAP_PATH is set, you could imagine an installer prompting you with the list of choices in your CLAP_PATH and installing there. I don't know if any installers do this yet. I know the Surge installers don't (and moreover I'm a mac user and innosetup confuses me so I'm not sure how to make them do this). But that would be a valid behavior.
But it's certainly not the case the CLAP dictates where to install plugins with no user control. It's been in the spec since day one. As we are, literally, 28 hours post launch it may be the case that some betas need to adopt, and Urs may choose to not read CLAP_PATH in his installers or Surge may not be able to figure it out. But I think some of the (frankly) pretty rude and nasty comments here could have instead been a bit more informed by simply reading the spec.
Which, of course, is one advantage of an open standard.