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.
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?”
).
