So, the default name for the Plugin “Tyrell N6” will be the name of the x32 dll “Tyrell N6.dll” (without. By default, each plugin is used in “ hosts, and its default name in all hosts is the name of the native x32 dll. 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. So, there will be ONE “tyrelln6.ini”-file, which contains 4 paths to the relevant dlls. Thus, for “Tyrell N6.dll”, it builds a name “tyrelln6”, for “Tyrell N6 (圆4)” it also build “tyrelln6”, as it does for “Tyrell N6 (Automap).dll” and again with “Tyrell N6 (圆4) (Automap).dll”. It deletes non-alpha-numeric chars and also, it tries to delete architecture dependant chars from dll names. This “identification name” is build as follows: If my tool detects a automap dll, it deletes the " (Automap)" portion of that name. ini-file per plugin which stores information about dlls belonging to that plugin. There is a x32 dll “Tyrell N6.dll”, a 圆4 dll “Tyrell N6 (圆4).dll”, a x32 automap wrapped “Tyrell N6 (Automap).dll” and a 圆4 automap wrapped “Tyrell N6 (圆4) (Automap).dll”, each belonging to the plugin “Tyrell N6”. There might be x32 dll, a 圆4 dll, a x32 automap dl, a 圆4 automap dll. There might be two or more dlls for a given plugin. It will gather information about which architecture each dll is (x32/圆4), wether it’s a automap dll or not, wether it’s a vst plugin dll. In a first step, the tool will scan your dlls recursively down (a) root path(s) you specify, where your dlls are installed. I wanted to have my plugins available sorted into cantegories, without ever moving the installed plugin dll, or associated data folders etc. VST3presets interchangeable between architectures, plugins named uniquely across hosts/architectures. So, whenever a host scans/loads the 圆4 dll “TyrellN6” (with “TyrellN6” then available to the 圆4 host, like in x32 hosts), it actually scans/loads the original “TyrellN6 (圆4) (Automap).dll”. 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. Some plugs rely on their dll name and/or even folder path. automap wrapped plugins won’t work without their " (Automap)" ending. With some plugins, and with all automap wrapped plugins, it is not possible and advisable to simply rename the dll. To me, it was necessary to name the automap wrapped plugins the same as the original dll. However, VST3presets stored with “embracer” are not available to “embracer (Automap)”, and vice versa. 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. For each “plugin.dll” which gets automap wrapped, automap creates a “plugin (Automap).dll”. To me, it was necessary to uniquely name plugins. VST3presets saved with “TyrellN6” are not available to “TyrellN6 (圆4)” and vice versa. Most hosts store their presets in a folder according to the dll name. TyrellN6’s x32 dll is called “TyrellN6.dll”, whereas its 圆4 dll is called “TyrellN6 (圆4).dll”, resulting in the plugin “TyrellN6” being available in a x32 host, and “TyrellN6 (圆4)” in a 圆4 host. Some venors name their 圆4 plugs different from their x32 versions.
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.ĭifferent naming schemes between different architectures. 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. jbridge file within the same directory as the bridged plugin dll. Jbridge works flawlessly, however, it has one minor drawback: jBridge stores its settings in a. I want to have ONE folder per plugin hosting application, without managing files. I wanted to get rid of the necessarity of managing and organizing multiple host dependant scan paths, using jBridge and automap. With some hosts their bridge work well, with others, they don’t. Some allow for multiple VST Scan Paths, some don’t. Each host treats usage of plugins somehow different. Cubase, Sonar, Live, FLStudio, Reaper, Kore2, Maschine, you name it, used in either x32 or 圆4 architectures. 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.įor me, the reasons to write such a tool were:
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?
0 kommentar(er)
