MODULAR X Netzwerk

[herw]

Nach langen Jahren ist ein Traum wahr geworden: endlich habe ich es geschafft, ein Netzwerk aufzubauen, mit dem es möglich ist, modulare Synthesizer in REAKTOR zu erstellen:modular x.
Ich sage nicht, es sei einfach: ihr habt Kenntnisse über den edit mode von REAKTOR, habt schon mal ein Ensemble erstellt; ihr habt euch mit RUHR 2 beschäftigt; ihr habt Lust, euch intensiv mit einem solchen Netzwerk auseinanderzusetzen und könnt auch Frust überwinden.

Ansonsten viel Spaß. Hier könnt ihr Fragen stellen und Vorschläge unterbreiten. Von Zeit zu Zeit ergänze ich das Netzwerk und baue Verbesserungen ein. Also ab und zu mal in die user library schauen.

ciao herw

[herw]

Hab viel gearbeitet, auch am modular x Netzwerk. Endlich habe ich das Handbuch erweitern können und anhand eines Beispiels (subharmonischer Oszillator) erklären können, wie man einen eigenen Container erstellen kann.In den nächsten Tagen ist der upload.
Es gibt viel zu lesen (27 neue Seiten).

neues Kapitel.jpg

Viele zusätzliche Dateien musste ich erstellen und mehrfach kontrollieren, damit keine Fehler passieren. Ich arrangiere noch die Ordner und dann geht's in ein paar Tagen hoch in die user library.
Ich bin mal gespannt, ob jemand auf den Zug aufspringt.

ciao herw

[herw]

hochgeladen!

modular x v2.1

ciao herw

[Rampensau]

Deine Arbeit am Modular ist einfach großartig. Ich habe echt Lust, mich da einzuarbeiten. Beeindruckend, zu sehen, wie ein Mann die komplette Arbeit und den Zeitaufwand einer Softwareentwicklung auf sich nimmt. Im Grunde solltest du Ehrenmitarbeiter von NI sein.

Grüße

[herw]

Im NI-Forum habe ich von einem Traum gesprochen (I had a dream), natürlich hatte ich da schon einen konkreten Ansatz im Kopf. Der Traum ist, die Zusammenstellung der Container extrem einfach zu gestalten: Container auswählen, im Panel positionieren und mit dem Musizieren anfangen. Zunächst glaubte ich, dass ich ganz extrem vorgehen könnte, so dass die einzelnen Container völlig unabhängig eingefügt werden könnten. Ich brauche aber wohl doch eine minimale Verbindung, die aber lächerlich einfach ist: ein Kabel verbindet alle Container und gibt ihen lediglich eine Kennzahl (es wird immer nur 1 addiert).
Entscheidender ist aber - und das ist der ursprüngliche realistische Traum - ich brauche keine send-receive-Verbindungen mehr, um die audio-Signale zu übertragen.
Auch die Informationen für die Grafikebene (Kabel auf dem Bildschirm) benötgen keinen Eventbus zwischen den Containern mehr.
Ich habe nun erste einfache Tests durchgeführt, ob diese Idee tatsächlich realistisch ist: ja - es ist tatsächlich möglich. Nachteil gegenüber den send-receive-Verbindungen ist ein höherer CPU-Verbrauch. Zumindest in monophoner Form ist es wohl in jedem Fall akzeptabel. Ich habe aber auch eine Trick gefunden, dass sich Container bei Nichtbenutzung automatisch ausschalten.
Der Traum manifestiert sich und ich kann jetzt konkrete Umsetzungen vornehmen. Mein Zwischenziel ist, dass ich zunächst einfache existierende Container umarbeite. Das bisherige Netzwerk soll aber nicht vernachlässigt werden. Der Traum ist (zunächst) ein Nebenprojekt.
Ich bin selbst gespannt, ob alles so reibungslos klappt. Interessant ist, dass sich manche „Probleme” bei intensivem Nachdenken doch relativ einfach lösen lassen. Es ist eine riesige und spannende Herausforderung.

ciao herw

[herw]

20% meines Traums sind Realität:

Traum 1.jpg

Das Ensemble und die Racks (hier 16 Stück) initialisieren sich automatisch. Dies geschieht nicht mehr über einen Bus, sondern wie man dem Bild entnehmen kann, über eine Eventtable. Zu meiner Kontrolle zeige ich sie im 2D-Modus.
An der Regelmäßigkeit der Farbänderungen kann man die gewünschten Werteänderungen erkennen (wenn man weiß, was gezeigt wird ).
Es liegen 17 Zeilen vor, die Zeile 0 gibt die Größen-Daten des gesamten Ensembles an, die anderen jeweils die der Racks.
Ich beschreibe alle Racks durch zwei Punkte, die den absoluten Rechteckbereich festlegen (Spalten 1-4). Dadurch erhält jedes Rack einen festen Koordinatenbereich auf dem Bildschirm. Die beiden restlichen Spalten geben an, wie groß das jeweilige Rack ist (hier sind offenbar alle gleich groß).
Jedes Initialisierungsmakro legt jeweils seine Daten in der entsprechenden Zeile der Eventtable ab.
In ähnlicher Weise werde ich die Bereiche der Container festlegen. Allerdings kommen hier noch weitere Daten hinzu (Anzahl der Ausgänge, Eingänge etc.). Natürlich muss ich dafür eine neue Eventtable definieren.
Ich brauchte letztlich zwei halbe Tage, um die Idee möglichst einfach und fehlerfrei zu gestalten. Das Ein- und Auslesen erforderte einen neuen Algorithmus. Da Iterationen sich als Hemmschuh beim Laden der ersten Version des Ensemble RUHR v1 erwiesen hatten, musste ich mir etwas Neues einfallen lassen, da nun der taktgebende Bus fehlt. Ich habe es gänzlich ohne Iterationen geschafft.
Probeweise habe ich mal 256 Racks geladen und die Ladezeit betrug weniger als 3 Sekunden einschließlich Initialisierung. Also das ist schon mal kein Problem.
Jetzt werde ich die Container initialisieren.
ciao herw

[herw]

Der Neuansatz ist zwar in meinem Kopf, doch habe ich gemerkt, wie ich in den letzten beiden Tagen immer wieder in den Makros nachschauen musste, wie ich auf die Datensätze zugreife und welche Informationen ich weitergebe. Daher habe ich mich entschlossen, parallel zu meinen Programmierungen alle Ideen und Festlegungen zu dokumentieren. Das ist zwar zunächst eine zeitliche Mehrarbeit, zahlt sich aber über die nächsten Wochen sicherlich aus.

[herw]

16 Seiten, aber endlich für mich eine schnelle Nachschlage-Möglichkeit zur Initialisierung der Racks. In ähnlicher Form gehe ich jetzt an die Datentabelle der Container. Hier werden die Erklärungen hoffentlich kürzer sein, da ich viele Algorithmen leicht verändert übernehmen kann.
Zu Kontrolle lasse ich mir die Tabelle im MultiLine-Modus anzeigen.

DATA 1.jpg

Hier zeige ich auch mal, wie die Daten eines neuen Racks berechnet werden:

neues Rack.jpg

Zunächst wird ein Logikwert gesetzt, ob das neue Rack über die Gesamthöhe My des modulars hinausragen würde. Dazu wird die letzte Höhe preRy1 des vorangegangenen Racks um die neue Rackhöhe Ry erhöht und mit My verglichen. In Abhängigkeit des Vergleichs werden die Eckpunkte (Rx0|Ry0) und (Ry1|Rx1) des Koordinatensystems des neuen Racks gesetzt.
Eigentlich ganz einfach !?! Aber natürlich habe ich den Ehrgeiz mit möglichst wenigen Daten und wenigen Rechenoperationen auszukommen, obwohl das bei lächerlichen 16 möglichen Racks überhaupt kein Problem ist.
Ich gestalte allerdings die Rechnungen möglichst einheitlich, so dass ich sie auch nach Jahren noch verstehen kann.
mit viel gehts weiter

[herw]

es war schon viel , aber relativ stressfrei. Die Notizen zur Initialisierung der Racks waren hier schon nützlich.
Ich habe die Initialisierung der Container sehr ähnlich aufgebaut.
Hier waren allerdings zwei Logikwerte L1 und L2 nötig, da nicht nur abgefragt wird, ob die Rack-Größe überschritten wird, sondern auch nach dem Wechsel eines Racks.

Fallunterscheidungen.jpg

Daher ist die Berechnung der lokalen Koordinaten etwas umfangreicher. Trotzdem kann man gut die Fallunterscheidungen erkennt.
Getestet habe ich mit 8 Rack-Initialisierungen und insgesamt 128 Containerinitialisierungen.
Ladezeit ca. zwei, Speicherzeit ca. sechs Sekunden.



ach ja, 30% des Traums sind jetzt Realität

[herw]

Heute gibt es wohl wieder etwas Schreibarbeit, damit mir die Programmierhintergründe nicht verloren gehen.
Wenn ich die Fortschritte mit dem existierenden Ensemble RUHR vergleiche, so stecke ich gerade im Interface der Container bei den Ein- und Ausgängen.
Ich will ja nicht das gesamte Netzwerk neu erfinden; es geht „lediglich” darum, den Datenverkehr neu zu organisieren, wie man an meinen Ausführungen erkennt, über shared event tables.
Das Prinzip bei den event tables ist immer ähnlich: Auslesen von Daten, Schreiben von Daten und globale Verfügbarkeit - schon praktisch.
Die eigentlichen Applikationen der Container, also die Audioverarbeitung taste ich nicht an, ist auch unnötig, denn die ist ja unabhängig in diesem Netzwerk; auch das GUI bleibt unangetastet. D.h. wenn die Datenverarbeitung steht, steht auch das gesamte Netzwerk.
Den interessantesten Part behalte ich mir zum Schluss auf: die Beseitigung der send-receive-Verknüpfungen. Das Prinzip ist sehr simple und noch einfacher als bisher, aber der CPU-Verbauch ist nur im Experiment messbar. Dazu muss das ganze Drumherum, an dem ich jetzt arbeite, stehen.
viel

PS: ich habe das letzte Bild nochmals mit der entsprechenden Struktur in RUHR verglichen und ich denke, dass die Benutzung der Logikwerte dazu führt, dass unnötige Rechnungen ablaufen. Das ist zwar etwas Haarspalterei bei den relativ wenigen Containern, aber immerhin. D.h. ich werde die Fallunterscheidungen nicht durch Multiplikationen, sondern doch durch direkte Verzweigungen lenken. Das lässt sich aber sehr leicht ändern:

Fallunterscheidungen2.jpg

[herw]

Nun kommt der Dreh- und Angelpunkt an die Reihe, der RAM, ein Arbeitsspeicher, in den die aktuellen Daten der gewählten Ein- und Ausgänge, die Darstellungsform des aktuellen Kabels gespeichert werden. Hierauf greifen die Speicher der Kabel, die Ausgangsbelegung und letztlich auch alle Audioausgänge und -eingänge zu, um entsprechende Signalwege zu erstellen.
Die Arbeitsteilung durch verschiedene Eventtabellen erweist sich als sehr praktisch, da man jeden Part gut strukturieren kann. Ich behalte so Überblick.
Ein solcher Arbeitsspeicher existiert auch schon in der Version 2 des modular x. Das Beschreiben des Speichers ist sehr ähnlich, ich muss nur die Indeces anpassen.
Trotz der zeitweisen Unterbrechungen kann ich durch mein Arbeitsbuch immer wieder zügig meine Arbeit fortsetzen
es wird nach und nach immer konkreter

[herw]

Das Arbeitsbuch ist ein Segen. Nun lagen tatsächlich einige Wochen zwischen der letzten Bearbeitung. Trotzdem war ich nach kurzer Zeit wieder in der Materie.
In den letzten Tagen habe ich mich nun an die Ausgänge und Eingänge herangemacht. Hier ändert sich eigentlich nicht viel: sie senden über einen kurzen Bus ihre Adresse und Koordinaten. Der Unterschied besteht - wie im gesamten framework der Version 3 - vielmehr darin dass diese Daten nicht über einen gemeinsamen Bus weitergeleitet werden sondern in EventTabellen hineingeschrieben werden. So weit so gut und auch einfach. Das eigentliche Problem besteht (bestand) nun darin, dass durch das Schreiben in eine Eventtabelle ja kein Event weitergeleitet wird, insbesondere an das Makro Kabel, das die Verbindungen auf dem panel zeichnet, und an die Audioverknüpfungen.
Wie macht man also diesen ohne einen weitergeleiteten Event klar, dass sie reagieren sollen.
Nach langen Überlegungen und kleinen Versuchen ist es mir gelungen dafür eine einfache Lösung zu finden:
Die Eventtabellen des Arbeitsspeichers (er speichert unter anderem die Adresse und die Koordinaten der gewählten Aus- und Eingänge) werden über die Display-Clock (25Hz) auf Änderung des Eingangs abgefragt. Nur bei Änderung wird ein Event erzeugt, der dann ein neues Kabel auf dem Panel zeichnet oder löscht und die Audioverbindung aufbaut oder entfernt. Das ist gegenüber der Version ein völlig anderer Ansatz, daher musste ich mir Zeit nehmen.
Insbesondere mussten wieder Initialisierungen herausgefiltert werden. Als nützlich erweist sich dabei, dass der Zustand des benutzen Eingangs durch ein Vorzeichen erkennbar ist. Auch wenn diese Methode schon lange in meinem Kopf ist, habe ich mich doch immer wieder etwas vor diesem Problem gedrückt. Letztlich ist es aber sehr einfach:

Bild.jpg

So klein diese Lösung im Nachhinein ist, sie ist das entscheidende Element, um einen Event ortsunabhängig zu übermitteln, ohne internal connections, IC-send-receive oder send-receive zu benutzen.

ciao herw

[herw]

Was mich richtig genervt hat, ist dieser (unsinnige) „bug”, dass eine corecell, die man öffnet, einzeln compiliert wird, ohne dass die Umgebung beachtet wird. Das hatte zum Beispiel zur Folge, dass dieses einfache Makro über mehrere Stunden (!) zickte, ohne dass ich auf diesen „bug” kam.
Beim Entwickeln einer event-corecell ist es normal, dass man im Innern zwischendurch auf die Kabel schaut und die Werte erhaschen will. Nur dass dann durch das Compilieren an den Eventeingängen nicht die erwarteten Werte liegen sondern 0! Es hat mich ca. sechs Stunden gekostet, bis mir dieses abstruse Verhalten wieder einfiel:
Wenn man also eine Event Corecell verändert und die Kabelwerte überwachen möchte (auch mit Eventwatcher), dann muss man kurz Reaktor deaktivieren und wieder aktivieren, damit das gesamte Ensemble compiliert wird. Erst dann sind alle Eingänge auch von außen richtig gesetzt.
arggh

ciao herw

[herw]

Die letzten beiden Tage waren sehr erfolgreich:
Ich habe die Verwaltung der Panel-Kabel voll auf das neue System umstellen können. In diesem Zuge habe ich auch das Makro Kabel neu strukturiert. Nach wie vor werden die virtuellen Kabel über einen Bus an die Multidisplays übergeben, doch brauche ich nicht mehr die Synchron-Nachrichten künstlich aufzubauen. Ich komme mit einem normalen Bus aus.
Das Makro Kabel ist jetzt völlig von den Racks getrennt und bekommt seine Daten ausschließlich über die Eventtabellen. Dadurch konnte ich mir einige Iterationen einsparen, was zwar nicht viel bewirkt aber doch wesentlich übersichtlicher ist.

Bild.jpg

Damit ist der optische Bereich vollkommen fertig und funktioniert genauso perfekt wie vorher.
Nun kommt der spannende Teil: das Ersetzen der send-receive Verbindungen durch Audio-Tabellen. Ich weiß, dass es funktioniert, da ich es schon in kleinen Testensembles ausprobiert habe. Ich denke es wird nicht so schwierig umzusetzen zu sein. An der Logik ändert sich nicht viel und an den „inneren Werten”, den eigentlichen Applikationen ohnehin nichts.
Wenn ich jetzt zurückblicke, dann bin ich in relativ kurzer Zeit schon zu Version 3 übergegangen. Ich denke mal vom Umstellungsaufwand habe ich ca. 75% geschafft.


ciao herw

[MvKeinen]

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 Containers 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.