Are you a plugin nerd? VST2 DLL management…

[TabSel]

Well, I am a plugin nerd. And I am a host nerd.
 
I use multiple plugin hosts, like Cubase, Sonar, Reaper, Live, FLStudio, Kore2, Maschine, VSTForx, Zen, you name it.
I at least try a lot of plugins, whose many many DLLs are available as x32 and/or x64.
I use jBridge, which again creates many DLLs, again in either x32 and/or x64.
And I use Automap, which, again, creates many many DLLs.
 
After trying to somehow manually manage all these DLLs and hosts scan paths and the jBridger utility and jBridges individual plugin bridge settings and Automapped versions and unwrapped versions etc, I found myself managing DLLs more than actually playing with plugins or even making music.
 
The need arose, to manage these DLL files automatically, whenever I install new plugins, or update.
 
I wanted my plugins available sorted into categories in every host.
I wanted to have my plugins named uniquely across architectures (instead of having for example "Tyrell N6" available Cubase x32, but "Tyrell N6 (x64)" available in Cubase x64. I wanted to be able to store presets for a given plugin in for example Reaper x32, and having these presets available in Reaper x64, which isn't the case if x32 and x64 DLLs aren't uniquely named. I wanted to get rid of this "(Automap)" extension to every automapped plugin, again for preset availability reasons, 'cause for example VST3presets in Cubase for "Embracer" are not available for "Embracer (Automap)", and I don't want to have "(Automap)" written all over my host, for convenience. I wanted to be able to sporadically alter the way a given plugin is being loaded in a given host, first trying its own bridge, then jBridge it, to evaluate wether jbridge works better, then automap it, or unwrap it etc.
It is impossible to just rename an automap plugin DLL, it won't work anymore. Even it renaming works for some plugins, it simply became much too complicated to keep track of all this upon updates, having plugins and hosts organized in a consistent, organized way.
 
So I wrote a little tool, which does all that for me automatically now.
It is a vbscript, which scans my installed plugins, let me organize plugins into categories, let me change the names for plugins without even changing anything with the installed plugins, and automatically creates a single VST Scan Path for each Host, containing category subfolders, and containing only ONE DLL for each plugin, either x32 or x64, automapped if you want, jBridged if you want to, to be scanned by the host, so hosts won't be scanning multiple DLLs of different architectures, automapped and native and jBridged and whatnot, with the same VST-ID just be confused which DLL to actually use...
 
With this tool, you simply specify the root folder(s) where your plugins are installed to, be it x32 or x64. If you have automap, simply wrap your desired plugins, automap creates a "… (Automap).dll" along within the original DLLs, no need to move the Automap DLLs anywhere else.
 
The tool will scan all the DLLs and it creates ONE .ini File for each plugin (containing which DLLs actually are available for this plugin, x32, x64, automapped x32, automapped x64 etc.) You can simply put these .ini-Files into subfolders as you like, to categorize your plugins.
 
And the tool then will use this subfolder structure and these .ini-Files, to create ONE dedicated Scan Path per host, with category folders, and ONE DLL per plugin. You simply specify for a given host, which kind of DLL shall be created on default, with the possibility to specify it individually per host/plugin. For example you could specify that Repaer x64's Scan Path should contain the automapped x64 DLL for a given plugin on default, if available. When there is no x64 DLL available, then the Scan Path should contain the automapped x32 DLL on default, Reapers Bridge will bridge it. But for another dedicated plugin, where Reapers bridge fails, you can specify that the Scan Path should contain the x64 jBridge DLL, bridging the x32, as it simply works better…
 
If you made some jBridge settings for a plugin in a given host, and you use the same plugin jbridged in another host, both hosts then can have different jBridge settings, which isn't possible with jbridge alone, currently, as jBridge stores its settings per plugin, but not per plugin/host.
 
 
 
This app doesn't have a GUI, so you will have to specify your plugin installation folders manually in a .ini-File. You have to specify which kind of DLLs you want a hosts scan path to contain by default manually in another .ini-File, once per Host, etc.
 
Once you've made your settings, you simply start the PluginManager.vbs and it will scan your plugin installation folder(s) for alterations and new plugins, offers you a dialog for new plugins to categorize them, and builds host scan paths, which then are used in the hosts. There will be message popup, the tool will inform you about what it's currently doing, but, there isn't a proper GUI to make adjustments for hosts/plugins/scanpaths/settings etc…
 
1) Specify your plugin installation root folder(s)
2) Specify your hosts, you want a dedicated single Scan Path for, containing sorted/categorized plugin DLLs
3) run the script whenever you update, automap (un)wrap or install a new plugin
 
Never ever again bother where to install a plugin, how to separate x32 from x64, how to jbridge, how to automap, where to put all these DLLs.

The script will aid you categorizing new plugins and integrates updates/additions to all your hosts automatically, uniquely named and sorted across architectures and hosts.
 
 
If you are interested, then head over to the cubase forums http://www.steinberg.net/forum/viewtopi ... 19&t=23740 where I provided additional information.
I might upload this small utility (about 40Kb) to my web space, but it's bandwith limited, so if anyone wants to host it, feel free to contact me.
 
 
 

[osiris]

This would be great. will check it out thanks so much.

[WOK]

This sounds interesting.
It would be mega-cool to program an interface to the KVR plugin database so the categories would be taken automatically from there (and the GUI thumbnail, so this could be developed to whole plugin manager tool....)

[TabSel]

I actually thought there'd be more interest for a plugin manager with people constantly complaining about a lack of plugin sorting/categorisation/organisation with all kinds of hosts...

Was it to hard to understand what this tool does, and how?

Or do people don't want to admit that they are addicted to plugins?

[Burillo]

this looks interesting. given that it's a VBS, i take it it's possible to customize it, right?

i can't get to steinberg forums for some reason, can i have a bit more technical details about how is this actually achieved? You're not duplicating DLL's in folders for each host, are you? Presumably something like this could be done using NTFS junction points, but maybe you found a simpler solution

[WOK]

I actually thought there'd be more interest for a plugin manager with people constantly complaining about a lack of plugin sorting/categorisation/organisation with all kinds of hosts...

Was it to hard to understand what this tool does, and how?

Or do people don't want to admit that they are addicted to plugins?

Organizing and sorting plugins (with tool or without) is work and requires decisions. Musicians have problems with both....

[TabSel]

this looks interesting. given that it's a VBS, i take it it's possible to customize it, right?

i can't get to steinberg forums for some reason, can i have a bit more technical details about how is this actually achieved? You're not duplicating DLL's in folders for each host, are you? Presumably something like this could be done using NTFS junction points, but maybe you found a simpler solution

It can't be done with junctions/symbolic links.

My tool builds one single scan path per host, containing category subfolders and dlls.
The dlls created are either jBridge dlls (if jBridge is installed) and/or so called loader dlls. Both dlls, when loaded by the host process, loads another dll, the actual plugin. So basically, the tool creates one single scan path per host, containing "links" to your once installed plugins, one "link" to only one dedicated installed or automapp dll per plugin ID, sorted into category subfolders. You specify path(s) where all your installed plugins are, you create one folder for each host you want a single scan path for, containing all plugins, and you specify for each host, which dll type should be available in its scan path. X64 plugs, where available and x64 jBridged x32 plugs when there is no x64 dll, for example, for cubase x64, and automapped x32 plugs when there is a automapped version of a x32 plug, and native x32 plugs, when there is no automapped x32 plug, for ableton live, for example.

You then run the tool and it syncs changes/additions to your installed plugins and automap en/disabling with all your separate hosts scan paths, offering you the possibility to categorize your plugins into subfolders as you like and have the plugs then available according to your category structure within every host.

As a plus, every plugin will always have the same name, in every host, even when you actually use automap.
For example, where you currently use "TyrellN6 (x64) (Automap)" in cubase x64 and "Tyrell (Automap)" in Live, you will be able to have "TyrellN6" available in every host, but actually using the "TyrellN6 (x64) (Automap).dll" in cubase x64 and the "Tyrell (Automap).dll" in cubase x32 or live... Essential for some hosts presets, which store/find presets depending on a plugs name, for example, to be able to use presets made with an automapped dll with the same unmapped dll...

[TabSel]

BTW the provided used "loader DLLs" dont have any impact on performance or stability. When loaded by the host, they simply load a plugin DLL whose path is specified in an equally named txt-file, call its VSTMain entry point and passes the return params back to the host which then will communicate with the plugin itself, as if it was loaded directly.

The loader DLLs are ~25kb, so there won't be a memory impact, too, and the created hosts scan paths will be small, too.

As said, I only install/update plugs and automap them, I don't care anymore for organizing dlls, splitting x32 from x64 etc. I simply specify once which host shall use which kind of plugin dlls, jbridged if necessary, and let my tool update the unique scan paths with a unique dll per plugin, with a unique name across the system, uniquely categorized.

Very convenient

[osiris]

I have a new 64 bit computer and it's maddening. I didn't know what I was doing when I first started installing stuff and 64 bit plugins are in the x86 folder and vice versa. They all seem to work - so far. But this would be a Godsend. Any way to specify paths after somethings already installed?

[TabSel]

No need to. Leave your mess where it is. Tell the tool where to look for plugin dlls of any kind, x32, x64, automapped x32/x64...
It will create a folder containing only plugin dlls of the type(s) you want. A folder containing only x64 plugs, if you so like. Or a folder containing x64 plugs and x32 only plugs jbridged to x64, as you desire.

The dlls in the created folder aren't duplicated plugin dlls. They are simply dlls which load the actual plugin, wherever it is installed to...

[osiris]

Then PLEASE upload it. Better yet - sell this to Microsoft to fix whatever crap code they've written that makes me put plugins all over the place. I like things simple and XP was great. One folder: VST Plugins. Done.

[WOK]

They all seem to work - so far. But this would be a Godsend. Any way to specify paths after somethings already installed?

Plugins without installer (.dll files) can allways be moved to any other folder (that is specified in the host).
Most plugins with installer use the user data folder for data so the .dll can be moved also. If there is a subfolder belonging to the plugin it must be moved too.

[TabSel]

Yes, and some dont. Some will write their install dir to the registry.
Also how so you keep track of your movements/dll copies, when updating a plugin?
What do you with plugins have data folders, which you want to have abailable in multiple hosts which don't or can't share the same scan path?

With my tool you just install any plugin anywhere, once. Update it once. Never touch the installation, never move or copy dlls, data folders etc. just let my tool generate a dedicated scan path for your hosts, with categorized/sorted/uniquely named/automapped/jbridged plugins, which will simply "link" to your installed plugs.

I'm currently writing a documentation, when finished, I'll provide a download possibility. Meanwhile you can download the pluginmanager and read information about how to use it @ the Steinberg forums.

Otherwise, please be patient. I'm sure it will serve you.

[mandolarian]

This sounds brilliant! Will try to be patient. Just not patient enough to sign up for the Steinberg forum, which is the only way to get the download. Membership, again, has privileges.

[TabSel]

http://www.kvraudio.com/forum/viewtopic ... 11#4958311