MODULAR X Netzwerk

[herw]

Etwas mühevoll ist die Erforschung des Compilers. Ich habe nämlich festgestellt, dass er große Schwierigkeit hat neue send-Module in die receive-Liste einzutragen. Dabei geht es ja hier nicht um einige wenige interne Verbindungen, sondern um mehrere hundert, sogar bis zu 1536! Ich benötige diese vielen Verbindungen, um den Audiobus aufzubauen. Dabei kann es abwegig lange Compilerzeiten geben.

Ich habe festgestellt, dass es für den Compiler viele einfacher ist, wenn zuerst alle send-Module eingebaut werden und dann erst die receives ergänzt werden.
Dies zeigt sich leider auch, wenn ich Container einfüge. Hier braucht der Compiler endlos lange, um seine receive-Module aufzubauen. Das ist völlig inakzeptabel.
Es gibt aber einen Trick: Alle Container werden zunächst ohne receive-Module geladen. Die sends des Containers werden zügig in den receive-Listen ergänzt (ca. 3 Sekunden).
Nun müssen allerdings die Container ja selbst receive-Module als Eingänge erhalten. Würde man bei einem Audiobus mit bis zu 512 Verbindungen nur ein receive-Module hinzuladen, dann braucht der Compiler dafür schier endlos.
Ich habe aber zusätzlich ein Makro erstellt, das solche receive schon im vorbereiteten Ensemble anbieten. Kopiere ich nun die benötigten receive-Module und füge sie in den Container ein, dann geht alles ganz schnell. Offenbar erkennt der Compiler, dass er diesen Part schon übersetzt hat.

Also wird das Plug&Play folgendermaßen ablaufen:
- Einfügen eines Containers
- Kopieren und Ergänzen eines receive-Makros

Klar wäre es schöner, wenn der zweite Schritt unnötig wäre, aber offenbar muss man bei einem so umfangreichen System Rücksicht auf die Möglichkeiten des Compilers nehmen. Ich werde diesen „bug” mal an NI melden.

ciao herw

[herw]

Gerade die Notwendigkeit, dass ich wegen dieser compiler-Eigenart ohnehin nachträglich die receive-Module einbauen muss, bringt mich auf die Idee, dass man die Umleitung der Audiosignale dann auch nicht benötigt, da durch das Kopieren der receive-Module diese ohnehin alle denselben Aufbau haben.
Wenn der Compiler eine Liste führen würde, die alle receive-Module aufrufen würden, dann dieser ungemein entlastet. Werde ich gleich mal an NI melden.
D.h. ich kann mir alle vorbereiteten send-receive-Verknüpfungen sparen. Lediglich die Adressleitungen müssen vorbereitet sein, damit der aktivierte send-Ausgang erkannt werden kann.

Das spart nochmals viel Arbeit und schafft für mich viel Klarheit.

[herw]

ja das klappt perfekt - wieder eine große Vereinfachung. Es werden jetzt im audiobus-Makro lediglich die Adressen des aktivierten Audio-Ausgangs verwaltet. Das war eine einfache Bruchrechenaufgabe!

Bild.jpg

Im Bild sieht man nur die entsprechende Core-Cell für acht Audiosignalwege, aber einer Erweiterung steht nichts im Weg.
Wenn man das mit dem Bild zu einer früheren Post vergleicht, so ist dies wesentlich einfacher. Insbesondere brauche ich keine zusätzlich vordefinierten send-receive-Verknüpfungen.

[herw]

Manchmal gibt es unangenehme Überraschungen:

zum Beispiel habe ich den Bus auf 32-Signalwege erweitert (mit dem Ziel auf 512 zu kommen).

merge.jpg

Zum Beispiel wusste ich nicht, dass in core merge-Module auf sechzehn Eingänge beschränkt sind. Gut dachte ich, dann packst du eben 2 merge-Module in eine Corecell und verbindest diese mit einem zweifach-merge. Doch so einfach man denkt, REAKTOR ist manchmal störrisch: kaum hatte ich mehr als sechzehn Eingänge verbunden, schlief der Compiler ein (der scheint in Extremfällen zu mucken).
Letztlich war die Lösung aber einfach: ein Init-Filter, der den Initialisierungsevent abblockt, brachte dann die Lösung. Die Ursache lag aber wohl nicht bei den merge-Modulen, sondern ich vermute es im Konstrukt der send-receive_Module - keine Ahnung. Aber was soll's; manchmal hilft einfach trial-und-error.

Es geht gut voran! Ich kontrolliere immer sofort, ob das alte System noch funktioniert und taste mich so langsam an die Endversion.

[herw]

Gerade habe ich die Erweiterung auf den 512-er Bus fertiggestellt, da läuft REAKTOR nicht korrekt.
Die Ursache sind die große Anzahl an z.B.„ A to E”-Modulen, also primary-Modulen mit Eventausgängen (wie zum Beispiel auch LFOs etc.). Deren Gesamtznzahl (!) ist auf insgesamt maximal 200 beschränkt (Reaktor R5.8.0). Früher gab es dazu eine Warnmeldung. Jetzt gaukelt einem das Ensemble vor, dass alles gut läuft. Aber die „überzähligen” Module geben einfach ihren Geist auf und schicken gar nichts mehr heraus.

limitation 200.jpg

Ich habe zu Testzwecken den Bus zunächst auf 128 beschränkt (ich verbrauche dort dann schon 128 A2E-Module). Laut NI ist diese Einschränkung beseitigt. Also warten wir auf das nächste Minor-Update. Bis R6 sind ja noch 199 Minor-Updates möglich (R5.99).

Ansonsten funktioniert plug&play hervorragend. Der Audiobus verbrät gerade einmal 0,7% CPU-Belastung, also viel besser als die Idee mit den Audio-Tabellen.

ciao herw

[herw]

nun die Audio-Eingänge; das war sehr viel Denkarbeit. Im Testaufbau war ja anstelle eines Paneleingangs nur ein Button zu bedienen. Im modular muss ich die Information aus einer Eventnachricht des Interfaces herausfiltern; nach einigen Stunden steht auch dies:

containerumbau.jpg

Hier am Beispiel des ADSR-Containers erkennt man die Änderungen. Das interface liefert im Gegensatz zur Version 2 nun Informationen, welcher Ausgang bzw. Eingang aktiviert wurde.
Dies ist auch die Version, mit der die Container abgespeichert werden. Der Nutzer hat beim Einfügen in ein Ensemble lediglich das Makro change! gegen ein vorbereitetes globales receive-Makro zu ersetzen. Das ist leider der Kompromiss, den ich eingehen musste, da NI es bis jetzt nicht schafft, ein gescheites Send-Receives-Management zu erstellen. Das wird noch eine riesige Baustelle werden.

Als nächstes werde ich das Audiobus-Makro ergänzen und dann kann ich daran gehen, nach und nach alle Container in die Version 3 umzuwandeln. Dies betrifft nur das Interface (zwei zusätzliche Ausgänge) und die neuen Makros für ins und outs. Die Applikation bleibt unberührt. Somit halten sich die Änderungen sehr in Grenzen.

Der Traum wird wahr.

[herw]

Der Audiobus ist für 512 Audiowege fertig gestellt. Ich benötige die vielen A to E - Module nicht mehr, da ich die Übertragung der Adressen auf Eventsignale beschränken konnte. Der Trick ist der, dass ich alle Signalequellen als Audiosignale übermittele, die Adressen als Events. Die Receive-Module, die an Eventeingänge angeschlossen sind, verweigern den Zugriff auf die Audiosignale; damit filtere ich automatisch Adressen und Audiosignale. Einzige Schwierigkeit war die, wenn ich als Signalquellen Events benutze (Triggersignale, LFOs, Midisignale); diese musste ich künstlich in Audiosignale umwandeln, damit sie von den Adress-receives ignoriert werden. Mit einem Dup-Filter kann ich sie wieder am Audioeingang reduzieren. Zu beachten sind eventuelle Event-Wert-Wiederholungen; das habe ich durch eine kleine Variation (Addition von 0,000001 bei jedem zweiten Wert) verhindert.

Variation.jpg

Ein Dupfilter oder ein Stepfilter erkennt diesen sehr kleinen Unterschied; wenn es darauf ankommt, kann ich diese Variation durch ein quantize-Modul mit Step 0,001 (oder kleiner) egalisieren.

Egalisierung.jpg

Beschränkungen fördern Fantasie und Produktivität!

[herw]

Ich weiß nicht wie viele Kaffeetassen mich die letzte Aktion gekostet hat.
Ich habe das neue Konzept für die Darstellung der Kabel auf dem Bildschirm und, was viel wichtiger war, auch das Audiobus-System vereint.
Es ist ein großer Unterschied, ob man solche Systeme einzeln ausprobiert oder im Zusammenhang.
Obwohl alles so logisch erscheint, ist die Praxis dann doch nicht perfekt.
Nun ich habe es trotzdem geschafft. Ein großes Hilfsmittel war mir dabe der AudioCoreEventWatcher von Mark Wadewitz. Hiermit konnte ich Schritt für Schritt genau nachvollziehen, welche Auswirkungen jeder Ausgangs- und Eingangsbutton hat.
Als große Krücke erwies sich im Rückblick die Initialisierung der Event-Tables. Diese habe ich bei der erstmaligen Erstellung in das Initialisierungsmakro des gesamten Ensembles gesteckt. Meistens wurde ein bestimmter Parameter auf 0 gesetzt.
Beim Gebrauch des Audiobusses werden aber die Signalverbindungen über receive-Module neu geschaltet, d.h. wiederum es gibt einen GER (globaler event reset) für die Initialisierung der Eventtabellen. Das war schwer zu finden; manchmal wurden Kabelverbindungen auf dem Bildschirm nicht gezogen, oder nur nach doppeltem Anklicken, mal wurde gewählte Signalausgänge auf OFF geschaltet usw..
Meine Beobachtungsumgebung sah meistens so aus:

Beobachtung 1.jpg

Mein erster Blick galt rechts immer dem Panel (hellblauer Rahmen). War die Kabelverbindung richtig gezogen, richtige Farbe, richtige Transparenz, Start und Endpunkte korrekt? Manche Informationen wurden durch das Anklicken der Ein- und Ausgangsbutton direkt verwertet. Da die Buttons nicht nur ON/OFF-Information ausgeben, sondern auch Koordinaten wurde diese mit einer Nachricht versendet. Splittet man diese Nachricht in der Struktur einfach auf, dann wird jede Teilinformation jeweils abwechselnd an die Ziele weitergegeben. Wenn dann zwischendurch ein Umschalten der receive-Module passiert, kommt es zu einer Initialisierung (s.o.). D.h. ich musste ein Order-Modul für den eventbus benutzen:

messageorder.jpg

Nun werden zunächst alle Daten an die zugehörige event-Tabelle geschickt und erst dann die Informationen an den audiobus weitergegeben.
Nachdem die Kabel auf dem Bilschirm richtig angezeigt wurden, gab es Chaos bei den receive-Verbindungen: gleich mehrere Unachtsamkeiten traten auf:
Zunächst mal hatte ich vergessen (!) dass ich ja zwischen event-Signalen und Audiosignalen beim Senden über send-receive unterscheiden muss. Natürlich hatte ich das beim MIDI-Container wieder vergessen. Ok, gefunden. Dann stimmten plötzlich die Zuordnungen der gewählten Ausgänge im MIDI-Container nicht: achja ich nummeriere ja von unten nach oben; also wieder mussten die sends umgeordnet werden.
Dann Kontrolle, ob das System eine neue Kabelverbindung registriert (roter Rahmen rechts unten). Dort wird eine Eventtabelle ständig mit Panel-Rate abgefragt. OK nachdem die Initialisierungen (s.o.) beseitigt waren, klappte dies.

Beobachtung 2.jpg

Dann der bange Blick auf den gewählten Eingang und das zugehörige receive-Modul (gelbe Rahmen): wird das Modul umgestellt und wird ein geradzahliger Eingang gewählt. Ja - Erleichterung.
Dann noch die letzte Frage: wie steht es mit einer nachträglichen Ergänzung eines Contaienrs: also zunächst eine Kopie des Containers erstellen, zugehörige receive-Module löschen und wieder in das Ensemble einfügen: werden die neuen send-Ausgänge richtig unten angefügt (send #49 und send #50). Ok kopieren eines receive-Moduls aus dem helper-Makro, Anschluss im neuen Conatiener und Test: ja es klappt
Erleichterung und viel

Jetzt lehne ich mich zurück und frische die Container der Reihe nach auf.

[herw]

Grafik und Audio-Signalweg-Umschaltung funktionieren perfekt. Ich habe jetzt schon oft mein Testensemble geändert (Löschen und Einfügen von Containern). Alles läuft wie geschmiert. Ich bekomme auch schon Routine, so dass ein Umbau eines Ensembles wirklich entspannend ist.
Wenn ich mal die Version 3 komplett habe, werden sicherlich einige User enttäuscht sein, da man ja keine Änderungen sieht; naja die Änderungen sind gewaltig, betreffen aber nur die Stukturen.
Hier mal zwei kleine Kostproben:
Hier habe ich mal eine Idee von David (MvKeinen) geklaut, der eine Exeltabelle als Strukturicon benutzt, um so die Bedeutung von Ein- und Ausgängen von Core-Makros zu erläutern, Damit es richtig passt, muss man für jede Zeile die Zeichensatzgröße 10pt und die Zeilengröße auf 0,55cm einstellen. Natürlich muss man eventuell in der Grafik oben etwas einfügen, damit es richtig passt, aber es ist sehr hilfreich. Die Icons müssen als bmp- oder tga-files gespeichert worden sein. Übrigens benötigt REAKTOR das Icon nur einmal; also kein sehr großes Aufblähen des Ensembles.

Bild 1.jpg

Die Aneinanderreihung der Container ist jetzt noch einfacher: nur noch ein verbindendes Kabel; innerhalb jedes Containers muss allerdings ein receive-Makro kopiert und eingefügt werden. Ich hoffe mal, dass es irgendwann einmal globale receive-Tabellen gibt, dann fällt diese Einschränkung weg.

Bild 2.jpg

Trotzdem keine große Sache, wenn man mal eben sein Ensemble ändern möchte. Aber, wie bei allen geänderten Ensembles gilt, dass alle Snapshots unbrauchbar werden; das heißt man sollte sich im Klaren sein, dass man, bevor man eine große snapshot-Datenbank aufbaut, auch wirklich die optimale Zusammenstellung an Containern gefunden hat.

Bild 4.jpg

Ich ändere jetzt vorrangig solche Container, mit denen ich den Audio-Signalweg kontrollieren kann; hier mal das Oszilloskop zur optischen Kontrolle)

Bild 3.jpg

die nächsten Container sind ein SCA und den Audio-Output, damit ich auch eine akustische Kontrolle habe.

[herw]

Version 3 läuft

version 3.jpg

[herw]

ein unbedeutendes Bild?

336-racks.jpg

nur ein kleines neues Detail: die Rackgröße habe ich nun auf 15" erweitert, genauer auf 1344 Pixel Breite. Das ist rein logisch kein Problem; das „Problem” sind die im Hintergrund liegenden Multidisplays; sie lassen nur eine Maximalgröße von 1024 Pixeln zu. D.h. ich lege zwei solche Multidisplays nebeneinander; damit sie auch gut aneinander schließen, haben sie die Größe von 673x361 Pixeln.
Damit die Multidisplay auch die höheren Koordinaten verstehen, muss der Ursprung des zweiten (rechten) Multidisplays um 672 Pixel verschoben werden. Ändert man also X0 auf 672, wird der neue Ursprung automatisch in den Properties gesetzt.

set origin.jpg

Ähnliches gilt für die y-Koordinate, wenn man nach oben erweitern möchte.
Damit habe ich nun auch die Möglichkeit, breitere Container zu erstellen zum Beispiel 16- und 24-Step-Sequenzer.

ciao herw

[herw]

neue Container sind in Bearbeitung: ich habe mich mal auf die Phasenmodulation gestürzt und dazu das Ensemble FM-4 aus der library mal auseinander gepflückt und versuche nun sinnvolle Container zu gestalten. Die Modulationsmatrix des Originalensembles ist etwas verwirrend bezüglich der eingespeisten Modulationen, aber ich glaube, dass ich eine sinnvolle Aufteilung gefunden habe. Ich muss ein wenig darauf achten, dass die Container nicht zu groß werden, damit der modulare nicht in einen semimodularen Charakter umschwenkt.

neue container.jpg

ciao herw

[herw]

ein kleines Test-Ensemble:

FILTER.jpg

ciao herw

[herw]

Alle alten und einige neue Container sind transformiert zur Version 3. Die Beta-Test-Phase beginnt; Phil Durrant (Sowari) ist der Tester. Die neuen Filter sind richtig gut und bringen ganz neu Möglichkeiten.
Die große Stärke liegt unter anderem auch in den vielfältigen Modulationsmöglichkeiten. Der neue Filtercontainer SCF6, der aus dem Upload von Stephan Schmitt entstanden ist, kann durch Selbstoszillation auch als Sinus-Oszillator benutzt werden. Ich habe dabei darauf geachtet, dass er im Tuning zu den normalen Oszialltoren liegt. Bei der Selbstoszillation benötigt das Filter kein Eingangssignal. Interessant ist aber, wenn die Selbstoszillation sich mit dem normalen gefilterten Eingangsignal überlagert. Das Ausgangssignal kann dann sehr komplex, aber durchaus musikalisch gut verwertbar sein.

bild 1.jpg

Auch das neue modulierbare 8-pol-Bandpassfilter liefert komplexe Wellenformen:

bild 2.jpg

bild 3.jpg

bild 4.jpg

Das gesamte System ist stabil und funktioniert wie die Version 2. Das Einfügen, Löschen und Verschieben von Containern ist leichter geworden, da man nicht mehr die sends der anderen Container löschen und wieder neu einsetzen muss. Es wird lediglich der Container an die richtige Stelle geschoben, eine Kabelverbindung zu den Nachbarcontainern erstellt und ein receive_makro kopiert und eingesetzt - sofort einsatzbereit.
Ich bin sehr gespannt auf die neuen FM-Oszillatoren - bisher habe ich sie in Kombination als Carrier und Modulator noch nicht gehört.

ciao herw

[herw]

hier mal ein paar sounds nur mit einem gewöhnlichem Sägezahn und den hervorragenden Filtern von Vadim:
sehr schön ist der Sound, wenn die Resonanz so hoch geregelt wird, dass das Filter selbst zu schwingen beginnt. Im letzten Klangbeispiel springt der Ton eine Oktave tiefer.

ciao herw