Hi,
mir ist letztens erschreckenderweise etwas aufgefallen, was Automap user betrifft:
wenn ein “Plugin” automap enabled wird, wird ein “Plugin (Automap)” erstellt.
Settings, die mit “Plugin (Automap)” gespeichert werden können u.U. mit “Plugin” NICHT wiederhergestellt werden!
Beispiele:
-
Neues Projekt in Cubase, in dem “Plugin (Automap)” verwendet wird. Später wird das “Plugin” wieder automap disabled (oder Automap deinstalliert, oder das Projekt auf einem anderen Rechner geöffnet auf dem Automap nicht installiert und/oder das Plugin nicht automap enabled ist). Resultat: Beim öffnen des Projekts wird zwar “Plugin” geladen (statt “Plugin (Automap)”), unter Umständen werden aber die settings, wie sie mit “Plugin (Automap)” eingestellt wurden mit “Plugin” nicht wiederhergestellt.
-
Speichern eines .fxp-presets mit “Plugin (Automap)”. Laden des .fxp-presets in “Plugin”. Auch hier: u.U. wird das preset nicht geladen.
Es betrifft nicht ALLE plugins, aber grunsätzlich läßt sich festhalten:
A) wenn ein “Plugin” automap enabled wird, wird ein “Plugin (Automap)” erstellt.
B) Das “Plugin (Automap)” hat 6 Automationsparameter mehr als “Plugin”
C) Die gleichen Einstellungen in beiden “Plugin” und “Plugin (Automap)” unterscheiden sich: “Plugin (Automap)” settings haben 6 Automationsparameter und 28Byte mehr Daten.
Resultat: Settings, erstellt mit “Plugin (Automap)” können u.U. nicht in “Plugin” geladen werden!!!
Zwar können Plugins auch automap enabled werden, wenn kein novation controller vorhanden ist, dennoch halte ich es für erschreckend, dass eine Controller-Software Preset-Daten-Inkompatibilität verursacht!
Ich bin am überlegen, ob ich meinen Plugin Manager erweitere, um wieder Preset-Kompatibilität zwischen einem automap enableten und einem originalen Plugin herzustellen:
Wenn mein Plugin Manager genutzt wird, wird jedes Plugin durch eine sogenannte Loader.DLL instantiiert. Im Prinzip ist das mittlerweile ein Mini-Wrapper, der nur das echte Plugin lädt, und die Kommunikation host<->plugin einfach nur weiterleitet, mit dem Resultat, dass ein Plugin für einen host jeden x-beliebigen Namen haben kann. Es gibt z.B. Plugins, die es nicht mögen wenn Ihre .dll umbenannt wird, Automap enablte plugins gehören dazu, die können nicht umebannt werden.
Meine Idee wäre: wenn ein Plugin settings wiederherstellen soll, dann könte ich in der Loader.DLL feststellen, ob die Anzahl Parameter in den settings-Daten zur Anzahl Parameter des geloadeten Plugins paßt. Wenn das geloadete Plugin genauso viele Parameter hat wie in den settings-Daten angegeben, dann handelt es sich wohl um das automap enablte plugin. Wenn das geloadete plugin aber 6 Parameter weniger hat als in den Settings-Daten angegeben, dann handelt es sich wohl um das originale Plugin, und ich könnte die Settings-Daten so modizieren, dass das originale Plugin diese laden kann.
Preset-Kompatibilität zwischen originalem und Automap gewrapptem Plugin wäre dann wieder hergestellt, zumindest wenn mein Plugin Manager verwendet wird.
Besteht Interesse?
Ist jemand schon mal auf das Problem gestoßen, dass settings, erstellt mit einem automap enablten plugin mit dem originalen plugin nicht mehr wiederhergestellt werden? Welche Plugins waren das?
Ich hab ein bisschen getestet: AAS Chrompahone settings werden inkompatibel mit Automap, Minimoog Original und TyrellN6 z.B. bleiben Kompatibel. Hat jemand noch andere Beispiele?