Hallo
Unlängst wollte ich endlich mal Virgin Territorys ausprobieren, habe die Funktion in den Automationseinstellungen aktiviert und mal in einer Audiospur eine Lautstärke-Automation gesetzt. Die erwarteten Lücken bei Nichtbewegung des Faders blieben aber aus. Beim Löschen von Automationspunken entstanden ebenfalls keine Lücken. Mehrmals probiert und Folgendes festgestellt: Cubase 8.5 verändert offenbar minimal den Wert der Anfangs- oder Endpunkte an den statischen Stellen, so daß es ein komplett dynamischer Verlauf bleibt. Beispiel: Bei -11.2dB lasse ich den Fader los, statt einer Lücke entsteht eine gerade Linie, nehme ich wieder Änderungen vor, wird eine Kurve generiert. Dies alles wäre normal, wenn die Virgin Territory-Funktion deaktiviert wäre. Bei mir ist sie aber jetzt aktiv. Beim Stoppen der Automation sehe ich zufällig, daß die vorher gerade Linie plötzlich leicht schräg ist. Ich kontrolliere die Werte des Anfangs- und Endpunktes und stelle fest, daß der Endpunkt nicht mehr bei -11.2dB sondern bei -10.8dB steht. Mehrmals hab ich neu getestet, immer wieder das gleiche Ergebnis. Ich gehe davon aus, daß es sich hier um einen Bug handelt, denn bei Cubase 8.0 (Wo diese Funktion eingeführt wurde) klappt alles wunderbar.
Also da ich gerade recht viel mit Automation mache und Aktuell mit 8.5.10 arbeite kann ich sagen, bei mir Funktioniert alles, wirklich tatellos! Bin selbst total sprachlos 
Das Verhalten ist normal. Ich vermute mal, dass du eine recht hohe Buffersize eingestellt hast. Je nach Größe der gepufferten Datenblöcke dauert es einen Moment, bis der beim Aufzeichnen einer Automation eingestellte Wert auch gespeichert wird. Wenn du also möglichst exakte Automationen Aufzeichnen möchtest, musst du die Buffer-Size heruntersetzen.
Bei den Virgin Territories ist es meines Wissens nach so, dass nur Abschnitte freigelassen werden, an denen keine Automation aufgezeichnet wurde.
Eben! Und dort wo es keine Automation gab, bleibt die Linie statt eine Lücke. Die Buffersize zwischen C 8.0 und C 8.5 ist bei mir identisch, warum gibt es dann bei C 8.0 keine derartigen Probleme? Und was verstehst Du unter „einen Moment?" Die falschen Endwerte bleiben , egal wie lange ich dem Programm Zeit gebe. Für mich geht dadurch die Welt bestimmt nicht unter, aber mein System ist sicher nicht das Schwächste.
Na ja Normal ist das nicht, aber…
Auch ich musste schon festellen das bei sehr hoher Latenz (50ms) die Automation schon mal spint.
Ich empfehle wie Svengali schon angedeutet hat, die latenz zumindest 1x kurzzeitig herunter zu setzen kurze Automation schreiben und dann die Latenz wieder hoch setzen, aber nur so weit wie Unbeding nötig!
Das hat nichts mit Schwäche des Systems zu tun, dass liegt an der Daten-Streaming-Technologie. Je größer die gepufferten Datenpakete sind, desto länger dauert es bis ein neues Datenpaket am Ziel ankommt. Man kann das auch deutlich an Automatiosnkurven erkennen. Bei großen Pufferblöcken weisen diese deutliche Treppenartefakte auf. Es gab gerade zu diesem Thema einen ausführlichen Thread im englischen Forum mit anschaulichen Grafiken.
Ich versuchs mal. 8.5.10 hab ich jetzt auch heruntergeladen, mal sehen, ob es was bringt
So, habe auf 8.5.15 geupdatet und auch die Buffersize verändert - ohne Erfolg. Trotz identischer Einstellungen funktioniert Virgin Territorys in C 8.0 aber tadellos und wenn ich das dort gespeicherte Projekt wieder mit C 8.5 öffne, wird VT korrekt (also mit Lücken) dargestellt, aber nicht, wenn ich dort Automationen aufzeichne.
Das mit den Lücken kann man doch einstellen ob mit oder ohne !
Schau mal die Treat Überschrift an …Das ist ja Virgin Territory
Ich habe es gestern mal mit 8.5.15 getestet. Hier funktioniert alles so wie von saxon8027 beschrieben. Wenn keine Werte bei der Aufzeichnung geändert werden, bleiben die Lücken leer. Es gibt allerdings die Einstellung “Fill - Gaps” im Automationsmenü. Diese füllt die Lücken nach der Aufzeichnung automatisch mit Linien. Vielleicht ist diese bei dir aktiviert?
Nebenbei gefragt, ist bei euch das Automationsmenü auch in Englisch?
Außerdem muss ich noch mal eine Fehlinformation meinerseits richtigstellen. Natürlich unterliegen nicht die Automationsdaten der Daten-Pufferverzögerung des Audiostreams, sondern das automatisierte Audiomaterial selbst, beim exportieren/rendern/bouncen. Es ist also ratsam für eine genaue Automationssteuerung die Buffer-Size beim Exportieren herunterzusetzen. Das hat also nichts mit der ungenauen Automationsaufzeichnung bei saxon8027 zu tun. Hier stellt sich die Frage wie du die Werte bei der Aufzeichnung eingibst? Kann es hier eventuell zu Verzögerungen Ungenauigkeiten kommen?
Das Problem scheint gelöst. Ich habe diese Funktion nach dem Ansehen eines Video-Tutorials von Holger Steinbrink ausprobiert und die exakt gleichen Einstellungen gehabt. Trotzdem ging es nicht. Jetzt habe ich mal den globalen Automationsmodus von „Auto-Latch" auf „Touch" geändert (ohne recht zu wissen, was das bedeutet) und die Virgin Territorys entstehen endlich so wie sie sollen schon während der Aufnahme. Die im Tutorial gezeigte Möglichkeit bei aktivierten VT Teile der Automation im nachhinein zu markieren und zu löschen, so daß auch dort Lücken entstehen, funktioniert allerdings nach wie vor nicht. In diesem Fall werden die äußeren Punkte wieder mit einer Linie verbunden. „Fill Gaps" war bei mir übrigens nicht aktiviert.
Ja, das ergibt Sinn. Bei “Touch” wird nur so lange Automation aufgezeichnet, wie der Regler berührt wird. Bei “Auto-Latch” so lange wie die Aufzeichnung läuft.
Sehr interessant! Mir ist das zwar selbst auch schon öfter mal aufgefallen und ich meine auch, davon schon mal gehört zu haben, aber dass das (in einigen Fällen) so krass ist, hätte ich nicht gedacht.
Das gehört aber sowas von verbessert! Da wünscht man sich jahrelang Bezierkurven, für genauere (und natürlich auch einfachere) Automationen und dann sowas…
Stellt sich die Frage, ob sich das Umstellen vorm Mixdown überhaupt lohnt, wenn man die ganze Zeit mit einem höheren Buffer arbeitet, oder ob sich das nicht sogar kontraproduktiv auswirkt. Theoretisch würde man diese Fehler ja dann schon vorher berücksichtigen und durch Anpassung der Automation ggf. kompensieren.
Danke jedenfalls für den Hinweis, hier ist der Thread für die, die es interessiert und sorry für OT.
Aber siehe hier: https://www.steinberg.net/forums/viewtopic.php?t=94217&p=523819#p524351. Die Artefakte beziehen sich auf die gebouncten Audiospuren und nicht auf die aufgezeichneten Automationskurven! Das ist natürlich logisch wenn die eine hohe Audiolatenz eingestellt hast. Da gibt es auch nichts zu verbessern außer eben eine niedrige Buffer-Size beim bouncen einstellen.
Bezier-Kurven für die Automation ist ein anderes Thema. Die würde ich aber auch gerne sehen.
Ja, aber die gebouncten Spuren sind ja auch das, was man man beim Abspielem des Projekts hört. Wenn man mit einem hohen Puffer produziert und alles so klingt, wie es sein soll, dann müsste es ja beim Mixdown mit niedrigerem Puffer anders (genauer) klingen. Und die Frage ist, ob das dann von Vorteil wäre, wenns vorher “perfekt” war, oder habe ich da einen Denkfehler.
Ich habe mir zum Thema auch noch andere Beiträge im englischen Forum angesehen und zumindest meinte da jemand, dass das bei FL wohl nicht so sei, da dort ne andere Engine arbeiten würde (oder so…).
Dadurch, dass das Resultat der Automation (nach dem Mixdown) in einigen Beispielen nach vorne verschoben wurde, müsste ja im Hintergrund irgendwie ein gewisser Ausgleich stattgefunden haben, der aber anscheinend nicht optimal funktioniert.
Ja, da gebe ich dir recht! Warum sollte nicht auch für die Automationsdaten ein Verzögerungsausgleich (Delay Compensation) wie bei Plugins möglich sein? Also gibt es hier doch was zu verbessern.