Windows Installer criticism

[Teksonik]

Huge mistake forcing an arbitrary install location.

Hive CLAP.png

Hive CLAP 2.png

[Urs]

Huge mistake forcing an arbitrary install location.

Your preference is not everyone's preference. If you ask our support team for instance, they'll tell you how much less work they have since we made our installers more restrictive. So for computer savvy people such as yourself it surely isn't a great deal to move a dll from one place to another once or twice a year?

[Funkybot's Evil Twin]

Huge mistake forcing an arbitrary install location.

Your preference is not everyone's preference. If you ask our support team for instance, they'll tell you how much less work they have since we made our installers more restrictive. So for computer savvy people such as yourself it surely isn't a great deal to move a dll from one place to another once or twice a year?

I agree, please for the love of God stick to one location for these plugins and let's just pray Microsoft and Apple don't decide to move those. I know users bitch and moan about VST3 installers that don't allow you to change the path, but how many installation issues get caused by users manually moving things around?

But at the same time, encourage developers to create orderly folder paths that include the vendor name just like you did. Don't install plugins into the root of the Clap folder. Should be:

[System Clap Folder]\[Vendor Name]\

...if the product needs resource folders, those should go into a single shared location (it's a pet peeve of mine BlueCat has individual resource folders per plugin type - inefficient) but if the plugin format itself requires resources and developers insis on being inefficient then the paths should be:

[System Clap Folder]\[Vendor Name]\[Plugin Name]\

...If a user is then savvy enough to need to change the folder, then let them figure out symlinks. But I totally agree in principal, enforce a common path.

And congrats to all involved! That's quite the list of interested parties. If Pro Tools, Studio One, Reaper, and of course Bitwig all support Clap in the near future, I think it will really take off. Thanks Steinberg!

[mudi1974]

Huge mistake forcing an arbitrary install location.

Your preference is not everyone's preference. If you ask our support team for instance, they'll tell you how much less work they have since we made our installers more restrictive. So for computer savvy people such as yourself it surely isn't a great deal to move a dll from one place to another once or twice a year?

As a user I find it actually very nice that e.g. with VST3 the path is fixed and it always works.
If one wants to move it somehwere else one can use a symbolic link, that should work fine.

[Funkybot's Evil Twin]

...if the product needs resource folders, those should go into a single shared location (it's a pet peeve of mine BlueCat has individual resource folders per plugin type - inefficient) but if the plugin format itself requires resources and developers insis on being inefficient then the paths should be:

[System Clap Folder]\[Vendor Name]\[Plugin Name]\

...If a user is then savvy enough to need to change the folder, then let them figure out symlinks. But I totally agree in principal, enforce a common path.

Resources should never be in the main plugin path though. They should be in Program Files or Program Data or maybe even Roaming/AppData depending on the type of plugin (and analogous paths on Mac and Linux)...

Oh, I totally agree but BlueCat doesn’t do this or Acustica. They stick crap (excuse me, “resources”) in the plugin folder. Drives me nuts. If some developers will insist, then they should at least be creating subfolders for their company and then another for each product so as not to create a mess of files in the root folders.

[EvilDragon]

Oh, I totally agree but BlueCat doesn’t do this or Acustica. They stick crap (excuse me, “resources”) in the plugin folder. Drives me nuts. If some developers will insist, then they should at least be creating subfolders for their company and then another for each product so as not to create a mess of files in the root folders.

Oh wow. That is pretty bad. Ugh!

[Urs]

As long as the only thing people complain about are our installers, I think we did something right with the concept of this standard for plug-ins and host. I guess that's why such an amazing number of industry players agree with us, even though we haven't even really started until today.

[zvenx]

Standardized locations for plugins also gets my vote.
rsp

[gnu23]

Finally, I would suggest not making the assumption the user is "computer savvy". Users span the spectrum from novice to pro. Software vendors should take that into account and make things as easy for the user range as possible.

I'd respectfully argue back that is exactly what they're doing: they're making things as easy as possible for all users in that novice to expert range. What that means is having to build for the novice and prevent changes to protect them from themselves. If more "Pro" users want to try their luck with Symlinks or manually moving files anyway, they can try that and hope for the best. But you have to prevent novices from making a mess of things, which means tighter controls.

I understand your points overall. Smaller SSD's as system drives can definitely fill up more quickly. But I think in the grand scheme of things, that's just going to have to be something users need to keep in mind and enforcing the path will do more good than harm.

I understand the counter-position to my view. I'm not going to soapbox it, except to offer two points:

First, the scenario I described happened to me three months ago when I got a shiny new upgrade to my decade-plus (but still working!) system. I'm not sure I am a "pro", but I was able to move everything (and as we all have GAS, "everything" = "oh my God, I had no idea how much that was") to an outboard 8TB SSD, and hack every registry setting, too.

Second, I have experience in ML/AI and am part of a subculture exploring ML/AI art. There is a program out there that eats NVidia 3090's for breakfast and was a highly complex beastie to set up, let alone maintain. Working with his user community, the developer used encapsulation to build in features that allow the user to move the voluminous amounts of libraries anywhere within their system at any time they need to. In-app, all the user has to do is specify the new location and the program does the rest - moves all the environment, support files, ML libraries..tens of thousands of things..and when complete, all the user has to do is restart the program (not reboot the system), and it all just works.

And that's why I offered the suggestion.

Knowing how contentious things can get on KvR, I knew I was taking a chance of getting slagged. But having seen complex reconfigurability work and a developer go the extra mile (and innovate!), I figured I'd risk it and offer my POV here.

Again, congratulations on CLAP.

[Funkybot's Evil Twin]

I understand the counter-position to my view. I'm not going to soapbox it, except to offer two points:

First, the scenario I described happened to me three months ago when I got a shiny new upgrade to my decade-plus (but still working!) system. I'm not sure I am a "pro", but I was able to move everything (and as we all have GAS, "everything" = "oh my God, I had no idea how much that was") to an outboard 8TB SSD, and hack every registry setting, too.

Second, I have experience in ML/AI and am part of a subculture exploring ML/AI art. There is a program out there that eats NVidia 3090's for breakfast and was a highly complex beastie to set up, let alone maintain. Working with his user community, the developer used encapsulation to build in features that allow the user to move the voluminous amounts of libraries anywhere within their system at any time they need to. In-app, all the user has to do is specify the new location and the program does the rest - moves all the environment, support files, ML libraries..tens of thousands of things..and when complete, all the user has to do is restart the program (not reboot the system), and it all just works.

And that's why I offered the suggestion.

Knowing how contentious things can get on KvR, I knew I was taking a chance of getting slagged. But having seen complex reconfigurability work and a developer go the extra mile (and innovate!), I figured I'd risk it and offer my POV here.

Hope you didn't feel like you were being slagged on my account. I definitely see where you're coming from and respect your viewpoint. In a perfect world, what you're suggesting could be done and implemented in such a way that even novice users couldn't mess it up.

[ThomasHelzle]

I think the question is, how relevant something is for a given task.
In the ML/AI case, yes, those files will get enormous and the probability is high, that one needs to move stuff to a different drive more than once.
In the case of plugins and the drives available these days, I can't see this as a huge thing for 99% of the users.
So what should dev resources be spent on.

I'm not against the idea and love devs who offer me the choice, but I only have a custom VST2 folder since I had to, VST3 I just leave alone (and I also know what GAS is ).

I'd still say, that for those in need, moving the files or using junctions is an available solution, you could even automate it with a script.

At this moment in time, with a very first release of a new standard, I'm not sure I would raise it to the top
There are some much more exiting things in the works.

Cheers,

Tom

[Teksonik]

Huge mistake forcing an arbitrary install location.

Your preference is not everyone's preference. If you ask our support team for instance, they'll tell you how much less work they have since we made our installers more restrictive.

Your preference is not everyone's preference.

So you are more concerned about how much work your support team has than how much work your paid customers have to do in order to workaround your arbitrary install path or how much freedom your customers or potential customers have?

Ok whatever. That tells me all I need to know.

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.

I have had a custom install folder for my VST2 plugins for over 20 years and have over 600 plugins installed. If you're saying I'll only have to move a .dll "once or twice" a year (that may or may not break the installation depending on the developer and support files etc) then you're saying that the CLAP format is not going to be popular enough to even concern myself with so I'll just wish you good luck and move on.......

[SLiC]

Yep...VST2 offered flexibility, perhaps a bit naively - but hey, it was new and we were young! This created support issues, installation issues, version mismatches, etc. More modern formats (VST3, AAX, AU) have gotten away from that approach and use fixed paths. Not unique to CLAP.

Yup, of all the problems in the world a fixed install path isn't one. I guess people who don't like fixed install paths cant use VST 3 either! Personally I like VST3 all going to the same place and can't wait to delete my 'custom' VST2 folder...no more 'oh look, I have a Steinberg folder to delete again

It would be a very strange reason to walk away from one of the most interesting things that happened to the VST world for a long time and it was all developed free of charge and open licence for our benefit...

[JamminFool]

Personally, I prefer the fixed directory for VST3 over having to make sure that every VST2 installation ends up in the correct directory.

this.

[PieBerger]

Huge mistake forcing an arbitrary install location.

Your preference is not everyone's preference. If you ask our support team for instance, they'll tell you how much less work they have since we made our installers more restrictive.

Your preference is not everyone's preference.

So you are more concerned about how much work your support team has than how much work your paid customers have to do in order to workaround your arbitrary install path or how much freedom your customers or potential customers have?

Ok whatever. That tells me all I need to know.

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.

I have had a custom install folder for my VST2 plugins for over 20 years and have over 600 plugins installed. If you're saying I'll only have to move a .dll "once or twice" a year (that may or may not break the installation depending on the developer and support files etc) then you're saying that the CLAP format is not going to be popular enough to even concern myself with so I'll just wish you good luck and move on.......

Dont be a detractor. A lot of work has gone into this, and it will be a benefit for many. What have you done in life?

KVRers gonna KVR