macrospank hat geschrieben: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