Werden in Cubase PlugIn Einstellungen mit dem Song gespeichert?

electric guillaume

keine Information
Wenn ich Cubase Songs speichere und dabei Drittanbieter Plugins mit eigenen Sounds verwende, werden diese beim erneuten Laden des Projekts auch wieder mit den korrekten Sounds geladen. Auch wenn ich die Sounds nicht explizit im Plugin gespeichert habe.
Hintergrund meiner Frage ist, dass in den nächsten Monaten ein Rechnerwechsel ansteht und ich einige alte Projekte nochmal angehen möchte. Leider habe ich nicht immer alle klanglichen Eigenkreationen separat abgespeichert, sondern einfach nur das Projekt.
Jetzt frage ich mich ob ich diese Projekte alle nochmal aufrufen muss um alle selbstgebauten Sounds dezidiert als eigene Sounds im Plugin zu speichern oder ob das doch nicht nötig ist, da diese Daten mit dem Song gespeichert werden.
Natürlich werde ich die entsprechenden VSTs auch auf dem neuen Rechner installieren.
So ganz konkret habe ich dazu auf die schnelle nichts gefunden.
 
Das ist gut.
Klar, wenn ein Plugin auf irgendeine interne oder externe Sample Library zugreift, dann muss ich diese natürlich wieder mit installieren.
Aber mir reicht es im Prinzip wenn die zuletzt eingestellten Parameter des Plugins mit dem Song abgespeichert werden.
Damit wird ja das Sample dann auf dem neuen Rechner genauso verwurstet wie auf dem alten.
 
Wenn ich Cubase Songs speichere und dabei Drittanbieter Plugins mit eigenen Sounds verwende, werden diese beim erneuten Laden des Projekts auch wieder mit den korrekten Sounds geladen. Auch wenn ich die Sounds nicht explizit im Plugin gespeichert habe.

in plug-ins kannst du sowieso nichts speichern.

die preset speicherplätze in einem plug-in, egal wo deren inhalt herkommt, sind nach dem laden des plug-ins einfach teil der projektdatei des hostprogramms (also z.b. cubase arrangement oder cubase song.) das ist in allen wysiwyg apps so.

diese presets blieben in einen neu geöffneten projet auch erhalten, wenn das plug-in fehlen sollte. erst wenn man ein anderes an dieser stelle öffnet gingen sie verloren.

Hintergrund meiner Frage ist, dass in den nächsten Monaten ein Rechnerwechsel ansteht und ich einige alte Projekte nochmal angehen möchte. Leider habe ich nicht immer alle klanglichen Eigenkreationen separat abgespeichert, sondern einfach nur das Projekt.

für die presets ist das vollkommen ausreichend.

probleme bekommst du nur mit den plug-ins selbst. da hat man schnell mal etwas nicht mehr in der alten version da, die authorisierung vergessen oder etwas am falschen ort abgelegt.
 
Zuletzt bearbeitet:
Deshalb der blödeste Tipp überhaupt:

Immer alles rendern!

Total Recall braucht man nur, wenn man nicht gezielt arbeiten kann.

Grund genug mal seinen Workflow zu überdenken.
 
naja oder das speichermedium klonen.

geht aber auch nicht immer und überall mit 3 clicks, u.u. hat der neue rechner ein neues filesystem oder die hälfte deiner plug-ins ist ethernet-based geschützt o.ä.

ansonsten habt man natürlich den alten rechner erst mal auf und hat sicherungkopien im schrank. ;-)
 
So? Welchen Grund hätte es denn, eine beteits perfekt bearbeitete Spur nochmal anzufassen? 😉😜
 
So? Welchen Grund hätte es denn, eine beteits perfekt bearbeitete Spur nochmal anzufassen? 😉😜
Perfekt im Kontext des Tracks? Es kann sicher immer etwas ändern.

Das ist doch eben das Gute daran: Man kann die Dinge immer ändern. Im Gegensatz zu gerendert. Ich sehe das jedenfalls als Riesenvorteil.

Nimm mir den Seitenhieb nicht krumm, aber, das klingt etwas danach, als wolltest du dir deinen Hardware-Workflow schöntrinken. 😉
 
Mit Hardware hat es nichts zu tun.

Die Unmöglichkeit einer Änderung macht was mit dir, deiner Kreativität und wieviel Mühe du hineinsteckst.

Zeichne ich eine Controllerbewegung auf, die ich eh noch ändern kann, was ich auch mache, damit sie perfekt on point ist, klingt sie direkt verunmenschlicht und das zieht sich durch die gesamte Musik. Humanizing und Fehler hingegen machen das Ergebnis möglicherweise objektiv schlechter, subjektiv besser.
 
die preset speicherplätze in einem plug-in, egal wo deren inhalt herkommt, sind nach dem laden des plug-ins einfach teil der projektdatei des hostprogramms (also z.b. cubase arrangement oder cubase song.) das ist in allen wysiwyg apps so.
vielleicht nur etwas missverstänlich formuliert, aber meines Wissens werden Plugin-Presets global (also nicht im jeweiligen DAW-Projekt, sondern in der allgemeinen Library des Users bzw. der DAW) abgelegt. Sonst wären sie ja nur in dem Projekt verfügbar, in dem sie abgespeichert wurden. Projektspezifisch sind selbstverständlich die nicht als Userpreset abgespeicherten Einstellungen der Plugins (darauf bezieht sich vermutlich das "nach dem laden").
 
Für Presets gibts nen Ordner, Einstellungen hingegen werden im Song gespeichert und wer ganz plietsch ist, macht sich Screenshots für die Ewigkeit.
 
Mit Hardware hat es nichts zu tun.

Die Unmöglichkeit einer Änderung macht was mit dir, deiner Kreativität und wieviel Mühe du hineinsteckst.

Zeichne ich eine Controllerbewegung auf, die ich eh noch ändern kann, was ich auch mache, damit sie perfekt on point ist, klingt sie direkt verunmenschlicht und das zieht sich durch die gesamte Musik. Humanizing und Fehler hingegen machen das Ergebnis möglicherweise objektiv schlechter, subjektiv besser.
Naja, das ist dann eher eine Beschränkung, die du dir freiwillig aufzwingst. Objektiv ist es definitiv flexibler, wenn du die einzelne Spur im Kontext des Tracks später ändern kannst. Und, nicht nur das, du hast sogar dann auch noch die Möglichkeit, den Track zu freezen oder zu rendern, wenn man das denn will. Letzteres würde ich nur machen, um CPU zu sparen, wenn diese am Limit ist.

Nicht umsonst bieten DAWs heutzutage ja all diese Flexibilität.
 
Natürlich.

Da gehen dann die Ansprüche auseinander.
Höchstmögliche Flexibilität passt dann aber mehr in den professionellen Bereich, bei dem man strugglenden Kunden gerecht werden möchte.

Wer künstlerisch für sich tätig ist, könnte durch Einschränkung inspirativ profitieren.
 
vielleicht nur etwas missverstänlich formuliert, aber meines Wissens werden Plugin-Presets global (also nicht im jeweiligen DAW-Projekt, sondern in der allgemeinen Library des Users bzw. der DAW) abgelegt. Sonst wären sie ja nur in dem Projekt verfügbar, in dem sie abgespeichert wurden.

sind sie auch nur. was willst du denn mit dem preset aus song A in song B. :)

Projektspezifisch sind selbstverständlich die nicht als Userpreset abgespeicherten Einstellungen der Plugins (darauf bezieht sich vermutlich das "nach dem laden").

ja das ist richtig. wenn ein plug-in mehr als 1 preset slot hat, dann werden natürlich in der projektdatei immer nur die preset einstellugnen abgespeichert, die gegenüber dem, was im plug-in selbst als presets war, verändert wurden.

beispiel: du öffnest #synth. #synth hat 8 presets. du schreubst an dreien dieser presets herum und wählst schließlich einen davon aus. die drei veränderten sind jetzt in der projektdatei verzeichnet.

nach dem nächsten laden lädt erst die host das plug-in, und danach werden die änderungen in den 3 presets über die default werte drübergeschrieben.


das ganze spiel funktioniert mit den diversen plug-in spezifischen preset browsern, dem laden von bänken und presets aus dateien oder mit hardware remotes und MIDI CCs exakt genauso: in dem moment, wo ein speicherplatz gegenüber dem im plug-in enthaltenen factory preset geändert wird, landet diese info in der projektdatei, damit der zustand wiederhergestellt werden kann.
 
man vergegenwärtige sich einfach mal, wie das zwangsläufig organisiert sein muss, wenn im ergebnis in einem projekt 2 instanzen des gleichen plug-ins mit unterschiedlichen einstellungen geladen waren.
 
sind sie auch nur. was willst du denn mit dem preset aus song A in song B. :)
Nein: Bei meinen Softsynths erstelle ich manchmal einfach so mehrere Presets, die ich dann in beliebigen Projekten verwenden kann. Die sind alle global abgelegt. :dunno:
Auch wenn ich tatsächlich die meisten Presets nur in einem Track nutze, verhält sich der Presetspeicher anders.

ja das ist richtig. wenn ein plug-in mehr als 1 preset slot hat, dann werden natürlich in der projektdatei immer nur die preset einstellugnen abgespeichert, die gegenüber dem, was im plug-in selbst als presets war, verändert wurden.
ich bezweifle, dass nur das Delta gespeichert wird, sonst würde sich der Sound in einem Projekt ändern, wenn man irgendwo anders das Preset ändert. Könnte natürlich vom Synth abhängen und müsste man ggf. mal ausprobieren. Spontan wäre ich jetzt davon ausgegangen, dass sobald ich ein Preset lade und auch nur einen Parameter ändere, der gesamte Editbuffer des Synths im Projekt abgelegt wird.
 
man vergegenwärtige sich einfach mal, wie das zwangsläufig organisiert sein muss, wenn im ergebnis in einem projekt 2 instanzen des gleichen plug-ins mit unterschiedlichen einstellungen geladen waren.

Passiert mir heute immer noch, wenn ich aus Kompatiblitätsgründen haha VST2 und 3 installiert habe und da
dann durcheinander komme. Irgendwann VST2 rausgeschmissen und Zack muss wieder installiert werden.

Was für´n scheiß! Wieso fragt das Programm nicht, ob anstatt 2 die 3 geladen werden soll?
Selbst nach Update, in dem die Reviision im Pluginnamen steht. Wer denkt sich sowas aus?

Ich kann da gut den Programmier verstehen, womöglich sieht das VST halt nicht vor, aber
da ist dann Steinberg "schuld" .. obwohl ... bei AU und co ist das wahrscheinlich ähnlich
 
Nein: Bei meinen Softsynths erstelle ich manchmal einfach so mehrere Presets, die ich dann in beliebigen Projekten verwenden kann. Die sind alle global abgelegt. :dunno:

das widerspricht sich nicht im geringsten untereinander.

es wäre ein ding der unmöglichkeit host programmen beizubringen wo und wie sie diese internen plug-in preset dateien laden sollen, dann hätte man damit auch noch das theater, was wir von dateipfaden zu samples in plug-in presets kennen.

alles, was sich zwischen der applikation und dem plug-in dokument abspielt, folgt festgelegten standards, das ist das, was wir zusammengefasst "VST" oder "AAX" nennen. ein plug-in hat einen unique identifier name, wenn man in einem projekt eines lädt, bekommt das intern eine ID, dann wird es gefragt wieviele preset es hat, dann werden diese presets mitgeladen.

getParameterCount(), getParameterInfo(), getParameter() & setParameter() usw. usf.

selbst eine asynchrone übertragung von parameteränderungen wäre noch teil solcher plug-in APIs.

erst bei der frage ob und wie die plug-in parameter mit einer projektdatei abgespeichert werden um damit beim init die defaults zu überscheiben macht dann jeder, was er will.

wobei das abspeichern zwar propertiär ist aber auch nicht besonders aufregend, im regelfall machen die da einfach eine liste aus ID (LONG) und wert (heutzutage float64), alles andere liefert dir morgen ja wieder das plug-in beim laden.

Auch wenn ich tatsächlich die meisten Presets nur in einem Track nutze, verhält sich der Presetspeicher anders.

natürlich hätte niemand etwas dagegen, wenn es auch einen standard für presetmanagement gäbe und man grundsätzlich in allen plug-ins eine unbegrenzte anzahl an plätzen hätten, die zentral im OS gespeichert werden.

aber das hattest du nicht mal mit sounddiver und "studiosetup", wir sind das chaos doch gewohnt. :)

ich bezweifle, dass nur das Delta gespeichert wird, sonst würde sich der Sound in einem Projekt ändern, wenn man irgendwo anders das Preset ändert. Könnte natürlich vom Synth abhängen und müsste man ggf. mal ausprobieren.

verstehe nicht was du damit meinst... innerhalb eines projekts ist immer alles identifizierbar.

Spontan wäre ich jetzt davon ausgegangen, dass sobald ich ein Preset lade und auch nur einen Parameter ändere, der gesamte Editbuffer des Synths im Projekt abgelegt wird.

...aber eine host kann in der tat genausogut einfach immer alle presets plätze (aka bank) mitspiegeln und sich die nur komplett merken. ist ja immerhin einfacher zu verwalten als nur die änderungen gegenüber dem post-init status der parameter.
ist halt nur auch irgendwann eine größere datenmenge, aber du könntest durchaus recht haben, dass es mehrheitlich so gemacht wird.
 
Zuletzt bearbeitet:
Passiert mir heute immer noch, wenn ich aus Kompatiblitätsgründen haha VST2 und 3 installiert habe und da
dann durcheinander komme. Irgendwann VST2 rausgeschmissen und Zack muss wieder installiert werden.

ja, weil die hersteller sich dafür entscheiden müssen, ob sie beim API- und/oder funktionsupdate ihres plug-ins dem produkt eine neue ID geben oder nicht, und egal wie man sich entscheidet, nichts davon ist perfekt.

sehr geil war das früher auch mit der waveshell.

Was für´n scheiß! Wieso fragt das Programm nicht, ob anstatt 2 die 3 geladen werden soll?

sowas fängt ja bei betriebssysteme schon an... manchmal werden zuweisungen nach erstellungsdatum vorgenommen und manchmal nach versionsnummer...

wenn man bildschirmsüchtig ist, ist das ganze leben ein workaround.

aber da ist dann Steinberg "schuld" .. obwohl ... bei AU und co ist das wahrscheinlich ähnlich

so ist es. schuld ist immer der andere. problem gelöst.
 
es wäre ein ding der unmöglichkeit host programmen beizubringen wo und wie sie diese internen plug-in preset dateien laden sollen, dann hätte man damit auch noch das theater, was wir von dateipfaden zu samples in plug-in presets kennen.
ich weiß nicht, wie das unter Windows läuft, aber am Mac liegen die z.B. hier:

presets.png

und daran scheinen sich auch die meisten Hersteller zu halten. Im Projektverzeichnis liegen bestenfalls abweichende Einstellungen (und die sind soweit ich weiß in der Projectdata-Datei mitcodiert, und lassen sich nicht ohne weiteres von einem Projekt in ein anderes exportieren).

Öffne ich in Logic Projekt A, erstelle dort ein Preset mit einem Softsynth, landet es in der Library (siehe Screenshot). Öffne ich nun Projekt B und erstelle dort eine Instanz des selben Softsynths kann ich das vorher in einem anderen Projekt erstellte Preset selbstverständlich öffnen.

wie die Datenmodelle und Interfaces zum Laden/Sichern etc. unter der Haube aussehen, interessiert mich dabei nicht (bzw. brauchst du mir das nicht zu erklären, bin selbst Entwickler). Aber vielleicht haben wir uns auch einfach missverstanden. :dunno:
 
ich weiß nicht, wie das unter Windows läuft, aber am Mac liegen die z.B. hier:

die haben auch sowas, nur doppelt so viele pfade.

und daran scheinen sich auch die meisten Hersteller zu halten.

es gibt immer noch auch welche die eigenformate benutzen :/

Im Projektverzeichnis liegen bestenfalls abweichende Einstellungen (und die sind soweit ich weiß in der Projectdata-Datei mitcodiert, und lassen sich nicht ohne weiteres von einem Projekt in ein anderes exportieren).

Öffne ich in Logic Projekt A, erstelle dort ein Preset mit einem Softsynth, landet es in der Library (siehe Screenshot). Öffne ich nun Projekt B und erstelle dort eine Instanz des selben Softsynths kann ich das vorher in einem anderen Projekt erstellte Preset selbstverständlich öffnen.

klar, aber doch nur weil das plug-in das kann, oder? die host kennt doch ansonsten schon das verzeichnis /cherryaudio nicht mehr und von einer library weiß die host dann nichts.

du kannst ja in einer DAW genausogut auch eine beliebige preset-datei von einem wunsch-pfad laden. für diese funktion braucht es keine default locations.

dass der parameter status komplett mitgespeichert wird ist in jedem falle zwingend, wegen der portability des projekts (dem hiesigen kontext)


ich hätte wie gesagt nix dagegen wenn es einfach pflicht wäre dass alle plug-ins einen filebrowser hätten, dann könnte sich das jeder so einrichten wie er lust hätte. :)

in meinen eigenen programmen lade ich plug-ins meistens per drag and drop - und speichere presets in eigenformaten auf knopfdruck direkt im verzeichnis wo das programm selbst liegt. eine art generische preset library habe ich auch, die hatte auf MacOS9 sonst keiner an bord. aber ich esse ja auch bratfisch mit schokosauce und erwarte dann, dass andere das ernst nehmen und nachmachen.
 
Zuletzt bearbeitet:
die host kennt doch ansonsten schon das verzeichnis /cherryaudio nicht mehr und von einer library weiß die host dann nichts.
nichts anderes habe ich behauptet. :)
Genauer gesagt: Bei Logic gibt es noch ein eigenes globales Verzeichnis für Pluginparameter, dass sämtliche für die DAW sichtbaren Parameter abspeichert - liegt auch in /user/library, aber an einem etwas anderen Ort.

dass der parameter status komplett mitgespeichert wird ist in jedem falle zwingend, wegen der portability des projekts (dem hiesigen kontext)
Ja - aber ich bin wie gesagt davon ausgegangen, dass das erst passiert, wenn man irgendeinen Parameter ändert. Lädt man ein Patch aus dem Standardpool, speichert das Projekt ab, öffnet ein zweites Projekt, in dem man den Patch ändert, und kehrt dann zum ersten Projekt zurück, müsste dort das geänderte Patch zu hören sein (sofern man nichts an den Reglern verstellt hat). Gebe aber zu, dass das erstmal nur eine Vermutung war, ausprobiert habe ich es noch nicht, und möglicherweise verhalten sich die DAW hier auch unterschiedlich. 🤷‍♂️
 
egal wo die änderung herkommt, sie muss immer direkt im projekt abgespeichert werden.

es sei denn natürlich es handelt sich um eine spezielle funktion in einer host, die das aus #gründen nicht haben will. das ist ja dann eigentlich nix anderes wie eine undo funktion. (ich persönlich lade dazu einfach eine zusätzlich instanz des gleichen plug-ins im hintergrund, die ich als edit buffer missbrauche^^)

das einzige was man nicht abspeichern muss sind die factory einstellungen aus dem plug-in dokument, weil die ja eh bei jedem laden abgerufen werden.


ich bemerke gerade, dass steinberg ja 1995 das schon mal versucht hatte zusätzlich zu den internen einstellungen solche factories auch an feste pfade neben dem plug-in dokument zu schreiben. das war bei 3 oder 4 produkten mal so und ich habe das nie verstanden warum das nicht auf variable/mehrere bänke ausgeweitet wurde weil es ein guter kompromiss zwischen dem digidesign-"befolge gefälligst unsere regeln und habe alles zetnral im systemordner" und dem "schau doch selber zu wie du presets exportierst und verwaltest" gewesen wäre.

jede organisation hat seine grenzen. es gibt auch hosts, die automatisch die AU version laden wenn beide, AU und VST, gefunden werden. da ist der pfad zu einer presetdatei dann auch wieder variabel, trotz plicht-pfaden von apple.
 


Neueste Beiträge

News

Zurück
Oben