If you have a VST2.x plugin “xxx.dll”, and you automap it with Novation Automap’s Plugin Manager, it will create an “xxx (Automap).dll” in the same folder as the “xxx.dll”.
If you then start Cubase, it scans the new plugin “xxx (Automap).dll” and makes it available to cubases’ Fx or Instruments.
Normally, if you had the “xxx” available within cubase, you then have “xxx (Automap)” available in Cubase.
However, sometimes you have both, “xxx” and “xxx (Automap)” available. This depends on the length of the plugin name. If it’s shorter than 9 chars, you will have both plugins, the “xxx” and the “xxx (Automap)” available. Otherwise, the “xxx (Automap)” plugin completely replaces the “xxx”. Projects are interchangeable between machines that have an automapped plugin, and machines that don’t. So no worry, you can easily open a project on machine that has “Trilian”, whereas the project was saved on a machine that used “Trilian (Automap)”, and vice versa.
The “xxx (Automap)” is and works exactly the same as the “xxx”, despite that it’s bound to the “automap server”, which communicates with a Novation Keyboard and maps its controls to the Plugins Automation parameters automatically whenever you open the plugin GUI.
Despite the fact that you sometimes get both plugins, the “xxx” and the “xxx (Automap)” available within Cubase, there’s another annoying problem:
VST3Presets are bound to the plugins’ name and vendor.
Thus, if you created VST3Presets for Trilian, and then automap it, it will be “Trilian (Automap)” in Cubase, and you can not see your VST3Presets for “Trilian”, for a plugin called “Trilian (Automap)”.
Well, there’s a solution to this.
After you automapped your plugins, and let cubase scan your new “xxx (Automap)” plugins: Leave Cubase.
Cubase 6 creates a file “vst2xplugin cubase.xml” in c:\user…\appdata…
In this file, there is a … section for each VST2.x plugin.
Within this section, there are four relevant name/value entries: “cid”, “editorCid”, “name” and “vendor”
if you set these exact four entries in a section of an “xxx (Automap).dll” to the same values of the section of the non-automapped “xxx.dll” plugin:
both plugins have the same Unique Identifier (cid, editorCid) and only the first plugin with this cid/editorCid is available to cubase.
If you have “xxx” AND “xxx (Automap)” available to cubase, you’ll notice that the cid/editorCid of this non-automapped plugin ends with “00” (because the name is shorter than 9 chars…), whereas the cid/editorCid of the automapped plugin doesn’t (because it’s name is always longer than 9 chars), so, for cubase, these are two different plugins, and both are available to cubase.
maybe some moderator oder programmer can explain, how the cid/editorCid is created during scanning, please?
And perhaps a rudimentary plugin manager possibility that enables us to change the name of a plugin within cubase. Simply make the coloumns “name” and “vendor” editable in the plugin info window…
- the name and vendor of the automapped plugin, though the dll has the name “xxx (Automap).dll”, will have the same name as the native plugin “xxx”. The automapped plugin will no more be available to cubae as “xxx (Automap)”, but it will be available as “xxx”.
And this way, when searching VST3Presets for this automapped plugin, Cubases shows VST3Presets for “xxx”, and nor more for “xxx (Automap)”!
Now, I’ve got a lengthy list of plugins, so the “vst2xplugins cubase.xml” is very big. And replacing the four entries “cid/editorCid/name/vendor” of an automapped plugin with the values of the corresponding unmapped plugin is a tedious task!
I, and surely others, will much appreciate if some scripting expert could write a simple script, that does this replacing automatically? Is anybody able to do this?
Or does anybody have a clue, how to make this task automateable?