Zuerst möchte ich Dich bitten mir nicht zu erklären was ich denke, nur um mir dann zu erläutern was daran alles falsch ist.maiermueller hat geschrieben:Denkfehler! ;-)stef hat geschrieben: Schlechtes Beispiel! Ich sehe überhaupt kein Problem darin z.B. 16KB-Puffer zu nehmen, drei Spuren auf drei Kernen zu berechnen, diese drei Puffer den Sendlevels entsprechend zu mischen und die Additionsergebnisse in den Hall zu schicken. Bei einem Faltungshall ist ein 16 KB-Puffer natürlich ruckzuck zu klein; da müsste Logic dann gucken wie lang ist der Hall (z.B 10 s), wie ist die Samplerate (z.B. 44100 Hz), macht bei 32Bit dann ca. 1,8 MB.
Wenn man jetzt Wert auf einen 1000 s Send-Hall auf 200 Spuren legt wäre eine 64Bit-Version on Logic schon wünschenswert :-)
Kniffliger finde ich da Sidechains; damit die funktionieren braucht man kleine Puffer. Wenn das Projekt den Rechner eh schon an die Wand drückt, bringt das dann nix mehr, aber wenn man noch Luft hat, könnte das bouncen trotzdem schneller gehen.
Stef
Du gehst davon aus, dass die drei Spuren in der gleichen Zeit berechnet werden. Das ist aber falsch. Eine Spur kann z.B. in 0.001 ms berechnet sein, während die andere 2 min braucht. Muss man also mit dem Weiterrechnen des Halls in jedem Fall 2 min warten. Mit Puffern an sich hat das nichts zu tun, allein mit der Rechenzeit pro Sample...
Mehrere Denkfehler! ;) ;)stef hat geschrieben: Ich denke auch, dass das Problem lösbar ist. In der Regel werden die meisten Spuren mit ein paar Inserts direkt auf den Ausgang gehen. Nur muss die Puffergröße bei Verwendung von Seitensträngen klein sein, damit dieser schnell genug regelnd eingreifen kann.
"In der Regel" ist jedes Projekt komplett anders und man kann von nichts ausgehen!
Die Puffergröße hat beim Offline-Bounce keine Auswirkung auf irgendetwas. Jedes Sample findet seinen weg durch den Algorithmusdschungel, ganz gleich, wie groß der Puffer ist, in dem es schwimmt. Da es beim Offline-Bounce nicht auf die Berechnung innerhalb einer festgelegten Zeit (Echtzeit) ankommt, können die Puffer vielmehr beliebig gewählt werden.
Die Wahl der Puffergröße ist eine Frage der gewünschten Effizienz und des vorhandenen Speichers. In der Tat fallen die Einzel-Samples irgendwann hinten heraus, einzeln oder als Puffer.
Deshalb irritiert mich warum Du die Millisekunden (die Zeit) so in den Vordergrund schiebst. Die sind doch viel belangloser als die Puffergröße. Für die Auswahl letzterer gilt wenigstens noch das Effizienzkriterium. Aber Zeit?! Wenn es fertig gerechnet ist, ist es fertig gerechnet.
Nehmen wir einen DualCore iMac: Kern 1 berechnet den ES1 von Spur 1, Kern 2 nimmt den Sculpture von Spur 2. Kern 1 ist eher fertig und macht sich schon mal über den EXS 24 auf Spur 3 her. Wo ist das Problem? Egal ob die Spuren komplett gerechnet werden oder in kleinen Abschnitten (Puffer); irgendwann werden die nach Send-Anteil gemischt und dann durch den Hall gejagt. Dieses macht dann nur ein Kern/CPU der/die andere kann ja schon mal Spur 4 berechnen. Und wenn es nur drei Spuren gibt... auch gut. Wer sagt denn das alle Prozessoren durchgängig zu 100% ausgelastet sein müssen.
Und dann Antwortest Du mir noch, dass "in der Regel jedes Projekt komplett anders ist".
Und das ist dann der Moment wo ich ein wenig die Lust verliere.
Vielleicht sollte Apple etwas mehr Mut zur Lücke haben. Ich kann mir momentan nicht vorstellen, dass es ein Projekt gibt bei dem das prinzipiell nicht geht, aber selbst wenn es das gibt, kann Logic eine Meldung ausgeben: "Zu kompliziert kann. Kann ich nicht."
Stef