EVENTBUS

[herw]

Ich greife hier mal ein aktuelles allgemeines theoretisches Thema auf. Ich habe es unter das Forum Projekte gefasst, da es sowohl die primary-Ebene wie auch Core-Ebene benutzt also nicht eindeutig einzuordnen ist. Außerdem ist es von der beabsichtigten Größe her eher als ein Projekt zu bezeichnen.
Ich wähle einen theoretischen Ansatz.

Ein Eventbus ist ein Konstrukt, das zum Ziel hat, viele Informationen, Events eben, über eine Leitung zu führen.
Viele Daten über eine Leitung? Warum eigentlich, da verliert man ja die Übersicht!

bus 01.jpg

Im oberen Bild sieht man in der linken Hälfte eine konventionelle Herangehensweise. Alle Informationen sind klar an ein zugehöriges Strukturkabel gebunden. Meistens haben Aus- und Eingang dieselbe Bezeichnung, so dass man den Signalweg gut weiterverfolgen kann.
Dagegen im rechten Teil nur eine Leitung, hier noch symbolisch durch einen Pfeil dargestellt. Gleich lautende Bezeichnungen verbieten sich automatisch - ein Manko.
Soweit der Nachteil: nun die Vorteile. Angenommen es handelt sich nicht nur um fünf bis sechs Eventleitungen sondern 8, 12, 20? Nun noch das ganze 16-fach also insgesamt 320 Leitungen. Ok wenn es sich um gleichartige Makros handelt, kann man diese einschließlich der Verbindungen kopieren.
Aber irgendwann einmal möchte man in ein (Core-) Makro hinein und landet prompt in den Beschränkungen: maximal 40 Eingänge!
Nach einigen (unberechtigten) Flüchen über REAKTOR, kommt die Einsicht, dass eine größere Anzahl von Eingängen einfach nur noch lästig ist. Interessant wird das ganze noch, wenn dieser Bus nicht nur hinein- sondern auch wieder hinausgeht und wieder in andere Makros hineinschlüpft (MODULAR X).
Da zeigt sich die ganze Stärke: Übersicht geht über alles, keine Verharfungen mehr.

Nun kann man fragen, was man alles so damit übertragen kann: ich zähle mal einige wenige einfache Beispiele auf:

• Kontroller-Events vom Panel, Regler, Schalterstellungen, Buttons, XY-Makro, Snapshot-Modul, Multidisplay etc.
• Eventquellen wie Intialisierungskonstanten, ADSR, LFO (siehe zum Beispiel im Ensemble GREYHOUND)
• Eventblöcke mit zusammengehörigen Werten
• ...

All das muss unter ein einheitliches Konzept.
Dies erfordert Basis-Makros, die kleinen Helfer, die den Ablauf und sichere Verarbeitung regelt.

Das Ziel dieses Projektes ist es, anhand von einfachen Beispielen die verschiedenen Prinzipien zu erläutern und vor allem alle Fallstricke sicher zu umschiffen.

Ich hoffe auf viel Diskussion und Beistand, so dass am Ende jeder für sich heraus einen Nutzen ziehen kann. Nebenbei wird das Thema Events in REAKTOR behandelt, also auch Basiswissen.

ciao herw

[KlangRaum]

Bin schonmal auf Deinen Ansatz gespannt !

Gruss
Peter

[herw]

Bin schonmal auf Deinen Ansatz gespannt !

Gruss
Peter

ja so hab ich mir das gedacht: zurücklehnen, Chips und Cola

[KlangRaum]

Nicht lästern. Ja ?
Ich zieh immerhin schon den ganzen Tag Strippen über den dunkelgrünen Hintergrund !
Grad eben ist mir ein kleines Trigger-Event runtergefallen - ich krabbel auf allen vieren aufm dunklen Teppich rum und find es nimmer

Aber ich sehe schon das Du vermutlich einen anderen Ansatz hast als meiner einer… .

[MvKeinen]

coole sache, das interessiert mich akut und brennend

[herw]

ein Kabel?
Wozu nur ein Kabel, abgesehen davon, dass die Obergrenze für die Zahl von Eingängen besteht?
Nun zum Beispiel können so über nur ein Kabel (Kanal) viele Informationen von einer Quelle in tief gelegene Makros übertragen werden:

bus 02.jpg

Angenommen es werden viele Daten von primary über diverse Makros auch in CoreCells übertragen und dort in tiefer gelegenen Core-Makros verwendet. Wie lästig ist es doch, wenn man von Ebene zu Ebene immer wieder dieselben und vielen Strippen ziehen muss.

D.h. ein Bus nimmt viele Daten von verschiedenen Quellen auf und verteilt sie über alle angeschlossenen Ziele. An diesem Bus hängt also nicht nur ein Ziel, sondern es können mehrere Makros je nach Bedarf zugreifen.

Damit das möglich ist, muss bekannt sein, woher die Daten kommen, d.h. unbedingt erforderlich ist auch das Übertragen einer Quelladresse:

Die serielle Übertragung von Daten über einen Bus erfordert zusätzlich zum Wert auch die Übertragung einer Adresse.

Muss ich erwähnen, dass diese Daten natürlich auch polyphon sein können? Man sieht schon nur an diesen noch völlig offenen „Forderungen”, was für Möglichkeiten in REAKTOR 5.5 schlummern.

Nun was kann man sich ausdenken: zum Beispiel können von verschiedenen Datenquellen A und C deren Werte x und z auf den Bus gegeben werden. Alle über den Bus verknüpfte Makros und Zellen können nun auf diese Daten zugreifen, wenn sie die Sendeadresse kennen.

bus 03.jpg

Das erfordert nur eine Leitung! Mehr noch: man überlegt sich, dass man noch eine zusätzliche Quelle B einfügen möchte. Sie benötigt nur auf der Sende- und der Empfängerseite entsprechende Einfügungen zum oder vom Bus. Dazwischen werden alle Makros nicht verändert!

bus 04.jpg

Das gibt Zeit zum Nachdenken und Pläne-Schmieden

ciao herw

PS: ich möchte an dieser Stelle Max Zagler danken, dessen Ideen (erkennbar unter anderem im Player-file PRISM) hier in großem Maße einfließen.

[herw]

Die Bündelung mehrerer Daten zu einem Bus nennt man MULTIPLEXING.
Unabhängig, welche Daten über diese eine Leitung geschickt werden, gibt es beim Multiplexing zwei Phasen: Die Daten müssen zusammengeführt und nach Durchlaufen des Bus wieder getrennt werden. Die erste Phase nennt man multiplexing-Phase (mux), die zweite demultiplexing-Phase (demux).

multiplexing 01.jpg

Die multiplexing-Phase muss die ankommenden Daten so aufbereiten, dass sie in der demultiplexing-Phase wieder korrekt entschlüsselt und an das richtige Ziel weitergeleitet werden. Grob kann man die beiden Phasen als eine Art Router bezeichnen. Das ist relativ einfach umzusetzen. Ein Nachteil ist allerdings, dass die beiden Phasen zentral für alle Quellen und Ziele arbeiten. Eine mögliche Anwendung ist zum Beispiel ein Panelbus, der alle GUI-Daten eines Makros (Stacked-Makros) über eine Leitung an das zugehörige Core-Makro übergibt.
Der MODULAR X benutzt zum Beispiel dieses Prinzip:

panel multiplexing.jpg

Hier am Beispiel eines ADSR-Containers, der die Reglerdaten an die CoreCell übergibt.

Dieser Aufbau ist für ein größeres System, das von vielen weit verzweigten Stellen Daten aufnehmen soll zu unflexibel. Daher ist in diesem Fall ein dezentrales multiplexing viel sinnvoller.

multiplexing 02.jpg

Ein solches Bussystem existiert schon auf primary-Ebene nämlich die internal connections. Die send-Module sind die mux-Makros, die receive-Module die demux-Makros. Die Schalterstellung eines receive-Moduls entschlüsselt die relevanten Daten. Nichts anderes wird im MODULAR für die Patch-Kabel genutzt.
In der zweiten Abbildung erkennt man vor der application ein receive-Makro. Es enthält lediglich ein receive-Modul, das zum Beispiel einen externen Gate-Event erhält. Der Container enthält auch drei Ausgänge (hier im Makro send m03 zusammengefasst), nämlich eine Gate-Quelle (internes Midi-Gate-Modul), den ADSR-Audioausgang und einen zweiten invertierten Ausgang.

[herw]

Konsequent weiter gedacht ergibt sich ein sehr flexibles dezentrales Multiplexing:

multiplexing 03.jpg

[herw]

eine seltsame Überschrift: ... (unkorrekt)

ja, ich will an einem einfachen Beispiel die Problematik des Eventbusses erklären; zur Beruhigung: es gibt eine einfache Lösung.
Nehmen wir als Beispiel das Trigger-Multiplexing. Angenommen es kommt nicht auf die Werte an, die über den Bus verschickt werden, sondern einzig und allein auf den Trigger, der ans richtige Ziel gelangen soll.
Ich habe als Eventquellen einen Regler, einen Button und eine Liste gewählt. Die übertragenen Werte sind ohne Belang, daher werden nur die Zieladressen übergeben.

trigger multiplexing 1.jpg

Ich habe mal zu diesem Ensemble den EventMonitor von James Walker Hall hinzugefügt, da man ihn gut benutzen kann, um die Eventquellen leicht zu erkennen.
Es gibt zwei Versionen der mux- und demux-Makros, jeweils eine in primary und eine in core.
Die mux-Makros sind sehr ähnlich aufgebaut; das value-Modul in primary entspricht dem latch-Modul in core.
Man erkennt sehr schön im Monitor wie ich zunächst den Regler (grünes Event), dann den Button (blaues Event), dann das Listenmodul (gelbes Event) und schließlich wieder den Regler bedient habe. Im Gegensatz zum EventWatcher von Chris List scrollt der EventMonitor von unten nach oben. Die eigentlichen Werte werden durch die Adressen 0, 1 und 2 ersetzt.

trigger multiplexing 2.jpg

Das Demux-Makro ist unterschiedlich gestaltet: in primary kann man sehr einfach den 1->M-Router benutzen in core muss man eine Mehrfachabfrage mit router erstellen.

ciao herw

[herw]

Nun kommt das Problem:
Ich schalte das Ensemble aus und wieder ein und erzeuge dadurch eine Intialisierung.

trigger multiplexing 3.jpg

Nach dem Einschalten erscheinen zwei Events. An den Aktivierungsbuttons des EventMonitors erkennen wir, dass wir die core cells beobachten. Der rote Monitor beobachtet Events hinter dem mux-Makro, grün, blau und gelb beobachten die Ausgänge hinter dem demux-Makro.
Alle Quellen senden bei der Intialisierung einen Event aus, doch es kommt nur einer an?!??
Wer es nicht glaubt kann mal den Regler direkt an den grünen Monitor anlegen.

trigger multiplexing 4.jpg

Wir sehen an der Anzeige, dass der regler den Wert 0,5 in der Tat sendet. Trotzdem gelangt dieser Trigger nicht an den Ausgang des mux-Makros und damit natürlich auch nicht an den Ausgang des demux-Makros.
Offenbar wird nur der Trigger der letzten Quelle 2 durchgereicht.
Wir testen das, indem wir mal in der Struktur vor dem merge-Modul die Anschlüsse 1 und 2 tauschen:

trigger multiplexing 5.jpg

und tatsächlich es wird nun der Trigger 1 durchgeleitet.
Für die Intialisierung gilt:
Alle Eventmodule, die zwei oder mehr Eventquellen verbinden (add, sub, merger usw.), erzeugen während der Initiaisierung nur einen Event.

Ein weiteres Problem ist es, wenn zum Beispiel der untere Anschluss nicht belegt ist; dann wird trotzdem ein Trigger auf den Ausgang 2 geroutet. Auch unbenutzte Eingänge erzeugen einen Event.
Dasselbe Verhalten tritt auch auf, wenn man die primary-Struktur benutzt.

[herw]

Wenn man bedenkt, dass viele Parameter beim Einschalten eines Ensembles und auch eventuell beim Snapshotwechsel gesendet werden müssen, dann ist das ein unhaltbarer Zustand.
Deshalb müssen beim Multiplexing folgende Regeln gelten:

Regel 1 (Durchreichregel)

Jeder Event, der den Multiplexer erreicht, muss auch am Demultiplexer erscheinen. Dies muss auch für die Intialisierung gelten.


Regel 2 (Ausschließlichkeitsregel)

Wenn einer der Anschlüsse des Multiplexers nicht belegt ist, dann darf auch kein Event zum Demultiplexer gelangen. Dies gilt auch für die Initialisierung.

(Dank an Max Zagler für diese klare Vorgabe)

[herw]

Tja, nun ist guter Rat teuer?
Nicht, wenn man einen Blick in das geliebte Handbuch (BidgH) wirft und sich dort das unscheinbare eigentlich so einfache Modul ORDER zu Gemüte führt. Wer etwas mehr lesen möchte, sollte unbedingt die neue (englische) REAKTOR 5 Application Reference English.pdf - Datei lesen und dort insbesondere die Seiten 238-250.
Für uns ist nur das Verhalten des Order-Moduls bei der Initialisierung wichtig. Ohne dessen eigentümliche Eigenschaft wäre multiplexing nicht durchführbar.

Initiaisierung 1.jpg

Wir haben im vorherigen Abschnitt festgestellt, dass das merge-Modul nur einen einzigen Event und zwar vom letzten Eingang bei der Initialisierung sendet. Wir wollen aber, dass alle Eventquellen ihren Initialisierungswert senden.
Nun, der einfache Trick ist, dass man hinter alle Eventquellen ein order-Modul klemmt, das nur den zweiten Ausgang benutzt.
Das Order-Modul verhält sich bei der Initialisierung folgendermaßen: Es sendet nur den Wert zum Ausgang 1. Da er nicht belegt ist, endet hier die Initialisierung. Nun kommt aber die wichtige Eigenschaft, dass nach allen Initialisierungen der Eingangswert über Ausgang 2 und 3 gesendet werden. Außerdem sendet das Ordermodul keinen Wert, wenn an seinen Eingang keine Eventquelle angeschlossen ist!

gerettet!!

[herw]

Nun können wir sehr schnell die korrekte Struktur aufbauen:

trigger multiplexing 6.jpg

Ich habe hinter alle Eventquellen das Ordermodul geklemmt. Das mux-Makro wurde für vier Quellen (0, 1, 2 und 3) vorbereitet, wobei der dritte Eingang (2) nicht belegt ist. Es gibt wieder eine core und eine primary-Version, beide reagieren identisch.
Ich habe den Monitor mal für die core-Makros eingeschaltet: (rot = Trigger 0, grün = Trigger 1, blau = Trigger 2 und gelb = Trigger 3).
Wir schalten das Ensemble aus und dann wieder ein

trigger multiplexing 7.jpg

und siehe da, es wurden drei Trigger-Events empfangen und wie gewünscht vom unbesetzten Eingang 2 nichts.


so einfach kann REAKTOR sein

ciao herw

PS: wer nachträglich mal einen Regler an den unbenutzten Eingang 2 einfügt, bekommt trotzdem nach der Initialisierung die Trigger in der Reihenfolge 0, 1, 2 und 3.

[herw]

Die Hälfte des Vorhabens ist nun geschafft: es ist möglich, nun „ordentlich” (heißt unter Beachtung der beiden oben angegebenen Regeln) Informationen über einen Bus zu übertragen.
Dabei ist das Triggersignal die einfachste Form. Aber man möchte natürlich reale Werte übertragen.
Der Trigger-Event übernimmt dazu die Aufgabe der Adressinformation.
Das oben angegebene Beispiel lässt sich nun leicht verändern; ich gebe mal die primary-Lösung an, das lässt sich aber genauso in core durchführen (mit Ausnahme der Order-Module):
Wir führen die zu übertragenden Werte mit Hilfe des dritten Order-Ausgangs über einen Merger zusammen.

event multiplexing 1.jpg

Wir sehen, dass jeweils zunächst die Adresse (roter Monitor) und dann der Wert (grüner Monitor) gesendet werden.

Auf der Empfänger-Seite gibt es nur eine minimale Änderung

event multiplexing 2.jpg

Nun, wenn schon denn schon: dann auch gleich nur eine Leitung benutzen:

event multiplexing 3.jpg

Das ist die Sendeseite. Die Events 1, 3, 5, und 7 sind jeweils die Adress-Events, die anderen die eigentlichen Werte. Hier ist nur die Initialisierung abgebildet.
Verändert man nun die Reglerposition, dann werden jeweils die Adresse und dann der Einstellwert übertragen.

ciao herw

[herw]

Gut, die Sendeseite ist eindeutig und gut vorbereitend. Durch die „Reinitialisierung” durch die Order-Module, kommen in jedem Fall nur Tupel (Zahlenpaare) der Form (id|val) durch, wobei id die Adresse des Senders ist und val den übertragenen Wert darstellt.
Durch den Anschluss an den zweiten oder dritten Order-Ausgang ist die Reihenfolge gesichert, da diese Events auf demselben Quellevent basieren. Es kann also auch bei komplexeren Eventfolgen (parallel laufende LFOs, ADSRs etc.) über ein und denselben Bus niemals zu Verschränkungen kommen. Es kommen in jedem Fall Adresse und zugehöriger Wert direkt hintereinander. Das ist für das weitere Vorgehen äußerst wichtig.

Für ganz Interessierte eine Bemerkung: richtig kompliziert ist ein Zusammenführen von GUI-events (Mausklicks, Mausreglerbewegungen, Computertastatur etc.) und Audio-basierten events, die mit ControlRate übergeben werden (z.B. MIdiEvents, LFOs, ADSR etc.). Wenn man diese ohne Vorsichtsmaßnahmen mischt, kann es ganz böse Überraschungen geben. Aber das ist ein anderes Thema.

Der Empfang der Tupel kann dezentral geschehen, d.h. mehrere Empfänger können auf denselben Bus zugreifen.