PARTIALS FRAMEWORK (multiplexing)
Moderator: herw
-
- user
- Beiträge: 27
- Registriert: 27. März 2011, 12:42
PARTIALS FRAMEWORK (multiplexing)
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 ?
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
- moderator
- Beiträge: 3122
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
dezentral-zentral
eine Textstelle, die in der Tat schwer verständlich ist: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 ?
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: 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. Einfacher wäre es, ein zentrales multiplexing zu verwenden, das bei jeder Aktion immer ein Daten-Tripel (mx, my, mb)
sendet. 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: Der Block wird durch einen SingleShot erzeugt:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- neu
- Beiträge: 2
- Registriert: 24. Januar 2011, 16:34
- Wohnort: Berlin
Re: dezentral-zentral
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 hat geschrieben: 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.
- herw
- moderator
- Beiträge: 3122
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: dezentral-zentral
Hi Max,
Danke für die Richtigstellung!
Ja - aber![Wink ;)](./images/smilies/icon_wink.gif)
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!
Danke für die Richtigstellung!
Ja - aber
![Wink ;)](./images/smilies/icon_wink.gif)
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!
-
- user
- Beiträge: 27
- Registriert: 27. März 2011, 12:42
Re: PARTIALS FRAMEWORK (multiplexing)
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.
Damit wurden auch einige Fragen für mich beantwortet die ich noch garnicht gestellt habe. Wie machst du das nur immer herw?
![Very Happy :D](./images/smilies/icon_biggrin.gif)
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
- moderator
- Beiträge: 3122
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: PARTIALS FRAMEWORK (multiplexing)
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.macrospank hat geschrieben:[...]
Damit wurden auch einige Fragen für mich beantwortet die ich noch garnicht gestellt habe. Wie machst du das nur immer herw?![]()
[...]
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
- moderator
- Beiträge: 3122
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Beispiel 1: einfacher Eventbus
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: 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). 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). 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:
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: 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). 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). 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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- user
- Beiträge: 27
- Registriert: 27. März 2011, 12:42
Re: PARTIALS FRAMEWORK (multiplexing)
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.
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
- moderator
- Beiträge: 3122
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: PARTIALS FRAMEWORK (multiplexing)
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.macrospank hat geschrieben: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 .
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.
(id,#,$) siehe obenNach 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.
korrekt
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.
zum Beispiel könnte man mal zwei primary LFOs und einen midi-gate-gesteuerten ADSR über den Bus leiten und wieder entschlüsseln
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.
ciao herw
-
- user
- Beiträge: 27
- Registriert: 27. März 2011, 12:42
Re: PARTIALS FRAMEWORK (multiplexing)
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![Smile :)](./images/smilies/icon_smile.gif)
Sobald ich die nächsten Tage etwas Zeit habe leg ich nochmal ein Beispiel mit den LFO´s nach.
Finde es gut das mit der Library ein Standard festgelegt wird. Auch gut das du mich nicht so einfach davonkommen lässt
![Smile :)](./images/smilies/icon_smile.gif)
Sobald ich die nächsten Tage etwas Zeit habe leg ich nochmal ein Beispiel mit den LFO´s nach.
- herw
- moderator
- Beiträge: 3122
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Eventbus und Eventtable
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: 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: 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
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: 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: 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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- user
- Beiträge: 27
- Registriert: 27. März 2011, 12:42
Re: PARTIALS FRAMEWORK (multiplexing)
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?
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?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
- herw
- moderator
- Beiträge: 3122
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: PARTIALS FRAMEWORK (multiplexing)
Ja das ist richtig;macrospank hat geschrieben: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?
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
-
- user
- Beiträge: 27
- Registriert: 27. März 2011, 12:42
OT: ADSR
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.
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
- moderator
- Beiträge: 3122
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: OT: ADSR
Ich habe dein Beispiel mal erweitert; das ADSR-Modul endet bei 0 nach Ablauf der Release-Dauer.macrospank hat geschrieben: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.
ciao herw
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.