logicuser.de

maiermueller hat geschrieben:

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

Denkfehler! ;-)

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...

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.

Mehrere Denkfehler! ;) ;)

"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.

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.
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

stef hat geschrieben:...aber selbst wenn es das gibt, kann Logic eine Meldung ausgeben: "Zu kompliziert. Kann ich nicht."

Stef

würde zu gern mal wissen, was dann hier abginge, wenn logic wirklich so ne meldung rausgäbe...!

stef hat geschrieben: 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.

Ja, das stimmt schon, aber:

stef hat geschrieben: 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.

Ich auch, denn Du nimmst bei Deinen Beispielen an, dass "in der Regel meisten Spuren mit ein paar Inserts direkt auf den Ausgang gehen". Bei mir ist das ganz und gar nicht so. Ich arbeite sehr viel mit Gruppen (z.B. Summenkompression), mit Send-Effekten und dann kommt am Schluss noch das Mastering. Da schwindet dann sehr schnell der Vorteil Deiner Methode, besonders, wenn man Instruments am Start hat, die mal locker 70-80% eines Kerns verbrauchen. Da wird dann eher sogar länger brauchen, als in Echtzeit, weil die Send-Effekte nicht schon gleichzeitig neben den Instruments rechnen können.

Solange es keine bessere Offlinebounce-Möglichkeit gibt, die wirklich zuverlässig und grundsätzlich schneller arbeitet, als Echtzeit, ist mir die jetzige Funktion lieber, die mir nebenher auch Zeit für anderes läßt.

stef hat geschrieben: 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."

So wie ich das verstehe würde das aber eine komplette zweite Audioengine nur zum Zwecke des Offline-Bounce erfordern. Sowas macht man nicht. ;)

Dass es prinzipiell bei jedem Logic-Projekt geht, zeigt der Online-Bounce. Man wird da auch sicherlich kaum Einbußen bei der Prozessorauslastung machen müssen und sehr nah an 100% kommen. Man müsste halt lediglich die einzelnen Puffer in maximaler Geschwindigkeit von der Audioengine abrufen (und nicht in festen Zeitabständen wie beim Abspielen über Coreaudio). Aber irgendwo wird es dabei einen Klops geben, den wir nicht kennen.

Nur weil es prinzipiell anders ginge heißt noch lange nicht, dass man dafür Projektharakiri begehen muss indem man nochmal eine komplette Renderengine schreibt.

Mit den Gruppen ist es das Selbe wie mit den Sends. Erst werden alle Instrumente berechnet, dann gemischt und dann komprimiert. Dann gerne noch in einen Send rein, über das Mastering auf Festplatte. Frisch serviert. Klar schwindet der Vorteil meiner Methode. Und?
Und wenn Instrumente 70 bis 80% einer CPU benötigen, was bei Deinen Projekten von mir aus die Regel ist (Ich verstehe dann allerdings nicht warum Du den ES1 als Beispiel angeführt hast.), kann der zweite Kern immer noch was machen bzw. die anderen 7 Kerne.

Da wird dann eher sogar länger brauchen, als in Echtzeit, weil die Send-Effekte nicht schon gleichzeitig neben den Instruments rechnen können.

Äääh?! Kannst Du mal welche von den Audioalgorithmen posten, die Programmiert hast? Gut kommentiert bitte. Ich würde gern mal nachvollziehen können wie sich bei Dir Rechenleistung in Luft auflöst.

Solange es keine bessere Offlinebounce-Möglichkeit gibt, die wirklich zuverlässig und grundsätzlich schneller arbeitet, als Echtzeit, ist mir die jetzige Funktion lieber, die mir nebenher auch Zeit für anderes läßt.

Tjaja, man kann es nicht jedem recht machen. Mir reicht eine Methode die oft schneller ist schon aus. Eine perfekte Lösung, an der keiner etwas zu mäkeln hat, wird es nie geben.

Aaah, hugoderwolf hat mich verstanden.

Wie auf wendig das ist kann ich nicht einschätzen. Mir ging es erstmal darum, dass es theoretisch geht. Wie aufwendig das ist, sollte von Leuten die wirklich was davon verstehen erläutert werden.

stef hat geschrieben: Wie auf wendig das ist kann ich nicht einschätzen. Mir ging es erstmal darum, dass es theoretisch geht. Wie aufwendig das ist, sollte von Leuten die wirklich was davon verstehen erläutert werden.

Ich bin sogar der Meinung, dass das Thema *eigentlich* überhaupt nur von Leuten, die wirklich was davon verstehen, diskutiert werden sollte. Im Trüben fischen bringt hier so gut wie gar nichts (abgesehen von etwas Denksport für die Diskussionsteilnehmer). Ohne eine vernünftige Wissensbasis (wie mehrfach angemerkt Kenntnis des Ist-Zustands innerhalb Logics) ist das reine Zeitverschwendung...

stef hat geschrieben: Äääh?! Kannst Du mal welche von den Audioalgorithmen posten, die Programmiert hast? Gut kommentiert bitte. Ich würde gern mal nachvollziehen können wie sich bei Dir Rechenleistung in Luft auflöst.

Was tut das hier zur Sache, dass ich Quellcode hier posten soll? Damit ich mich glaubwürdig mache? Damit Du dann besser verstehst, was ich geschrieben habe? Geht's Dir hier eigentlich ums Provozieren oder ums Diskutieren? Unter diesen Umständen habe ich kein Interesse daran, Dir noch irgendetwas zu erklären.

Wenn Du wieder runtergekommen bist, dann versuch's doch mal nachzuvollziehen, dann kommst Du auch selber drauf. Ganz ohne Beleidigungen. Ok?

hugoderwolf hat geschrieben: Ich bin sogar der Meinung, dass das Thema *eigentlich* überhaupt nur von Leuten, die wirklich was davon verstehen, diskutiert werden sollte. Im Trüben fischen bringt hier so gut wie gar nichts (abgesehen von etwas Denksport für die Diskussionsteilnehmer). Ohne eine vernünftige Wissensbasis (wie mehrfach angemerkt Kenntnis des Ist-Zustands innerhalb Logics) ist das reine Zeitverschwendung...

Ein Wort! Recht hat der Mann!

Mittlerweile habe ich den Überblick verloren, worum gehts hier eigentlich? Funktioniert was nicht oder findet man es unelegant, dass nur ein einziger Prozessorstrich in der Anzeige sichtbar ist? Letzteres liesse sich eventuell vermeiden indem man die Anzeige nicht anzeigt.

:D
+++

Peter Ostry hat geschrieben:Letzteres liesse sich eventuell vermeiden indem man die Anzeige nicht anzeigt.

Ja nein, das geht leider auch nicht, weil Logic eben nur noch in einem Thread läuft. Ich fordere also daher von Apple, beim Offlinebouncen wenigstens 2 Threads zu aktivieren, einen fürs Bouncen und einen für die Anzeige.

maiermueller hat geschrieben: Ja nein, das geht leider auch nicht, weil Logic eben nur noch in einem Thread läuft. Ich fordere also daher von Apple, beim Offlinebouncen wenigstens 2 Threads zu aktivieren, einen fürs Bouncen und einen für die Anzeige.

Der Erfahrene Programmierer weiß, dass genau das mit Sicherheit bereits der Fall ist. ;)

hugoderwolf hat geschrieben:(Man soll nicht meinen, da wären völlige Idioten am Werk. Da sitzen Profis, und mit Profis meine ich nicht x-beliebige Informatiker sondern Spezialisten mit zig Jahren Erfahrung in *genau* diesen Dingen. Das sind keine Probleme, die für Ferndiagnose geeignet wären... ;))

Da gebe ich Dir absolut recht - ich denke wir wurden dort auch schon klar und deutlich registriert mit unserem Multicoreofflinebouncewunsch ...

Und danke für Deine Erklärung zum "Offline Clocken" - genau so hatte ich das gemeint ... statt "Clock" hätte ich wohl besser "Scheduling-Event zur Zuteilung des Aktionsflusses an den entsprechenden Audio-Processing-Graphen" schreiben sollen ...

Heiner meinte vielleicht einfach daß die programmierer sich nicht trauen. ich glaub ihm das. :)