Alte PlugIns, in neuer Form ohne Zutun nutzen?

Registriert
10.08.10
Beiträge
3.105
Reaktionen
1.313
Punkte
7.290
Ich weiß nicht ob ich hier richtig bin, aber es geht eigentlich nicht um eine bestimmte DAW. Deshalb hier.


Ihr kennt es wahrscheinlich auch alle. PlugIns werden in regelmäßigen Abständen aktualisiert. Man selbst setzt auch alle paar Jahre einen neuen Rechner ein und schon kann man alte Projekte nicht mehr so hören wie sie einst klangen.

Das Thema wurde hier schon diskutiert:

Trotzdem, vielleicht gibt es ja inzwischen eine Lösung.

aktuelles Beispiel:
FabFillter: 2018 Version 2 genutzt. Inzwischen hatte ich auf 3 und 4 geupdatet, die beide auch installiert sind.
Das reicht aber offenbar nicht, das Projekt will ProQ2 haben. Ich kann es jetzt nicht öffnen und die Parameter kopieren oder so. Ich muss quasi von vorn anfangen.

Das gleiche mit Imager von Ozone. Ich habe Ozone immernoch. Der Imager ist in der Suite. Aber damals schien es ein einzelnes PlugIn zu sein, jetzt habe ich diesen OZONE 10 Host im Host Cubase. Innerhalb OZONE 10 gibt es den gleichen Imager noch, aber er wird beim Öffnen des Projekts natürlich nicht erkannt.

Aber wer installiert sich alle alten Ozone Versionen für solche Fälle?
Geht das überhaupt?

Letzter Fall Sample Inhalte.
Gerade habe ich das mit VSL durch. Lizenssystem wurde umgestellt. Beim neuen Lizenssystem muss man alles neu herunterladen, aus Sicherheitsgründen vielleicht an einem anderen Ort. Hier war man so clever, dass das alte Projekt trotz neuer Struktur davon "nichts merkt".

Aber Kontakt? Da kannst Du die Samples von Hand suchen und neu verbinden.

Kennt ihr irgendwelche Tricks oder habt Erfahrungen (positiv?)
 
Alles als Wave einmal mit einmal ohne FX rausbouncen. Audio überlebt alle Wechsel.

Dazu kommt, dass ich relativ fatalistisch bin und einen Song ab einem Punkt als erledigt erkläre und nicht mehr daran rumfummele. Sehr oft habe ich nur noch den Bounce, keine Einzeltracks mehr.
 
Ja. Mach ich.

Bei mir ist oft so, dass ich Arrangements erarbeite, die tatsächlich irgendwann optimal scheinen. Trotzdem kommt 10 Jahre später eine Situation, in der ein Arrangement angepasst werden muss, oder es gab einen oder ein paar kleine Fehler in der Notation, oder aus einer Flöte soll eine Klarinette werden, (neue Range, neuer Schlüssel usw.)

Denk Dir was aus, es gibt genug Fälle.
 
Ich kenne als Mac-User das Problem hinreichend gut (um es sehr vorsichtig auszudrücken). Da fallen permanent ältere Versionen vom Support-Laster, gerade wenn man bspw. Zeug von NI benutzt.
Abgesehen davon, dass ich mal schlau genug hätte sein sollen (Konjunktiv...), die wichtigen Sachen als Audiospuren rauszubouncen, ist meine "Lösung" die, dass ich einfach noch meine beiden alten Rechner hier stehen habe. Damit kann ich dann auch sehr alte Projekte laden und die bei Bedarf rausrendern oder Presets sichern, die dann auch in neueren Plugin-Versionen geladen werden können (was allerdings nicht immer klappt).

Das ist aber ein Schuh, den sich, neben Apple (also in meinem Fall), die Plugin-Hersteller endlich mal anziehen sollten. Wieso updaten die (also natürlich nur sofern möglich) nicht das Ursprungsplugin, welches dann aber denselben Namen, vor allem aber dieselbe Plugin-ID behält?
Dass so etwas absolut möglich ist, exerziert U-He auf nahezu perfekte Art und Weise vor. Zebra 2 etwa wurde 2006 veröffentlicht und man kann selbst auf Macs trotz zahlreicher Updates (sowohl des Synths wie auch des Betriebssystems, in meinem Fall sogar inkl. Umstieg von Windows PC auf Mac) immer noch sämtliche alten Projekte 1:1 laden. Das ist einfach vorbildlich, davon sollten sich alle anderen Firmen mal 'ne dicke Scheibe abschneiden.
Besonders schlimm ist es bei NI, die im Prinzip *exakt* das Gegenteil machen, da bekommt nicht nur jedes Plugin eine neue Versionsnummer, nein, die alten Versionen werden auch permanent eingestampft, sodass sie selbst kleinere Änderungen des Betriebssystems nicht mehr mitmachen. Warum heißt Kontakt nicht einfach nur Kontakt sondern Kontakt 1-8? Warum Absynth 1-5? Etc. Grauenvoll - zumal ja die neueren Versionen durchaus patch-kompatibel mit den alten sind. Da sind einfach am zugrundeliegenden Framework niemals die Hausaufgaben gemacht worden.

Ergo bleibt einem wohl nix anderes, als immer brav in Audio zu rendern, mit den damit einhergehenden Nachteilen.
 
Also, Danke @Sascha Franck , Du sprichst mir aus der Seele mit mehr Backroundwissen als ich es habe.
Stimmt, bei u-he gibts da nie Stress.

Für FabFilter habe ich jetzt zumindest ProQ2 noch gefunden und nur die VST3 Version installiert - zack 17 Spuren sind nun fehlerlos.

Immernoch fehlt mir der korrekte Einsatz des Ozone-Imagers, obwohl er ja da ist. :rolleyes:

Die alte Version war aus Ozone 8 und vermutlich bei Izozope gekauft.
Da mir Ozone 10 jetzt bei NI seit irgendeinem Komplettpaket "hinterher geworfen" wird, sah ich keinen Anlass, das alte Einzelzeug wieder zu installieren. Man soll schließlich alte "Zöpfe abschneiden".
Ich suche noch...
 
Zuletzt bearbeitet:
Warum heißt Kontakt nicht einfach nur Kontakt sondern Kontakt 1-8?

Das ändert sich ja wohl immer mal wieder, mal mit Versionsnummer, mal nicht.

Mein älteres Kontakt 6irgendwas heißt einfach nur Kontakt, das aktuelle Kontakt 8. Aktuell ist es noch praktisch, alte Projekte laden bei mir Kontakt 6, neue dann Version 8. Das Problem kommt erst dann, wenn Kontakt 6 die Libraries nicht mehr läd, weil sie für 8 upgedatet wurden.
 
Ergo bleibt einem wohl nix anderes, als immer brav in Audio zu rendern, mit den damit einhergehenden Nachteilen.
Oder halt mal ein Lied tatsächlich fertig machen.


Und so toll sind alte Projekte oft gar nicht, dass alles 1:1 wieder da sein muss. Ärgerlich ist aber, wenn zum Beispiel der Halion die Samples nicht mehr findet und man von Hand zuweisen muss. Das nervt.
 
Oder halt mal ein Lied tatsächlich fertig machen.

Damit hat das ja nicht zwingend zu tun. Ich habe bspw. etliche Sachen, die ich aus ganz anderen Gründen immer wieder öffne, ob es jetzt Templates für gewisse Dinge sind (Samples und IRs basteln), Übeprojekte (ja, gibt Leute, die das mal machen) oder mehr oder minder "Lehr-Projekte". Und dann natürlich sowas wie alte Bandsachen, denen man vielleicht nach vielen Jahren gerne mal einen neuen Aufguss verpassen will.
Gründe gibt's dafür wirklich mehr als genug.
 
wirklich tragisch ists wohl nur bei instrumenten, die sollte man halt bouncen zur sicherheit.

mixplugins a la eqs/comp/hall usw. sind mir in so einem fall dann recht egal -> wenn ich ein altes projekt nochmal angreife will ich ja ohnehin was ändern, neuere plugins einsetzen… oder die spur in neuem kontext einsetzen was auch eine neue bearbeitungskette erfordert.

technisch bedingt ist vollkommene abwärtskompatibilität nur bedingt realisierbar -> neue funktionen gibts ja nicht in den alten versionen, teilweise werden bestehende parameter angepasst (klanglich oder weiterer regelbereich) - deswegen schützen die unterschiedlichen plugin id’s einen zuverlässigen recall.
und das die hersteller die alten versionen ewig mitschleppen ist auch nicht wirklich wirtschaftlich machbar/sinnvoll weil es einfach extremer aufwand wäre und große rewritetes erfordern würde.

fabfilter macht das imho eh ganz gut bei pro-q … die alte version wird da noch einige jahre mitunterstützt. Q2 ist halt jetzt einfach seit >=7 Jahren Geschichte.
 
Achja, eine Sache, die ich wirklich auch versuche, ist, abgesehen von Dingen, zu denen es wirklich quasi keine Alternativen gibt, so viele von der benutzten DAW mitgelieferte Plugins wie möglich zu bemühen. An sich kommt man damit idR ja wirklich schon sehr weit und kann die Anzahl der Tracks, die man bei älteren, aufbewahrenswerten Projekten sicherheitshalber rausbouncen muss, vielleicht deutlich reduzieren.
 
Q2 ist halt jetzt einfach seit >=7 Jahren Geschichte.

Ein Song von 2018 darf also nicht mehr problemlos geöffnet werden können? (Na gut Q2 gibt's ja noch, aber wehe wenn nicht)

technisch bedingt ist vollkommene abwärtskompatibilität nur bedingt realisierbar -> neue funktionen gibts ja nicht in den alten versionen, teilweise werden bestehende parameter angepasst (klanglich oder weiterer regelbereich)
Warum? Aber die alten Funktionen können in den alten Versionen beibehalten werden. Und wenn Parameter angepasst werden dann muss das alte Plugin wie ein extra Plugin weiter gepflegt werden.
Denn:
und das die hersteller die alten versionen ewig mitschleppen ist auch nicht wirklich wirtschaftlich machbar/sinnvoll weil es einfach extremer aufwand wäre und große rewritetes erfordern würde.
Wenn die Firma das nicht macht, hat der Kunde die Arbeit.

Ich habe die letzten 3 Tage etwa 30 Songs geöffnet und bearbeitet. Jedes mal mehr oder weniger Gehuddel.
Ganz zu schweigen vom neuen Noteneditor, der mit der neuen Version quasi alles vergangene schreddert.
So viel zum Thema interne Plugins verwenden.
 
was heißt ‘darf’?

wenn es dir wichtig ist dass du deine projekte auch in 10 jahren noch klanglich 1:1 aufgehen musst du eben vorkehrungen dafür treffen -> sei es durch commiten von tracks (einfach gemuted/deaktiviert drunter legen oder in nen ordner und ausblenden), alten rechner behalten mit den alten versionen oder ne zweite platte mit dem alten betriebssystemstand-inkl. plugins

hindert dich niemand dran das zu machen.

wenn du das nicht gemacht hast war es dir anscheinend nicht wichtig genug dass du das auch 1:1 in zukunft aufbekommst.

bzgl plugin kompatibilität -> du musst ja auch in die andere seite denken, wenn die plugin id dieselbe ist muss auch die alte plugin version zuverlässig eine session öffnen können die mit ner neuen version erstellt wurde.

d.h. neue funktionen hinzufügen quasi nicht möglich, einen regelbereich erweitern höchst problematisch weil es die alte version dann anders interpretieren würde - mit klangauswirkungen von minimal bis dramatisch. session recall wird dann zum glückspiel.
und somit das tool in einem kollaborativen/professionellem umfeld nicht mehr zuverlässig verwendbar.

dh. eine neue plugin id muss her und das erklärt dann auch wieso du mit einem installieren q3/q4 nicht direkt einen q2 automatisch abbilden kannst sondern parameter händisch übertragen musst.
weiß nicht wie es bei q2 -> q3/4 aussieht aber alle q3 einstellungen lassen sich direkt in eine q4 instanz reinkopieren.

‘die hersteller müssen einfach weiter alte > 7 Jahr alte plugins pflegen’ -> sagen wir mal du bist musikproduzent und ein künstler der vor 7 Jahren mit dir was aufgenommen hat will jetzt für lau eine neue mixversion von dir. das ist aufwand für dich oder? du hast damals ja geld von ihm/dem label bekommen….. aber was wär da deine reaktion?
 
bzgl plugin kompatibilität -> du musst ja auch in die andere seite denken, wenn die plugin id dieselbe ist muss auch die alte plugin version zuverlässig eine session öffnen können die mit ner neuen version erstellt wurde.

Nein, das ist idR nicht notwendig, denn der Rechner ist dann ja so upgedatet, dass nur noch die neue Version läuft.
 
da kannst du dann halt nur für deinen persönlichen use-case sprechen aber nicht für den rest der welt.

sobald man kollaborativ im team arbeitet oder ein projekt in mehreren bearbeitungsschritten in verschiedenen studios/arbeitsplätze läuft wird das sehr wichtig.

ich verdiene meine brötchen hauptsächlich in der film-postpro und in der regel arbeiten da mindestens 5 leute in mindestens 5 verschiedenen arbeitsplätzen… da muss man sich drauf verlassen können dass session recall einwandfrei funktioniert und da bleibt auch keine zeit immer eine hand voll plugins zu überprüfen ob deren automationsdaten eh richtig geladen worden sind, grad auch weil sich die ja im verlauf des filmes ja die ganze zeit ändern.
 
sobald man kollaborativ im team arbeitet oder ein projekt in mehreren bearbeitungsschritten in verschiedenen studios/arbeitsplätze läuft wird das sehr wichtig.

Das ist ja schön und gut, aber es ändert ja, egal wie die Plugins gehalten werden, nichts daran, das ältere Versionen idR einfach mit neueren nicht kompatibel sind. Umgekehrt ist das hingegen nicht so, da sind fast alle neueren Versionen mit älteren kompatibel.

da muss man sich drauf verlassen können dass session recall einwandfrei funktioniert und da bleibt auch keine zeit immer eine hand voll plugins zu überprüfen ob deren automationsdaten eh richtig geladen worden sind, grad auch weil sich die ja im verlauf des filmes ja die ganze zeit ändern.

Und genau dafür müssen identische Plugin-Versionen vorliegen. Ist dann aber auch vollkommen egal, ob die Plugins dieselbe Plugin ID benutzen oder nicht - identische Versionen müssen so oder so vorhanden sein.

Es hat einfach niemand einen Vorteil davon, dass bspw. Kontakt in Versionen "aufgeteilt" wird. Es sei denn, du willst dich immer mit der "kleinsten gemeinsamen Nenner" Version begnügen. Dann dürfest du aber bei einer solchen Arbeitsweise nie aktuelle Plugins benutzen.
 
es geht um nachvollziehbarkeit.

ich hab lieber eine fehlermeldung: “hey plugin X fehlt und konnte deshalb auf track Y nicht aktiviert werden” -> dann kann ich aktiv entscheiden ob ich die alte oder neue version installiere, je nachdem was in dem fall sinnvoller ist damit ich 100%ige session recall hinbekomme.

wenns aber die gleiche plugin id ist dann kann man nicht wissen ob es eigentlich gleich klingt wie mit der alten version, weil der eingebaute hall in der neuen version besser klingt, oder bei gleicher einstellung 10% mehr wet klingt, oder mein drive regler in der alten version jetzt auf 100% steht weil der regelbereich in der neuen version insgesamt weiter ist und demnach die werte falsch interpretiert werden - es muss ja alles in den automationslinien der daw abgebildet werden können. demnach kann man das nicht im plugin selber ablegen und regeln, weil das würde heißen man müsste auch alle plugin einstellungen und automationen extern verwalten.

was ihr vorschlägt wäre so wie wenn ein hihat sample fehlt und das system automatisch ohne nachfragen dann ein anderes sample verwendet was ‘eh ähnlich klingt’. kann funktionieren, kann aber auch deutlich anders sein weil die bearbeitungskette danach kleinste nuancen aufbläst.
 
Ganz zu schweigen vom neuen Noteneditor, der mit der neuen Version quasi alles vergangene schreddert.
Das ist aus meiner Sicht der einzige Vorwurf, den man Steinberg in Richtung Abwärtskompatibilität machen kann.
Wenn man mal von einigen inzwischen gecancelten Steinberg-Plugins absieht, kann man in C14 immer noch Projekte laden, die mal vor >20 Jahren mit Cubase SX erstellt worden sind.
Und da man mit der C14-Lizenz weiterhin (donglefrei) mit C12 und C13 arbeiten kann und sich alle Versionen bestens nebeneinander vertragen, kann man im Bedarfsfall diese älteren Versionen zum schnellen Editieren der Noten verwenden.
 
es geht um nachvollziehbarkeit.

Ja klar, aber auch da macht es doch überhaupt keinen Unterschied, ob die Plugin-ID gleichbleibt.

wenns aber die gleiche plugin id ist dann kann man nicht wissen ob es eigentlich gleich klingt wie mit der alten version

Das muss so nicht sein. Sobald die Plugin Version älter ist, wird das Plugin einfach nicht geladen, vollkommen unabhängig von der Plugin ID - die kann ohne weiteres die gleiche bleiben. Der einzige Unterschied wäre die Fehlermeldung.
In einem Fall wäre es "plugin Kontakt 7 missing", im anderen "this project is using a newer version of Kontakt" (idealerweise mit angegebener Versionsnummer).

Nachteile gibt's da keine. Wenn du mit Kontakt 7 arbeitest, dein Kollege aber mit Kontakt 6, kann er deine Files natürlich nicht total recallen. Und du aber auch nicht seine, weil die Plugin ID eine andere ist. Wenn es in beiden Fällen nur "Kontakt" wäre, könnte er zwar nach wie vor deine Projekte nicht 1:1 laden, du aber immerhin seine. Ganz klarer Vorteil für die Variante.
Und ein noch klarerer Vorteil für haufenweise Leute, die sich nämlich jetzt immer und immer wieder mit dem Versionsnummerärger rumquälen müssen.
 
Da hilft nur eines: überlegen, was mann am System wie ändert.

Upgrades von Q2 auf Q3/Q4 sind doch ein gutes Beispiel.

Wenn ich Q3 installiere und Q2 deinstallieren will, sollte ich das in dem Moment testen, wie sich das auf "alte" Daten auswirkt.

In dem Moment würde mann ja merken, Q2 wird eben aus Kompatibilitätsgründen noch gebraucht. Also keine Deinstallation. Frisst auch kein Brot.

Der nächste Gedanke sollte sein, dann auch alle Installer/Lizenzunterlagen aufzubewahren.

-> Problem gelöst.

Ich habe mein ehem. Windows XP-System in eine VM umziehen lassen, ist nicht sonderlich performant, genügt aber, um so ziemlich alle altertümlichen Werke immer noch öffnen zu können, um sie dann nachbauen zu können.
 

Similar threads

seleph
Antworten
2
Aufrufe
2K
FriedemannKootz
FriedemannKootz

Oft gelesene Themen

Zurück
Oben