Cubase 7 CPU Last muss verbessert werden!

[Saurus]

...Selbstverfreilich entlastet ein Bypass die CPU und das Herz.

Danke. Ich hatte schon Schiß, dass ich Shice erzählt habe

 

[bafc24]

Ist das in CB so? In PT z.B. entlastet ein Bypass die CPU nicht, nur das Deaktivieren des PlugIns. Ist ähnlich wie bei Hardware. Wenn Du die auf Bypass schaltest, dann wird das Stromnetz auch nicht gross entlastet, erst beim Ausschalten.
Aber wenn das in CB in einem geht, umso besser.

 

[r4r]

auch in cubase entlastet der bypass die cpu nicht.....nur das ausschalten des plugins macht das ....vg

 

[Nachtschicht]

nicht korrekt. bypass entlastet die CPU, und dies schon seit alten VST tagen (als man das ganze noch an der CPU anzeige sehen konnte wenn man ein waves trueverb gebypasst hat, was heute nichtmal mehr im ein-prozent-bereich zu erkennen ist)

einfach probieren -kanalzug voll mit aufwendigsten inserts so dass man was aufm CPU meter sieht. all-inserts-bypass knopf am kanal drücken -> belastung weg.

zusätzlich bei allen VST 3 plugins: sobald nix am input anliegt belastet es ebenfalls nicht mehr die CPU (allerdings in den preferences auch abschaltbar)

beim TE würde ich am ehesten auf 2 sachen tippen:

1. hall effekte überall im insert, klar, das geht schnell auf die performance. wenn der hall jetzt aufm auxweg liegt (selbstmord ist auch kein auxweg), dann unbedingt auch dran denken die inserts alle zu deaktivieren

2. viel essentieller wird aber wahrscheinlich sein: wenn der TE noch nie das wort latenz gehört hat, dann ist die chance gross dass er mit eher niedriger latenz unterwegs ist und/oder evtl. nichtmal mit nem richtigen asiotreiber an start ist. sollte das der fall sein, könnte sich da bei korrektem setup natürlich potentiell die generelle performance noch vervielfachen.

auch dazu empfiehlt sich ein blick ins handbuch, stichworte asiotreiber, control panel und latenz.

 

[Loop_Breaker]

Bypass schont Resourcen? das ist mir auch noch nicht aufgefallen. das muss aber das Plugin unterstützen? (bypass kann jedes VST aber dabei Resourcen schonen meine ich)

Würd´ ich denken. Dann muss dieses PlugIn ja nicht mehr berechnet (CPUed) werden. Ach, weiss der Geier

mein Name ist Geier. Selbstverfreilich entlastet ein Bypass die CPU und das Herz.

Ja Stimmt anscheinend, ich konnte (aber nur bei einen Plugin...) feststellen das die ASIO Auslastung beim bypassen runter geht, hab sogar im Steinberg Forum einen Thread dazu aufgemacht:
http://www.steinberg.net/forums/viewtopic.php?f=176&t=48001

 

[insomnia-bcn]

@Katzenschrei ... sind die Effekte sehr verschieden??

Die Funktion des Freezens ist sicher eine Lösung, doch ebenso kann man die CPU-Last senken, wenn du Kanäle, die im Endeffekt die gleich Effekte nutzen, auf ne Gruppenspur routest und dort dann den Effekt drauf packst.

Ich kenn das zumindest aus dem orchestralen Bereich, mit welchem ich mich gerade beschäftige, wenn man da auf jeden Kanal einen Effekt drauf packen würde, um die Raumakustik eines real spielenden Orchesters zu schaffen, dann würde die CPU mal ganz fix in die Knie gehen.

Wie gesagt - ist nur ein Tipp und mit dem Freezen kannste nicht wirklich etwas kaputt machen - sobald du Deine Noten in den Midispuren zu deinem jeweiligen Instrument klar hast, kannst du über das VST-Plugin-Fenster (F11 - gleich der erste Button vor dem jeweiligen Instrument) das Instrument freezen - später dann natürlich, wenn du was dran ändern willst auch wieder "entfreezen".

 

[Signalschwarz]

zusätzlich bei allen VST 3 plugins: sobald nix am input anliegt belastet es ebenfalls nicht mehr die CPU (allerdings in den preferences auch abschaltbar)

Irgendwie scheint das aber nicht ganz richtig zu funktionieren, denn das würde bedeuten, dass ein Projekt im Stillstand nahezu null Auslastung anzeigt - tut's aber nicht. Also ich konnte dahingehend bisher keine wirkliche Verbesserung durch VST3-Plugins feststellen.

doch ebenso kann man die CPU-Last senken, wenn du Kanäle, die im Endeffekt die gleich Effekte nutzen, auf ne Gruppenspur routest und dort dann den Effekt drauf packst.

Das gilt aber nur für Prozessoren die nicht die Dynamik bearbeiten.

Freezen kann man mW nur VSTi´s, aber das wirst Du heute abend nach dem Lesen des entsprechenden Betriebshandbuchkapitels genau wissen.

Man kann Audiospuren, dann werden die eingesetzten Insert-FX in das Audio eingerechnet.
Man kann VSTi-Kanäle einfrieren, dann bekommt man die Wahl, lediglich das vom VSTi erzeugte Audiosignal zu rendern oder auch gleichzeitig die im Kanal eingesetzten Insert-FX mit in die Audiodatei einrechnen zu lassen.



@ TE:

1) System-Latenz während des Mixings hochschrauben, das entlastet die CPU. Einziger Nachteil ist ein etwas trägeres Reaktionsverhalten des Systems, macht z.B. beim Frequency-Sweeping (suchen von Störfrequenzen) bemerkbar, das muss dann entsprechend etwas langsamer vonstatten gehen.

2) Hall ist ein typischer Zumisch-Effekt, also über einen Send-Bus einbinden UND natürlich nicht einfach jedes Hall-Plugin das zunächst als Insert eingebunden war auf einen Effekt-Bus legen, sondern mit mehreren Spuren in ein Hall-Plugin gehen - das entlastet den Rechner. Dabei solltest Du darauf achten, dass Direktsignal komplett rauszudrehen, heisst idR den Dry-Wet-Regler auf 100% "wet" stellen.

3) Es gibt diverse Plugins (Effekte wie Instrumente) die einen "Performance-Mode" bieten, diesen kann man während man das Projekt noch bearbeitet ruhig aktivieren und dann am Ende beim Mixdown wieder deaktivieren.

4) Wenn Du Spuren einfrierst, solltest Du vorher in den Projekteinstellungen als Aufnahmeformat "32 bit float" einstellen.

 

[Saurus]

Freezen kann man mW nur VSTi´s, aber das wirst Du heute abend nach dem Lesen des entsprechenden Betriebshandbuchkapitels genau wissen.

Man kann Audiospuren, dann werden die eingesetzten Insert-FX in das Audio eingerechnet.
...

Nennt sich das dann tatsächlich freezen (wenngleich es technisch gesehen einen vergleichbaren Effekt hat)?

 

[Signalschwarz]

Verdammt, immer werden die Textstellen zitiert in denen ich mich mal verschreibe, da fehlt ja das "einfrieren".

Joar, Steinberg nennt es so, man findet es im entsprechenden Bereich im BHB, es funktioniert genauso und man nutzt dazu den "normalen" Freeze-Button... ich denke man kann es also als "freezen" bezeichnen.

 

[Saurus]

Ich fragte nur mal so blöd, weil ich das mit Audio noch nie gemacht habe. Brauchte ich noch nicht - zum Glück.

 

[Katzenschrei]

so, nun habe ich eure Tipps umgesetzt. Hall etc auf send anstatt insert und mit freeze gearbeitet.
Viel hat es nicht gebracht. der Spaß ging durch die langen Reaktionzeiten und das Ruckeln dennoch flöten.
Ich werde einen neuen PC anschaffen müssen.

 

[tubeless]

@ syrius

Nennt sich das dann tatsächlich freezen

Logisch.
Es ist ein Unterschied zum Digital Mixdown, bei dem zwar auch das Zeugs eingerechnet wird, aber eine neue Datei entsteht und das Ganze nachher nicht mehr geändert werden kann.

Beim Freezen wird der Zustand eingefroren und man kann ihn nachher wieder auftauen. Letzteres ist dann der eklatante Unterschied zum Digital Mixdown.......

@ digital_dominion

Irgendwie scheint das aber nicht ganz richtig zu funktionieren, denn das würde bedeuten, dass ein Projekt im Stillstand nahezu null Auslastung anzeigt

Es will mir scheinen, dass diese Funktionalität auch vom VSTi unterstützt werden muss. Mir scheint, dass manche den Ausgang abschalten, aber ansonsten munter weiterrödeln, während andere wirklich die Tätigkeiten einzustellen scheinen und dann wirklich für geringere CPU-Last sorgen.

 

[Nachtschicht]

so, nun habe ich eure Tipps umgesetzt. Hall etc auf send anstatt insert und mit freeze gearbeitet.
Viel hat es nicht gebracht. der Spaß ging durch die langen Reaktionzeiten und das Ruckeln dennoch flöten.
Ich werde einen neuen PC anschaffen müssen.

check erstmal das mit asio Treiber. lange Reaktionszeiten klingt ebenfalls danach dass du mit falschen Treiber unterwegs bist. selbst ein core 2 Duo dürfte bei weitem noch nicht bei dem von dir genannten in di Knie gehen. wenn du dir jetzt ne neue koste kaufst und wieder mit falschen Treiber (=lange Reaktionszeit, wenig leistung) unterwegs bist, dann biste schlecht beraten. Google mal asio4all und probiers mal testweise damit. und asio Treiber und Latenz im Handbuch nachschlagen.

 

[thesoundlab]

hi zusammen,

dieser thread scheint mir passend zu meinem problem, was hier mal direkt ins rennen schicken möchte, in der hoffnung, dass sich ein hilfreiche seele meiner erbarmt.

hab einen intel i7, cubase 7.0.5, focusrite saffire 40 pro am laufen. seit nicht langer zeit (ich weiß leider nicht ab wann), kommt es zu krassen verzögerungen zwischen signal am mikro und input beim aufnehmen sowie beim "cuen", also das ausgeben des mikrosignals auf kopfhörer.

was meine ich mit krass? ein delay von ca. 200 ms, bei einer puffergröße von 256 samples, fs = 48 khz. dass das für einen i7 kein thema sein kann, muss ich keinem sagen.

-> es tritt nicht bei jedem projekt auf
-> wenn ich bei betroffenen projekten ALLE spuren lösche samt plugins, wenn ich also ein jungfräuliches projekt vor mir habe, dann habe ich in diesem projekt immer noch eine CPU auslastung von ca. 40 % (!!)
-> in einem großen "gesunden" projekt mit 50 + spuren inkl. gleicher anzahl an plugins und gleicher puffergröße kratzt sich der i7 am hintern vor langeweile...
-> wenn ich ein neues projekt anlege, ist alles wieder easy

hier nun die konkrete frage: hat jemand mit cubase 7 ähnliche erfahrungen gemacht? kann das ein treiberproblem des saffire sein? kann das ein routing problem sein im "control room"? hab schon so gut wie alles gecheckt, aber ich komme nicht weiter. der steinberg support ist ja auch nicht der schnellste... email ist schon zwei wochen her...

HELP

 

[John_Lennon]

hi zusammen,

dieser thread scheint mir passend zu meinem problem, was hier mal direkt ins rennen schicken möchte, in der hoffnung, dass sich ein hilfreiche seele meiner erbarmt.

hab einen intel i7, cubase 7.0.5, focusrite saffire 40 pro am laufen. seit nicht langer zeit (ich weiß leider nicht ab wann), kommt es zu krassen verzögerungen zwischen signal am mikro und input beim aufnehmen sowie beim "cuen", also das ausgeben des mikrosignals auf kopfhörer.

was meine ich mit krass? ein delay von ca. 200 ms, bei einer puffergröße von 256 samples, fs = 48 khz. dass das für einen i7 kein thema sein kann, muss ich keinem sagen.

-> es tritt nicht bei jedem projekt auf
-> wenn ich bei betroffenen projekten ALLE spuren lösche samt plugins, wenn ich also ein jungfräuliches projekt vor mir habe, dann habe ich in diesem projekt immer noch eine CPU auslastung von ca. 40 % (!!)
-> in einem großen "gesunden" projekt mit 50 + spuren inkl. gleicher anzahl an plugins und gleicher puffergröße kratzt sich der i7 am hintern vor langeweile...
-> wenn ich ein neues projekt anlege, ist alles wieder easy

hier nun die konkrete frage: hat jemand mit cubase 7 ähnliche erfahrungen gemacht? kann das ein treiberproblem des saffire sein? kann das ein routing problem sein im "control room"? hab schon so gut wie alles gecheckt, aber ich komme nicht weiter. der steinberg support ist ja auch nicht der schnellste... email ist schon zwei wochen her...

HELP

Selbst wenn du alle Spuren löschst, hast Du immer noch die Eingangskanäle und mindestens einen Ausgang im Projekt. Und in diesen Kanälen können Plugins im Insert sein und die können CPU-Leistung brauchen. Es gibt auch Fälle, in denen ein Plugin GERADE dann, wenn es nichts zu tun hat, unglaublich viel CPU-Leistung zieht. Das ist das sog. Denormal-Problem. Sollte eigentlich seit vielen Jahren gelöst sein, aber man stolpert auch heute ab und an mal über Plugins, die das Problem haben (allerdings sehr selten bei etablierten Anbietern, die haben das im Griff). Sollte also bei Dir tatsächlich in den Ein- und Ausgangskanälen Plugins sitzen, dann wäre es mal interessant zu erfahren, welche das sind.

Die dürften auch für die Latenzen beim Monitoring verantwortlich sein. Ich würde daher entweder auf DSP-Plugins tippen - die haben nämlich sich addierende Latenzen - oder aber Dinge wie Faltungshall, auch solche Plugins haben andere (größere) Latenzen als das Projekt an sich.

Unabhängig vom Performanceproblem kannst du das Latenzproblem beim Monitoring durch ausschalten der "Delay Kompensation" in den Griff bekommen. Das ist ein Modus, der speziell für den Fall gedacht ist und alle Plugins mit zusätzlichem Delay einfach ausschaltet. Das ist der kleine orangene Knopf mit der stilisierten Uhr darauf links oben im Projektfenster.

 

[Gelöschtr 9460]

thesoundlab schrieb in #34:


hier nun die konkrete frage: hat jemand mit cubase 7 ähnliche erfahrungen gemacht? kann das ein treiberproblem des saffire sein? kann das ein routing problem sein im "control room"? hab schon so gut wie alles gecheckt, aber ich komme nicht weiter. der steinberg support ist ja auch nicht der schnellste... email ist schon zwei wochen her...

HELP

Also im control room kann man ja auch Plugins laden und demnach auch vergessen, auszuschalten. Eines der wenigen Plugins die eine grosse Latenz erzeugen ist bei mir das Ozone Plugin, wenn ich das als Multibandkompressor laufen habe oder fürs Mastering. Da hilft es auch nicht den Control Room auszuschalten, erst wenn das Plugin ausgeschaltet ist , ist wieder Ruhe mit der Cpu, sonst zeigt das schon 30 % Cpu an, obwohl keine Spuren da sind .