Sorry if this has been already answered I couldn’t find it with a search …
Automap doesn’t wrap Cubase plugs as yet right ?
its not just me is it ?
Automap beta v.3.7.2 does wrap Cubases VST3 plugs (despite of HALion Sonic SE) and Cubases VST2 plugs.
Beware that some VST2 plugs might appear twice in Cubase (as “xxx” and as “xxx (Automap)”) and that you loose VSTpresets for the plugs that got automapped.
(I have found a reliable workaround for both, if anyone’s interested)
interesting, thanks tabsel
hm ? preset a.w.o.l. issues…
not good… but it works & you may have a temp solution ?
ta
When you have a VST2.x plugin “xxx.dll”, and you automap enable it with Novation Automap’s Plugin Manager, it will create an “xxx (Automap).dll” in the same folder as the “xxx.dll”.
Beware, that there currently is a bug with Automap: If you automap enable two equally named plugins (like “FM8.dll” (x32) and “FM8.dll” (x64) only the least one automap enabled works, the other simply can’t be instantiated in a host…
When you start Cubase, it scans the new plugin “xxx (Automap).dll” and makes it available to its 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 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)” plugin is and works exactly the same as the “xxx”, despite that it’s bound to the “automap server”, which communicates with a Novation Controller 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, then automap it, it will be “Trilian (Automap)” in Cubase, and you can not see your “Trilian” VST3Presets for the plugin called “Trilian (Automap)”, even though both plugins are “the same”.
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 cid and 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 some non-automapped plugin end 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.
I asked several times now, if maybe some moderator oder programmer can explain, how the cid/editorCid is created during scanning, but never got any support here from steinberg.
- 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 again be available as “xxx”.
And this way, when searching VST3Presets for this automapped plugin, Cubases shows VST3Presets for “xxx” and you will see yout “Trillian” VST3presets again for the automap enabled “Trillian”.
this is, what I do:
I’ve got two separate folders for x32 VSTs and x64 VSTs with subfolders per vendor and plugin:
x:/VST2 plugins/native/VST2 x32/vendor/plugin/(plugin.dll and data)
x:/VST2 plugins/native/VST2 x64/vendor/plugin/(plugin.dll and data)
- I jBridge all x32 VSTs into a separate folder:
x:\VST2 plugins/jbridged/VST2 x64/VST2 x32/vendor/plugin/(plugin.dll)
-
I run the Automap Plugin Manager for the path “x:\VST2 plugins/jbridged/VST2 x64/VST2 x32/” and automap enable every jbridged plugin
-
I use windows explorer search, search for all “automap” files in “x:\VST2 plugins/jbridged/VST2 x64/VST2 x32/”, mark all and copy them to another folder:
x:\VST2 plugins\automap\VST2 x64_(plugin (Automap).dll)_
-
I run the Automap Plugin Manager for the path “x:\VST2 plugins/native/VST2 x64/” and automap enable every native x64 plugin
-
I use windows explorer search, search for all “automap” files in “x:\VST2 plugins/native/VST2 x64/”, mark all and copy them into the folder x:\VST2 plugins\automap\VST2 x64, overwriting existing automapped dlls (jbridged from x32 to x64) with their native automap enabled x64 version
This way, I have a folder x:\VST2 plugins\automap\VST2 x64\ containing only automapped x64 plugins (either native or jbridged from x32) (If you want, you could create subfolders with in this folder and move the files there, for sorting plugins into categories for cubase)
-
I delete cubases “blacklist” and “vst2xplugin cubase.xml”, start cubase, add the path "x:\VST2 plugins\automap\VST2 x64" to cubases vst2 search path and let cubase rescan.
-
I quit Cubase and open the “vst2xplugin cubase.xml” in the notepad editor
-
I replace all occurences of ’ (Automap)“/>’ with '”/>’
Ready to go: Every plugin is a automapped x64 plugin (either native or jbridged from x32) and its name shows without the “(Automap)” extension in cubase, thus, I can use VST3presets made with non-automapped plugins
Cubases own plugins resides in folder “c:\program files\steinberg\cubase 6\vsplugins” and contains x32 plugins and x64 plugins, as installed. I don’t jbrdige them, as I believe, that steinberg plugins work well with steinbergs VSTBridge, but I automap these, too.
-
I run the Automap Plugin Manager for the path "“c:\program files\steinberg\cubase 6\vsplugins” and automap enable every plugin there. I don’t move these "xxx (Automap).dll"s
-
I start cubase, cubase scans the automap plugins of its own plugins
Some plugins then appear twice in cubases plugin list, for example “embracer” and “embracer (Automap)”, the reason for this is explained above
-
I leave cubase and again edit “vst2xplugin cubase.xml” in the notepad editor and again replace all occurences of ’ (Automap)“/>’ with '”/>’
-
I search the file for all occurencies of ‘00"/>’ in lines with “cID”. When found, I copy the 4 lines cid, editorcid, name, vendor and replace the 4 lines of the automapped version usually one item above with these 4 lines
There are only a few plugs with fewer than 9 chars, like embracer, tonic, da tune, etc… so not much work
Ready to go. All third party plugins and all cubases own plugins automap enabled availabe under their original name.
Seems a lot of work, but it is only done once, fortunately.
Of course, a proper plugin manager within cubase would be fine 
hai,
thanks for all the work, i have the same bullshit with Automap.
I finally sold my Nocturn 3 years ago because of this preset problem.
However, i bought a new one today, to give it one more change. (Also to use it with Traktor dj software)
So im gonna see tonight and tomorrow if there’s another way to do this…
Cheerz
Well, thats me who developed it
can automap map one physical knob to multiple vst parameters across different plugins, using arbitrary scaling? (eg. one vst parameter being controlled in a linear ‘clockwise’ fashion, while another parameter is controlled with the same physical control, inversely, exponentially, and within a certain limited range - say 10% - 40%)? thank you!
also, tabsel, well done, i’d try to hire you right off the bat if i were steinberg.
there is another work around … only run a 64 bit system and you don’t have any of the conflicts , automap has always run perfect for me just running 64 bit , every thing wraps perfect ,never crashes ,doesn’t cause Cubase to hang …it’s perfect
Do you have a reliable solution by the time or PluginManager does the job ?