Novation Automap and Cubase VST3Presets, need a scripter!

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:

  1. 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…

  1. 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?

They have plenty of open source text editors, with many search and replace functions.

For the amount of time you spent writing that it should be a snap.

I hope that this is some useful information for some (frustrated vst3preset creators)? I tried to explain as good as I can.

However, I tried already using various texteditors and regular expressions for search/replace, but that didn’t work…

And maybe, maybe, someone with steinberg can give some usefull information back on how the cid/editorCid are created during scanning? And who’s task it might be correcting the differences regarding the cid of automapped/unmapped plugins with short names? Steinberg? Novation?

Or if there are other, simpler methods of sharing vst3presets between automapped/unmapped plugins? (Some suggested copying the presets from “xxx” to “xxx (Automap)”, but I don’t want to do this everytime I unmap/map a plugin…

Maybe you can try moving all but one or two plug ins, rescan so it’s a smaller file then save the fragments and replace them later.

It’s all effort of course but would be worth it for often used plugins, since if cubase does a rescan itself you can slowly build up a solid replacement file.

Of course it should not be this way, but unfortunately it is, hence the reason why my Bitstream 3x mostly is not used but I think some generic remote changes might be in C6.

BTW I read on a novation answerbase file that they are working on VST3 compatibility, have you written to them?

I know they are pretty lame with support (they ditched V-Station on Powercore) but maybe focusrite can help.

what I described is only valid for automapping VST2.x-Plugins.

With VST3, it seems, that an automapped plugin (in a “xxx (Automap).vst3”-file) does not provide the “xxx (Automap)” name to the host, but tells him it is “xxx”. The same as I described above, but done “internally”. So there’s nothing to do with automapped VST3 plugins, they have the same name and vendor as the unmapped plugins (VST3Preset compatible) and the same Identifier (so there’s always only the automapped plugin available)…

However, there are problems, so that most C6 VST3 Plugins seem not to be automapped.

Novation support told me that VST3 plugins even don’t need to be automapped with the plugin manager. But this doesn’t work for me as they told me. I always have to enable VST3 plugins with the plugin manager, too, in order to haven them automapped…