maybe you suffer from managing multiple vst2 scan paths and installation folders of your VST2 plugins, have trouble organizing your plugin DLL files for your plugin hosts, for different archiectures, using automap and/or jBridge?
Well, that was the case for, so I ended up writing a little tool, which does manage all this clusterf.ck automatically, providing each host with its own plugins, jbridged if needed, automapped, if you decide to, all well organized into categories.
For me, the reasons to write such a tool were:
Here are multiple plugin hosts in use. Cubase, Sonar, Live, FLStudio, Reaper, Kore2, Maschine, you name it, used in either x32 or x64 architectures. Each host treats usage of plugins somehow different. Some allow for multiple VST Scan Paths, some don’t. Some have a x32/x64 birdge, some don’t. With some hosts their bridge work well, with others, they don’t. I wanted to get rid of the necessarity of managing and organizing multiple host dependant scan paths, using jBridge and automap. I want to have ONE folder per plugin hosting application, without managing files.
jbridge works flawlessly, however, it has one minor drawback: jBridge stores its settings in a .jbridge file within the same directory as the bridged plugin dll. Now, if a bridged plugin works with some settings in host A, it doesn’t mean that the same plugin works well with the same settings in host B. So it’s necessary to eventually have ONE dedicated plugin folder per host, so that jBridge stores its settings depending on the host the plugin is used in.
different naming schemes between different architectures. Some venors name their x64 plugs different from their x32 versions. TyrellN6’s x32 dll is called “TyrellN6.dll”, whereas its x64 dll is called “TyrellN6 (x64).dll”, resulting in the plugin “TyrellN6” being available in a x32 host, and “TyrellN6 (x64)” in a x64 host. Most hosts store their presets in a folder according to the dll name. VST3presets saved with “TyrellN6” are not available to “TyrellN6 (x64)” and vice versa. To me, it was necessary to uniquely name plugins.
Same applies to automap. For each “plugin.dll” which gets automap wrapped, automap creates a “plugin (Automap).dll”. These plugins are identified by their same VST-ID, so they are easily interchangeable and project compatibility is guaranteed between a system which uses automap and a system that doesn’t. However, VST3presets stored with “embracer” are not available to “embracer (Automap)”, and vice versa. To me, it was necessary to name the automap wrapped plugins the same as the original dll.
With some plugins, and with all automap wrapped plugins, it is not possible and advisable to simply rename the dll. automap wrapped plugins won’t work without their " (Automap)" ending. Some plugs rely on their dll name and/or even folder path. So I had to write so called proxy dlls, which can be named to my liking (this altered name is then available as plugin name in hosts), but, when loaded by a host, load the actual plugin dll. So, whenever a host scans/loads the x64 dll “TyrellN6” (with “TyrellN6” then available to the x64 host, like in x32 hosts), it actually scans/loads the original “TyrellN6 (x64) (Automap).dll”. VST3presets interchangeable between architectures, plugins named uniquely across hosts/architectures.
Sorting and categorizing. I wanted to have my plugins available sorted into cantegories, without ever moving the installed plugin dll, or associated data folders etc.
That’s what I wrote my tool for.
In a first step, the tool will scan your dlls recursively down (a) root path(s) you specify, where your dlls are installed. It will gather information about which architecture each dll is (x32/x64), wether it’s a automap dll or not, wether it’s a vst plugin dll.
The tool will write a .ini-file for each plugin (not dll). There might be two or more dlls for a given plugin. There might be x32 dll, a x64 dll, a x32 automap dl, a x64 automap dll. Take for example the plugin Tyrell N6.
There is a x32 dll “Tyrell N6.dll”, a x64 dll “Tyrell N6 (x64).dll”, a x32 automap wrapped “Tyrell N6 (Automap).dll” and a x64 automap wrapped “Tyrell N6 (x64) (Automap).dll”, each belonging to the plugin “Tyrell N6”.
My tool will create ONE .ini-file per plugin which stores information about dlls belonging to that plugin. This “identification name” is build as follows: If my tool detects a automap dll, it deletes the " (Automap)" portion of that name. It deletes non-alpha-numeric chars and also, it tries to delete architecture dependant chars from dll names. Thus, for “Tyrell N6.dll”, it builds a name “tyrelln6”, for “Tyrell N6 (x64)” it also build “tyrelln6”, as it does for “Tyrell N6 (Automap).dll” and again with “Tyrell N6 (x64) (Automap).dll”.
So, there will be ONE “tyrelln6.ini”-file, which contains 4 paths to the relevant dlls.
This ini-file also contains information about hosts, this plugin is being used in and which name the plugin will have by default in each host. By default, each plugin is used in “@all” hosts, and its default name in all hosts is the name of the native x32 dll. So, the default name for the Plugin “Tyrell N6” will be the name of the x32 dll “Tyrell N6.dll” (without .dll).
Some plugins have any architecture in their name, like “Rapture32LE” and “Rapture64LE”. The default name then would be “Rapture32LE”, even in a x64 host, but you can change this name simply to “Rapture LE” for example, valid for all hosts, by editing the “hostedBy”-line in the .ini-file.
In a second step, if the tool detects new plugins (as it will when you run it the first time), it will stop and offer you the chance to edit (if necessary) and sort these .ini-Files into subfolders, as you prefer.
In a third step, the tool will use the folder structure of the .ini-files and the .ini-files itself, to create a Scan Path for a given host, which then will only contain ONE dll for given plugin. WHICH dll the tool will create, is up to you. You can specifiy wether a given host should prefer automap wrapped native x64 dlls, and if it won’t find the automap dll, it shall use the unwrapped native x64 dll instead. If it won’t find any x64 dll, it shall use the automap wrapped x32 dll and jBridge it automatically to x64 (if jBridge is installed), and so on…
If you download the .zip-archive, you’ll notice the folder structure of my tool. The root folder is “Plugin Manager”:
bin (contains so called loaded DLLs, which are simply used to load another dll, so a host can scan/load the renamed loader dll “A.dll”, which in turn loads “Tyrell N6 (x64) (Automap).dll”
vbscript are folders which contain files used by the PluginManager.vbs
configs (the combination VSTScanPaths/.ini-files/categories/Hosts and their ScanPaths containing plugin dlls is called a “config”. Currently, there is only one “config”: “default”. Each subfolder of “configs” contains one config.
a config/ subfolder contains the subfolders “cache” and hosts"
“cache” in turn contains a “VSTScanPath.ini”-file, where you specifiy the root folders, where my tool will scan for dlls. The resulting .ini-files are stored in the subfolder “categories”. The subfolder “categories” again contains subfolders representing, well, your plugin categories. You can create additional subfolders as you like for easy organization, I provided a subfolder structure already.
“hosts” contains a subfolder per Host, which you want to create a unique Scan Path for. You create one subfolder per host, as I already have done, for “Cubase 64Bit”. This host subfolder will later on contain a “categories” subfolder, where my tool will create it’s DLLs into, according to the subfolder structure in “cache/categories”. The host subfolder also contains a “default.ini”-file. This is, where you specifiy which kind of DLLs you want my tool to create for you. You simply specify kinds of dlls in a priority order:
use the automap wrapped native x64 dll for a plugin, if found. If not, then
use the unwrapped native x64 for a given plugin, if found. If not, then
use the automap wrapped native x32 dll, jbridged to x64, if jbridge is installed and the wrapped x32 dll is found. If not, then
use the native x32 dll, jbridged to x32, if jbridged is installed and a native x32 dll is found. If not, well…
“x64” or “x64|@none” means:
use the native x64 dll for a given plugin, if found. If not, do not search for other dlls. This way, you could have installed all your x32 and x64 plugins all over the place, without different install paths for x32 and x64, simply let my tool gather information and let it create a host scan path, which only contains native x64 plugins for plugins, where there is a x64 dll.
always create x32 dlls, even when there exists a x64 dll for a given plugin (for x32 hosts for example).
possible notations are:
x32 = native x32 dll
x64 = native x64 dll
ax32 = automap wrapped native x32 dll
ax64 = automap wrapped native x64 dll
j32x32 = native x32 dll, jbridged to x32 (if jbridge is installed)
j32ax32 = automap wrapped native x32 dll, jbridged to x32
After step 3) above, the host subfolder will contain a “categories” subfolder, containing s folder structure as you specified and sorted your .ini-Files into “cache/categories”, containing plugins in a format you specified in the hosts “default.ini”, for example “…\PluginManager\configs\default\hosts\Cubase 64Bit\categories”
This “categories” folder then could be set up as the only one Plugin Scan Path in the given host.
The host will scan the plugins and present the plugins uniquely named across architectures and hosts, automapped as you like without “(Automap)” extension, sorted as you like. Cubase for example will present the plugins in a nice submenu structure according to your categories.
Feel free to try it out, it won’t do any harm to your current installation of plugins, everything the tool does will happen with the “PluginManager” folder. It won’t alter dll names, it won’t change anything in your current setup.
However, I am not responsible for any faults, nor do I feel obliged to give support.
Maybe you find a use for it.