KVR Audio

CinningBao · Post by **CinningBao** » Thu Jan 21, 2016 4:35 pm

Thanks whyterabbyt and aMUSEd for supporting the idea that we are smart enough to manage our own plugin locations.

It did slip my mind that VST3 is also fixed non-hierarchical location, as is AU. So the newer plugin architectures are building in the limitation as part of the core design. This is when DAWs will need to offer plugin management schemes. And would users want the opportunity to create different plugin hierarchies for each DAW? I suspect not, and this will need some kind of standard all the DAWs manufacturers adhere to. I'll bet this will never happen.

harryupbabble · Post by **harryupbabble** » Thu Jan 21, 2016 6:07 pm

Yeah, some people may want to place their VSTplugins folder(s) on external drive(s) because internal drive(s) can get full or is too small.

Also, if the OS have to be reinstalled, it would be a pain to reinstall all that plugins (10,000+ VST plugins in my case).

Probably about 90 percent of freeware plugins installed on external drives will not need re-installation should the internal drive(s) fail.

do_androids_dream · Post by **do_androids_dream** » Thu Jan 21, 2016 6:40 pm

harryupbabble wrote:Also, if the OS have to be reinstalled, it would be a pain to reinstall all that plugins (10,000+ VST plugins in my case).

I have less than 100!

robotmonkey · Post by **robotmonkey** » Thu Jan 21, 2016 7:38 pm

I'm completely with OP on this. Users should be able to install and move plugins where ever the hell they want. Everyone has their own way of organizing their file structure and I see no reason to limit that. I for example have never installed a single plugin inside Program Files and because of that avoided all the problems related to user rights and the stupid suggestions to disable uac, run your daw as admin and whatever. I absolutely loathe the software that does not let you choose the install location and the content location (in case sample libraries and such are included) during installation.

jancivil · Post by **jancivil** » Thu Jan 21, 2016 7:41 pm

I never had any interest in where the plugins are located, incl. on Windows. My preference in Cubase is sort by vendor and at least w. C5 VST3 is a clear distinction. Beyond that, I'm not typically looking at it. Apparently under Windows there can be the x64 v. 86 distinction and I've seen users baffled re: VE Pro's name for the x64 instantiation. One thing I do have an opinion about is NI installers default to 'Shared' folder for libraries which is extraneous, already there's the Application Support and Documents for Factory v. User saves, on top of Applications. I don't see the point of a Reaktor item (.rkplr->.ens) residing in Shared when the initial Library lives at Applications. If there are vendors creating paths that must be followed, I don't need to care about it.

jancivil · Post by **jancivil** » Thu Jan 21, 2016 7:52 pm

robotmonkey wrote:plugin inside Program Files/all the problems related to user rights and the stupid suggestions to disable uac, run your daw as admin...

I def. would seek to avoid that. Windows for me is 2003-2005 and I didn't run into that. There was one installation (of a demo version) here, OSX where the developer created a need for run as admin (idiotic; no point for it at all here, that's a first: I'm logged in as admin by definition.) which cured me of any desire to demo that thing.

harryupbabble · Post by **harryupbabble** » Thu Jan 21, 2016 8:10 pm

do_androids_dream wrote:

I have less than 100!

Yeah well I bet a few can say "I have less than 10" and may be surprised at your 100. It varies, I guess.

Let me justify my sickness. Hoarding is sometimes good. For example, lately I have been downloading ancient complete Reaper Projects by someone that supposedly mixes/mixed people's songs professionally. Most of the projects require superexpensive UAD plugins!!!!!! but a few also required bootsy's ancient freeware Density.

Anyways, I may never afford those UAD plugins but hey I got version 1 of bootsy's Density plugin... superhard to find, AFAIK. You never know how long these developers are going to be around based on all the RIP threads popping up lately and their creations might RIP with them. Does bootsy himself even have Density version 1 anymore?

I didn't even know that pros uses/used freeware. Who knows what other great plugins I have in my 10,000+ VST freeware plugins collection that are/were used by the pros and are now or just about to disappear.

And not just from C:\Program Files (x86)\VSTplugins.

CinningBao · Post by **CinningBao** » Fri Jan 22, 2016 9:23 am

Thank you all for your interesting words. If any plugin manufacturers choose to use this page as a discussion point, they made a good decision.

There is touch more detail to this which I am not considering for discussion - the location of files external to plugins. From what I understand most companies who require external sample sources offer the chance to install the files on an external drive or alternative folder, or the use of a folder alias to soft-link to the plugin resource.

And since AU and VST3 architecture has fixed folders with no depth, they are excluded as well.

This brief, but polite discussion, has shown a need for both systems. There are those who don't care, and those who, if they couldn't move the files around, would not be able to pursue their interests.

So, this company I have been in conversation with, if you are reading this, this thread may not be the definitive evidence you would need to un-fix the location of your installed plugin. It should, though, provoke a discussion about how you have possibly got this wrong, for the moment.

A message to plugin developers: if you develop for the VST (not VST3) standard (no idea about LADSPA restrictions mind you), please consider that the users may not want it where you put it.

xNiMiNx · Post by **xNiMiNx** » Fri Jan 22, 2016 10:10 am

Heres a tip for vst3 dev's;

Just because the folder location is fixed, doesnt mean the drive letter is too.

Dont create folders on C, if my OS isnt on C.

jancivil · Post by **jancivil** » Sat Jan 23, 2016 12:22 am

In the interest of helping you solidify your case, a couple of points:

CinningBao wrote: There is touch more detail to this which I am not considering for discussion - the location of files external to plugins. From what I understand most companies who require external sample sources offer the chance to install the files on an external drive or alternative folder, or the use of a folder alias to soft-link to the plugin resource.

And since AU and VST3 architecture has fixed folders with no depth, they are excluded as well.

I use several instruments which use samples: Kontakt, Absynth, Reaktor, Battery, BFD2/BFD3, Vienna Instruments. All of these are both AU and VST. I noticed the other day that, on my MBP, the folder Absynth 4 in Applications contained an Alias for Samples. It does not appear to be meaningful per se; I deleted it and then loaded a patch built on samples, no problem.

The installation for the samples-using VST and AU instruments in Plug-Ins is all of it straightforward, no subfolders. The installer of samples provides for other locations than the instrument in every case, AFAIR. So there is no issue at all here. The data paths for BFD's samples are inviolable, however.

The folder VST3 in Plug-ins contains a couple of things w. folders below 'VST3'; one has folders per type of processor below the folder 'MeldaProduction' below 'VST3'. The other is folders for Vienna Ensemble to contain aliases 'Content'. I don't know why, exactly. (The VST3 version of VE (and VE Pro) is the one thing on the planet currently that directly provides multiple MIDI ports in a plugin.) But the VST3 MeldaProduction items reveal in Cubase. The VST folder under Plug-Ins has a couple of items with presets folders below their main folder. One of these has an AU plugin (no subfolder) and loading presets there works the same.

jancivil · Post by **jancivil** » Sat Jan 23, 2016 12:27 am

So, I see the situation with Program Files under Windows that I def. could care about. I do think that with Mac OSX there isn't as much to talk about.

CinningBao · Post by **CinningBao** » Mon Jan 25, 2016 4:37 pm

Thanks jancivil for your Windows-based observations - Looking in my VST3 folder now I notice you mention Melda, I also see the same 'Melda Production' -> 'Pitch Shift' folder structure here. This post https://www.steinberg.net/forums/viewto ... 32#p448958 supports the idea that it _is_ possible to organise your VST3 plugin folders in your file system, but I suspect nothing changes at the host level.

And unfortunately, perhaps because you are a windows user and aren't familiar with the system, there _is_ something to talk about on OSX with VST; the company I am speaking to refuse to acknowledge that they should allow us to move the VST files around our VST folder as we see fit.

As others have said in this thread, until the DAW manufacturers all agree to a standard of organising 3rd party plugins across the hosts, and _not_ a 3rd party app (as I see being promoted here at the moment), I don't believe any VST manufacturers should be forcing us to keep the files we license from them in a fixed location.

NystagmusE · Post by **NystagmusE** » Mon Jan 25, 2016 9:09 pm

In terms of freewares, I always really liked the VST(i) DLL's that don't come with an installer; you just unzip them and stick them somewhere in your VSTplugins folder. That to me is the most stable, sane, and easy approach to VST(i)'s.

Everything else starts to get annoying and makes it harder to migrate the installs if you change operating systems, or have to reformat or move stuff around for other reasons.

I also noticed during past migrations, that some installer-based freeware VST(i)'s don't actually need the installer to do anything in reality. What I mean is that I just archived the DLL's and their related contents and reinstalled the whole operating system and then unzipped the DLL archive back to where it was and the plugins still worked without any registry entries or .LNK files.

Not all plugins work this way; usually the paywares rely upon the Registry and special data folders. But it's at least refreshing that a lot of freewares are easier to cope with.

Also, I like to rename the DLL files and their folders to more sane and normal and easy to read names. Most freewares can be renamed without any problems as long as you use common sense and make sure their dependent folders have the same names.
I've been doing this for years without any issues within Reaper and FL Studio and EnergyXT.

But again, it doesn't work with all of them, and I don't even try to do it to paywares.

But I agree that the end-user should be entitled to put stuff where they want with minimal Registry dependency. But a lot of developers have their own ways of doing things and you can't really mess with what might break the program.

The thing I hate most about installers is that you can never really be sure about what the heck they are doing behind the scenes.
It makes administering a system a bit more difficult and it's a definate vulnerability in terms of malware.

If it's just a zipped DLL with a manual, it's a lot safer and easier. It also reflects that the software creator is using common sense.

jancivil · Post by **jancivil** » Mon Jan 25, 2016 9:35 pm

No, I'm a Mac user. What I wanted to indicate was 1) the Melda installation created a secondary set of directories below Audio/Plugins/VST3 and Cubase reflects it. It was asserted that VST3 won't work with any but a flat one-directory installation which doesn't appear to be true. 1b) The lack of a presets folder for one AU which uses a presets folder for its VST installation results in no functional difference. And 2) that samples directories do not have any real relationship with location of plugins. The Windows default to Program Files and a consequent 'run as administrator' OTOH would mean a concrete reason to create an alternative folder structure. SO, if you approach developers with those 2 ideas there does not seem to be any 'there', there at least as to OSX in my experience. I don't know about differences under Windows except that report in this thread re: Run as admin., which OSX does not cause thru the normal installation of plugins. That is a concrete problem, it looks like. So do what you like but I would focus on what's real if I expected devs to do some work.

Fixed plugin locations discussion