PARTIALS FRAMEWORK (multiplexing)

[macrospank]

Moin !

In der PDF Multiplexing hab ich einen Fehler entdeckt. Folie 43 mit der Überschrift Improvements?

Da heißt es ....

A decentralized demultiplexer is a lot more useful than a decentralized multiplexer


...kann ja irgendwie nicht stimmen oder? Vielleich weiß jemand wie´s richtig heisst? Centralized ?

[herw]

Moin !

In der PDF Multiplexing hab ich einen Fehler entdeckt. Folie 43 mit der Überschrift Improvements?

Da heißt es ....

A decentralized demultiplexer is a lot more useful than a decentralized multiplexer


...kann ja irgendwie nicht stimmen oder? Vielleich weiß jemand wie´s richtig heisst? Centralized ?

eine Textstelle, die in der Tat schwer verständlich ist:
springe im Text zurück auf die Folien 15 und 16:
Der Begriff „zentral” wird benutzt, wenn alle Daten an einer zentralen Stelle gesammelt oder verteilt werden (Folie 15); der Begriff „dezentral” wird dann benutzt, wenn an beliebigen Punkten des Eventbusses ein Zugriff schreibend wie lesend erfolgt (Folie 16). Beide sind extrem gegensätzlich.
In Folie 43 wird nun abgewogen, ob man das prinzipiell vorteilhafte dezentrale Zugreifen auch wirklich gut einsetzen kann.
Der zitierte Satz macht deutlich, dass auf der Entschlüsselungsseite (demultiplexing) die Vorteile offensichtlich sind, da die gesendeten Daten ja an ganz verschiedenen „Verbrauchstellen” (sinks) ausgelesen werden.
Der Vorteil einer dezentralen Einspeisung in den Bus (multiplexing) ist dagegen nicht so offensichtlich, da man ja die Adressierung der Daten durch einen identifier id in sich stimmig halten muss. D.h. man muss sich Gedanken darüber machen, wie man die Adressen verwaltet. Dies geschieht in der konkreten Anwendung zum Beispiel durch eine serielle Adressenverwaltung:

zentrales multiplexing.jpg

Man hängt einfach weitere mux-Makros an. Unbenutzte Eingänge senden dabei keinen Event. Die Adressierung kann auch in den negativen Bereich gehen.
Zum Beispiel kann man so leicht Systeminformationen wie Anzahl der Voices, aktuelle Voice, SampleRate etc. mit negativen Adressen versehen, so dass man sie von den GUI-Events sehr schnell trennen kann und so Abfragen spart.
Zurück zum zentralen Multiplexing: auf der Folie 15 wird deutlich, dass ein zentrales multiplexing quasi einen starren Verbund an Daten erfordert. D.h. alle Quellen senden in fester Reihenfolge und Anzahl ihre Daten. Ein dezentrales Multiplexing dagegen „wartet” auf die Daten einer beliebigen Quelle und kann auch Datenverbunde oder Datenblöcke (message) unterschiedlicher Länge senden.
Der Vorteil ist offensichtlich (?). Der Satz meint, dass es aber schwieriger ist ein ordentliches multiplexing bereitzustellen.

Ich mache mal ein einfaches Beispiel:
Will man die Daten eines xy-Moduls senden, so werden bei einem ersten Click sowohl die x-Koordinate, die y-Koordinate als auch der Buttonzustand mb gesendet, also ein Datenblock mit drei Daten (mx, my, mb). Alle weiteren Aktionen liefern aber nur Änderungen: d.h. ändert sich beim Ziehen mit der Maus nur die waagerechte Position des Cursors, so werden auch nur x-Daten gesendet.

xy-mux.jpg

Einfacher wäre es, ein zentrales multiplexing zu verwenden, das bei jeder Aktion immer ein Daten-Tripel (mx, my, mb)
sendet.

xy-mux2.jpg

Andererseits müsste eventuell auf der Empfängerseite wieder geprüft werden, was sich geändert hat.
D.h. man muss sich hauptsächlich auf der multiplexing-Seite Gedanken darüber machen, wie man die Daten einspeist.
Insofern ist das dezentrale Demultiplexing viel einfacher zu handhaben (a lot more useful).

In meinem Projekt sende ich beispielsweise bei der Initialisierung einen ganzen Block:

Initialisierungsblock.jpg

Der Block wird durch einen SingleShot erzeugt:

singleshot.jpg

[zama]

Zurück zum zentralen Multiplexing: auf der Folie 15 wird deutlich, dass ein zentrales multiplexing quasi einen starren Verbund an Daten erfordert. D.h. alle Quellen senden in fester Reihenfolge und Anzahl ihre Daten. Ein dezentrales Multiplexing dagegen „wartet” auf die Daten einer beliebigen Quelle und kann auch Datenverbunde oder Datenblöcke (message) unterschiedlicher Länge senden.
Der Vorteil ist offensichtlich (?). Der Satz meint, dass es aber schwieriger ist ein ordentliches multiplexing bereitzustellen.

Also mit der Art der Daten hat das eigentlich nichts zu tun... In erster Linie empfinde ich es als sinnvoll die IDs beim Senden an einer zentralen Stelle verwalten zu können. Ein zentraler Multiplexer schafft meiner Meinung nach mehr Übersicht (aber darüber lässt sich vielleicht auch streiten).

[herw]

Hi Max,
Danke für die Richtigstellung!

Ja - aber

Wenn man einen modularen Aufbau zum Beispiel mit Hilfe des AMPERE MODULAR oder meines Projektes plant, dann liegen nun einmal die Quellen dezentral.
D.h. man muss die Identifier der einzelnen Quellen möglichst einmal festlegen (das ist bei einem veränderbaren Aufbau unbequem) oder, wie ich es mache, die relativen Adressen zu absoluten machen, indem man einen Initialisierungsbus legt und die Identifier aufgrund ihrer Anordnung automatisch errechnen lässt.

Beide Möglichkeiten zentral/dezentral hängen wirklich von dem speziellen Ensemble ab und sind ja mit Hilfe der multiplexing library realisierbar.

PS: wenn man unter google „partials framework” eingibt, landen wir schon jetzt auf der Spitzenposition!

[macrospank]

Vielen Dank für die Erleuchtung!
Damit wurden auch einige Fragen für mich beantwortet die ich noch garnicht gestellt habe. Wie machst du das nur immer herw?

Sehr aufschlussreich das ganze. Bisher kannte ich nur das Zentrale Multiplexing was sich meiner Meinung nach übersichtlich Implementieren lässt.
Letztendlich schliesse Ich aus euren Antworten das es abhängig von der eigenen Struktur und der Art der Verwendung entscheidend ist ob "Zentral" oder "Dezentral" besser ist.

Danke euch beiden und Danke für die PARTIALS FRAMEWORK Library. Kann es nur jedem empfehlen sich damit auseinanderzusetzen.

[herw]

[...]
Damit wurden auch einige Fragen für mich beantwortet die ich noch garnicht gestellt habe. Wie machst du das nur immer herw?
[...]

Ach, das fällt mir leicht, da ich 1. stark in diesem Thema bin und 2. ich ab jetzt (heureka!) endlich wieder Zeit für REAKTOR finde.
Die dezentrale Anordnung gefällt mir natürlich im Moment besser.
Bei einem nicht-modularen Ensemble (ich habe schon eines im Kopf) ist ein zentrales Multiplexing sicherlich besser, wie Max das erwähnt.

[herw]

Beispiel 1: einfacher Eventbus

Hier möchte ich mal ein sehr einfaches Beispiel vorstellen. Damit auch die Notwendigkeit eines Busses sichtbar und einleuchtend wird, habe ich mal einfach ein Dummie-Beispiel eines Sequenzers genommen. Dummie heißt: nur die Daten der Panelelemente werden in eine AudioCoreCell über einen Bus transportiert und dort exemplarisch ausgelesen.
Als Orientierung diente mir der Hardwaresequenzer DarkTime von Doepfer.

Hier nun meine Dummieversion:

Beispiel 1-1.jpg

16 Step-Regler und 32 List-Module und zwei globale Regler, also insgesamt 50 Eventquellen, werden über einen Bus in eine AudioCoreCell geleitet (EventMonitor rot).

Beispiel 1-2.jpg

Dort werte ich exemplarisch nur die Eventquelle 6 aus (Stepregler 3) und alle Eventquellen zwischen 24 und 47 (Stepregler 9 bis zum zweiten Listmodul des 16. Steps).

Beispiel 1-3.jpg

Nach dem Start des Ensembles (REAKTOR-Version 5.6.0) wurden 152 Daten gesendet: 150 vom Bus selbst und zwei von den Ausgängen A und B der AudioCoreCell.

Hier ist Zeit zum Experimentieren:

• Erkläre die roten Events (1-150) und die günen und blauen Events nach dem Start des Programms
• Setze den Eventmonitor zurück, aktiviere den Stepregler 1 und verändere den Wert mit dem Cursor - Erklärung?
• Setze den Monitor zurück und verfahre genauso mit dem Regler 3 und einem Panelelement der zweiten Stepreihe. - Erklärung?
• Finde in der Struktur jeweils die jeweiligen Module im partials framework! (mühsam, aber nur so lernt man die library kennen)
• verändere das Beispiel

Viel Spaß herw

[macrospank]

Homework Korrekt ?

1.Erkläre die roten Events (1-150) und die grünen und blauen Events nach dem Start des Programms

Die Events zum roten Monitor sind die Panel Elemente, Länge und Index.
Diese werden in ein Kabel zu einem Eventblock zusammengeführt .

Nach dem Start wird an die Monitore rot,grün und blau ein Initialisierungs Event von der jeweiligen Quelle gesendet (weitergeleitet).


2.Setze den Eventmonitor zurück, aktiviere den Stepregler 1 und verändere den Wert mit dem Cursor - Erklärung?

Es werden immer 3 Events gesendet. 1. # Länge des Event Blocks 2. []Index des Events 3. $ Der eigentliche Wert.


3. Setze den Monitor zurück und verfahre genauso mit dem Regler 3 und einem Panelelement der zweiten Stepreihe. - Erklärung?

Das Macro Datenverarbeitung (eine Art Demux) Filtert Länge und Index aus, lässt nur Events vom 3rd Panel Knob durch und leitet diesen einen Regler-event zu Monitor grün.
Events von einem beliebigen Knob der 2.Panel Reihe senden zu Monitor blau.


4.Finde in der Struktur jeweils die jeweiligen Module im partials framework! (mühsam, aber nur so lernt man die library kennen)

Um schnell die Richtigen Module zu finden würde Ich alle Macros in eine große Core Cell packen. So hat man alles direkt im Überblick, nimmt sich das passende Macro raus und kann den Rest dann wieder Löschen.


5.verändere das Beispiel

Hier sollte jeder selbst experimentieren. Das wird auch etwas dauern, da die Library sehr groß ist.

[herw]

Homework Korrekt ?

1.Erkläre die roten Events (1-150) und die grünen und blauen Events nach dem Start des Programms

Die Events zum roten Monitor sind die Panel Elemente, Länge und Index.
Diese werden in ein Kabel zu einem Eventblock zusammengeführt .

nicht ganz korrekt: jede Eventquelle sendet zum Programmstart einen Initialisierungsevent. Jeder Event erzeugt einen Eventblock aus drei Werten: (id,#,$) = (Identifier der Eventquelle, Anzahl der folgenden Daten, der Eventwert); d.h. es werden über den Bus 50 Tripel (Dreierblöcke) gesendet.
Eigentlich wären nur zwei Events nötig (id,$). Dann müssten aber alle Makros die für Eventblöcke existieren nochmals zusätzlich für reine Events erstellt werden.
Das war auch in der ursprünglichen Version des partials framework der Fall, doch hat Max (sinnvollerweise) entschieden, dass eine einheitliche Verwaltung viel sicherer ist. Der zusätzliche Event # (Länge des „Blockes”) ist nicht der Rede wert. Vergleiche dazu meine Ausführungen im Thread EVENTBUS.
Der grüne Event ist der Wert des Stepreglers 3; das ist klar. Interesant ist, dass beim Initialisieren der zweiten Stepreihe nur der Wert der 48. Eventquelle (unteres List-Modul des 16. Steps) ausgegeben wird und nicht wie man vermuten könnte alle Events zwischen 24 und 48. D.h nur der sequentiell letzte Block wird ausgewertet. Das kann man mal ausprobieren, indem man nur die Abfrage id>23 benutzt, dann wird logischerweise nur der letzte Reglerwert pulsewidth übertragen.

Nach dem Start wird an die Monitore rot,grün und blau ein Initialisierungs Event von der jeweiligen Quelle gesendet (weitergeleitet).

2.Setze den Eventmonitor zurück, aktiviere den Stepregler 1 und verändere den Wert mit dem Cursor - Erklärung?

Es werden immer 3 Events gesendet. 1. # Länge des Event Blocks 2. []Index des Events 3. $ Der eigentliche Wert.

(id,#,$) siehe oben

3. Setze den Monitor zurück und verfahre genauso mit dem Regler 3 und einem Panelelement der zweiten Stepreihe. - Erklärung?

Das Macro Datenverarbeitung (eine Art Demux) Filtert Länge und Index aus, lässt nur Events vom 3rd Panel Knob durch und leitet diesen einen Regler-event zu Monitor grün.
Events von einem beliebigen Knob der 2.Panel Reihe senden zu Monitor blau.

korrekt

4.Finde in der Struktur jeweils die jeweiligen Module im partials framework! (mühsam, aber nur so lernt man die library kennen)

Um schnell die Richtigen Module zu finden würde Ich alle Macros in eine große Core Cell packen. So hat man alles direkt im Überblick, nimmt sich das passende Macro raus und kann den Rest dann wieder Löschen.

5.verändere das Beispiel

Hier sollte jeder selbst experimentieren. Das wird auch etwas dauern, da die Library sehr groß ist.

zum Beispiel könnte man mal zwei primary LFOs und einen midi-gate-gesteuerten ADSR über den Bus leiten und wieder entschlüsseln

ciao herw

[macrospank]

Ok, danke fürs Berichtigen. Werde mich nochmal damit auseinander setzen.

Finde es gut das mit der Library ein Standard festgelegt wird. Auch gut das du mich nicht so einfach davonkommen lässt
Sobald ich die nächsten Tage etwas Zeit habe leg ich nochmal ein Beispiel mit den LFO´s nach.

[herw]

Ich sende mal nur für einen allgemeinen Eindruck zwei Screenshots, um zu zeigen, dass trotz eines hervorragenden frameworks der Teufel immer noch im Detail liegt:
Zur Sache: ich möchte mal „ganz simpel” die Daten einer EventTable auslesen und vernünftig in einen Bus packen, eigentlich eine Standardanwendung; aber wenn man es gescheit realisieren will, dann muss man doch schon arg experimentieren.
Mein Ansatz war der, dass ich eine Schleife für den Index nehme und dann einfach die Daten auslesen lasse und in einer CoreCell schließlich zu einem Eventblock zusammenlege.
Hier das Ergebnis nach ca. fünf Stunden erfolglosen Experimentierens:

EventBus-EventTable1.jpg

Grün umrandet sind die erfolgreichen Bestandteile (von links nach rechts): eine For-to-do-Schleife (0..8, d.h. es sollen neun Daten ausgelesen werden), dann die kopierte EventTable und schießlich der Ausgang.
Na toll! also mit anderen Worten: fast nichts ist gelungen (rot umrandet). Zwar bekam ich die Daten ausgelesen; die Krux war aber, wie kombiniert man den Index und die Daten so, dass daraus auch wirklich ein Eventblock entsteht? Ich bekam sie sogar in der passenden Reihenfolge, also erst Index dann Wert und immer abwechselnd. Der Eventblock sollte dann entstehen durch Vorschalten des entsprechenden Kopfes (id, #, or, ...). Das ging gründlich in die Hose. Zwar wurde der Block beim Initialisieren gesendet, doch wenn man den Block durch einen Trigger später nochmals starten wollte, ging gar nichts. Wie sich nachträglich herausstellte, lag es an der Fehlinterpretation des Makros singleshot, das ich in der rechten CoreCell benutzte.
Ich gehe jetzt nicht in dieser Post ins Detail, doch war nach einer Nacht des Darüber-Schlafens dann plötzlich der Kopf wieder klar, um nochmals die Denkweise des frameworks systematisch aufzugreifen.
Das Endprodukt nach zwei Stunden konstruktiver stressfreier Denkarbeit stimmt mich nun sehr zufrieden:

EventBus-EventTable2.jpg

Viel aufgeräumter und es passt nun auch voll in die Machart des framework hinein. Ich habe dabei trotz der vielen nutzlosen Stunden wieder extrem viel gelernt.
Ich werde das Beispiel in den nächsten Tagen mal hier erörtern.

ciao herw

[macrospank]

Hi, wie angekündigt poste ich mal ein Demo mit LFO Multiplexing. Den ADSR Gate habe ich leider noch nicht ganz verstanden. Vielleicht kann jemand so ein ADSR Midi Gate einfach an den freien Ausgang anschliessen und mein Demo erneut hochladen?

Ich habe die Multiplexing Seite von dem Beispiel hier weiter oben im Thread und die Demux Seite selbst erstellt aus der Partials Framework Library.
Soweit ich das verstehe kann {e} und {b} ohne Probleme gemischt werden.
Wofür sind die ID Trigger Events im {b} mux und was ist sonst der Unterschied zwischen {e} und {b} ?

Hoffe das ist soweit richtig?

[herw]

Hi, wie angekündigt poste ich mal ein Demo mit LFO Multiplexing. Den ADSR Gate habe ich leider noch nicht ganz verstanden. Vielleicht kann jemand so ein ADSR Midi Gate einfach an den freien Ausgang anschliessen und mein Demo erneut hochladen?

Ich habe die Multiplexing Seite von dem Beispiel hier weiter oben im Thread und die Demux Seite selbst erstellt aus der Partials Framework Library.
Soweit ich das verstehe kann {e} und {b} ohne Probleme gemischt werden.
Wofür sind die ID Trigger Events im {b} mux und was ist sonst der Unterschied zwischen {e} und {b} ?

Hoffe das ist soweit richtig?

Ja das ist richtig;
das ADSR-Module ist auch eine Eventquelle, so dass man auch sehen kann, dass man ganz unterschiedliche Arten von Events problemlos nebeneinander laufen lassen kann.
Schließe das Midigate-Modul einfach an ein ADSR-Modul und stelle die Parameter auf Werte um 20-40 (sustain auf 0,5.
Zur Überprüfung, dass auch Eingangs- und Ausgangssignal schön synchron laufen, kann man besser Meter anschließen als Lampen (am besten nebeneinander anordnen).
Ja, {e}-bus und {b}-sind vom Aufbau-Prinzip her identisch, nur dass beim {e}-bus die „Blocklänge” 1 schon bekannt ist und dadurch manche Berechnungen sich erübrigen. In der ursprünglichen Version waren diese beiden Arten, wie schon weiter oben erwähnt, getrennt.
Dass ein beliebiges Mischen möglich ist, ist viel konsequenter und praktischer.

ciao herw

[macrospank]

Ok, eigentlich einfacher als ich gedacht habe. Aber ist ja auch erst der Anfang.

Kurz mal OT. Was ich bei dem ADSR nicht verstehe ist das bei Initialisierung bei mir der Wert 4.41079E-09 anstelle von 0 angezeigt wird. Was bedeutet der Wert bzw warum nicht der wert 0 ? Das es nicht am Multiplexing liegt weiss ich.

[herw]

Ok, eigentlich einfacher als ich gedacht habe. Aber ist ja auch erst der Anfang.

Kurz mal OT. Was ich bei dem ADSR nicht verstehe ist das bei Initialisierung bei mir der Wert 4.41079E-09 anstelle von 0 angezeigt wird. Was bedeutet der Wert bzw warum nicht der wert 0 ? Das es nicht am Multiplexing liegt weiss ich.

Ich habe dein Beispiel mal erweitert; das ADSR-Modul endet bei 0 nach Ablauf der Release-Dauer.

ciao herw