geht aber nicht anders…
Beispiel: Ein Plugin gibt’s erstmal als Version 1 mit der ID 1111. Der Hersteller nennt es “PlugV1”. Projekte, die dieses Plugin verwenden speichern die ID des Plugs und die Plugin-Settings mit ab. Wenn das Projekt geladen wird, wird das Plugin mit der ID 1111 geladen und diesem werden die Settings übergeben.
Nun erweitert der Hersteller das Plugin, fügt z.B. nen 8ten Oszillator dazu. Er nennt das Plugin “PlugV2”, gibt diesem aber auch die ID 1111. Du updatest und erstellst ein Projekt mit diesem PlugV2. Du speicherst das Projekt, damit wird dann die ID 1111 und dessen Settings gespeichert. Die Datenstrukturen dieser Settings unterscheiden sich zwischen PlugV1 und PlugV2. Z.B. müssen ja auch die Einstellungen für den 8ten Oszi in den Settings enthalten sein… Dann gibste das Projekt Deinem Spezl, der aber noch nicht von PlugV1 auf PlugV2 upgedated hat…
Dein Spezl lädt das Projekt. Cubase instantiiert das Plug mit der der ID 1111. Bei Deinem Spezl wird dann “PlugV1” geladen. Und dem Plug werden Settings mitgeteilt, die das PlugV1 gar nicht versteht, es kann mit Settings für den 8ten Oszi gar nix anfangen, es ja gar keinen, z.B.
Im Besten Fall ist PluginV1 so geschrieben, dass es Settings die es nicht versteht überliest. Dann schmiert es wenigstens nicht ab. In anderen Fällen haste ein Plugin das abschmiert und Deine Kiste gleich mit. Selbst wenn es NICHT abschmiert: Das Projekt klingt bei dem Spezl total anders als bei Dir. SEIN PlugV1 hat ja gar keinen 8ten Oszi. Dein Spezl werkelt ein bisschen mit Deinem Projekt und will’s Dir dann wieder “zurück geben”. Er speichert also das Projekt, damit wird im Projekt ID 1111 vermerkt, und die Settings des Plugins werden mitgespeichert. Da Dein Sepzl PlugV1 hat wird es sicherlich die Settings zu, 8ten Oszi nicht sichern, sowas “kennt” es ja gar nicht…
DU wiederum öffnest das Projekt wieder, PlugV2 wird geladen, und dem PlugV2 werden die PlugV1 Settings übergeben. Im normal-Fall würde das PlugV2 die PlugV1-Settings “importieren”. “Laden” kann es die Settings nicht, da es ganz andere Settings erwartet als Cubase Ihm gibt. Importiert wird aber nix zum 8ten Oszi, wie denn auch, PlugV1 hat dazu gar nix in seinen Settings gespeichert…
Einem Hersteller bleibt also nix anderes übrig, als entweder
-
Das “alte” PlugV1 bis zum Sanktnimmerleinstag “mitzuwarten”, also eine PlugV1.1 rausbringen, es also an veränderte Datenstrukturen in weiteren Versionen anzupassen, so dass es z.B. PlugV2 settings laden kann, Daten überliest mit denen es nichts anfangen kann, und beim Speichern unverändert wieder mitspeichert, damit nix verloren geht für PlugV2… In jedem Fall aber hätten all die User die dann noch auf PlugV1 sitzen und (noch) nicht auf PlugV1.1 upgedatet haben ein Problem… Im Changelog von PlugV1 auf PlugV1.1 würde dann nur stehen “Anpassung an PlugV2 Settings”, und die Leut werden sich denken "warum updaten, ich hab ja gar kein PlugV2, und hätten u.U. Abstürze, nur weil PlugV2 rauskam, und nicht weil PlugV1 Bugs hätte. Nicht nur müssen Hersteller uralte Plugs mitwarten, sondern User müssten laufend Uralte Plugs updaten, selbst wenn sie die neuen Versionen gar nicht haben (wollen)…
-
Er vergibt ne neue ID. PlugV2 bekommt die ID 2222 und alle Probleme sind beseitigt. User die PlugV2 haben können das Projekt speichern, öffnen, Settings gehen nicht verloren, es muss nix importiert/konvertiert etc. werden… User die das Plug nicht haben (kauften) eben nicht.
Es geht leider nicht anders. So blöd es klingt, aber sowhl Hersteller wie auch Anwender profitieren davon.
Mach nen Ordner “legacy” und schmeiß Deine alten Plugs da rein, damit sie in den Menüs von Cubase nicht stören. Besser noch: schalte die Anzeige älterer Plugins in Cubases “Plugin-Informationen” aus. (Das Plugin wird dann in den Menüs nicht mehr angezeigt. Wenn Du aber ein Projekt lädst mit nem “ausgeschalteten” Plugin, dann wird es auch geladen…
