Mit schwerem Schädel, mmer noch müde, schlecht riechend, ...
O.k., o.k., eigentlich weiß man´s: Ab einem bestimmten Pegel braucht man sich solcher Materie nicht mehr zu widmen.
Wäre ja auch zu schön gewesen.
Dass die Benutzung des PrimaryLevel-Eventsystems zur Übertragung/Speicherung von Audio-Daten zu absurder CPU-Belastung führt, ist logisch.
Zwingt man mehrere Audio-Kanäle auf einen solchen Event-Bus, wirds ebenso logischerweise schlimmer.
Hätte ja sein können, dass das core-intern - wie so manches andere auch - besser geht.
Immerhin wissen wir es jetzt:
Nein, es geht nicht besser, es geht wahrscheinlich gar nicht.
Auch ein Ergebnis
Vor dem Hintergund werde ich denn wohl auch das Start-Ensemble für diesen thread noch einmal untersuchen müssen:
Ist der nicht-gleichzeitige Event wirklich einfach durchgerutscht, oder hat er doch einen anderen überschrieben ?
Mir wird nichts anderes übrigbleiben, als bei super-niedriger Rate Counterstände von gleich- und nichtgleichzeitigen Events zu vergleichen.
Und selbst dann bleibt die Frage, ob sich das System bei schnelleren Raten nicht doch wieder anders verhält. Da wird das Auge nicht mehr mitmachen, ergo muss man´s automatisieren.
Falls der Event tatsächlich durchrutscht, müßte geklärt werden, wie groß der Abstand zu einem nächsten sein muß, damit es wieder funktioniert. In Audio-Rate funktioniert es ja offenbar nicht.
Man könnte auch noch versuchen, mit doppelter Sample-Rate ein "normales" Audio-Signal abzutasten und die Zeit des jeweils "doppelten" Samples zu nutzen, um Informationen dazwischenzuschicken.
Ausprobieren lässt sich da schon noch was.
Zaubern logischerweise nicht,
Es wird aber wohl dabei bleiben, dass sowas Aufgabe von Reaktors Polyphonie-System ist.
herw hat geschrieben:mein Resumee:
regelmäßige „Zwischentaktungen” sind nicht oder nur mit höherer CPU möglich. Eine Aufsplittung in mehrere Speicher (d.h. für einen Oszillator mehrere Loops) sind das effektivste, also genau das, was REAKTOR mit seiner Voice-Verwaltung sowieso macht.
Ja, dabei wird es bleiben.
herw hat geschrieben:Trotzdem erhellt es tiefe Einblicke in REAKTOR.
Danke, ich finde das auch nach wie vor spannend, auch wenn es jetzt nicht zum Wunschergebnis geführt hat.
Es gibt ja auch einfache Möglichkeiten, Nicht-Gleichzeitigkeit im Sinne von Nicht-Synchronisiertsein zu nutzen, die dann auch funktionieren.
herw hat geschrieben:Übrigens eine kleine Verbesserung der CPU erhältst du, wenn du statt des AtoE perm-Moduls einen einfachen Clock-Generator wählst.
Du meinst sicher den PrimaryLevel-ClockGenerator. Ja, das ist das letzte, woran ich mich aus der letzten Nacht erinnere.
Gab´s da nicht ein Problem mit der Genauigkeit bei höheren Frequenzen ?
Immerhin sollte es bei dem Experiment ja Audio sein.
herw hat geschrieben:Für mich ist die erstaunlichste Erkenntnis, dass der Clockgenerator die eigentliche Ursache des CPU-Verbrauchs ist. Obwohl man ihn ja monophon benutzen kann, erhöht sich sein Verbrauch, wenn man die Stimmenzahl erhöht!
Ja, das ist schon verrückt, wie hungrig diese Modul ist. Eigentlich weiß man es ja. Trotzdem, ein Modul verschlingt soviel wie - kann sein, dass ich mich jetzt verrechne - fast 6 Core-Sinus-Osc´s ? Heftig.
Dass die "Energiedifferenz" zum Versuch des "übertakteten" Oscillators besonders heftig ausfällt, liegt natürlich daran, dass eben nur EIN Oscillator tätig ist und was anderes passiert eben auch nicht.
Oh,oh, dieser Tag wird wohl in die - zum Glück - sehr kleine Schublade der verlorenen Tage gehören.
Hat trotzdem richtig Spaß gemacht,
Bis bald, Gerald.