MODULAR X Netzwerk

Hier soll es ausschließlich um Arbeiten zu neuen und alten Ensembles gehen.

Moderator: herw

Antworten
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von herw »

MvKeinen hat geschrieben:Das ist sehr spannend.

Ich hab in meinem system auch die notwendigkeit Koordinaten zu berechnen. Dazu "schreibe" ich die Koordinaten (X&Y) in einen einzigen Wert indem ich Y um 10 bit nach links verschiebe und mit X addiere. Wenn ich nun einen Punkt innerhalb eines Kontainers Berechnen will muss ich nur den geshifteten Wert der linken unteren Ecke des Kontainers mit dem des zu ermittelnden Punktes addieren und habe so 2 additionen gespart. Vielleicht ist das ja interessant für Dich?

Gruss D

edit: aber vielleicht bringt es auch keine Ersparnis, denn wenn ich es richtig verstanden habe sind es bei Dir ja nur die Koordinaten der Patchpunkte die berechnet werden müssen.
interessante Lösung, aber ich muss mehrfach die Koordinaten einer Verbindung neu berechnen, da ich die virtuellen Koordinaten, abhängig von dem Gridraster von REAKTOR, in die realen Koordinaten des Multidisplays umrechnen muss und zudem noch aus jeder virtuellen Verbindung vier reale Strecken berechnen und übergeben muss. Aber ich werde deine Idee im Kopf behalten. Ich muss auch beachten, dass ja mein modular größer sein kann als das größt-mögliche Multidisplay. D.h. ich brauche unbedingt die Einzelwerte, insofern müsste ich ständig eine Maske auf die zusammengesetzten Werte anwenden.
Ich finde es nett, dass auch mal jemand etwas schreibt, damit ich durchhalte. Von deinem Projekt würde ich auch mal wieder etwas mitbekommen, es ist ja wohl auch ein modular aber mit anderem Ansatz.
Aber jetzt muss ich mich um die Audiotables kümmern.

ciao herw
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MODULAR X Netzwerk

Beitrag von MvKeinen »

Bei mir dauert es noch ein wenig bis ich wieder was präsentables habe, weil mein Grundsystem noch erweitert werden muss. Ich hab allerdings gerade kontinuierliche Fortschritte. ::kaffee::
Reaktor Befürworter
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von herw »

Gestern habe ich (wiederholt) über die Organisation der Audiosignalwege nachgedacht.
Mein bisheriger neuer Ansatz ist, Audiotables anstelle von send-receive-Verbindungen zu benutzen.
Send-Receive-Verknüpfungen haben den Nachteil, dass sie in einer ganz bestimmten Reihenfolge in den Modular eingesetzt werden müssen, damit man sie gezielt über den Eventbus ansteuern kann. Leider lassen sich Container mit eingebundenen send-Modulen nicht original kopieren, da sie in anderen Containern in den receive-Modulen mit einer anderen Reihenfolge eingetragen werden. Somit lassen sich die Signalwege nur universell gleich aufrufen (feste Adressen), wenn die Send-Module sich in derselben Strukturebene befinden. Sie müssen also nachträglich eingebaut werden.
Das ist zwar nicht besonders schlimm, jedoch hinderlich, wenn man „mal eben” das Ensemble umgestalten will.
Ziel der Version 3 ist es, nur eine einzige sehr einfache Verbindung zwischen den Containern zu besitzen (eigentlich nur ein einziger Initialisierungsevent), alles andere läuft über Eventtables und Audiotables.
Audiotables haben den Vorteil, dass sie als shared Tables im gesamten Ensemble direkt abrufbar sind und zwar polynom und nur über einen Index gesteuert.
Der große Nachteil gegenüber den send-receive Verbindungen ist, dass sie etwa 0,1% CPU-Last pro Stimme und pro Aufruf erzeugen. Das summiert sich bei einem 8-stimmigen großen Ensemble schnell auf 40%.

Das hat mich natürlich ziemlich geärgert; auch NI sieht diesen Nachteil, der sich wohl nicht so leicht programmtechnisch abstellen lässt.

Aber ich bin zäh und ich glaube, ich habe trotz dieses Stolpersteins wohl einen ungewöhnlichen Weg gefunden, weiterhin mit send-receive-Modulen (ohne CPU-Verbrauch (!) ) arbeiten zu können, ohne dass ich sie nachträglich ins Ensemble einsetzen müsste; alle Container werden ihre send- und receive-Module schon beinhalten, sie werden auch beliebig gelöscht und ausgetauscht werden können, ohne dass man sich neu um die receive-Reihenfolgen kümmern muss.
Es sind noch einige logische und mathematische Hürden zu nehmen, aber ich bin großer Zuversicht, dass es klappen wird. Es wäre für mich natürlich eine Sensation, dass ich REAKTOR 5 „überlisten” kann (das Wort selbst ist ein passendes Wortspiel ;) ).

Drückt mir die Daumen! Die letzten beiden Nachmittage waren sehr aufregend und gedankenintensiv.

ciao herw
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MODULAR X Netzwerk

Beitrag von MvKeinen »

2 fragen:

1. Wie ersetzen denn die Audiotables die Send-recieve verbindungen? "schreibt" jedes Modul seinen Audioausgang in ein Table und dessen inhalt wird dann "geshared" mit den Tables die die Audioeingänge versorgen? Oder ganz anders?

2. kannst Du ungefähr prozentual einschätzen wieviel Zeit der Projektarbeit in die Eventprogrammierung und in die Audioprogrammierung fließt?

Frage 2 interessiert mich, weil ich mir bei meinem Projekt etwas sorgen mache, da dort die Verteilung ca. 95% Event und 5% Audio ist. :roll:
Reaktor Befürworter
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von herw »

MvKeinen hat geschrieben:2 fragen:

1. Wie ersetzen denn die Audiotables die Send-recieve verbindungen? "schreibt" jedes Modul seinen Audioausgang in ein Table und dessen inhalt wird dann "geshared" mit den Tables die die Audioeingänge versorgen? Oder ganz anders?
Die Idee ist relativ einfach: alle sends und alle reveives werden durch eine einzige mehrdimensionale audiotable ersetzt. Jeder send (für mich Audioausgang eines Containers) hat eine eindeutige Adresse, ebenso jeder receive (für mich Audioeingang eines Containers). Alle Verknüpfungen werden über die Adresse des Eingangs mit dem zugeschaltetem Ausgang in einer EventTable gespeichert. Diese Eventtable wiederum wird in einem snapshot array auch längerfristig abgespeichert. In der Version 2 entsprechen diesen virtuellen Verknüpfungen den realen Schaltungen der receive-Module. Dadurch musste die Reihenfolge der send-Module beim Erstellen des Modulars konsequent eingehalten werden; der Adresse entspricht die Einordnung in die receive-Tabellen. Da dann alle receive-Module dieselbe Tabelle besitzen, kann man durch Abruf der gewählten Ausgangsadresse und der Eingangsadresse (aus einem Arbeitsspeicher (shared eventtable)) das zugehörige Receive-Modul zur gewünschten Umschaltung zwingen. Dasselbe gilt für die Audiotables, dort wird lediglich die Koodinate Wx (fürs Schreiben) bzw. die Koordinate Rx (fürs Lesen) gesetzt. Ansonsten ist die Systematik gleich. Alle Audiosignale laufen also über dieselbe mehrdimensionale Audiotabelle, wobei die x-Komponente die Adresse des entsprechenden Audioausgangs angibt.
2. kannst Du ungefähr prozentual einschätzen wieviel Zeit der Projektarbeit in die Eventprogrammierung und in die Audioprogrammierung fließt?

Frage 2 interessiert mich, weil ich mir bei meinem Projekt etwas sorgen mache, da dort die Verteilung ca. 95% Event und 5% Audio ist. :roll:
Diese Einschätzung ist völlig realistisch. Letztlich muss man die Organisation der Adressenzuweisungen über eine Eventlogik durchführen. Das ist durch diverse nötige Initialisierungen und Abfragen sehr logikintensiv. Die Audioanwendungen sind bis auf die Signalwegzuteilungen ja eigentlich bekannt; Oszillatoren, Filter etc. kann man ja den Bibliotheken entnehmen.

Das Aufrufen der Audiotabellen ist wie oben erwähnt nur ein Setzen der Schreib- und Lese-Parameter. Beachten muss man, dass es aber einen Versatz von einem sampletick gibt (keine Gleichzeitigkeit). In der Regel kann man das Verschmerzen, jedoch eventuell nicht, wenn eine Rückkoppelung erfolgen soll. Ein großes Problem der Audiotables ist aber, dass sie einen relativ hohen CPU-Verbrauch haben (siehe Rechnung in früherer Post). Das muss man bei umfangreichen Ensembles auffangen, indem man nur diejenigen Audiotables aktiviert, die auch wirklich gebraucht werden. Bei meinem modular ist dies sehr aufwändig, da ich immer rückverfolgen muss, ob ein Audioausgang auch wirklich über eine Lesekomponente derselben shared Audiotable wirklich abgerufen wird. Man kann eine Audiotable abschalten, indem man an deren Eventausgang Dx ein dummiemodul (z.B numeric readout) mit einem switch hängt. Wenn man weiß, dass der Audiokanal nicht benutzt wird, dann kann man die entsprechende Sende-Audiotable und damit das gesamte vorgeschaltete Makro abschalten. Die Verwaltung der Audioausgänge muss wiederum über eine Eventtable erfolgen, die die Benutzung durch Empfangs-Audiotabellen registriert. Ein ziemlicher Aufwand mit vielen Kleinigkeiten vor allem bei Initialisierungen, aber machbar.

send-receive-Verknüpfungen haben den Vorteil, dass sie keinen CPU-Verbrauch haben und die Benutzung bzw. die Nichtbenutzung eines send-Modules selbstverwaltend ist. Das ist ein unschätzbarer Vorteil. Bisher habe ich dies dadurch erreicht, dass alle send-Module in derselben Strukturebene in der entsprechenden Reihenfolge eingesetzt werden. Leider ist dies etwas abschreckend für Neueinsteiger, obwohl es eigentlich ganz einfach ist.

Jetzt habe ich einen Weg gefunden, dass die sends durch einen kleinen Trick immer die richtigen Zuordnungen finden, obwohl alle receive-Tabellen verschieden aufgebaut sind, da sie sich in völlig verschiedenen Strukturebenen befinden und auch in völlig beliebiger Reihenfolge erstellt werden können; alle Receive-Tabellen stimmen allerdings in einem wichtigen Teil zwangsweise überein; für diese neue Erkenntnis habe ich ca. jetzt zwei Jahre gebraucht, allerdings brauchte es dazu nur einer einzigen „Erleuchtung”; genau nur diesen Tabellenausschnitt benutze ich. Mehr kann ich dazu noch nicht sagen, da die zugehörige Eventlogik noch nicht vollständig erstellt ist, aber es wird nur auf sehr wenige Bruchrechnungen hinauslaufen.
Eine Schwierigkeit, die sich bei aller Universalität ergibt, ist, dass man ja nicht vorher den Umfang einer receive-Tabelle kennt, also wie viele send-Module es geben wird. Modular x bestimmt die Anzahl der Audioausgänge bei der Initialisierung selbständig. Alle receive-Tabellen behalten den range [0..1] bei, aber die Adressen rufen jeweils einen Bruch auf : n/A, wobei A die Gesamtzahl aller Ausgänge ist und n die Adresse des gewählten Ausgangs. Die Receivetabellen erkennen dies beim Umschalten an! Man muss also keinen Eingriff in die Receivetabellen machen.
Also zum Beispiel, hat man drei send-Module, so werden sie normalerweise über 1, 2, und 3 aufgerufen (IC-connection der Properties) mit dem range [0..3]. Man kann dies aber auch mit den Werten 1/3, 2/3 und 3/3 und dem range [0..1] durchführen. Ergänzt man nun noch send-Module, so ändert sich nur der Nenner (Anzahl der Ausgänge insgesamt).

ciao herw

PS: wenn du willst, dann können wir einen gesonderten Thread über send-receive-Verknüpfungen und shared audiotables eröffnen:
Thema: „wie verteilt man Audiosignale mit globalem Zugriff?”
MvKeinen
meister
Beiträge: 168
Registriert: 10. August 2006, 14:06
Wohnort: Berlin

Re: MODULAR X Netzwerk

Beitrag von MvKeinen »

erstmal danke für die Antwort
herw hat geschrieben: PS: wenn du willst, dann können wir einen gesonderten Thread über send-receive-Verknüpfungen und shared audiotables eröffnen:
Thema: „wie verteilt man Audiosignale mit globalem Zugriff?”
Das wär natürlich sehr erfreulich. Wenn Du mal die Lust und Zeit dazu fändest wäre ich sehr interessiert. Allerdings freue ich mich natürlich auch wenn Du so viel Du kannst an Deinem Modular arbeitest. ::kaffee::
Mit einem Thread und einem kleinen Ensemble könnte ich Deine Erklärung oben natürlich viel einfacher folgen.

gruss
Reaktor Befürworter
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: MODULAR X Netzwerk

Beitrag von herw »

ein ganz einfaches Beispiel: Audio-Signalwege
::kaffee::
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Audiobus

Beitrag von herw »

herw hat geschrieben:[...]
Jetzt habe ich einen Weg gefunden, dass die sends durch einen kleinen Trick immer die richtigen Zuordnungen finden, obwohl alle receive-Tabellen verschieden aufgebaut sind, da sie sich in völlig verschiedenen Strukturebenen befinden und auch in völlig beliebiger Reihenfolge erstellt werden können; alle Receive-Tabellen stimmen allerdings in einem wichtigen Teil zwangsweise überein; für diese neue Erkenntnis habe ich ca. jetzt zwei Jahre gebraucht, allerdings brauchte es dazu nur einer einzigen „Erleuchtung”; genau nur diesen Tabellenausschnitt benutze ich. Mehr kann ich dazu noch nicht sagen, da die zugehörige Eventlogik noch nicht vollständig erstellt ist, aber es wird nur auf sehr wenige Bruchrechnungen hinauslaufen.
Eine Schwierigkeit, die sich bei aller Universalität ergibt, ist, dass man ja nicht vorher den Umfang einer receive-Tabelle kennt, also wie viele send-Module es geben wird. Modular x bestimmt die Anzahl der Audioausgänge bei der Initialisierung selbständig. Alle receive-Tabellen behalten den range [0..1] bei, aber die Adressen rufen jeweils einen Bruch auf : n/A, wobei A die Gesamtzahl aller Ausgänge ist und n die Adresse des gewählten Ausgangs. Die Receivetabellen erkennen dies beim Umschalten an! Man muss also keinen Eingriff in die Receivetabellen machen.
Also zum Beispiel, hat man drei send-Module, so werden sie normalerweise über 1, 2, und 3 aufgerufen (IC-connection der Properties) mit dem range [0..3]. Man kann dies aber auch mit den Werten 1/3, 2/3 und 3/3 und dem range [0..1] durchführen. Ergänzt man nun noch send-Module, so ändert sich nur der Nenner (Anzahl der Ausgänge insgesamt).
[...]
Es ist sehr anstrengend, die Gedanken und Ideen zu sortieren: zu groß ist die neue Erkenntnis und zu klein die noch nicht vollständig vorhandenen Erfahrungen. Ich formuliere zunächst mal die Hauptidee und kann dann hoffentlich nach und nach an die Realisation gehen. Die Umleitung von send-receive-Verbindungen auf eine fixe Liste ist so neu, dass ich die Systematik erstmal in den Griff bekommen muss.
Die wirklich neue Idee ist die Emulation eines Audio-Busses. Die AudioTables schienen durch die Indizierung eine ideale Kombination, da der Index durch die Nummerierung der virtuellen Verbindungen ohnehin schon festgelegt ist. Doch der CPU-Verbrauch hat mich schon mächtig gefuchst. Die send-receive-Verbindungen sind mir schon seit 2004 die liebste Art der Verknüpfung. Leider hat es NI bisher nicht geschafft, hier eine vernünftige Lösung des Adressierungsproblems zu liefern. Daher musste jetzt diese kleine „Krücke” her.
Jeder reale Audioausgang bekommt nun zwei send-Module; das erste sendet lediglich einen Event-Trigger. Das zweite liefert das eigentliche Audiosignal. Der Trick besteht darin, dass ich beim Einfügen eines Containers mit send-Modulen erzwingen kann, dass die neuen Adressen in allen existierenden und zukünftigen Receive-Modulen in einen Bereich ergänzt werden, der nicht (!) benutzt wird. Die Audiosignale werden vielmehr in einem vorbereiteten Makro auf andere send-receive verbogen, deren Adressen im guten geordneten Bereich der receive-Tabellen liegen.

Dieser normalerweise ärgerliche Umstand, dass receive-Tabellen unterschiedlich sind, je nachdem, wo diese in die Struktur eingebaut werden, kann hier vorteilhaft umgangen werden. Die größte Hemmung bestand in der Überlegung, dass die virtuellen und die realen Adressen der Audioausgänge nicht übereinstimmen müssen.

ciao herw
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Audiobus

Beitrag von herw »

sehr schwer und gedanklich anstrengend, da ich viele Baustellen gleichzeitig im Kopf haben muss :shock:

So langsam beginne ich zu sortieren. Es gibt immer wieder unvorhergesehene Haltepunkte, an denen ich experimentieren muss.
Ich versuche sehr systematisch das ganze aufzubauen.
Startpunkt war erst mal die aktuelle Zahl der eingefügten Audioausgänge zu ermittteln: das ging relativ leicht, da jeder Container für sich ohnehin die Anzahl jeweils aktualisiert. Insofern brauchte ich nur ein Makro ans Ende der Containerkette einzufügen und die Gesamtzahl abzufragen:
read O#.jpg
Das Audio-System basiert auf einem Bussystem mit send-receive-Verbindungen. Da das nachträgliche Einfügen, Löschen und wieder Neueinfügen von Containern mit send-Modulen zu einem Chaos in der Reihenfolge der receive-Verbindungen führt, muss eine eigene hiervon unabhängige Adressierung erfolgen.
Folgende Forderungen müssen erfüllt werden: Alle Ausgänge müssen selbsterzeugende Adressen besitzen, die genau angeben, welcher Audioausgang momentan gewählt ist. Alle receive-Module müssen diese Audioquelle unter derselben Adresse aufrufen können.
Die Idee basiert auf der Eigenart von REAKTOR (Version 5.8.0), dass alle anzuwählenden send-Module in derselben Strukturebene liegen müssen, damit sie von allen receive-Modulen in gleicher Art und Weise aufgerufen werden können. Beim direkten Einbau in Container ist dies von vorneherein nicht gegeben.
Aber es gibt einen Ausweg:
Man definiert in einem globalem Makro, vorgegebene fixe receive-send Verknüpfungen, zum Beispiel 512 an der Zahl.
Werden nun in Containern oder sonst wo receive Module ergänzt, so sind diese sends immer unter den 512 ersten Adressen zu finden. Nur mit diesen 512 Adressen werden die Verknüpfungen erstellt; alle anderen (verschiedenen) Adressen der receive-Listen werden nicht beachtet. Alle durch Container nachträglich ergänzten send-Module haben höhere Adressen.
Nun werden durch die Container die eigentlichen Audioquellen eingefügt und zwar zwei send-Module pro Audioquelle. Dadurch, dass sie in den Containern immer paarweise auftreten (oder gelöscht) werden, belegen sie immer zwei aufeinanderfolgende Adressen in den receive-Modulen. Das folgende Bild zeigt das Prinzip:
send 1.jpg
Das erste send-Modul sendet nur einen Event-trigger. Im vorbereiteten globalen Makro wird dieser Event in eine Adresse der fixen Verbindungen umgewandelt und in einer shared event-Tabelle gespeichert.
Das zweite send-Modul überträgt das eigentliche Audiosignal an die nächstfolgende fixe Verbindung. Es muss sich hierbei unbedingt um ein Audiosignal handeln, eventuelle event-Signale etwa von einem LFO- oder ADSR-Modul können ressourcensparend durch ein unit-delay in ein audioSignal umgewandelt werden.
send 2.jpg
Ein beliebiges aktiviertes receive-Modul greift aus der shared event-Tabelle die neue Adresse auf und kann so aus der receive-Liste korrekt auswählen.
Da ja die absolute Zahl aller send-Module nicht fest ist (durch diveres Einfügen, Löschen und Wieder-Einfügen, werden die Adressen auf den Bereich [0..1] genormt. Dazu muss die Zahl der virtuellen Ausgänge abgefragt werden. Auch hier hilft eine shared Event-Tabelle.

Die wichtigste Erkenntnis beim Aufbau des Audiobusses ist, dass es zwei Arten der send-receive-Verbindungen geben muss: die reinen Event-und die Audiosignalwege. Auf der (globalen) Empfängerseite werden beide Arten von receivern empfangen. Warum nun die strikte Trennung von Event- únd Audiosignalen? Die receive-Module haben eine interessante Eigenschaft: sind sie an event-Eingänge angeschlossen, so ignorieren sie alle Audiosignale. Das heißt, ich kann die event-Adressen automatisch herausfiltern. Andererseits lassen sich die Audiosignale ebenfalls herausfiltern über die receive-Nummer: sie ist immer gerade.
::kaffee::
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Audiobus - ein Testprogramm (Teil 1)

Beitrag von herw »

Ich entwickle ein Testprogramm um für mich und alle interessierten Leser, um Klarheit zu schaffen. Hier werden auch viele Kleinigkeiten erwähnt werden, die man beim Gebrauch von send-receive-Verknüpfungen beachten muss. Nicht alles wird sofort klar sein, ich hoffe aber, dass durch sukzessiven Aufbau auch der Nichteingeweihte die Idee verstehen kann. Ich zitiere dazu einfach aus meinem Projektbuch:

Da ein vollständiger Audiobus sehr unübersichtlich wird, soll zunächst ein kleines Test-Ensemble erstellt werden.
Maximal acht Audioquellen sollen möglich sein. Als Testcontainer fungieren ein Sinus- und ein Dreiecksoszillator, ein LFO und ein Midi-Modul. Die Anzahl der Quellen sollen selbst bestimmt werden. Wie beim geplanten Ensemble sollen wichtige Daten in den Eventtable T-DATA 3 und T-DATA 4 gespeichert werden.
Jeder präparierte Signalweg besteht aus zwei receive-, zwei IC-send-Modulen und einem Send-Modul.
Leider kann man eine solche Einheit nicht komplett kopieren und einfügen. REAKTOR friert ab dem achten Signalweg ein (ein Bug aus früheren Zeiten).
Daher müssen, vor allem bei sehr vielen Signalwegen, zunächst alle sends, dann die IC-sends eingefügt werden und zum Schluss alle receive-Module.
Bild 1.jpg
Tests haben ergeben, dass durchaus alle 512 solcher Signalwege in einem Makro akzeptiert werden. Probeweise habe ich auch mal über 3000 send-Module eingefügt. REAKTOR bewältigt auch dies. Die Compilierung dauert aber einige Zeit ca. 1 Minute, da offenbar die receive-Tabellen entsprechend aufgebaut werden müssen. Die Menge stellt also prinzipiell kein Hindernis dar.
Alle receive-Module sind auf „enable switch off” geschaltet (beim Kopieren vorher aktivieren!).
Bild 2.jpg
Wie schon oben erwähnt, werden die eigentlichen Audioquellen mit ihren beiden sends nun in ihrer Einfügereihenfolge unten angehängt.
Dies darf aber erst geschehen, wenn das Audiobus-Makro vollständig aufgebaut ist, inbesondere müssen die linken receive-Module mit den rechten IC-send verbunden sein, damit klar ist, dass sie nur event-Signale empfangen können. Würde man nur ein (audio-) send erstellen, dann schalten alle receive-Ausgänge auf audio-Signal um (schwarzer Ausgang). Es können dann auch keine Event-receive-Module mehr neu erzeugt werden.
Bild 3.jpg
Es müssen also vorher die event-Verbindungen zwischen den linken receive und den rechten IC-send-Modulen erstellt werden; zur Veranschaulichung habe ich mal hier eine direkte Verbindung gezogen, um event-receives zu erzwingen:
Bild 4.jpg
[/i]
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Audiobus - ein Testprogramm (Teil 2)

Beitrag von herw »

Fügt man nun eine Audioquelle mit seinem Adress-Signal hinzu (hier durch eine Konstante repräsentiert),
Bild 5.jpg
dann akzeptieren die event-receive auch nur event-Signalwege: man sieht sehr schön, wie die beiden neuen sends (#9) und (#10) in der Liste angehängt wurden.
Bild 6.jpg
In den Properties erkennt man, dass nur der event-Signalweg akzeptiert wird. Noch deutlicher wird dies, wenn man im Panel oder in den Properties sich das Pulldownmenu dazu anschaut.
Bild 7.jpg
Hier tauchen die nicht akzeptierten Audio-Signalwege gar nicht erst auf. Dies ist wichtig zu wissen, da man später beim Aufruf des Patches für diese Module eine kürzere Liste hat.
Die Audio-receive-Module hingegen akzeptieren alle Signalwege. Mit jedem eingefügten Send-Paar verlängert sich deren Liste um zwei.
Bild 8.jpg
Man findet nun die event-Signalwege auf den folgenden ungeraden Nummern (#9), (#11), (#13) usw. und die Audio-Signalwege auf den geraden Nummern (#10), (#12), (#14) usw..
An dem Pulldown-Menu sieht man auch sehr schön, dass die receive-Liste von unten nach oben sortiert ist. Ruft man nun über ein IC-send einen Kanal auf, so wird von unten nach oben nummeriert:
Off entspricht der Nummer 0, send (#10) der 1,... send (#7) der 4 und schließlich send (#1) der 10.
[/i]
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Audiobus - ein Testprogramm (Teil 3)

Beitrag von herw »

so schön die Idee der teilweise ausgeschalteten Receive-Zustände auch ist; sie hat einen Haken: es gibt ja auch normale event-sends der Container z.B. midi-Ausgänge, ADSR, LFO etc.. Die würden mir meine Nummerierung völlig durcheinander wirbeln.
Also dann lasse ich doch lieber alle möglichen send-Adressen zu. Allerdings muss ich dann die Adress-sends der Ausgänge für einen kleinen Moment durch ein AtoE-Modul zu künstlichen audio-Eingangen umdefinieren (wie auch schon bei event-Modulationseingängen). Das hat den Vorteil, dass nun wirklich alle receive-Modul auf dieselbe Anzahl an sends zugreifen. Durch ein dup-flt-makto wird der event-Strom wieder in einzelne events zurück verwandelt. Da die entsprechenden event trigger gate-trigger sind, brauche ich mir auch keine Sorgen zu machen, dass ein solcher verloren geht.
Ich baue gerade meinen ersten Primitivsynth mit diesem Prinzip zusammen. Ich denke es dauert nur noch wenige Stunden (!) Entwicklungszeit. Wenn das funktioniert, dann ist mein Traum wahr geworden. :D

::kaffee::

herw
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Audiobus - ein Testprogramm (Teil 3)

Beitrag von herw »

::ole:: ::der Unaussprechliche:: ::halleluja:: ::pianoplayer:: ::!!:: ::nikolaus:: ::key::


ja ja ja ja ja ja - es klappt !!!!!!!!


::ole:: ::der Unaussprechliche:: ::halleluja:: ::pianoplayer:: ::!!:: ::nikolaus:: ::key::

PS: es gibt allerdings noch einen Wermutstropfen zu beseitigen: plug&play läuft perfekt, aber REAKTOR compiliert noch zu lange. Da werde ich nochmal NI wecken müssen.
PSPS: hab schon eine Lösung gefunden!
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Audiobus - ein Testprogramm (Teil 4)

Beitrag von herw »

Die IC-Send-Module setzen jeweils die folgenden Receive-Module auf eine feste Adresse. Auf der linken Seite werden die receive-Module jeweils auf die Adress-Einträge der receive-Liste gesetzt.
Bild12.jpg
In der Nummerierung (!) der Sends sind diese ungerade und zwar im Bereich, der über dem letzten geordneten Send liegt; wegen der bottom-top-Anordnung werden diese allerdings mit geraden Adressen der Receives aufgerufen. Das ist eine sehr verwirende Eigenart von REAKTOR, die allen Listen „anhaftet" (receive-, switch- und list-Listen).
D.h. wenn zum Beispiel acht geordnete Signalwege verfügbar sind und zum Beispiel sieben Container-Ausgänge hinzugefügt wurden, dann sieht die Belegung folgendermaßen aus:
Bild13.jpg
Beim Aktivieren eines Ausgangs wird ein trigger gesendet und zwar auf den ungeraden sends, die größer als acht sind (#9, #11, #13, #15, ..., #21). Die Receive-Module rufen diese über die geraden (!) normierten Adressen 2/22, 4/22, 6/22, ..., 14/22 auf, wobei 22 die Gesamtzahl aller send-Module ist und 14=22-8 die Anzahl der Container-sends.
Bild14.jpg
Hier wurde der Container lfo bewusst als letzter eingesetzt. Die Position im Ensemble ist aber der vierte Platz. D.h. für ein Aufgreifen des lfo-Ausgangs ist seine Position im Panel völlig unerheblich.
Bild15.jpg
[/i]
Vielleicht wundert sich ein aufmerksamer Leser darüber, dass die Adressen, die die IC-Sends an die receive-Listen senden, Bruchzahlen sind. Nun, das ist ein kleiner Trick. Die IC-Sends können unterschiedliche Intervalle annehmen. Entscheidend ist, dass sie eine regelmäßige Einteilung haben. Normalerweise würde jeder denken, man hat 8+2·7=22 send-Module, also auch 22+1=23 mögliche Anwahlen auf der receive-Liste (Zustand off gehört auch dazu).
Wenn ich den range der IC-sends auf [0...1] belasse, dann akzeptiert dies das receive-Modul ebenfalls. Dies liegt wohl an der internen Behandlung der IC-send-Liste. D.h. die interne Liste hat aufeinanderfolgende Einträge, die wohl eine integer-Zahl senden. Durch den range des IC-sends wird allerdings die IC-send-Liste durch eine gleichmäßige Unterteilung gesteuert. Das hat nun ungeheuere Vorteile: lässt man den range-Berecih unangetastet, und wird die Anzahl der Signalquellen verändert, so ändert sich an dem Aufruf des Listenelements lediglich der Nenner (Anzahl aller send-Module). D.h. ich muss den range niemels mehr anpassen, sondern lediglich für jedes modular-ensemble die Anzahl der send-Module überwachen. Das ist aber überhaupt kein Problem, da diese ohnehin für die Panelgrafik ermittelt wurde!
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Container-Umbau (Teil 1)

Beitrag von herw »

Nun geht's an den ersten Container. Ich habe mir dazu den MIDI-Container ausgesucht, da er nur Ausgänge besitzt und somit der Audiobus sich relativ einfach testen lässt.
Ich muss zunächst dafür sorgen, dass jeder Panel-Ausgang einen gate-Event sendet. Da sich die Ausgänge im interface befinden, leite ich aus der ohnehin an die Grafik gesendete Nachricht eine neue Nachricht für den Audiobus ab: Beispielsweise lautet eine Grafik-Nachricht (5, 3, 0, 9, 12).
Bild 1.jpg
5 ist der Bus-Identifier, 3 die Anzahl der events, 0 die Ausgangsnummer (diese werden bei vier Ausgängen von 0 bis -3 durchnummeriert) und 9 und 12 sind die Koordinaten auf dem Panel. Ich benötige aber für den Audiobus nur eine Nummer und zwei events für ein Gate (1, 0).
Bild 2.jpg
Ich benutze einfach die drei letzten Events und bilde durch latch-Module eine entsprechende neue Nachricht der Form (id, 1, 0). Die ist eigentlich formal eine Nachricht der Länge 1. Das ist zwar redundant, Max Zagler hat aber sich dafür entschieden, damit man nicht einen ganzen Satz an Modulen für diese Art Nachricht extra aufstellen muss.
Auf der Empfängerseite interpretiere ich die Nachricht als gate-Event.
Bild 3.jpg
Das neue Makro outs enthält nun die send-Paare für die vier Ausgänge. Im Gegensatz zur Version 2 des modular frameworks ist dieses Makro nun Bestandteil des Containers und damit vorgegeben. Der Nutzer muss sich darum nicht mehr kümmern.
Der veränderte Container sieht nun aufgeräumt aus:
Bild 4.jpg
- fertig :)

PS : es geht noch einfacher: ich kann die Umwandlung in einen nummerierten Gate auch direkt im Makro outs durchführen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Antworten