Logic Pro und Mulitthreading

[raketenmann]

Moin
Ich mal wieder. Sorry...

Ich bin gerade ein Podcast am Mastern und habs mal wieder mit einem rumzickenden Logic zu tun. Mal wieder Systemüberlastung. OK, ich hab da ein paar Plugins in Oversampling drin und iZotope RX7 in der höchsten Qualität. Trotzdem: da läuft eigentlich nicht so viel.
Nun habe ich mal auf die CPU-Anzeige geklickt und die zeigt, dass die Überlastung auf CPU Kern 1 auftritt, dann geht da noch ein wenig was auf Kern 2, Kern 3-8 sind einfach leer... Wie geht das? Liegt es daran, dass alle Plugins auf nur einer Stereospur und auf dem Master liegen? Kann mein Mac das irgedwie nicht aufteilen? Oder ist da sonst was im argen... Vielleicht kann mir da wer weiterhelfen.

Ich arbeite an einem MacBook Pro 15" Late2011, 2.5GhZ i7, 16GB RAM

Danke für eure Hilfe

Im Anhang noch ein Screenshot

 

[Supercreative]

Gute Frage. Würde mich auch mal interessieren.
Wenn ich Maschine als Plugin laufen habe, konnte ich das auch schon feststellen (wenn das Plugin mit Sounds/FX gut gefüttert ist).

Ich war bisher der Meinung, dass Logic die Plugins an sich auf die CPU-Threads aufteilt. Das habe ich aber seitdem nicht mehr hinterfragt. Kann natürlich auch anders sein...

 

[clemenserwe]

Ich arbeite an einem MacBook Pro 15" Late2011, 2.5GhZ i7, 16GB RAM

Mit welchem OSX und welcher Logic-Version?

Es gibt - ich weiß aber gerade nicht mehr, seit welcher Version - eine Option bei Einstellungen > Audio > Multithreading

 

[rz70]

Wenn ein VST nur einen Core nutzen kann (so ist es wohl bei Maschine), dann kann die DAW natürlich auch nichts verteilen.

 

[raketenmann]

Ich arbeite an einem MacBook Pro 15" Late2011, 2.5GhZ i7, 16GB RAM

Mit welchem OSX und welcher Logic-Version?

Es gibt - ich weiß aber gerade nicht mehr, seit welcher Version - eine Option bei Einstellungen > Audio > Multithreading

High Sierra und Logic Pro X 10.4.8. Die Option unter MultiThreading gibt es in meiner Version, da ist standardmässig automatisch drin, aber auch wenn ich da auf 8 schalte ändert sich das Verhalten nicht.

Wenn ein VST nur einen Core nutzen kann (so ist es wohl bei Maschine), dann kann die DAW natürlich auch nichts verteilen.

Wie in meinem Screenshot zu sehen ist, arbeite ich nicht mit Maschine, sondern mit verschiedenen Plugins. Ich habe nun ein paar Tests gemacht und musste feststellen, dass in dem von mir verwendeten Projekt (Mastering-Projekt, also nur eine einzelen Stereo-Spur) die Audiospur und die Plugins auf dem Masterkanal alle auf nur einem CPU-Kern laufen und dadurch an den Anschlag kommen. Ich vermute tatsächlich, dass Logic die Plugins auf einer Spur nicht auf verschiedene Kerne verteilen kann. Warum die Plugins vom Masterkanal und von der Audiospur nicht aufgeteilt werden kann verstehe ich nicht.

Die problematischen Plugins in meinem Projekt waren im Übrigen soothe2 (benötigt ca. 50% eines Kerns) und iZotope RX7 (benötigt ebenso ca. 50% eines Kerns).

 

[Sascha Franck]

Warum die Plugins vom Masterkanal und von der Audiospur nicht aufgeteilt werden kann verstehe ich nicht.

Das läuft halt alles seriell, Masterbus inklusive. Da ist dann nix mehr mit Multithreading.

 

[raketenmann]

Warum die Plugins vom Masterkanal und von der Audiospur nicht aufgeteilt werden kann verstehe ich nicht.

Das läuft halt alles seriell, Masterbus inklusive. Da ist dann nix mehr mit Multithreading.

Kannst du das nochmals näher erklären? Also wenn ich ein Plugin auf einer zweiten Spur platziere, kann das auf einem weiteren Kern verarbeiter werden, obwohl das Audiosignal am Ende trotzdem im Master landet, aber auf die Plugins auf der ersten Spur müssen mit den Plugins auf dem Master verarbeitet werden? Das macht in meiner Logik keinen Sinn. Also entweder können Plugins auf verschiedenen Kernen berechnet werden oder sie können es nicht. Schlussendlich wird alles im Master summiert...

 

[HannesMac]

Hier ein Artikel von Apple vom Dezember:
https://support.apple.com/de-de/HT205975

https://support.apple.com/de-de/HT203930


Verteilung der Last dürfte demnach grundsätzlich gehen (auf verschiedene Arten).

 

[Sascha Franck]

Kannst du das nochmals näher erklären? Also wenn ich ein Plugin auf einer zweiten Spur platziere, kann das auf einem weiteren Kern verarbeiter werden, obwohl das Audiosignal am Ende trotzdem im Master landet, aber auf die Plugins auf der ersten Spur müssen mit den Plugins auf dem Master verarbeitet werden? Das macht in meiner Logik keinen Sinn. Also entweder können Plugins auf verschiedenen Kernen berechnet werden oder sie können es nicht. Schlussendlich wird alles im Master summiert...

Also, auf Threads aufteilen lassen sich ausschließlich parallele Prozesse. Das heißt auch, dass der Masterkanal *immer* Teil einer seriellen Verarbeitung ist. Das, was da vorher abläuft, kann aufgeteilt sein und auch von verschiedenen Threads abgearbeitet werden, aber der Master wird immer quasi oben draufgeschlagen.

 

[raketenmann]

Hier ein Artikel von Apple vom Dezember:
https://support.apple.com/de-de/HT205975

https://support.apple.com/de-de/HT203930


Verteilung der Last dürfte demnach grundsätzlich gehen (auf verschiedene Arten).

Anhang anzeigen 89310

Das bringt mich nicht weiter bzw. habe ich bereits gelesen. Da gerade aktuell das Projekt im Screenshot (Mastering) das Problem war, kann die Einstellung mit den Livespuren nicht wirklich das Thema sein. ich verwende keine Softareinstrumente und höre auch nicht durch die DAW ab. Von daher finde ich das schon krass, dass ich da mit 9 Plugins an die Grenze stosse...

Kannst du das nochmals näher erklären? Also wenn ich ein Plugin auf einer zweiten Spur platziere, kann das auf einem weiteren Kern verarbeiter werden, obwohl das Audiosignal am Ende trotzdem im Master landet, aber auf die Plugins auf der ersten Spur müssen mit den Plugins auf dem Master verarbeitet werden? Das macht in meiner Logik keinen Sinn. Also entweder können Plugins auf verschiedenen Kernen berechnet werden oder sie können es nicht. Schlussendlich wird alles im Master summiert...

Also, auf Threads aufteilen lassen sich ausschließlich parallele Prozesse. Das heißt auch, dass der Masterkanal *immer* Teil einer seriellen Verarbeitung ist. Das, was da vorher abläuft, kann aufgeteilt sein und auch von verschiedenen Threads abgearbeitet werden, aber der Master wird immer quasi oben draufgeschlagen.

Das macht Sinn, das verstehe ich sogar Also in dem Fall ist tatsächlich wie bereits festgestellt soothe2 auf dem Master und dann noch RX7 obendrauf zu viel des Guten.

Ich habe auch nochmals ein wenig in Richtung RX7 recherchiert und im Manual gelesen, dass tatsächlich die Einstellung, die ich im Spectral Denoiser vorgenommen habe, nicht für das mischen/abhören empfohlen wird, da sie zu rechenintensiv ist (minimale Artefakte). Insofern handelt es sich mal wieder um ein Anwenderproblem!

Aber: wieder mal ein Stück näher am Verständnis für Logic (das ich nun schon fast 10 Jahre verwende... .

 

[Sascha Franck]

Wenn du dir sicher bist, dass du die Sachen im eigentlichen Kanal so haben willst, könntest du die ja so rausbouncen und mit dem gebouncten File weitermachen, da hättest du dann vielleicht genug CPU Luft nach oben.

 

[clemenserwe]

Ich habe auch nochmals ein wenig in Richtung RX7 recherchiert

Vielleicht sollte man das mal als generellen Tip veröffentlichen.
RX7 ist (für mich) ein externer Editor. Plugins davon in der DAW in Echtzeit beim Playback berechnen lassen zu wollen, ist (vermutlich für die meisten Rechner) ambitioniert.

Bei mir ist RX7 als externer Editor eingebunden - Backup der Audiodatei machen -> in RX7 editieren -> mit der bearbeiteten Version weiterarbeiten.

Wenn man während dem Mixen mit RX7-Einstellungen probieren will, hat man trotzdem die Möglichkeit, über die auswahlbasierte Bearbeitung den aktuellen Bearbeitungsstand "festzunageln" und bei entsprechenden Einstellungen die unbehandelte Version auf der Hinterhand zu halten.

 

[Drumfix]

Eine triviale Lösung ist die Plugins auf einzelne Spuren zu verteilen und die einzelen Spuren aus der DAW raus und per Loopback auf einer anderen Spur wieder rein zu führen. Also statt alle Plugins auf der Masterspur, den ganzen Mix pre Master in eine Bus, den Bus per Loopback auf eine andere Spur mit dem ersten Plugin leiten, die wieder per Loopback auf die nächtste Spur usw. Das erhöht zwar mit jedem Loopback die Latenz, dafür sind die Plugins jetzt parallelisiert.
Man kann natürlich die Plugins so auf die Spuren verteilen, dass die einzelnen CPU Cores gerade nicht mehr überfordert werden. Dann reduzieren sich die benötigten Loppbacks entsprechend.

 

[Sascha Franck]

Eine triviale Lösung ist die Plugins auf einzelne Spuren zu verteilen und die einzelen Spuren aus der DAW raus und per Loopback auf einer anderen Spur wieder rein zu führen. Also statt alle Plugins auf der Masterspur, den ganzen Mix pre Master in eine Bus, den Bus per Loopback auf eine andere Spur mit dem ersten Plugin leiten, die wieder per Loopback auf die nächtste Spur usw. Das erhöht zwar mit jedem Loopback die Latenz, dafür sind die Plugins jetzt parallelisiert.
Man kann natürlich die Plugins so auf die Spuren verteilen, dass die einzelnen CPU Cores gerade nicht mehr überfordert werden. Dann reduzieren sich die benötigten Loppbacks entsprechend.

An sich 'ne ganz interessante Idee, zumal speziell unter macOS ja auch einfach wie verlustfrei machbar (bspw. per Soundflower). Und wenn es sich nicht um eine Echtzeitgeschichte handelt (was ja bspw. beim Mastern so wäre), dann kann man auf die Latenzen auch pfeifen (RX7 kommt ja ohnehin mit riesiger Eigenlatenz, wenn ich mich recht entsinne).

 

[Sascha Franck]

Eigentlich ja auch 'ne interessante Frage, warum man so ein Routing dann nicht auch direkt innerhalb Logics veranstalten kann.
Wobei - vielleicht geht das ja sogar mit ein bisschen Trickserei. Wenn ich Bock habe, fummele ich nachher mal rum.

 

[Drumfix]

Noch besser wäre es und ohne zusätzliche Latenz, wenn die DAWs Pipelining direkt implementieren würden. Dazu einfach den Buffer in kleinere Teile unterteilen und die Plugins nur den kleineren Teil bearbeiten lassen und dann das Ergebnis an das nächste Plugin auf einem anderen Core weiterreichen usw und das so lange bis alle Subbuffer abgearbeitet sind.
Setzt halt voraus, dass, wenn man eine bestimmte Anzahl Samples vorne in ein Plugin reinschiebt, hinten auch die gleiche Anzahl an Samples wieder rauskommt. Im idealfall für ein Inputsample auch jedesmal ein Outputsample.
Hätte man z.B. lauter Plugins die alle eine Zeiteinheit für die Bearbeitung eines Samples benötigen dann ergäbe sich:

Im Idealfall also z.B.10 Plugins, Buffersize 64 Samples, alle brauchen eine Zeiteinheit pro Sample:

Jetzt: 10*64 Zeiteinheiten auf einem Core = 640 Zeiteinheiten.
Mit Pipelining: 64 Zeiteinheiten je Cores, das Ergebnis liegt dadurch nach 9+64 = 73 Zeiteinheiten vor, da die jeweils 63 anderen Zeiteinheiten der ersten 9 Plugins durch die Parallelisierung überdeckt werden (das bisschen Overhead für die Parallelisierung jetzt mal weggelassen).
Hat man in diesem Beispiel also 10 Cores zur Verfügung, benötigt man nur eine Singlecoreleistung von ca 10% gegenüber der "Jetzt" Version.

 

[notebynote]

Mit dem M1 dürften sich viele dieser Überlegungen erledigen. Es wird natürlich auch dort wieder Plugins geben, die bis an die Grenzen gehen werden.

 

[zille1976]

Mit dem M1 dürften sich viele dieser Überlegungen erledigen. Es wird natürlich auch dort wieder Plugins geben, die bis an die Grenzen gehen werden.

Warum sollte das so sein?
Die Parallelverarbeitung muss in der DAW erfolgen und hat nichts mit der CPU zu tun, die dahinter steckt.