Deutsches Reaktor Forum

Werte Reaktor-Freunde,
zur Zeit bastle ich mal wieder an etwas.
In dessen Zusammenhang geht es immer wieder um einen Zusammenhang, den ich für einen der schwierigsten
in Reaktor überhaupt halte, nämlich den zwischen gleichzeitigen und nichtgleichzeitigen Events in AudioCore.
Schwierig ist er immer dann, wenn gleichzeitige und nichtgleichzeitige Events an einem Modul aufeinandertreffen.
Es kann einem die letzten Haare rauben.
Allerdings funktionieren auch echt skurile Dinge ganz wunderbar, die man nicht für möglich halten sollte.
Das wollt ich Euch nicht vorenthalten.

Das beiliegende Test-Ensemble lässt Trigger-Impulse zählen,deren Weg zum Counter ein gewisses Nadelöhr aufweist.

Na, kommen die (Event-) Trigger-Impulse vom Primary-Level "durch" ?
Der "direkte" Impuls kommt selbstverständlich durch.

Durch den Merger, an dessen unterem, Priorität genießenden Eingang die SR.C. unermüdlich sendet,
ja, tatsächlich, auch da kommt er durch.

Und - last but not least - auch wenn ständig die SR.C. am EScontrol Modul hämmert,
der Impuls kommt durch, wenn der Router-Augang gewählt wird, der aktiv ist, wenn KEIN Event am EScontrol anliegt.

Den meisten wird das schon klar sein. Ich dachte mir nur, das es wirklich erhellende Beispiele für einen EIGENTLICH logischen, aber anfangs nicht leichten Sachverhalt sind:

Alles, was nicht gleichzeitig ist, ist nicht-gleichzeitig !

Wofür kann man das gebrauchen ?
Wie gesagt, normalerweise macht dieser Bereich nur Ärger.
Immerhin, das Beispiel mit dem Router zeigt sowohl einen Einsatz, der erstaunlich unproblematisch ist, als auch, wie leicht sich gleichzeitige und nicht gleichzeitige Events ordnen lassen ( ! )
Vielleicht findet´s ja sonst noch jemand spannend.

Viele Grüße, Gerald.

P.S.: Herwig, was meinst Du ?
Ist vielleicht doch eher was für´s Core-Forum ?
Viele Grüße, Gerald.

krümelmonster hat geschrieben:[...]
Immerhin, das Beispiel mit dem Router zeigt sowohl einen Einsatz, der erstaunlich unproblematisch ist, als auch, wie leicht sich gleichzeitige und nicht gleichzeitige Events ordnen lassen ( ! )
Vielleicht findet´s ja sonst noch jemand spannend.

Viele Grüße, Gerald.

P.S.: Herwig, was meinst Du ?
Ist vielleicht doch eher was für´s Core-Forum ?
Viele Grüße, Gerald.

nöö, ist schon korrekt so; (PS (7.4.2009): ich hab's in das Core-Subforum geschoben) ich hab's gleich in mein Archiv übernommen.
Ich hoffe, ich habe heute noch Zeit, hineinzuschauen.

ciao herw

Hhhhmmmh,
jeder scheint´s zu wissen ....
Auch gut, viele Grüße, Gerald.

krümelmonster hat geschrieben:Hhhhmmmh,
jeder scheint´s zu wissen ....
Auch gut, viele Grüße, Gerald.

ich stecke gerade in 45-50-Stunden-Wochen und hab' kaum Zeit zum Atmen

herw hat geschrieben:... stecke gerade in 45-50-Stunden-Wochen ...

Armer Kerl, hast mein volles Mitleid.
Hatte zwar letztes Jahr 3,5 Monate lang >70-Stunden-Wochen; trotzdem, 50 Stunden will ich mir auch nicht noch mal antun.
Das ist dann auch irgendwann nicht mehr gesund. Also, Ball flach halten !

Wenn Du mal wieder dazu kommst - anscheinend sind wir hier ja eh privat: Was hältst denn Du im Moment vom internationalen Forum. Ist zwar natürlich mehr los, aber doch teilweise ganz schön traurig, oder ?
Damit meine ich vor allem ein paar Kandidaten, die schon ewig dabei sind, ..oh, oh ...
Da traut man sich ja gar nicht zu sagen, wie es geht.

Laß es Dir, soweit möglich, gut gehen.
Bin Anfang April mal wieder da.
Viele Grüße, Gerald.

krümelmonster hat geschrieben:

herw hat geschrieben:... stecke gerade in 45-50-Stunden-Wochen ...

Armer Kerl, hast mein volles Mitleid.
Hatte zwar letztes Jahr 3,5 Monate lang >70-Stunden-Wochen; trotzdem, 50 Stunden will ich mir auch nicht noch mal antun.
Das ist dann auch irgendwann nicht mehr gesund. Also, Ball flach halten !

[...]
Viele Grüße, Gerald.

Die gefühlten Stunden sind leider höher, denn um auf eine reine Arbeitszeit von 7 Stunden pro Tag zu kommen, muss man sich ca. 10 Stunden mit dem Beruf beschäftigen. 70 Stunden sind mörderisch.

ciao herw

PS: Anfang April ist gut!

herw hat geschrieben:70 Stunden sind mörderisch.

Ja, da ist auch was kaputt gegangen. Nie mehr wieder.
Viele Grüße, Gerald.

krümelmonster hat geschrieben:Werte Reaktor-Freunde,
zur Zeit bastle ich mal wieder an etwas.
In dessen Zusammenhang geht es immer wieder um einen Zusammenhang, den ich für einen der schwierigsten
in Reaktor überhaupt halte, nämlich den zwischen gleichzeitigen und nichtgleichzeitigen Events in AudioCore.
Schwierig ist er immer dann, wenn gleichzeitige und nichtgleichzeitige Events an einem Modul aufeinandertreffen.
Es kann einem die letzten Haare rauben.
Allerdings funktionieren auch echt skurile Dinge ganz wunderbar, die man nicht für möglich halten sollte.
Das wollt ich Euch nicht vorenthalten.

Das beiliegende Test-Ensemble lässt Trigger-Impulse zählen,deren Weg zum Counter ein gewisses Nadelöhr aufweist.

Na, kommen die (Event-) Trigger-Impulse vom Primary-Level "durch" ?

event-audio-connection, small.JPG

Der "direkte" Impuls kommt selbstverständlich durch.

Durch den Merger, an dessen unterem, Priorität genießenden Eingang die SR.C. unermüdlich sendet,
ja, tatsächlich, auch da kommt er durch.

Und - last but not least - auch wenn ständig die SR.C. am EScontrol Modul hämmert,
der Impuls kommt durch, wenn der Router-Augang gewählt wird, der aktiv ist, wenn KEIN Event am EScontrol anliegt.

Den meisten wird das schon klar sein. Ich dachte mir nur, das es wirklich erhellende Beispiele für einen EIGENTLICH logischen, aber anfangs nicht leichten Sachverhalt sind:

Alles, was nicht gleichzeitig ist, ist nicht-gleichzeitig !

Wofür kann man das gebrauchen ?
Wie gesagt, normalerweise macht dieser Bereich nur Ärger.
Immerhin, das Beispiel mit dem Router zeigt sowohl einen Einsatz, der erstaunlich unproblematisch ist, als auch, wie leicht sich gleichzeitige und nicht gleichzeitige Events ordnen lassen ( ! )
Vielleicht findet´s ja sonst noch jemand spannend.

Viele Grüße, Gerald.

[...]

Hallo Gerald,
ich habe mir die Struktur mal angesehen und ein wenig verändert: statt der 1-Werte, habe ich verschiedene gelatchte Werte gewählt.
Ich weiß nicht ob es beabsichtigt ist, aber vor dem Speicher des post merge ist der Schreibbefehl nicht getriggert (also nur beim initial reset); ist das beabsichtigt?
Interessant ist, dass bei meiner Struktur der direkte Wert 4 niemals ankommt bzw. vielleicht nur einmal und daher nicht nachweisbar. Ich muss über die Struktur nochmals nachdenken.

herw hat geschrieben:Ich weiß nicht ob es beabsichtigt ist, aber vor dem Speicher des post merge ist der Schreibbefehl nicht getriggert (also nur beim initial reset); ist das beabsichtigt?

oooops, keine Ahnung, wieso das Latch im Upload nicht verbunden ist
In meiner Datei auf dem Rechner ist dem selbstverständlich so. Sonst ließe sich ja nicht resetten.
Da muss der Schlafmangel seinen Tribut gefordert haben.
Hab das Original hier noch mal drangehängt.

herw hat geschrieben:Interessant ist, dass bei meiner Struktur der direkte Wert 4 niemals ankommt bzw. vielleicht nur einmal und daher nicht nachweisbar.

Ich habe mir gerade die Finger wundgetriggert und alles läuft bestens.
... muss ein Mac-Problem sein

Gruß, Gerri.

Bitte versuch's mal mit meinem Ensemble!
Im obersten Zweig wird durch den Trigger-Impuls einmal der Speicher (mit dem Wert 0) ausgelesen und durch den 1+Addierer erhöht. Danach wird dieser Zwischenspeicher mit Audiorate ständig unverändert ausgelesen. Also logisch, dass eine 1 ausgegeben wird. Im zweiten Zweig wird der Latchwert 4 zwar über das merge-Modul zugeführt aber beim nächsten SR-Clock (Wert immer 0) überschrieben, so dass bei der Ausgabe core-logisch der Wert 0 durchgereicht wird und dementsprechend der Wert 0+2=2 angezeigt wird.
Im dritten Zweig wird der Latchwert 4 beim nächsten Sample-Tick durchgereicht.
Der Latchwert 4 gelangt gleichzeitig (synchron zum Sample-Tick) als Triggerevent an das Auslesemodul des dritten Zwischenspeichers und gibt den 0-Wert an den 3+Addierer weiter, der neue Wert 3 wird auch brav in den Zwischenspeicher geschrieben und im folgenden ausgegeben. Der Wert 3 liegt zwar am oberen Eingang, überschreibt aber die anderen Werte 0, da diese nur bei der Intialisierung und beim Reset einmal hineingeschrieben werden. Also alles logisch.

Ich kann keinen Fehler entdecken. Die Core-Interpretation und -Implementation der Gleichzeitigkeit ist in allen Punkten erfüllt.

ciao herw
(kauf Dir einen gescheiten Rechner )

(PS : ich hab's in das Core-Subforum geschoben)

herw hat geschrieben:Bitte versuch's mal mit meinem Ensemble!

Hab ich gemacht.
Sry, Herwig, wenn ich wiedersprechen muss.
Nichts für ungut, aber - : Was hast Du verändert ?
4 Konstanten. Drei davon sind Inkremente des Counters. Die verändern ausschließlich den Betrag der Wertausgabe und zwar bei Dir dahingehend, dass die Zählerstände ab dem ersten Triggervorgang verschieden sind (die sich ergebenden verschiedenen Folgenbildungen tun hier ja nichts zur Sache).
Ich finde, dass diese Maßnahme den Blick für den Sachverhalt, um den es mir geht, eher verschleiert.

Die vierte Konstante ist die Gelatchte ausserhalb des Counters. Die "4", durch die Du die ursprüngliche "1" ersetzt hast, verhält sich im einzigen nachfolgenden Test ( >0 ?) exakt gleich. Mit anderen Worten: Strukturell hast Du nichts verändert.

herw hat geschrieben: ... Danach wird dieser Zwischenspeicher mit Audiorate ständig unverändert ausgelesen. Also logisch, dass eine 1 ausgegeben wird.

Nein, es wird nichts mit Audio-Rate ausgelesen.

herw hat geschrieben:Im zweiten Zweig wird der Latchwert 4 zwar über das merge-Modul zugeführt aber beim nächsten SR-Clock (Wert immer 0) überschrieben

Nein, es wird nichts überschrieben. Im Counter nicht, da Events <0 durch den Separator geblockt werden und am Merger davor auch nicht, weil sie NICHT gleichzeitig mit der SR.C. sind.
Das ist der entscheidende Punkt. Der Grund für den thread.
Die quickbubble über dem wire zwischen Merger und Counter mag nie eine "4" anzeigen (Trägheit von Auge und Display), überschrieben wird der Wert nicht. Er geht einfach durch.

herw hat geschrieben:Im dritten Zweig wird der Latchwert 4 beim nächsten Sample-Tick durchgereicht.
Der Latchwert 4 gelangt gleichzeitig (synchron zum Sample-Tick) als Triggerevent an das Auslesemodul des dritten Zwischenspeichers ...

Nein. Nein, nein, nein, ... Der Triggerevent ist NIE gleichzeitig mit der SR.C.
Sonst käme er nicht durch den Router !
Der entscheidende Punkt. Wieder.
Ich finde das höchst beindruckend.
Die Gleichzeitigkeit in Core ist eine solche per declarationem: ' Alle Events, deren Ursprung ein und derselbe ist, sind gleichzeitg'. Gut.
Hier geht es um den Umkehrschluss:
"Alle Events, deren Ursprung nicht ein und derselbe ist, sind nicht-gleichzeitig." Auch nicht-gleichzeitig mit der Sample-Clock.
Die Konsequenzen daraus kann man an beiden Beispielen erkennen.

Für die meisten dürften daraus nie Probleme entstehen.
Bei der Klangerzeugung mit Oszillatoren in AudioCoreCells benutzt Du doch immer - und zwar bewußt - die Vorteile der Gleichzeitigkeit, die durch die SR.C. entsteht.
Bei der Eventverarbeitung in EventCoreCells macht man von beiden Prinzipien Gebrauch; eine SR.C. als interne synchronisierende Maßnahme fällt weg.
Solange diese beiden Dinge nicht in AudioCore kollidieren, gibt es keine Probleme.

Ich hatte sie auch nie.
Deswegen war ich auch über einen NI-thread, den ich mal raussuchen sollte, sehr überrascht, in dem CList irgendwo ein Beispiel für diese Problemzone gibt: Eine Ramp, die ein Modulationssignal steuert, soll mit einer EXTERNEN, somit in jedem Falle nicht-gleichzeitigen Midi-Clock synchronisiert werden. Durchaus lösbar. Aber wenn es wirklich sauber sein soll ein Graus.

Mein "Problem" derzeit - eigentlich ist es gar keins - ist, ebenso eigentlich, kleiner:
Man hat ja JEDERZEIT die Möglichkeit, einkommende Events mit der SR.C. zu synchronisieren.
Ich frage mich nur, ob ich mich in meinem Falle nicht mit dieser Maßnahme vieler Möglichkeiten beraube.
In meinem Fall reichen Eventketten, deren Ursprung Event-Eingänge sind, sehr tief in den Raum einer AudioCoreCell. Das sind jetzt schon reichlich Berechnungen, die ich nur ungern mit der SR.C. synchronisieren würde. Irgendwann treffen diese Welten aber dann doch aufeinander.
Um den Zusammenhang zwischen diesen Welten - und darum, wie man sie dazu bringen kann, sich selbst zu ordnen - ging es in diesem Beispiel.
Wie gesagt, kaum einer wird damit je Probleme bekommen; ich versuche nur, das zu nutzen.

herw hat geschrieben:(kauf Dir einen gescheiten Rechner )

Hab einen. Könnte nur ein bischen neuer und somit flotter sein

Viele Grüße, Gerald.

krümelmonster hat geschrieben:

herw hat geschrieben:Bitte versuch's mal mit meinem Ensemble!

Hab ich gemacht.
Sry, Herwig, wenn ich wiedersprechen muss.
Nichts für ungut, aber - : Was hast Du verändert ?
4 Konstanten. Drei davon sind Inkremente des Counters. Die verändern ausschließlich den Betrag der Wertausgabe und zwar bei Dir dahingehend, dass die Zählerstände ab dem ersten Triggervorgang verschieden sind (die sich ergebenden verschiedenen Folgenbildungen tun hier ja nichts zur Sache).

das war der Sinn, damit ich einfach unterscheiden kann was passiert. Man kann daran gut erkenn, dass dein Trigger (zufäälig hier auf 1 gesetzt, mit den Ausgabewerten nichts zu tun hat

[...]
Die vierte Konstante ist die Gelatchte ausserhalb des Counters. Die "4", durch die Du die ursprüngliche "1" ersetzt hast, verhält sich im einzigen nachfolgenden Test ( >0 ?) exakt gleich. Mit anderen Worten: Strukturell hast Du nichts verändert.

war auch nicht meine Absicht

herw hat geschrieben: ... Danach wird dieser Zwischenspeicher mit Audiorate ständig unverändert ausgelesen. Also logisch, dass eine 1 ausgegeben wird.

Nein, es wird nichts mit Audio-Rate ausgelesen.

???? da Du eine AudioCoreCell gewählt hast, werden deren Ausgänge ständig mit Audiorate angezeigt. Was ist daran falsch?

herw hat geschrieben:Im zweiten Zweig wird der Latchwert 4 zwar über das merge-Modul zugeführt aber beim nächsten SR-Clock (Wert immer 0) überschrieben

Nein, es wird nichts überschrieben. Im Counter nicht, da Events <0 durch den Separator geblockt werden und am Merger davor auch nicht, weil sie NICHT gleichzeitig mit der SR.C. sind.
Das ist der entscheidende Punkt. Der Grund für den thread.
Die quickbubble über dem wire zwischen Merger und Counter mag nie eine "4" anzeigen (Trägheit von Auge und Display), überschrieben wird der Wert nicht. Er geht einfach durch.

soll er ja auch; ich widerspreche nicht; alles konform zur core-logik

herw hat geschrieben:Im dritten Zweig wird der Latchwert 4 beim nächsten Sample-Tick durchgereicht.
Der Latchwert 4 gelangt gleichzeitig (synchron zum Sample-Tick) als Triggerevent an das Auslesemodul des dritten Zwischenspeichers ...

Nein. Nein, nein, nein, ... Der Triggerevent ist NIE gleichzeitig mit der SR.C.
Sonst käme er nicht durch den Router !

korrekt - mein Fehler (ich hatte ein latch-Modul im Kopf)

Der entscheidende Punkt. Wieder.
Ich finde das höchst beindruckend.
Die Gleichzeitigkeit in Core ist eine solche per declarationem: ' Alle Events, deren Ursprung ein und derselbe ist, sind gleichzeitg'. Gut.
Hier geht es um den Umkehrschluss:
"Alle Events, deren Ursprung nicht ein und derselbe ist, sind nicht-gleichzeitig." Auch nicht-gleichzeitig mit der Sample-Clock.
Die Konsequenzen daraus kann man an beiden Beispielen erkennen.

korrekt, aber wo ist jetzt der Widerspruch zur core-Logik der Gleichzeitigkeit? Genau so wird es im Handbuch beschrieben.

[...]

Viele Grüße, Gerald.

herw hat geschrieben: ... Danach wird dieser Zwischenspeicher mit Audiorate ständig unverändert ausgelesen. Also logisch, dass eine 1 ausgegeben wird.

krümelmonster hat geschrieben:Nein, es wird nichts mit Audio-Rate ausgelesen.

herw hat geschrieben:???? da Du eine AudioCoreCell gewählt hast, werden deren Ausgänge ständig mit Audiorate angezeigt. Was ist daran falsch?

Die Ausgänge selbstverständlich, aber keine Zwischenspeicher.

herw hat geschrieben: korrekt, aber wo ist jetzt der Widerspruch zur core-Logik der Gleichzeitigkeit? Genau so wird es im Handbuch beschrieben.

Da ist kein Widerspruch Hab auch nie von einem gesprochen.
Es ist alles komplett konform mit allen Normen und Gesetzen von Core.
Es bräuchte einen also alles nicht zu wundern.
Es hat mich trotzdem beeindruckt.
Zum einen, wie mühelos Reaktor mit solchen Signalengpässen umgeht.
Zum anderen, wie gut sich alles dahinter wieder auflösen lässt.
Ins Extrem gedacht bedeutet dies, das man einen jeden Audio-Bus benutzen kann, um nicht-gleichzeitige Events - und zwar "ohne Ende" - an einen jeden Punkt innerhalb der Cell zu leiten. Gut, wird man nicht machen, weil die anschließenden Abfragen mit SR.C wieder "teurer" würden.
Mich würde - noch extremer - sogar interessieren, ob sich - audioCell-intern - nicht sogar Dein Konzept vom AudioEvent-Bus anders anwenden ließe. Mir kommen da ziemlich fiese Multiplexing-Ideen.

Aber für Euch ist das ja alles einfach nur selbstverständlich, schnüff

Viele Grüße, Gerald

Schau Dir das hier mal an !
Da wird man ja verrückt !
Der Trick, Strukturen nicht über die SR.C. zu treiben, sondern über eine externe Clock, ist ja nun ziemlich alt.
Was ich nie, nie, nie gedacht hätte: Wenn die externe Clock über einen Event-Eingang die gleiche Frequenz wie die SR.C hat, ergibt sich dadurch KEINE Steigerung der CPU-Last. Ganz im Gegenteil
Im angehängten Beispiel eines simplen Sinus-Osc in einer Cell sinkt sie bei mir auf ein Fünftel
Das ist schon mal kaum kaum zu glauben.

Wenn man jetzt ein und die gleiche Clock nun über n Event-Inputs in die Cell leitete und alle diese Clocks gleich nach dem Eingang einfach zusammenmergte, könnte man sie als n nicht-gleichzeitige Event-Ströme alle in ein und die gleiche Struktur schicken und hätte so selbst innerhalb einer Mono-Cell n "Stimmen".
Das Ganze mal der in Reaktor maximal möglichen Voices ergibt .....

.............. unendliche Weiten .............

Und das Ganze zu weniger CPU als sonst ?

Bitte sagt mir, dass das alles nicht wahr ist, sonst heb ich gleich ab !
Also jetzt bin ich mehr als schwer beeindruckt.

Viele Grüße, Gerald.

P.S.: Muss gleich mal schauen, ob der Sound bei externer Taktung der gleiche bleibt.
Und mal schauen, ob sich das in einer EventCell gleich bleibt.
Jetzt gehe ich erst mal was essen.

Meine Güte, Du gehst aber ans Eingemachte; Du arbeitest wohl heimlich an Reaktor 7?
Wenn ich jetzt zehn unkoordinierte Sinusgeneratoren miteinander zusammenbringe, bekomme ich dann negative CPU-Einheiten geschenkt? Und was ist, wenn ich dann Parallelwelten in Reaktor habe und miteinander verknüpfen möchte? Kann ich die dann überhaupt hören? Den philosophischen Aspekt REAKTORs habe ich noch nie betrachtet.
Interessant, da diskutieren wir in den nächsten Tagen drüber. Vorher zeige ich Dir aber erst so profane Dinge, wie man einen Bildschirmausschnitt verkleinert

ciao herw

PS: Guten Appetit übrigens; ich geh ins Bett, seit es wieder Sommerzeit gibt, bin schon eine Stunde früher müde; irgendwie erinnert mich das an die negativen CPU-Einheiten. Normalzeit und Sommerzeit laufen wahrscheinlich unkoordiniert parallel ab, daher die vorgezogene Müdigkeit.