This is, what the "PluginManager"-Folder contains: The "data" folder contains two so called loader DLLs. These are DLLs which are used in the generated hosts scan paths and do nothing else than loading the actual VST Plugin. Because these DLLs will be scanned by a Plugin hosting application, the DLLs can have any name, which will be visible in the host. The loader DLLs, when loaded by a host, will load the VST Plugin, wherever it may be installed in your system. The host will communicate directly with the VST Plugin. There will be no "wrapping" or "bridging" going on, so using the Plugin Manager won't have any impact on stability or performance! The "data" folder also contains a "html" file and a .jpg file, which is displayed using the Internet Explorer application, to show the progress of the Plugin Manager dynamically. However, if you don't have Internet Explorer installed, you still can use the Plugin Manager, but it can't present you its progress. Instead, there will be an occasional Message Box, which you have to confirm, or enables you to abort the program. The programm will then run "in the background". The "data" folder contains a PluginManager.vbs, a Visual Basic Script, which will do "all the magic...". Please don't alter any of these Files! The "configs" folder contains PluginManager "configurations". A configuration consists of any information the PluginManager will need to run and will gather while executed. All of this is covered below. You can create as many configurations as you want. Simply create another subfolder under "./configs". The PluginManager.bat will start the Plugin Manager, when doubleclicked (see executing the Plugin Manager below) (please don't start the tool multiple times concurrently, the script won't work in this case, you'll get vbs runtime errors) |
Before you are able to execute the PluginManager.vbs, make sure that you tell the PluginManager where in the system it has to search for VST plugins: Within each configuration folder, there has to be a "cache" folder, which will hold information about your VST Plugins and installation paths, and a "hosts" folder, which will be explained below. In that "cache" folder, there has to be a "VSTScanPaths.ini" file. This is where you specify one or more paths (one path per line) to folders where you installed your VST Plugins to. These paths will be searched recursively, i.e. its subfolders will be searched for Plugins, too, and their subfolders, too, and so on... It doesn't matter which kind of DLLs there are present in these paths, be it x32 plugins, or x64 plugins, etc. You don't have to split your plugins into different folders. Simply install them wherever you like and just tell the Plugin Manager, where it has to search for Plugins... If you use Automap, simply automap enable/disable your installed plugins. To do so, enter the paths to your plugins in the automap software. Automap will generate automap enabled plugins, which are DLLs like "plugin (Automap).dll", in the same place where the actual wrapped DLL is located. You do not have to move these automap enabled DLLs anywhere else. If you whish to do so, the include the paths to the automap enabled plugins to the Plugin Managers VSTScanPath.ini, too. All DLLs found within the ScanPaths will be analysed whether they are VST Plugins at least, whether they are native x32 plugins, or native x64 plugins, or whether they are automap enabled plugins. jBridge DLLs and automap enabled jBridge DLLs are skipped, because the Plugin Manager will jBridge your (automap enabled) plugins by demand, and jBridging an already jBridged file really isn't necessary ;) If you use jBridge, you won't have to run the jBridger tool anymore. The Plugin Manager will jBridge your files, if you so desire. Native x32 plugins, in the following, are called x32 DLLs. Native x64 plugins are called x64 DLLs. Automap enabled native x32 plugins are called ax32 DLLs, and Automap enabled native x64 plugins are called ax64 DLLs. The PluginManager will "classify" DLLs it will find within your VSTScanPaths. For one VST Plugin there might be multiple DLLs available, a x32 DLL, a x64 DLL, a ax32 DLL and/or a ax64 DLL. The PluginManager will create one .ini file per VST Plugin, which, amongst other things contain the paths to the DLLs it has found for a given Plugin. |
The Plugin Manager will search your VST Scan Paths for DLLs. It will create (or sync with already existing) .ini files per VST Plugin. The name of that .ini file derives from the DLL names. An " (Automap)" extension for example is truncated, as are architecture dependant identifiers in a given DLL. The Plugin "TyrellN6" for example is available as "TyrellN6.dll" (the native x32 DLL), as "TyrellN6 (x64).dll" (the native x64 DLL), maybe a "TyrellN6 (Automap).dll" (the automap enabled native x32 DLL) and a "TyrellN6 (x64) (Automap).dll" (the automap enabled native x64 DLL). There will be ONE "tyrelln6.ini", which, amongst others, contains the four paths to these four DLLs. Newly created .ini files will either be created directly under ".\cache\categories\" folder, or, if you like, the PluginManager will automatically create a category folder derived from the DLLs parent folder. Already existing .ini files in any category subfolder within "\.cache\categories\" will be updated, if necessary, by the Plugin Manager. The Plugin Manager won't move these .ini files. It's up to you, to move these .ini files per Plugin into an appropriate category subfolder. To later on have your VST Plugins available in your host categorized, you won't have to copy, duplicate or move plugin DLLs around any more. Simply create category subfolders in the ".\cache\categories" folder and move the .ini files into the appropriate category folder. When you download the "example configuration.zip", the ".\cache\categories\" folder will already have some category subfolders I find useful with my own setup. Feel free to create your own categories und subcategories, simply by creating a folder structure, with subfolders, as you like. (see below for more information about these .ini files and about categorization...) |
Ok, so the PluginManager searches your installed and possibly automap enabled VST Plugins and creates or syncs .ini file for each Plugin, which you move freely into category folders. With this very category folder structure and with these .ini files, the Plugin Manager will create a "host scan path", i.e. a folder which will be used by a host as its single Plugin Path, and which will contain only plugins of a dedicated type that you specify. The download contains three "demo hosts": In the ".\configs\default\hosts\ folder, you will find three subfolders. Each subfolder represents a scan path to be build for a specific host. After executing the Plugin Manager, the "example x32" folder will contain a single scan path, with only native x32 DLLs. The "example x64 & x32" folder will contain native x64 DLLs for plugins where a native x64 DLL has been found, and x32 DLLs otherwise. The "example x64 & x32 jBridged to x64" will contain native x64 DLLs for plugins where a native x64 DLL has been found, otherwise, a x32 DLL of that plugin will be made available to the host jBridged to x64 (assuming you have jBridge installed in your system; if not, you'll get an error message saying that jBridge is missing, and not all plugins could be made available...) You can create as many host folders in ".\configs\default\hosts" as you like. You can delete the example folders and create your own. Just make sure that each host folder contains a "default.ini" file, which will tell the Plugin Manager which DLLs should be made available to the host. A "default.ini" file contains a string of DLL classes found (see above), the Plugin Manager should priorize for the host, separated by "|". If you specify for example "x32", the Plugin Manager will create a x32 DLL for each Plugin it has found a x32 DLL for. Specify "x64|x32" and the Plugin Manager will create a x64 DLL for each Plugin it has found a x64 DLL for, and a x32 DLL otherwise. Specify "ax64|x64|ax32|x32" and the Plugin Manager will create a x64 DLL for each Plugin it has found an automap enabled x64 DLL for, otherwise it will create a x64 DLL for the Plugin, when there is a x64 DLL available. Otherwise it will create a x32 DLL if it has found an automap enabled x32 DLL for the plugin. And if not, it will create a x32 DLL for the x32 Plugin... By prefixing a DLL class with "j32" or "j64", you can tell the Plugin Manager to create a jBridged DLL for the given architecture (x32/x64), using the prefixed DLL class. So, specifiying "x64|j64x32" tells the Plugin Manager to create x64 DLLs for each plugin it has found a x64 DLL for, otherwise it will create a x64 jBridge DLL, which bridgeds the x32 plugin DLL to x64... You can jBridge automap enabled plugins, too, you simply specify "ax64|x64|j64ax32|j64x32" in the default.ini. Or you specify for example "j32ax64|j32x64|j32ax32|j32x32", which means that each plugin, available with a x64 DLL will be bridged to x32, with the automap enabled x64 DLL having priority over the unwrapped x64 DLL, and even x32 plugins will be used with the jBridge, bridged to x32 as well, with the automap enabled x32 DLL having priority over the unwrapped... If you are satisfied with your current hosts scan path and don't want the PluginManager making any change to the plugins for this host, then specifiy "@preserve" in the default.ini (notice, that if you use the automap enabled version of plugin in the host, and automap disable this plugin later on, with the hosts plugins "@preserve"d, the host won't be able to instantiate the plugin, as the automap enabled plugin won't be available anymore due to disabling it) |
As mentioned, the Plugin Manager creates a .ini file for a VST Plugin. The .ini files all will look similar. Normally, you won't have to edit these .ini files. You just move them into category folders. You CAN however edit these files to influence the behaviour of the Plugin Manager for a given Plugin. In the following, I'll explain the structure of these .ini files for "TyrellN6": The first line in this file is called the "hostedBy"-line, where you specify in which Hosts (see above) the Plugin shall be available. The Plugin Manager automatically specifies "@all" when he creates a new .ini file for any plugin, which means that this Plugin will be available in each hosts scan path the Plugin Manager found a subfolder for in ".\configs\default\hosts". You can specify "@none" (this plugin shall be available in no Host). You can specify a dedicaated host (the name of the host subfolder), too, in which case the Plugin will only be available in the specified hosts scan path. The second field contains the name under which the plugin will be available to the host, no matter which plugin DLL is actually is used. Normally, the Plugin Manager will use the name of the native x32 Plugin (in this case "TyrellN6") for a given Plugin. For some Plugins, this won't do it. "Rapture LE" for example is available as "Rapture32LE.dll" and "Rapture64LE". The plugin will then be available as "Rapture32LE" in each host, even when the "Rapture64LE.dll" is being used by the host... In this case, simply edit the .ini file and specify a name, "Rapture LE" for example, so "Rapture LE" will be available in any host, no matter which DLL it actually uses! In no case delete the field separator, shown in the example .ini above with "-". These aren't "-" chars, but hex00 chars. Don't delete these chars and replace them with a "-"! If you accidentaly do, then simply delete the .ini file. The Plugin Manager will create a new one automatically... The following lines are "usageIn:"-lines, one line for each host. Here you can override the default "usage" (default.ini) for the plugin in a given host. When you for example discover that a given DLL won't simply work automap enabled currently, you can override the default usage "ax32" specified in the default.ini of the host, with a special usage here "x32" here. Or, if you specified "x64|x32" in the hosts default.ini, the plugin currently is only available as x32 DLL, and the given host does have problems with bridging it to x64 with its own bridge, you can specify "x64|j64x32" here. As soon as a x64 DLL will be available for that plugin, the x64 version will be used. Until then, the x32 DLL will be bridged to x64 using jbridge, which might work better than the hosts own bridge... You can specifiy "@none" here, too, which means that this Plugin shall not be available to this host. You could switch plugins availability in a given host on and off easily with this. The Plugin Manager always will create the entry "@DefaultUsage" here, which means that the usage specified in the "default.ini" for the host is being used. With the third field, you are able to give a plugin a special name for a given host, if you so desire. The Plugin Manager will create the entry "@DefaultName", which means that the name according to the hostedBy-line is being used, but you can alter this to your liking. The following lines contain information about the DLLs the Plugin Manager found for a given plugin. Don't alter these lines. Whenever you change one or more .ini files, simply run the Plugin Manager to update the hosts scan paths according to the new information. |
Once you made your settings, you doubleclick the PluginManager.bat: |
This .bat will simply start the PluginManager.vbs script and specifies, which configuration is to be processed. The second line is commented (REM) by default. If you instead comment the first line, and uncomment the second, the Plugin Manager will create category folders for newly found VST Plugins automatically. The category is derived from the Plugin DLLs parent folder. So if you already sorted your Plugins into categories during installation, the Plugin Manager will be able to adopt your organizational work. |
While running, the Plugin Manager will show to you its progress. At first, it will read previously cached information about your VST Plugins: |
After that, it will scan your VSTScanPaths for new or altered Plugin DLLs, it will analyse them and create .ini files for newly found Plugins or syncs information with previously created .ini files for Plugins: |
After that, it will write back this information to the ".\cache\" folder. |
When the Plugin Manager found a new Plugin, it will stop and offer you the possibility to move the new .ini file to an appropriate category folder... You can use this dialog to create new category folders and move .ini files into category folders, or you can use the Windows Explorer to move .ini files of plugins around freely in your ".\cache\categories\" subfolders, as you like... When done categorizing, simply hit [ok]... You can move .ini files with the Windows Explorer anytime, even when the Plugin Manager isn't running, too. Changes will be reflected in your hosts scan paths as soon as you ran the Plugin Manager! |
After searching for new DLLs and categorizing, the Plugin Manager will begin to create the hosts scan paths and will then finish. |
The Plugin Manager creates a "categories" subfolder in each host folder, which mirrors the category folder structure of ".\cache\categories\" and will create the desired plugin DLLs into it... (notice that these DLLs are either jBridge DLLs, or Loader DLLs (see above). Both jBridge and Loader DLLs need a .txt file with the same name, containing the path to the actual DLL it will bridge/load...) This "categories" folder" has to be specified in your host as Plugin Root Path. It will contain all your desired plugins. Whenever you install or update plugins, automap enable or disable plugins, create a new host within the Plugin Manager, edit .ini files for Plugin changes, or default.ini settings for hosts, then simply run the Plugin Manager. It will update all your hosts scan paths to reflect your changes to your system. |