(Nicht-) Gleichzeitigkeit in AudioCore

[herw]

spannender wird es natürlich, wenn die Frequenzen unterschiedlich sind und alles über eine Leitung läuft.
Das kannst Du ja heute Nacht vollenden.
Wenn Du es nicht bis morgen früh schaffst, mach ich es

external trigger 2.ens.zip

[krümelmonster]

Hatte eben lange Besuch. Mal schauen, ob ich mich soweit wiederbeleben kann, dass das heute noch geht

[krümelmonster]

DONE !

CoreInternalAudio2EventBus.zip

Bin ich jetzt so hacke, dass ich halluziniere, oder was ist los ?

Es Funktioniert wirklich:

Externe Clock: 1 Osc, 2 (!!) Töne, 0.1% CPU
SR.C.: 2 Osc, 2 Töne, 0.9% CPU

gerald 3.gif

Also das ist schon mal komplett irrsinnig, dass es überhaupt geht.
Dann noch dieser immense CPU-Vorteil ...nein, bevor ich morgen nüchtern zum gleichen Ergebnis komme will ich das nicht glauben.
So ganz unsynchronisiert wäre das Ganze übrigens nicht. Im Grunde ist es sogar EXAKT synchronisiert.
Auch wenn ich gleich zusammenklappe: Jetzt muss ich mir noch ein wenig das Verhalten bei verschiedenen Voice-Einstellungen anschauen, anschließend kommt das Voice-Multiplexing (Anzahl, ...wie soll ich´s nennen ... - "virtueller" klingt besser als "nicht-gleichzeitiger" - Mono-Spuren multipliziert mit Reaktor-Voices) dran.
Wenn das funktioniert, brauchen zumindest die Synth-Bauer vorerst kein R6 mehr.
Wollen wir natürlich alle trotzdem. Sehnsüchtig....

Boooah ey, ich kippe gleich aus den Latschen. Bis zum Wiederaufwachen also erstmal das hier:
Na, siehe ganz oben !
Kann das nicht glauben.
Bestgelaunte, müde Grüße, Gerald.

P.S.: Das sollen die max-Priester einem erst mal nachmachen

P.P.S.: Geil, einfach nur ...

[krümelmonster]

Erste Probleme: Mehr als 2 Töne will er offenbar nicht ausspucken. Schnarch, jetzt reichts aber wirklich für heute.

[krümelmonster]

Hahahaha, die externe Clock selbst läßt die Rechnung natürlich auch nicht aufgehen
Gibt es da nicht was genügsameres als A/Eperm, was auf Eventebene ebenso sauber läuft ?
Klatsch, touchdown im Bett ...

[herw]

Hahahaha, die externe Clock selbst läßt die Rechnung natürlich auch nicht aufgehen
Gibt es da nicht was genügsameres als A/Eperm, was auf Eventebene ebenso sauber läuft ?
Klatsch, touchdown im Bett ...

Deswegen hatte ich den Audiobus auch fallen lassen; in der Regel läuft es darauf hinaus, dass man durch Voice-Erhöhung effizienter arbeitet. Da muss man dann im Nachhinein den Programmierern von REAKTOR hohes Lob zollen.
Aber heute werde ich mich mal an Deine Lösung setzen; man muss auch hohe Voice-Zahlen testen, um abschätzen zu können, ob sich das lohnt.
Zaubern wird man nicht.

[herw]

moin Gerald;
damit es weiter geht, habe ich mal etwas ergänzt:

CIAudio2EventBus2.ens.zip

test 1.gif

Interessant ist, dass es das Oszilloskop (natürlich) nicht schafft, beide oberen Schwingungen zu entdecken.
Im dritten und vierten Oszilloskop werden die wahren Schwingungen von 300Hz und 600Hz angezeigt. In den oberen beiden dagegen wird eine Sinusschwingung von 900Hz abgebildet!

Ich habe übrigens das AtoE-Modul auf mono geschaltet. Das bringt nochmal etwas. Trotzdem ist insgesamt die Lösung mit zwei Oszillatoren effektiver.

herw

[herw]

prinzipiell spannender ist es, wenn man zwei verschiedene Schwingungformen verschachtelt:

test 2.gif

test 3.gif

[herw]

nein Gerald so klappt es nicht: du hast nur scheinbar zwei Töne gehört, da du im letzten Crossfader die Strippen falsch gezogen hast.
Es handelt sich bei "beiden" Schwingungen im oberen Oszillator nur um eine Schwingung die durch die doppelte Taktung eine Schwingung mit der Frequenz f1+f2 erzeugt.
Also wenn überhaupt, dann muss ja auch bei jedem Step des loop-Generators jeweils jeder zweite Wert zwischengespeichert und bei jedem zweiten Clockevent zurückgeholt werden.
Da ist es ja effektiver, gleich zwei loops parallel laufen zu lassen.
Das Oszilloskop müsste bei entsprechender höherer Taktung eine Sinusschwingung anzeigen, deren jeweilige Loop-Steps abwechselnd unterschiedliche Höhen anzeigt. Das schafft es hier natürlich nicht.

CIAudio2EventBus3.ens.zip

Man könnte das wohl darstellen, wenn man beide Oszillatoren extern mit einer geringeren Taktung laufen lässt. Probier ich aus! - nee, klappt nicht.

[herw]

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.

Trotzdem erhellt es tiefe Einblicke in REAKTOR.

Übrigens eine kleine Verbesserung der CPU erhältst du, wenn du statt des AtoE perm-Moduls einen einfachen Clock-Generator wählst.
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!

[krümelmonster]

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.

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.

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.

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

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.

[herw]

[...]
Bis bald, Gerald.

wolltest Du nicht schon längst auf der Matte stehen? Heute ist MITTWOCH!!

ciao herw

[krümelmonster]

Morgen früh geht´s los.
See ya, Gerald.

[KlangRaum]

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.

Ich hab mir das Thema mal vorgenommen, mal sehn wie weit ich komme: Im Grunde geht es darum eine einzelne Struktur in einer Art Schleife mehrfach mit unterschiedlichen Parametern anzusprechen - das wäre dann -falls es auch so klappt- ein guter Ansatz um zb.Multitimbralität zu erzeugen

[herw]

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.

Ich hab mir das Thema mal vorgenommen, mal sehn wie weit ich komme: Im Grunde geht es darum eine einzelne Struktur in einer Art Schleife mehrfach mit unterschiedlichen Parametern anzusprechen - das wäre dann -falls es auch so klappt- ein guter Ansatz um zb.Multitimbralität zu erzeugen

ja dann viel Spaß, ich hoffe du kannst krümelmonster provozieren, sein Wissen hier einzubringen - ein ganz schwieriges Thema - oft auch frustrierend.

ciao herw