I so totally hate installers...!

[Fabian]

<BEGIN RANT>
I so totally hate plugin installers that do not do what they are told and install stuff all over the place just because the programmer thought that he/she should control me and what I do with my computer!

This just happened. And I did it twice just to check, so it is not pilot error.

I downloaded a new version of a plugin I have paid for, and I ran the installer. The install wizard opened, and asked me to put in the path to where I wanted to install the plugin. So I browsed to my plugin folder D:\Plugins and the installer showed me D:\Plugins\ThisPlug.

Looked fine so far; clicked Next.

A new dialog popped up asking me where to install the VST2 32-bit dll, default to C:\Program Files (x86)\Steinberg\VSTPlugins. But I do not need the 32-bit version on my 64-bit system at all so I set that to install into B:\Temp. Why could I not skip this part? And why wasn't the default related to the path I set on the first dialog?

Probably fine so far; clicked next

A new dialog popped up asking me where to install the VST 64-bit dll, default to C:\Program Files\Steinberg\VSTPlugins. Here I go "What was it that I was asked to install on the first dialog? Hm... maybe that was the vst3-version then". So I set the path to D:\Plugins\ThisPlug. Why would I have to do this again?

Hoped for the best; clicked next.

A new dialog popped up where I now could choose which plugin versions to install, 32-bit VST2, 64-bit VST2, 32-bit VST3, 64-bit VST3, 32-bit RTAS, 32-bit AAX, 64-bit AAX? So I unchecked all except 64-bit VST2 and 64-bit VST3. Why was this not the first dialog?

Crossed my fingers; clicked next.

A new dialog popped up where I was asked to select start menu folder. Why on earth...? This is a plugin! I'm not going to run it from Windows Explorer or command line. What would it need a start menu folder for? Leaving it blank was no option, so it stayed at the default.

I cursed; clicked next.

A new dialog popped up with the title "Ready to install". I browsed through all the info there and it looked correct.

Didn't pray, but close to it; clicked Install.

Install proceeded, but of course I did not get what I expected.

The 64-bit VST2 installed where I wanted it, but... The 64-bit VST3 got installed in C:\Program Files\Common Files\VST3\ThisPlug.vst3. On top of this, inside my D:\Plugins\ThisPlug I get a whole bunch of unins000.* files! WTF! I don't want those. Now I have to manually hunt around and clean things up!

So instead of a two minute download and drop the *.dll and *.vst3 in folder of my choice, and hit re-scan in Reaper, I have now fiddled with this for more than half an hour. And yes, part of that I spent writing this, but I just could not go back to making music...
<END RANT>

Thanks for listening. This kind of therapy is priceless

EDIT: And on top of it all... the first thing that happens is that the plugin crashes Reaper!
#¤%!&§!½åäö Good night.

And it crashes Reaper consistently! Simply load it on a track and hit play, and BOOM Reaper crashes!

[EvilDragon]

VST3 plugins have a FIXED location per Steinberg's SDK, which is in Common Files/VST3. That's where they are expected to be.

[karbomusic]

Originally Posted by EvilDragon

VST3 plugins have a FIXED location per Steinberg's SDK, which is in Common Files/VST3. That's where they are expected to be.

And...

On top of this, inside my D:\Plugins\ThisPlug I get a whole bunch of unins000.* files! WTF! I don't want those. Now I have to manually hunt around and clean things up!

There may be some files that require registry entries or something else related to the plugin such as... Those unins000 files tell the installer how to properly uninstall it. If you clean all that up, you are hosing the uninstaller. I agree on a 1 DLL = 1 plugin mantra but if that isn't how that plugin operates, you are likely making things worse by manhandling those seemingly unimportant files.

[brynolf]

I recognise that exact install procedure from many plugins. It's probably some Steinberg standard. And yes, it's dumb.

[LightOfDay]

Originally Posted by Fabian

<BEGIN RANT>
I so totally hate plugin installers that do not do what they are told and install stuff all over the place just because the programmer thought that he/she should control me and what I do with my computer!



...


Didn't pray, but close to it; clicked Install.

not to pray is a mistake. it doesnt help, but it doesnt hurt anybody and who knows? maybe...

you are right. that all is disgusting. everytime I ran into this bullshit I would like to hurt someone really bad. (though I never did that because I never got close enough to the right person...)

[xpander]

Haha, rant right on time Fabian. I've just been through a bunch of new plugins to test and been bugged by some of the install procedures. It's not just that some of the steps are seemingly unnecessary like when only wanting the 64-bit versions. But the order is ass backwards with many of them, imho.

Only one from the lot asked right away what bit versions I want and the folder settings after that were just for the given choice. Like usual, all the others made me go through all the folder options first and then choose whatever actually gets installed. Tired enough I finally left one without my usual 32-bit folder choices, thinking ahead that it wouldn't be needed anyways. Couldn't fool that one, for some reason it decided to install all, only that now the 32-bit versions had to be hunted down separately. Great, thanks.

Yea, some of that stuff like the default VST3 install folder is what it is. But some seem to need some changes.

[ivansc]

Hopefully the Steinberg-imposed default location for VST3 stuff will stick and we might finally see an end to this folderol, but I doubt it.
And of course all your old stuff wont obey this relatively new "standard".

Shame as there is of course already a VST2 folder in the common files directory, too...

[karbomusic]

Originally Posted by EvilDragon

VST3 plugins have a FIXED location per Steinberg's SDK, which is in Common Files/VST3. That's where they are expected to be.

Hmm... I wonder what some creative 'mount pointing' might result in.

[Lawrence]

It might not work at all. That is to say, because developers know where VST3 plugs are supposed to be, they might not scan anywhere else for them.

Indeed, the only path settings for vst plugs (haven't checked Reaper) are for vst 2.x and if it's only looking for *.dll's there it won't locate any vst3 plugins.

[karbomusic]

Originally Posted by Lawrence

It might not work at all. That is to say, because developers know where VST3 plugs are supposed to be, they might not scan anywhere else for them.

Indeed, the only path settings for vst plugs (haven't checked Reaper) are for vst 2.x and if it's only looking for *.dll's there it won't locate any vst3 plugins.

A mount point or better stated symbolic link would hide that fact, it would appear as the exact right path to any software but it would actually be somewhere else. They would still scan the common files/VST3 directory but that is only a symbolic representation that the software has no idea about; it just thinks that's the right place to be but in reality, the underlying data is say D:\Plugins\VST3:

https://technet.microsoft.com/en-us/...rnals/bb896768

[Lawrence]

Ah, I got ya. Thanks.

[karbomusic]

Originally Posted by Lawrence

Ah, I got ya. Thanks.

I'm sure it could be more trouble than it's worth but was a nice side thought.

[xpander]

This must be also plugin dependent. I have had few VST3 plugins in my portable install and unless I dreamed it, I used them on hosts which certainly haven't had any plugins installed on them. Cant test that atm.

[SonicAxiom]

I usually drag & drop plug-in installers into Sandboxie first and then look into Sandboxie's files and folders view to get an idea of where files would be saved during a real install and then I decide wether I re-run the installer outside of Sandboxie or simply restore the required files from Sandboxie manually and put them to the location I prefer.

[CrimsonFlak]

Originally Posted by EvilDragon

VST3 plugins have a FIXED location per Steinberg's SDK, which is in Common Files/VST3. That's where they are expected to be.

Yes, Common Files\VST3, not C:\Common Files\VST3. My OS isnt on drive C, stop making folders on drive C mickey fickey.

Please, Reaper, please never lose your portable install option.

[Lawrence]

Originally Posted by xpander

This must be also plugin dependent. I have had few VST3 plugins in my portable install and unless I dreamed it, I used them on hosts which certainly haven't had any plugins installed on them. Cant test that atm.

Looks like Reaper's scanning is universal. It picks up Span VST3 here in my regular VSTPlugins folder. Not sure how many hosts do that.

[Lawrence]

Originally Posted by CrimsonFlak

Yes, Common Files\VST3, not C:\Common Files\VST3. My OS isnt on drive C, stop making folders on drive C mickey fickey.

Well, on Windows it's actually \Program Files (or x86)\Common Files\VST3.

[Fergler]

I use and .exe extractor now to grab the .dll out of most installers, way faster and less hassle. I only use the VST2 64bit versions of any plugin I get (or 32 if that's available only).

Also if you want to uninstall afterwards to clean up, just move the .dll files you want out of their original folder, and run something like Geek uninstaller, then move the files back where you want them.

[Heart Doctor]

@Fabian (original poster):
First of all, I understand your frustration. I wish that all plugins would be delivered in a Zip file containing just the DLL files. You extract the one you need (VST2 or VST3, 32-bit or 64-bit) and place it where you want it. Done, and no confusion.

Unfortunately, sometimes the architecture around a plugin is more complicated. Registry entries must be made by the installer. Files related to the plugin must be stored somewhere. These files can be the uninstaller, help files, and sometimes other stuff.

Originally Posted by Fabian

The install wizard opened, and asked me to put in the path to where I wanted to install the plugin. So I browsed to my plugin folder D:\Plugins and the installer showed me D:\Plugins\ThisPlug.

This was a mistake. The installer wanted to know where to place the "program" files related to the plugin. Most likely this path starts with "c:\Program Files\", followed by manufacturer name and then the product name. You should have accepted this path as suggested by the installer. The uninstaller and the help file (PDF) will be stored in this folder.

In the next step you can select where to store the VST2 plugins. However, the installer does not ask where to store the VST3 plugins because this path must be "c:\Program Files\Common Files\VST3" on any Windows PC. Steinberg invented VST3 and wants it that way.

If the VST2 plugin did not end up where you wanted it, you can simply move it to the correct folder later on.

In case of VST3 you should not move any plugins outside the VST3 folder. But you may create subfolders inside the VST3 folder for better organization and move the plugins there.

NOTE:
If you move any DLL files (*.dll or *.vst3) manually, they will most likely not be found and removed by the uninstaller later on. After running the uninstaller you must delete the DLL files manually.

[Fabian]

Thanks people for all the input.

I really thought I was going to be seriously flamed for this post; I'm glad it didn't happen

And, though I think this installer business is a sad state of affairs, I'm sort of glad that I am not alone with being annoyed by it.

The plugin I'm talking about is a spectrum analyzer with no saveable settings (in fact, this is another annoyance with it, it always starts up in default mode and has to be fiddled with), so it should have nothing to save in the registry or anywhere else. Thus, installing is really overkill. Uninstall would and should be as simple as deleting a directory.

And, just as xpander points out, first asking for a bunch of install paths, only then ask for what to install is really, really backwards.

As for vst3... Voxengo's Span works fine with span.vst3 moved from the Common Files\VST3 directory into its own dir under D:\Plugins, so why should this one crash? Reaper 5.11/x64, portable install, sure does not by default look into that Common Files\VST3 directory...

Anyways, as I said, this kind of therapy on this forum is priceless
Thanks all.

[kenz]

Originally Posted by ivansc

Hopefully the Steinberg-imposed default location for VST3 stuff will stick and we might finally see an end to this folderol, but I doubt it.

I completely disagree. That is the single worst thing about the entire VST3 spec from a user point of view. I absolutely hate this dumbed down shit which most likely came from OS X. It's my computer, I want to be in control of it. My hard drive, I put the files where I want, period.

I hate the registry and I hate all the "common" or "shell" folders (i.e My Documents etc). I don't hate them for what they are, I hate the fact that I have no choice if said software uses them.

Meanwhile, as usual, people who don't care can always use the retarded default location, so they have the choice. But like everything in life when it's about what I want, I get the middle finger while I never take away choice from others. (but they think it's cool to impose their crap on me, "cause it works for them" or "for the greater good" in their viewpoints, since it doesn't affect them, who gives a shit of others' preferences or usage right? and thus retarded installers were born that give you no options! I have nothing nice to say to Steinberg in regards to this)

Sorry but I'm quite sick of this non-portable crap.

/rant off

[Lawrence]

Pointless rant. Like I suggested earlier, it seems to be more a guideline than anything madatory. If Reaper can load VST3 plugins from any folder, anyone else could also if they choose to.

It's the - developers - who may or may not restrict you to that location by only scanning for VST3 plugins in that location, and nowhere else. If it was forbidden by Steinberg, or not possible to load them from anywhere else, Reaper wouldn't be doing it.

We do love to rail against Steiny though.

[Bjorn218]

Your plight isn't so bad. Try installing one where it asks where to install the plugin directory which goes where you want it but no dll's get installed there, nor in the standard default locations but elsewhere, then having to hunt for files you don't know the name of. Only to find they are put in a user/app data/common file directory with no sub directory for that plugin.

[karbomusic]

That is the single worst thing about the entire VST3 spec from a user point of view.

Steiny did that before with Program Files\Steinberg\VST et al. Caused lots of issues since that's a protected location. They tried to fix it by moving to \Common Files but that doesn't really fix the underlying issue - it's a mixed bag because for every one computer savvy user, there are ten more musicians who have no idea and need something 'common' that is default.

[serr]

Originally Posted by Fabian

<BEGIN RANT>
I so totally hate plugin installers that do not do what they are told and install stuff all over the place just because the programmer thought that he/she should control me and what I do with my computer!

I hear ya.
As a Mac user with that sentiment, I fire (as in "you're fired!") plenty of software I believe violates this rule.

But sometimes you have to pick your battles!
This is one of those times IMHO.

Plugins have 'standard' locations. Organization in a good thing sometimes. Install to the standard location (/Library/Audio/Plug-ins/ and then the appropriate folder (VST, Component, etc) in OSX - probably something similar in Windows) and all audio apps know where to look.

Yes, you can change it and then point all your audio apps to the new spot (assuming they all have the flexibility of Reaper for that). But that's kind of like moving the mountain! For this one, just install them to the standard location and use features in Reaper (or other apps) to "organize" them into subfolders and so forth for display purposes as desired.


Does the installer for Google's web browser app (Chrome) still install an app (allegedly a software updater helper app) unannounced and hide it deep in the Library and further inside a bundle for a different item so you can't search for it? And the thing calls home every 20 minutes!

That's the kind of thing that sets me off!

[bladerunner]

I can't help but think there's essentially something very bogus about this idea of 'it's my computer so I want control of it'. This would imply that you would have to have total and complete knowledge over every aspect of your computer. Do you have total control over your OS files? Do you know why they're all where they are? It might just be that you don't personally understand why what files go where - and kneejerk reacted to this?

[noise_construct]

Originally Posted by bladerunner

I can't help but think there's essentially something very bogus about this idea of 'it's my computer so I want control of it'. This would imply that you would have to have total and complete knowledge over every aspect of your computer. Do you have total control over your OS files? Do you know why they're all where they are? It might just be that you don't personally understand why what files go where - and kneejerk reacted to this?

It's a VST plugin so it and all it's files need to go to it's own folder inside the VST plugin folder structure I made.

Installers should be illegal tbh

[karbomusic]

Originally Posted by noise_construct

It's a VST plugin so it and all it's files need to go to it's own folder inside the VST plugin folder structure I made.

Not quite correct, if you have a VST that creates lots of settings/libraries/presets, Reaper's load time may eventually skyrocket because it has to ask the OS to enumerate the VST directories, which means it is wasting time enumerating files that aren't VSTs; which makes the end-user think Reaper is stuck scanning actual VSTs when that isn't really the case. The VST DLL should be separate from all the non-VST files typically.

Many installers try to account for this (rightfully so), hence the reason to point the settings/help/presets etc. to a different location than the actual VST. In such cases where licensing components aren't in the mix, installers are nothing more than file copiers which also keep track of where those files went in order to remove them later. All users (especially DAW users) aren't computer experts.

So, you can make the folders yourself but the best way to do it is make one for the VSTs and one for the meta data that is outside the main scan path.

[Fabian]

Originally Posted by bladerunner

I can't help but think there's essentially something very bogus about this idea of 'it's my computer so I want control of it'. This would imply that you would have to have total and complete knowledge over every aspect of your computer. Do you have total control over your OS files? Do you know why they're all where they are? It might just be that you don't personally understand why what files go where - and kneejerk reacted to this?

For me it is a matter of collecting the stuff (data, dll's etc) in places so I know where they are, so I can easily keep or take the stuff with me when I (re-)install the OS. This is why I have a special drive D: that contains all that stuff (or I want it to contain, but as we know I have to fight some developers over this). This is also why I only use the portable install of Reaper, and most other SW's that I use on this machine.

I built this computer myself, selected the components carefully, put them together, installed the OS on a clean drive, tweaked it to my liking, measured DPC latency, RAM voltages etc, etc...

The OS comes first, I let it do its thing and abide by it, but the rest I want control over. Some installers I have to accept (Chrome, VirtualBox, Reaper portable), but very few; if it comes with an installer I usually do not want it. In this particular case the plugin came from what I regarded as a trustworthy source.

[noise_construct]

Originally Posted by karbomusic

Not quite correct, if you have a VST that creates lots of settings/libraries/presets, Reaper's load time may eventually skyrocket because it has to ask the OS to enumerate the VST directories, which means it is wasting time enumerating files that aren't VSTs; which makes the end-user think Reaper is stuck scanning actual VSTs when that isn't really the case. The VST DLL should be separate from all the non-VST files typically.

Many installers try to account for this (rightfully so), hence the reason to point the settings/help/presets etc. to a different location than the actual VST. In such cases where licensing components aren't in the mix, installers are nothing more than file copiers which also keep track of where those files went in order to remove them later. All users (especially DAW users) aren't computer experts.

So, you can make the folders yourself but the best way to do it is make one for the VSTs and one for the meta data that is outside the main scan path.

The scan time of a few folders is absolutely irrelevant in all realistic situations with current SSDs, and software loading in itself is meaningless.

[karbomusic]

Originally Posted by noise_construct

The scan time of a few folders is absolutely irrelevant in all realistic situations with current SSDs, and software loading in itself is meaningless.

It's the contents of the folders, metadata matters far more... as in 50,000 1 byte files will take forever to enumerate but 1 50k file will take microseconds... start around post 56 (then 68) since that is precisely what I described above because enumerating directories means enumerating their contents:

http://forum.cockos.com/showthread.php?t=162215

As soon as ED moved all the non-DLL files (patches in this case) out of the VST scan path, problem solved.

[kenz]

Originally Posted by noise_construct

It's a VST plugin so it and all it's files need to go to it's own folder inside the VST plugin folder structure I made.

Installers should be illegal tbh

^^ Exactly this.

As for Windows, no I don't know everything about it, but why should I? It's not the plugin's files itself I want to reposition unless they get put all over the place. Plugins are obviously separate software.

I want all files in ONE folder and one folder only. So I know that is exactly what the plugin is. Delete it? Just delete the folder.

Backup? Copy the folder. One click, one push of a button, everything is done. No need for any stupid backup software!! Hassle-free.

I'm baffled why in this day and age portable apps are still not the norm and enforced. They're the literal definition of convenience and ease-of-use for anyone who has the slightest clue of their filesystems.

But I forgot, there's people who don't even know what a folder is.

EDIT: To add to that, by "backup" I mean literally run it from the backup, external drive, USB stick, whatever. No "absolute paths", those are bad!

As to how Reaper or other software can find these... very simple, relative paths.

[Lawrence]

Installers should be illegal tbh

I wouldn't spend much time worrying about it. In some cases you can simply unzip an install.exe and pull whatever you want out of it. Or run the installer, copy what you want, and then uninstall it... and put the dll's wherever you want.

Seems like such a trival thing to obsess or rant over.

Saying that it should be "illegal" (?) for a developer to create the kind of installer he wants is kinda... silly? If a company's installer annoys you that much, stop buying their products.

[noise_construct]

Originally Posted by karbomusic

It's the contents of the folders, metadata matters far more... as in 50,000 1 byte files will take forever to enumerate but 1 50k file will take microseconds... start around post 56 (then 68) since that is precisely what I described above because enumerating directories means enumerating their contents:

http://forum.cockos.com/showthread.php?t=162215

As soon as ED moved all the non-DLL files (patches in this case) out of the VST scan path, problem solved.

I have all my plugin stuff including the few presets I've saved and manuals inside the same structure, REAPER still starts up in a few seconds. Guess it's different for preset users with folders full of them.

[noise_construct]

Originally Posted by Lawrence

I wouldn't spend much time worrying about it. In some cases you can simply unzip an install.exe and pull whatever you want out of it. Or run the installer, copy what you want, and then uninstall it... and put the dll's wherever you want.

Seems like such a trival thing to obsess or rant over.

Saying that it should be "illegal" (?) for a developer to create the kind of installer he wants is kinda... silly? If a company's installer annoys you that much, stop buying their products.

I wouldn't spend that much time worrying about what other people do, especially if you miss the joke

[Lawrence]

Originally Posted by noise_construct

I wouldn't spend that much time worrying about what other people do, especially if you miss the joke

I'm not. It's a discussion and it seems way overblown because...

1. Reaper loads VST3 from anywhere anyway... and...
2. Ranting all day doesn't make Steiny do anything, ever... and...
3. It takes all of 5 minutes to work around it.

Install it, copy your plugin files, uninstall it. Now you have all of your plugins files to put wherever you want. Is that really so hard? (assuming registration isn't based on install)

Or is it easier to make every plugin developer on the planet bend to your personal preference?

But sure, keep ranting about Steiny. I'm sure they'll do exactly what you want any day now.

[karbomusic]

Originally Posted by noise_construct

I have all my plugin stuff including the few presets I've saved and manuals inside the same structure, REAPER still starts up in a few seconds. Guess it's different for preset users with folders full of them.

It depends on the amount etc., if you don't have any issues I wouldn't worry about it but since there have been multiple threads on the issue over the past couple years, with unknown root cause (until now), I always mention it so that everyone reading these threads will be aware.

[karbomusic]

I want all files in ONE folder and one folder only.

That's fine but the way Reaper calls into Windows to enumerate VST directory contents to see if it needs to update the cache; if there are lots of small files the enumeration can take a very long time during startup. This is NOT actually loading DLLs, it is simply enumerating the folder contents which requires reading the metadata of every file in the folder. You can test this outside of reaper, just create a script that creates 100k tiny files of a few bytes, open that folder, CTRL+A - go get coffee because its going to be quite awhile. There is an FR to disable that pre-scan but for now, it's something to be aware of just in case.

Personally however, I prefer manuals/presets etc. to not be in the same directory as the executable which in this case is a DLL YMMV.

[Fabian]

Originally Posted by Lawrence

Install it, copy your plugin files, uninstall it. Now you have all of your plugins files to put wherever you want. Is that really so hard? (assuming registration isn't based on install)

This is exactly what I eventually did, but I had to hunt around for where things were installed. However, the vst3 version of the plugin crashed Reaper every time I hit play. So it is not that easy, though I agree that it would be an acceptable work around.

And no, registration is not based on install in this case; the plugin was registered.

[karbomusic]

But sure, keep ranting about Steiny. I'm sure they'll do exactly what you want any day now.

With VST being open for implmentation, there must be some fallback/common location mechanism... because (especially in the early days) a musician installing a DAW and VSTs must be assumed to be clueless about computer inner workings. Not because they all are but because some will be (and that should be OK) and there must be some mechanism that assumes 'a caveman can do it' successfully. I don't see a problem with Steinberg trying to achieve some semblance of commonality and success for the end users who overall should be able to be musicians first computer experts distant second.

That idea that a non computer expert should be able to successfully use a product should take precedence over the testosterone laden super user who has masculinity issues. I'm joking but sometimes the "this is my god damn computer" attitude is missing the big picture entirely.

The only place Steiny did sort of screw the pooch was the first time around where they used Program Files\Steinberg which is a protected location. I'll give them slack because it wasn't enforced back then but it was a best practice back then - there is a tiny exception that Win98 which still shared user and kernel modes and was strictly home user may not have had that practice meaning I'd have to look it up but otherwise, this is old news going back at least that far on the windows 2000/XP side anyway.

All that being said, some installers piss me the f'k off as well. Many times installers need as much attention to detail when being created as the thing being installed, yet the programmer never takes it as seriously as the app itself. That sucks and is almost always obvious.