EVENTBUS

[herw]

Die folgenden Core-Macros und die Idee stammen von Max Zagler. Ich habe sie für unsere Zwecke etwas vereinfacht und manche Bezeichnungen angepasst.
Ganz tief im PRISM kann man sie entdecken, wer aber noch weiter sucht ( man folge dem Strang {e} ), kann unschwer erkennen, dass da (sehr professionell) noch viel mehr drinsteckt.

Was ist auf der Empfängerseite zu tun? Eigentlich nicht viel; die Koordinaten des jeweiligen Tupels müssen durch einen Router getrennt werden:

demux 1.jpg

Das demux-macro leitet die Quelladresse auf den Ausgang 0, den Wert auf den Ausgang 1.
Da alle Tupel jeweils in der festgelegten Reihenfolge ankommen, bietet sich ein automatischer Umschalter an, der jeweils auf die erste oder die zweite Koordinate verweist und so den Router steuert. Der Startwert muss dabei 0 sein, da ja immer die Adresse id zuerst gesendet wird. Wer schon mal ein wenig mit anderen Programmiersprachen gearbeitet hat, hat schnell die Assoziation zu einem FlipFlop. Dieses Modul schaltet jeweils einen Zustand um.
Das wird mit der Kombination select [] und einem value delay erreicht.

demux 2.jpg

Wie erkennen, dass es eine Rückkoppelung zum macro value delay gibt; trotzdem erscheint nicht das Symbol für einen Z^-1-Versatz. D.h. die Reihenfolge, in der REAKTOR den Signalfluss interpretiert, führt nicht zu einem loop, sondern ist eindeutig und endlich.
Das Makro select [] ändert jeweils den Zugriff auf die aktuelle Koordinate: wurde gerade die Adresse id (am Ausgang 0) ausgegeben, so wird sie auf 1 geändert und umgekehrt.

demux 3.jpg

Mit dem geänderten Wert muss nun wieder der Router umgeschaltet werden. Das geschieht über eine Zwischenspeicherung im value-delay-Makro (daher kein eventloop!). Erst der nächste eintreffende Wert aus dem Eventbus übergibt nun die geänderte „Anweisung”, so dass der Router auf den anderen Ausgang umschaltet.
Das geschieht immer im Wechsel, d.h. alle Tupel werden korrekt entschlüsselt.
Bleibt nur noch der Einstieg bei der Initialisierung. Der Anfangszustand des Routers muss bei 0 stehen. Da hilft uns die Initialisierung des Speichers im value-delay-Makro. Jeder Speicher wird bei der Initialisierung auf den Wert 0 gesetzt: alles paletti!

Hat man einmal die Systematik des Zwischenspeicherns erfasst, dann erscheint alles völlig einfach und logisch.

[herw]

Alles, was ich gerade beschrieben habe, steckt in dem unscheinbaren Makro receive all.

demux 4.jpg

Wie sein Name schon sagt, wird einfach alles ausgegeben. Bei einem dezentralisierten demux-Makro ist jedoch die Idee eine andere.
Es sollen aus dem Signalfluss nur ganz bestimmte Werte herausgefiltert werden, bzw. wenn man alle Werte benötigt, so sollen sie dem entsprechenden Ziel zugeführt werden. Daher müssen wir zusätzlich noch einen Vergleich durchführen.
Das Makro receiver enthält neben dem receive-all-Makro noch zwei Abfragen, eine für die Übergabe des passenden id-Events und eine für den passenden Wert, die jeweils einen Router öffnen, um die gefilterten Werte durchzulassen.

FERTIG

demux 5.jpg

Ich habe hier als Beispiel den Eventbus in eine Event-CoreCell geführt; dies diente nur dazu, um außen den Monitor anzuschließen, der ja nicht nötig ist, da jetzt ja alles perfekt funktioniert. Selbstverständlich kann man den Eventbus auch in eine Audio-CoreCell führen.
Jetzt könnt ihr eure Fantasie walten lassen und auf die ausgefallendsten Ideen kommen, was man alles mit einem Eventbus anstellen kann. Beachtet, dass die Adressen ja mit übergeben werden. Schaut in der Beschreibung zum Modular X nach, dort findet man weitere Ideen.

ciao herw

[MvKeinen]

WOW erstmal vielen Dank. Super erklärt! Dass es doch so relativ einfach ist hätte ich nicht gedacht. Ist für mich auch sehr nachvollziehbar jetzt. Das wird irgendwann meine Strukturen sehr aufräumen. Genial ist das natürlich für "Engines" die sich ausschließlich in einer Cell befinden sollen und somit die maximalen 40 Eingangsports überschreiten. Das hilft auch für meinen Sequenzer. Vielleicht könnte man sogar mit dem Eventbus per Knopfdruck sämtliche Einstellungen die der User an einem Sequenzer gemacht hat auf einen zweiten kopieren. Dazu müsste man doch nur die Eventleitung in den 2. Sequenzer "routen" und danach die Panelelemente zu einer Werteausgabe "zwingen"?

[herw]

WOW erstmal vielen Dank. Super erklärt! Dass es doch so relativ einfach ist hätte ich nicht gedacht.

Max Zaglers Werk. Seine Gedanken zum Bus sind sehr klar und Ziel führend.

Ist für mich auch sehr nachvollziehbar jetzt. Das wird irgendwann meine Strukturen sehr aufräumen. Genial ist das natürlich für "Engines" die sich ausschließlich in einer Cell befinden sollen und somit die maximalen 40 Eingangsports überschreiten. Das hilft auch für meinen Sequenzer. Vielleicht könnte man sogar mit dem Eventbus per Knopfdruck sämtliche Einstellungen die der User an einem Sequenzer gemacht hat auf einen zweiten kopieren. Dazu müsste man doch nur die Eventleitung in den 2. Sequenzer "routen" und danach die Panelelemente zu einer Werteausgabe "zwingen"?

warum nicht?
schau mal in PRISM hinein, um zu erahnen, was alles möglich ist.

ciao herw

[herw]

Hallo helmsklamm,
lange nichts von dir gehört
Hattest du dein Passwort vergessen und daher die Neuanmeldung?

Das ist keine Geisterbahn sondern lediglich in den jeweiligen read[]- und write[]-Makros gemeinsam genutzte Event-Tables mit Clients. Das geht sogar über verschiedene Instrumente weg.
James Walker Hall hat's erfunden.

ciao herw

[herw]

da sag ich jetzt mal gar nichts zu; ich habe ja auch noch andere viel interessantere Projekte laufen, die hier noch nicht diskutiert sind.
Falls du über event-Tabellen diskutieren möchtest, dann öffne einen neuen thread. Sonst verwässert es sich hier. Der Thread Eventbus ist eigentlich abgeschlossen. Dazu kann man natürlich noch Fragen stellen.

ciao herw

[toxonic]

is ne schöne sache und verständlich erklärt. schade, dass man bei reaktor da so nen riesen aufriss für machen muss, das ist in max und puredata aufgrund der dort vorhandenen "message domain" absoluter standard. funktioniert im prinzip genauso, is bloss 100 mal simpler zu realisieren. da geht dann der
wert von slider 1
in eine messagebox [1 $1( <---die adresse ist also 1 und $1 leitet den wert des sliders weiter
und ein slider 2 in eine messagebox [2 $1(,
deren ausgänge dann mit einem [pack] object (analog zum mux macro) gepackt wird und über ein wire weitergeleitet wird.
das kann man dann hinterher mit einem [route 1 2] object wieder demuxen - feddich.
aber immerhin gibt#s die möglichkeit ja, also wie auch immer - danke für die erklärung.

[herw]

is ne schöne sache und verständlich erklärt. schade, dass man bei reaktor da so nen riesen aufriss für machen muss, das ist in max und puredata aufgrund der dort vorhandenen "message domain" absoluter standard. funktioniert im prinzip genauso, is bloss 100 mal simpler zu realisieren. da geht dann der
wert von slider 1
in eine messagebox [1 $1( <---die adresse ist also 1 und $1 leitet den wert des sliders weiter
und ein slider 2 in eine messagebox [2 $1(,
deren ausgänge dann mit einem [pack] object (analog zum mux macro) gepackt wird und über ein wire weitergeleitet wird.
das kann man dann hinterher mit einem [route 1 2] object wieder demuxen - feddich.
aber immerhin gibt#s die möglichkeit ja, also wie auch immer - danke für die erklärung.

Ich habe die Möglichkeiten, die es hier gibt, nur zu etwa 5% angerissen.
Da gibt es viel komplexere Varianten. Beachte, doch einfach mal, wie in PRISM verschiedene Clocks, und Busse ineinander verwoben sind.
Ich weiß nicht, ob so etwas wie modale Synthese in max oder puredata realisert worden sind.
Inhaltlich stütze ich mich, wie ich schon des öfteren erwähnt habe, auf Max Zagler. Seine frischen Ideen haben mir auch nach jahrelanger REAKTOR-Praxis nochmals die Augen geöffnet.

Aber es freut mich zu hören, dass meine Darstellung so verständlich war.

ciao herw

[toxonic]

tja, ich muss gestehen, ich habe mich seit längerem nicht mehr mit reaktor auseinadergesetzt, da ich mich stärker mit puredata und der faust sprache beschäftigt habe, mit der man im übrigen auch auf extrem simple art und weise seine eigenen vst-dll's kompilieren kann.
was man unter modaler synthese versteht, ist mir unklar, aber ich habe mir jetzt mal das 5.5er reaktor update gezogen und schau mir die geschichte mal an.
cheers

ps: prism kostet 80 euro, die ich gerade nicht habe. schade...

[herw]

tja, ich muss gestehen, ich habe mich seit längerem nicht mehr mit reaktor auseinadergesetzt, da ich mich stärker mit puredata und der faust sprache beschäftigt habe, mit der man im übrigen auch auf extrem simple art und weise seine eigenen vst-dll's kompilieren kann.
was man unter modaler synthese versteht, ist mir unklar, aber ich habe mir jetzt mal das 5.5er reaktor update gezogen und schau mir die geschichte mal an.
cheers

ps: prism kostet 80 euro, die ich gerade nicht habe. schade...

Es gibt in R5.5 zwei sehr starke neue Makros.
Bei der modalen Synthese geht es darum, dass man additiv (durch Obertöne, Partiale) Klänge erzeugt.
Das ist nicht neu. Das neue bei REAKTOR ist, dass es dort nicht um ein paar Obertöne, sondern um hunderte solcher Obertöne geht, die ihre eigenen Hüllkurven, Filter und natürlich ihre Frequenz (hier ratio) haben.
Das muss mit Eventbussen geschehen und zwar dynamisch.
So schön einfach kann eine solche Struktur aussehen:

prism1.jpg

prism2.jpg

Das ist aber auch nur ein kleiner Ausschnitt dessen, was so alles mit Bussen möglich ist:
Digitale Busse (mehrere Informationen in einer integer-Zahl), Block-Event-Busse verschiedener Größe mit variierendem Indexbereich, Mischen verschiedener Busse, Umsortieren von Blöcken, dazwischen selbstverständlich so harmlose Sachen wie LFOs, ADSRs, differentielle Busse (siehe greyhound.ens), alles was mit Events zu tun hat etc..
Aber das ist nicht Thema dieses Threads.

ciao herw

[macrospank]

Vielen Dank für dieses Tutorial !

Hatte bisher eine andere Eventbus Version von CList verwendet. Das Prinzip ist aber gleich. Es funktioniert auch über eine ID und den eigentlichen Wert der gesendet werden soll.

Mit dieser Technik braucht es ja nur noch zwei Kabel für ein Komplexes Ensemble das sonst 1000 Kabel hätte. Klasse Zeitersparniss

[herw]

Vielen Dank für dieses Tutorial !

Hatte bisher eine andere Eventbus Version von CList verwendet. Das Prinzip ist aber gleich. Es funktioniert auch über eine ID und den eigentlichen Wert der gesendet werden soll.

Mit dieser Technik braucht es ja nur noch zwei Kabel für ein Komplexes Ensemble das sonst 1000 Kabel hätte. Klasse Zeitersparniss

ein Kabel!

ciao herw

[macrospank]

ein Kabel!

ciao herw

ups vertippt. Da haste recht

Arbeite gerade an was, da hab ich ein zusätzlichen Feedback bus. Daher hat ich wohl falscherweise zwei Kabel im Kopf.

[herw]

ein Kabel!

ciao herw

ups vertippt. Da haste recht

Arbeite gerade an was, da hab ich ein zusätzlichen Feedback bus. Daher hat ich wohl falscherweise zwei Kabel im Kopf.

Das wäre dann ja ein „Ring-Eventbus”?
Da müsste man Bremsen einbauen, damit es nicht zu einem Eventloop kommt.
Eine sichere Alternative ist, eine Event-Table mit clients zu benutzen.

[macrospank]

Das wäre dann ja ein „Ring-Eventbus”?
Da müsste man Bremsen einbauen, damit es nicht zu einem Eventloop kommt.
Eine sichere Alternative ist, eine Event-Table mit clients zu benutzen.

Na gut, auf „Ring-Eventbus” können wir uns einigen. Ebenfalls richtig erkannt das es da ohne "Bremsen" zu Eventloops kommt.

Wenn es den Rahmen dieses Threads nich sprengt.....
Kannst du mir bitte Event-Table "Clients" kurz erklären oder mich zu einer Erklärung Verweisen?


cheers