Latency Plugins Bypass

[musicdevil]

Ehrlich gesagt ist meine eigene Arbeitsweise da eh eine ganz andere.
Ich exportiere meinen Mix und nenne ihn zb. "für Vocals" und lade den dann in nen neues Songfenster, wo ich dann zb. 20 Vocalspuren aufnehme, bearbeite usw. und dann nur diese bearbeitete Vocalspur wieder in den ursprünglichen Song lade. Mach ich bei Gitarren auch öfter so.

Und zweite Sache ist, dass ich auch Plugins meide, welche eine hohe Latenz erzeugen.
Hab zwar auch Ozone im Einsatz, allerdings weiß ich es da und kann es mal schnell wenn nötig per Hand deaktivieren.
Wären sonst überwiegend Slate Digital Plugins (VTM, FG-X) und ansonsten liegen die Meisten bei unter 1 ms gesamt (Phönixverb, Lexicon, Decimort...)
Zum Glück summiert sich das ja nicht, sondern es gilt immer der Wert, welchen das Plugin mit der höchsten Latenz erzeugt.

 

[chrisspeed]

Aber nur weil die Arbeitsweise anders ist, kann es doch nicht richtig sein, andere zu überzeugen, dass ihr Wunsch "Quatsch" ist, oder?

Was würdest du denn sagen, wenn das Feature in Studio One enthalten wäre und in nicht in Cubase?
Dann wäre es das Feature schlecht hin.....

 

[Beatback]

Dass deine Ampsim erhalten bleibt, ist ja schön, hast allerdings eine, welche ne bestimmte Latenz erreicht, wäre die in Cubase ja auch stumm.

Kommt ganz darauf an was man als Latenz in den Prefs eingestellt hat.
Ich habe mir das auch schon für die Ampsims eingestellt mit dem ich noch als Latenz beim Einspielen leben kann.

Es ist auch bei elektronischem sehr wichtig wenn man mit Arpeggiatoren oder Chordern in Echtzeit arbeitet und die noten genau im Timing aufnehmen will.
Ich habe da meine gesamte Masteringkette von vornherein drauf um mir ein Bild vom Gesamten zu machen und schalte dann zum Einspielen die "hochlatenzigen" Plugins vorrübergehend aus.
Damit ist das aber gleich im Kasten und ich muss da nichts mehr verschieben oder quantisieren.

 

[musicdevil]

Aber nur weil die Arbeitsweise anders ist, kann es doch nicht richtig sein, andere zu überzeugen, dass ihr Wunsch "Quatsch" ist, oder?

Was würdest du denn sagen, wenn das Feature in Studio One enthalten wäre und in nicht in Cubase?
Dann wäre es das Feature schlecht hin.....

Doch, denn das willkürliche deaktivieren von Plugins ab einem bestimmten Wert, ist für mich eher suboptimal. Besser wäre, wenn wie gesagt die Latenz weg wäre und trotzdem kein Plugin deaktiviert werden müsste. So ein Button an sich wäre sinnvoll, aber bitte nicht wie in Cubase.
Ich plädiere da ja einfach nur für eine bessere Lösung, sofern es diese gäbe.

 

[Saurus]

 

[Beatback]

Doch, denn das willkürliche deaktivieren von Plugins ab einem bestimmten Wert, ist für mich eher suboptimal. Besser wäre, wenn wie gesagt die Latenz weg wäre und trotzdem kein Plugin deaktiviert werden müsste. So ein Button an sich wäre sinnvoll, aber bitte nicht wie in Cubase.
Ich plädiere da ja einfach nur für eine bessere Lösung, sofern es diese gäbe.

Wie soll das gehen bei 3rd Party plugins?
Wie willst du die Latenz vom Plugin überbrücken?
Das geht technisch überhaupt nicht, wenn das plugin aktiv ist und intern einen Lookahead hat ......????!!!!!

 

[organix]

Wie willst du die Latenz vom Plugin überbrücken?
Das geht technisch überhaupt nicht, wenn das plugin aktiv ist und intern einen Lookahead hat

Dem Musicdevil geht es prinzipiell um die Lösung für das Problem, hohe Latenz = schlecht für Softwaremonitoring, und nicht speziell auf die Art- und Weise wie es Cubase macht.

Weil vielleicht findet sich da ein anderer Lösungsweg als einfach nur Plugins in Abhängigkeit zu deaktivieren. In einem Punkt gebe ich Musicdevil absolut recht, das Deaktivieren von Plugins kann zu seltsamen Ergebnissen des Playback führen und damit auch verwirrend sein. Wenn beispielsweise der Gitarrensound auf einer Kette von Plugins wie Kompressor, Filter, EQ, Distortion etc. beruht und zwischen dieser Kette abhängiger Plugins dann welche deakvitiert werden, hört sich die Gitarre plötzlich fremd an.

Vielleicht sollte man einen solchen Feature Request nicht mit einer Cubase Lösung konfrontieren, sondern mit der Problemstellung und schauen ob Presonus nicht vielleicht eine geschicktere Lösung findet.

Eine Aussage "geht technisch überhaupt nicht" hat sich schon öfter als nicht treffend herausgestellt.
Wie kann man die Latenz von Plugins überbrücken?
In dem man das Audio der Pluginausgabe zwischenrendert und dann dass Plugins temporär deaktiviert. Damit wäre die Latenz weg und der Effekt des Plugins bliebe erhalten.

-Markus

 

[Saurus]

...Vielleicht sollte man einen solchen Feature Request nicht mit einer Cubase Lösung konfrontieren, sondern mit der Problemstellung und schauen ob Presonus nicht vielleicht eine geschicktere Lösung findet....

...oder Steinberg, oder Avid, oder, oder...

 

[danam]

Irgendwo hier in diesem Thread wurde glaube ich eine nicht ganz korrekte Aussage über die Entstehung von Plugin-Latenzen gemacht. Vor kurzem hab ich mir das in S1 genauer angesehen und es läuft so: Die Latenz erhöht sich pro Plugin, aber nicht pro Plugin-Instanz. Die Latenz wohlgemerkt, nicht die CPU-Last, die erhöht sich natürlich pro Instanz. Will sagen: Hat man in einem Song ein Plugin, welches 5 ms Latenz erzeugt, so kann man so viele Instanzen dieses Plugins einfügen wie man will, es bleiben 5 ms. Kommt aber ein anderes(!) Plugin hinzu, welches sagen wir 10 ms erzeugt, so hat man insgesamt 15 ms. Auch von diesem zweiten Plugin kann man dann mehrere Instanzen einfügen. Es bleiben 15 ms solange auch nur jeweils eine Instanz der beiden Plugins aktiv ist (egal ob auf Bypass oder nicht). Das sagt zumindest die Latenzanzeige in S1.

Warum ich das erzähle? Naja, Software-Monitoring muß man mindestens dann betreiben, wenn man Software-Instrumente oder Gitarren mit Gitarren-Amp-Simulationen einspielen will. Hall für den Sänger können die meisten Soundkarten ja per ZLM einbinden.Wenn ZLM geht, sollte mans machen. Keine Frage. Aber den realen, mehr als üblichen Anwendungsfall fürs Software-Monitoring will man bei Presonus hartnäckig ignorieren. Die von musicdevil zitierte Diskussion bzw. die dortigen Argumente von Ari beweisen dies (danke devil....) . War auch schon bei den Studio 192-Interfaces zumindest anfangs so. Und man wußte warum. Weil man betreffs der Latenzen nicht konkurrenzfähig war (da hat sich Treiber-technisch was getan denke ich). Punkt.

Ums Software-Monitoring kommt man also manchmal nicht drumrum, auch in einem fortgeschrittenen Mixing-Stadium kann noch mal was neu aufgenommen werden müssen. Also stellt man die Buffersize des Audio-Interface so niedrig ein, wie knackfrei möglich. Das allein kann schon den Wunsch erzeugen, einige Plugin-Instanzen zu deaktivieren. Dadurch spart man vielleicht schon soviel CPU, dass man die Buffersize noch mal niedriger setzen kann oder wenigstens keine Knackser mehr hat. Jetzt hat man aber vielleicht auch Plugins, die zwar für das Aufnahme-Playback keine tragende Rolle spielen, aber hohe Latenz und/oder CPU-Last erzeugen. Slate VTM wäre da ein klassischer Kandidat, zumal davon gern mal mehrere Instanzen verwendet werden. Also wird eine Möglichkeit benötigt, dieses Plugin zeitweise zu deaktivieren. Alle Tracks mit dem Plugin zu rendern halte ich für wesentlich langwieriger und unpraktikabler als eine Stelle, wo man mit einem Klick ALLE Instanzen eines bestimmten Plugins vorübergehend deaktivieren kann. Eine andere Möglichkeit sehe ich darin, Plugins (und/oder eventuell auch spezifische Instanzen) als "disabled while recording" zu markieren, so dass sie automatisch bei Aufnahmen deaktiviert werden. Letzteres natürlich auch nur als Option. Diese Treshold-Geschichte bei Cubase finde ich zumindest vom Hörensagen her auch nicht so ideal. Andererseits: Wenn so viele User das seit Jahren nutzen, scheint es ja seinen Zweck zu erfüllen. Möglich, dass es besser geht, aber schlecht reden ist halt auch albern...

 

[musicdevil]

Will sagen: Hat man in einem Song ein Plugin, welches 5 ms Latenz erzeugt, so kann man so viele Instanzen dieses Plugins einfügen wie man will, es bleiben 5 ms. Kommt aber ein anderes(!) Plugin hinzu, welches sagen wir 10 ms erzeugt, so hat man insgesamt 15 ms.

Ich hatte mich einfach nur auf die angezeigte Latenz bezogen und da gilt anscheint der bereits erwähnte höchste Wert und nicht die Summe.

 

[danam]

@Devil: Das erstaunt(e) mich jetzt ein wenig. Aber anscheinend haben wir beide Recht. Hier ein Screenshot mit einem VST2-Effekt und drei VST3-Effekten. Anscheinend ergibt sich die Latenz unterschiedlich. Die zwei unterschiedlichen (!) VST3-Effekte werden zusammengezählt (131.6 + 39.2 = 170.8), das VST2-Plugin wird gar nicht gerechnet, wohl weil die Gesamtlatenz schon darüber liegt.

 

[Beatback]

@danam

Nein es ist so :
1.Sind die gleiche Plugins auf parallelen Spuren ist es so wie du es sagst, nur einmal Plugin Latenz.
2.Sind die gleichen Plugins im Insert nacheinander ein paar mal vorhanden addieren sich die Latenzen!

 

[stoman]

@danam

Nein es ist so :
1.Sind die gleiche Plugins auf parallelen Spuren ist es so wie du es sagst, nur einmal Plugin Latenz.
2.Sind die gleichen Plugins im Insert nacheinander ein paar mal vorhanden addieren sich die Latenzen!

Genau. Das muss auch so sein, wenn man sich mal überlegt, was da in der Software passiert:

Jede parallel laufende Spur erhält denselben Audiopuffer zur Bearbeitung. Damit ist der Audiopuffer fertig bearbeitet, wenn der am längsten laufende Prozess fertig ist. Das Ergebnis geht dann zum nächsten Prozessor (Plugin) in der Kette, und dort entstehen neue Latenzen.

 

[musicdevil]

Ja genau so ist es. Addiert sich nicht, wenn zb. VTM in zwei Kanäle geladen wird und addiert sich in einem Kanal. Alles okay.

 

[danam]

Da habt Ihr natürlich recht. Denkfehler meinerseits. Letztlich wird die Plugin-basierte Gesamtlatenz (wie sie in S1 angezeigt wird) vom Track (!) mit der höchsten Latenz bestimmt. Ob auf diesem Track nun ein oder mehrere Plugins diese Latenz erzeugen, ist aber egal.

Aber zurück zum eigentlichen Problem. Neben der Lösung in Cubase oder der FXBay in Reaper gibt es in Samplitude schon lange diese Hybrid Audio Engine. Hab es selber nur mal angetest. Die Grundidee scheint zu funktionieren: Es gibt eine Low-Latency-Engine (=ASIO) und eine Economy-Engine. Man kann alles über ASIO laufen lassen (wie wir es von den anderen DAWs her kennen) oder auch Tracks als Economy-Track definieren. Die werden dann mit einer einstellbaren, deutlich höheren Latenz berechnet. Man kann dann zwischen verschiedenen Engine-Kombinationen wählen um entsprechend gezielt Ressourcen zu sparen bzw. die Latenz zu verringern.
Hier ein Auszug aus dem Handbuch:
"Die Hybrid Engine ermöglicht Ihnen also eine Kombination von Low Latency Engine und
klassischer Engine für die Spur-und Effektberechnung. So können Sie beispielsweise viele
rechenintensive VST-Instrumente in sogenannten „Economy“-Spuren abspielen [...], während nur das VST-Instrument welches Sie gerade aufnehmen in der Low
Latency Engine berechnet wird. "

Könnte man in der Handhabung sicherlich noch vereinfachen. Als reiner Software-Ansatz aber schon mal ziemlich gut. Und es muß nix deaktiviert werden.
Aber eigentlich sehe ich das Problem eher in der Hardware bzw. den Audio-Treibern. Für Mac kann nicht nicht sprechen, aber dass man unter Windows bei all der hochgezüchteten Hard- und Software im Jahr 2016 immer noch nicht mit einer DAW zwei Audio-Interfaces gleichzeitig verwenden kann, ist eigentlich ein Unding. Oder dass man auch nicht in der Software (bspw. als Songeinstellung) die ASIO-Buffer-Size einstellen kann.... Da könnten sich die Hersteller mal was Neues einfallen lassen...

"Having said that" gibts aber noch einen anderen Einsatzzweck für den besprochenen globalen Effekt-Aus-Schalter: Der Export aller Spuren/Stems ohne Effekte. Bspw. um jemand anders in dessen DAW einen Remix machen zu lassen. Kann man natürlich auch noch eleganter (bspw. mit Unity-Gain für alle Tracks) als eigenes Feature einbauen, aber der Global-FX-Off-Button bzw. das Deaktivieren aller Instanzen eines Plugins wäre für beides (Low-Latency-Recording/Stem-Export ohne Effekte) eine Lösung, die immer noch besser ist als der aktuelle S1-Workflow für diese beiden Usecases. Just my2cents...

 

[Navar]

Um von ASIO weg zu kommen muss OS seitig was passieren und das wird es nicht.

Die globalen FX On/Off Schalter werden ja aus verschiedenen Gründen schon lange gefordert und gewünscht. Ich schätze schon, dass das irgendwann kommen wird. Warum das bisher nicht passiert ist erschließt sich mir auch nicht. Das ist nicht so schwer umzusetzen und in dem Performance Monitor hat man ja alle Informationen zu den PlugIns, da könnte man auch einen bestimmten Typ deaktivieren. Irgendwann wird's sicherlich kommen nur wo auf der Roadmap das aktuell steht sieht man nicht.

Für mich würde es trotzdem das eigentliche Problem nicht beheben. Software Monitoring ist und bleibt auch damit problematisch. Je nach Interface ist die reine Roundtrip Latenz schon relativ hoch, hierbei darf man natürlich nicht nur die Eingangslatenz beachten und auch nicht die Plugin Latenz. Da summieren sich Bus Latenzen (USB/Firewire etc.) mit AD/DA Latenzen, Buffer Latenzen und Plugin Latenzen. Wenn man sich freut, dass da, nachdem man alle Plugins abgeschaltet und die Puffergröße auf 32 oder 64 Samples runtergeschraubt hat, auf einmal ein Wert von 3 oder 4ms steht, dann ist das leider nur trügerisch.
Natürlich muss man das irgendwie machen, wenn man mit Software Instrumenten spielt, gar keine Frage!
Mir wäre (und ist) der Aufwand zu hoch erstmal rauszusuchen, welche Plugins ich deaktivieren will, dann alles umzuswitchen, dann die Latenz wieder zu kontrollieren usw. Ich exportiere an der Stelle, dann hab ich wenigstens einen vernünftigen Stand. Ich würde da deutlich mehr profitieren, wenn an der Export Performance gearbeitet wird,
Vocals zum Beispiel mache ich grundsätzlich nur über Direct Monitoring, alles andere ist mir da zu umständlich. Hall gibt's dann halt mit nem leichten Pre Delay aus der DAW, das stört in der Regel auch nicht und wenn ich einen Kompressor brauche, dann ist der entweder eh in der Kette, oder aber ich hab ein gesplittetes Signal und nehme komprimiert/unkomprimiert auf.
Aber so hat ja jeder seinen Workflow, möglichst viele User dabei mitzunehmen und jedem sein Toolchen anzubieten dauert halt...

 

[Beatback]

Für mich würde es trotzdem das eigentliche Problem nicht beheben. Software Monitoring ist und bleibt auch damit problematisch. Je nach Interface ist die reine Roundtrip Latenz schon relativ hoch, hierbei darf man natürlich nicht nur die Eingangslatenz beachten und auch nicht die Plugin Latenz. Da summieren sich Bus Latenzen (USB/Firewire etc.) mit AD/DA Latenzen, Buffer Latenzen und Plugin Latenzen. Wenn man sich freut, dass da, nachdem man alle Plugins abgeschaltet und die Puffergröße auf 32 oder 64 Samples runtergeschraubt hat, auf einmal ein Wert von 3 oder 4ms steht, dann ist das leider nur trügerisch.
Natürlich muss man das irgendwie machen, wenn man mit Software Instrumenten spielt, gar keine Frage!

Die Bus oder AD/DA Latenzen haben mich noch nie gestört die sind so klein....
Ich habe in den letzten Jahren noch nie Probleme beim Einspielen mit Software Monitoring in Cubase gehabt, deswegen will ich ja gerade diese Funktion auch in S1 sehen.
Dort stört mich nämlich die Latenz der Plugins die ich nicht einfach so mit einem Schatler umgehen kann....

 

[Saurus]

Der IQ-DeEsser zieht über 130 ms Latenz!? Alter Falter!

 

[musicdevil]

Ich würde da deutlich mehr profitieren, wenn an der Export Performance gearbeitet wird

Hab ich jetzt schon öfter gelesen und der Punkt ist mir selbst gar nicht so bewusst gewesen.
Mir kommt es schnell vor, aber auch zb. stoman hat schon mal davon geredet, dass es bei ihm ungewöhnlich lange dauert.

Hab mal kleines Testprojekt mit 7 mal MaiTai gemacht. Vielleicht mag jemand testen.
https://dl.dropboxusercontent.com/u/9176594/Test.song

Songlänge 3:20Min, jeweils 32Bit Float Wav
Stems exportieren (7 Spuren) 1:11Min = 2,7 fache der Echtzeit
Mix exportieren 1:11Min = 2,7 fache der Echtzeit

Hab keine SSD drin....und CPU Auslastung liegt bei ca. 40% (i7 920)

 

[danam]

@Saurus: Yep, ziemlicher Hammer, die Latenz vom IQ-DeEsser. Auch extrem sind die iZotope RX-Plugins. Tun aber ihren Job...

Wie gesagt finde ich die Samplitude-Lösung auch sehr, sehr schick und funktioniert auch. Generell hat mich Samplitude bei nem 1-2 stündigen Testlauf positiv überrascht. Da fehlen mir leider 1-2 Killer-Features, aber sehr vieles ist auch auf eine Art umgesetzt, da können sich andere eine Scheibe von abschneiden. Etwas altbackene GUI halt. Aber der Objekteditor, der Drumeditor, eine Punch-Marker-Spur (= mehrere Punch-In-Bereiche innerhalb einer Loop-Wiedergabe, wie geil ist das denn...) und ein Praxis-gerechter Mixer als Kompromis zwischen S1- und Mixbus-Philosophie usw. Die alten Hasen haben auch was für sich...