MODULAR X Netzwerk

[herw]

Das war Schwerstarbeit gestern. Mark (quietschboy) und ich haben im Stakkato eMails ausgetauscht und über die Organisation des zentralen Speichers in der CoreCell diskutiert.
Er gab mir mit seinem ACEW eine schwere Nuss zu knacken, bei der es zum Zusammenbruch des ganzen Systems kam (Kabelverknüpfungen wurden in „falscher” Reihenfolge interpretiert.
Ich habe mich überzeugen lassen, dass asynchrone Events unbedingt zu vermeiden sind. Netterweise hatte Mark schon ein entsprechendes Makro erstellt, so dass ich darauf zurückgreifen konnte.
Im Laufe des Tages gab es viele Tücken zu lösen oder zu umschiffen.
Auch haben wir festgestellt, dass PC und Mac, obwohl intern mit demselben Prozessor i7 ausgestattet, doch unterschiedlich reagieren, insbesondere offenbar beim Händeln mit dem Multidisplay; eine Änderung der Transparenz der Kabel z.B. ergibt beim Mac einen geringeren CPU-Ausschlag, beim PC einen deutlichen CPU-Peak, was zeigt, dass diese ganze CPU-Messerei wohl Augenwischerei ist (auf beiden Systemen).
Dann machte mir auch zu schaffen, dass beim Umschalten der Snapshots es zu einem ärgerlichen „Knacken und Kracksen” kam, das mich stundenlang genervt hat.
Lösung war schließlich, dass beim Umschalten und „Kaltschalten” eines Ausgangs die letzten Werte erhalten blieben und fröhlich auf den nicht mehr verbundenen Eingang nahmen. D.h ich musste erreichen, dass beim Lösen der Verbindung alle Werte im entsprechenden Eingang auf 0 gesetzt werden (Makro set nil im Bild). Irgendwie hat es geklappt, das muss ich aber unbedingt dokumentieren, denn schon nach 14 Tagen werde ich das ganze nicht mehr durchschauen und wer weiß, wann ich weiter arbeiten kann:

loesen_einer_verbindung_1.jpg

Man erkennt auch, wie ich jetzt nur noch ein SpeicherArray M benutze (Marks Idee); es gehören immer zwei Elemente zusammen, auf den geradzahligen wird angezeigt (shift links erzeugt geradzahlige Zahlen), dass ein Event kommt, auf den ungeradzahligen (das oder-Modul addiert hier 1) ist die eigentliche Information. Der Trick dieser doppelten Buchführung besteht (unabhängig ob ein oder zwei Felder) darin, dass auch einzelne (wertgleiche) Events erkannt werden. Durch die Synchronisation mit dem SampleRateTick,wird sichergestellt, dass einzene Events auch wirklich alle Eingänge erreichen können. Mit SampleTick-synchronen Events bekommen alle Eingänge ihre Werte.

Wichtig ist dabei auch, dass man dieselben Ergebnisse erzeugt, wenn die Reihenfolge der Module sich ändert:
in den nächsten gezeigten snapshots wurde lediglich die Rolle der beiden SCOs als Modulator und Träger vertauscht. Das musikalische Ergebnis ist in der Tat nach dem Hören identisch:

modulation_1.jpg

modulation_2.jpg

ciao herw

Übrigens, was ich noch gar nicht wusste und worauf mich Mark aufmerksam machte ist, dass es alte und neue Regler in REAKTOR gibt. Dass die Properties sich für Regler gegenüber früheren Versionen geändert haben (Verwaltung von stepsize zum Beispiel) kann man leicht erkennen. Neue Regler haben intern einen Stepfilter eingebaut, so dass sie niemals mehr zwei gleiche Werte beim Panelregeln senden. Leider werden in existierenden alten Ensembles (R5.6 ?) die Properties ebenfalls geändert, doch ist der Stepfilter nach wie vor nicht enthalten. Hat man also einen Regler aus einem älteren Ensemble kopiert, so ist er immer noch alt. D.h. man muss alle benutzten Regler einzeln durch neu eingefügte ersetzen
Sollte ich mal im Thread Kernschmelze erwähnen.

[herw]

Ich habe nun die Gesamtstruktur vereinfacht. Die monophonen core-Container habe ich in die polyphone AudioCoreCell SVA (Signalverarbeitung) integriert:

signalverarbeitung_1.jpg

Damit in den monophonen Containern nicht alle Stimmen verarbeitet werden, müssen die polyphonen Signale aus der CoreCell zunächst hinausgeführt, durch einen AudioVoiceCombiner in monophone Signale umgewandelt und wieder direkt eingeführt werden. Innerhalb der SVA ist dies dann wieder eine polyphones Signal mit identischen Stimmwerten.
Innerhalb der SVA ist es natürlich unwirtschaftlich, wenn nun alle folgenden (Effekt-) Container mit identischen Stimmen arbeiten würden. Wenn man die SR.C auf die erste Stimme beschränkt, dann reduzieren sich die folgenden Bearbeitungen nur auf eine Stimme. Die restlichen sind quasi stillgelegt.

signalverarbeitung_2.jpg

Dies ist geringfügig unwirtschaftlicher, als wenn man sie nur in einer externen monophonen AudioCoreCell verarbeiten würde. Der Vorteil ist, dass die monphonen Container in die allgemeine Core-Struktur voll integriert sind, d.h. ich kann sie beliebig verteilen.

signalverarbeitung_3.jpg

[herw]

Die gemeinsame AudioCoreCell (ACC) für polyphone und monophone Container hat sich als schwierig herausgestellt. Zu oft sind 3rd-Party-Makros sehr speziell programmiert. Ich musste ständig die SR.C durch spezielle voice1-SR.C ersetzen - ein mühsames Geschäft.
Ich musste dann doch einsehen, dass getrennte CoreCells einfacher zu handhaben sind.
Ok, auch das gehört zu einem Projekt, einen Weg zu versuchen, der in eine Sackgasse führt. Nun es gibt ja die Alternative, an die polyphone ACC nun eine monophone anzuschließen.
Es funktioniert jetzt auch; eine Optimierung muss nun in den nächsten Tagen geschehen: wo werden unnötige Resourcen verbraucht, was kann einfacher „programmiert” werden?
Mark (Quietschboy) gibt mir einige Hinweise, wo mein Drahtverhau uneffektiv oder auch fehlerhaft ist. Das spart mir sehr viel Arbeitszeit und gibt mir auch Hinweise, an die ich vielleicht nicht denken würde.
Lange habe ich an den Initialisierungen gesessen. Ich musste genau darauf achten, in welcher Reihenfolge core und primary initialisiert werden sollen. Da können schnell Stunden und viele frustrierende Versuche verstreichen.

modular_4__15-01-23__1.jpg

ciao herw

[herw]

Zwischenbilanz

zwischenbilanz.jpg

es läuft gut. Die Diskussionen mit Mark ersparen mir mancherlei CPU-Prozente.

[Eventmanager]

Übersteigt eindeutig meinen Horizont - aber ich finds Klasse, wie ihr euch gemeinsam einem Problem stellt!

[herw]

eine harte Woche; eigentlich lief es ganz gut, die Verknüpfungen waren stabil, das Prinzip funktionierte, also ran an die neuen (alten) Container. Was soll da schon schief gehen? Da die Verknüpfungen funktionieren, müssen auch die Signalverarbeitungen funktionieren.
Stimmt auch, wenn da nicht so komische Spezialfälle passieren. Beim Resetten von REAKTOR (aus- und anschalten) tat ein Modul keinen Dienst, absolute Stille nach zwei mittel lauten Knacksern.
Es passierte bei der Gestaltung des REVERBS. Also habe ich mindestens drei Abende jedes Kabel und jedes Signal verfolgt. Wenn man keine Ahnung hat, wo die Ursache liegt, tappt man völlig im Dunkeln.
Unmengen an snaps habe ich ausprobiert, immer in wechselnden Kombinationen. Heute, nach vier Tagen, habe ich den Fehler eingrenzen können, erstaunlicherweise bei einem Container, den ich als 100%ig gesichert angesehen habe, dem SCO 1 (signal controlled Oscillator), einem gut erprobten und zuverlässigem Arbeitstier.

Nachdem ich die Quelle des Fehers identifizieren konnte, musste ich doch noch tief in die Struktur schauen, Vergleiche mit dem ursprünglichen Makro aus der NI library, dem 4-Wave-Oszillator und (erstaunlicherweise) auch dem MultiwaveOszillator. Ich konnte es kaum fassen,:ich hatte beide Makros vermengt. Das funktionierte in RUHR fehlerlos, doch hier im neuen System gab es eben den Ausfall. Nachdem ich das erkannt hatte, ging es relativ schnell (2 Stunden), ich musste mich nur entscheiden, welchem Original ich den Vorzug gebe.
Jetzt gibt es keinen Fehler mehr.
Als User erkennt man, glaube ich, nur schwer, wie viel Misserfolge und neue Erkenntnisse hinter einem neuen Ensemble oder sogar einem ganzen System stecken.

Im Moment sieht so aus: ...

zwischenbericht_2.jpg

es folgen einige Container, auf die ich mich verlassen kann, aber natürlich möchte ich ein neues Ensemble schaffen, das über die traditionellen Container hinausgeht.
Aber auch wenn viele Container nach außen hin genauso aussehen wie im alten System, intern ist alles anders und letztlich für den Benutzer, der sich einen eigenen Modular zusammenstellen möchte, so viel einfacher. Zum Beispiel, nachdem ich den SCO repariert hatte, dauerte es nur dreißig Sekunden, um die anderen Oszillatoren zu ersetzen, ohne auch nur einen snap ändern zu müssen.

ciao herw

[herw]

Der Ladder-Filter zwitschert schon schön:

ladder_filter.jpg

ladder.jpg

[Eventmanager]

Sei doch so lieb und stell den Ladder bitte als Macro hier rein.
Ein Filterdesign vom Meister würde mich echt interessieren, sofern CPU nicht exorbitant ausfällt.

Ich mag übrigens das Prim-Ladder sehr. Mit etwas automatischen Res/Pegel-Ausgleichs-Gebastel bleibt es selbst bei ziemlich unterschiedlichen Eingangsfrequenzen schön pegel-konstant, egal wie wild die Mod-Combis sind.
Bin mal gespannt wie du das toppen willst!

[herw]

Sei doch so lieb und stell den Ladder bitte als Macro hier rein.
Ein Filterdesign vom Meister würde mich echt interessieren, sofern CPU nicht exorbitant ausfällt.

Ich mag übrigens das Prim-Ladder sehr. Mit etwas automatischen Res/Pegel-Ausgleichs-Gebastel bleibt es selbst bei ziemlich unterschiedlichen Eingangsfrequenzen schön pegel-konstant, egal wie wild die Mod-Combis sind.
Bin mal gespannt wie du das toppen willst!

Das brauche ich gar nicht, da ich nur das Makro aus der REAKTOR Library an moduar x angepasst habe (Panelelemente werden über partials framework eingespielt, Ein- und Ausgänge werden über ein array geschaltet).
Du kannst also einfach auf das Original zurückgreifen. Das Makro ist im Wesentlichen eine CoreCell. Übrigens befindet es sich auch im Ensemble RUHR. Die Pegel sind ziemlich stabil. Der CPU-Verbrauch ist ca. 12% bei 8 Stimmen, also relativ teuer.

ladder-filter.jpg

ciao herw

[Eventmanager]

Das Teil hatte ich schonmal gecheckt und wieder aussortiert.
Falls es tatsächlich einen klanglichen Zuwachs gab, war er mir zu esoterisch als das ich den CPU-Verbrauch in Kauf nehmen wollte.

Trotzdem danke.

[herw]

Das Teil hatte ich schonmal gecheckt und wieder aussortiert.
Falls es tatsächlich einen klanglichen Zuwachs gab, war er mir zu esoterisch als das ich den CPU-Verbrauch in Kauf nehmen wollte.

Trotzdem danke.

also esoterisch würde ich den Klang nicht nennen. Das Modul liefert genau den Klang, den man erwartet.
Hier ist ein Klangeindruck (Doepfer-Modul) einer Filterung eines Rauschsignals:
https://www.youtube.com/watch?v=9ZxRsxPLuI4
Ab der Video-Minute 15 etwa wird das Zwitschern und Pfeifen deutlich demonstriert (Emulation eines Windpfeifens).
So arbeitet das Core-Filter auch.

ciao herw

[Eventmanager]

Ich schätze ich hab meine Building Blocks auf den Datenfriedhof geschickt;-)
Hab aber die 3 Ladders aus der VCFSektion A/B mit den Prim getestet. CPU ist mit Prim im HighQuality vergleichbar (das Ladder 3 verbraucht mehr, weil alle 4 outs was verbraten, egal ob switch on oder nicht, lösche ich 1,2,3pole ists mit den anderen ca. gleichteuer). Nun ja, sie klingen subtil bis leicht wahrnehmbar anders, irgendwie bissl mehr pfeifend/selbstoscilativ/schärfer. Das kann mal gewollt sein, mal nicht. Das ultimative Allround-Filter gibts natürlich nicht, in der Praxis bleibts also beim Durchswitchen bei veränderten Input / erwarteten Ergebniss.

PS: Was du oben zum CPU-Meter schreibst, dir ist schon klar, das das reaktor-Meter nur Audio misst und alle Grafik-Berechnungen komplett verschwiegen werden? Gilt auch für Hosts. Im Zweifel immer den Activity-MOnitor bemühen, da siehst du die Gesamtlast einzelner Anwendungen.

[herw]

[...]
PS: Was du oben zum CPU-Meter schreibst, dir ist schon klar, das das reaktor-Meter nur Audio misst und alle Grafik-Berechnungen komplett verschwiegen werden? Gilt auch für Hosts. Im Zweifel immer den Activity-MOnitor bemühen, da siehst du die Gesamtlast einzelner Anwendungen.

Das stimmt so nicht, da NI mit der Version 5.9.2 die Berechnung umgestellt hat (nichts genaues weiß man nicht „NGWMN”); aber ich glaube, dass außer den audio-Anwendungen noch einiges hinzugekommen ist und dem wahren Verbrauch näher kommen soll, aber „NGWMN”.

[Quietschboy]

[...]
PS: Was du oben zum CPU-Meter schreibst, dir ist schon klar, das das reaktor-Meter nur Audio misst und alle Grafik-Berechnungen komplett verschwiegen werden? Gilt auch für Hosts. Im Zweifel immer den Activity-MOnitor bemühen, da siehst du die Gesamtlast einzelner Anwendungen.

Das stimmt so nicht, da NI mit der Version 5.9.2 die Berechnung umgestellt hat (nichts genaues weiß man nicht „NGWMN”); aber ich glaube dass außer den audio-Anwendungen noch einiges hinzugekommen ist und dem wahren Verbrauch näher kommen soll, aber „NGWMN”.

In aller Regel ist der GUI-Thread vernachlässigbar. Auffallend ist, daß er gerne auch auf einem zweiten CPU Core läuft (gesehen mit Windows und Reaktor Standalone).
Welche der Event-Berechnungen in den GUI- oder Audio-Thread fallen, hängt von der Triggerquelle ab. Für Panel Elements z.B. ob man die Maus (GUI) benutzt oder Midi-quellen (AUDIO).
Für Midi-Noten gilt:
MIDI-In --> AUDIO,
Computertastatur --> GUI
Bei den ganzen Graphik-Elementen wie Multidisplay, etc. bin ich mir nicht sicher, ob diese grundsätzlich im GUI Thread abgearbeitet werden.
Potenziell gefährlich wird´s, wenn man GUI und AUDIO-Thread Events vermischt an das selbe Ziel sendet. Stichwort Multiplexing und Thread Safeness, siehe die Dokumentationen zum Partial Framework.
Ok, ich schweife ab....

[herw]

Nach einer mittleren bis großen Katastrophe kann es weiter gehen.
Ich habe frisch und fröhlich weitere Container entwickelt und eingebaut und plötzlich gab es nur noch Abstürze. Es hat mich (und wahrscheinlich auch Mark) einige Nerven gestern (mehr als 13 Stunden) gekostet. Es war nicht einfach, den Grund einzugrenzen, da ich natürlich die Fehlerprotokolle nicht zu interpretieren weiß.
Erst schien das neue Filter die Ursache zu sein. Nach und nach kristallisierte sich heraus, dass die Länge der OBC-Verbindung der Grund sein musste. Aus bestimmten Gründen sollte diese Kette aber seriell angeordnet sein.
Heute morgen bekam ich endlich anstelle des Absturzes eine reguläre Fehlermeldung:

bild_1.jpg

Aha, also der Compiler schafft es nicht. Nun gut, ein sternförmiger Aufbau funktioniert, ist aber aus Initialisierungsgründen in bestimmten Fällen problematisch:

bild_2.jpg

Also musste dem Compiler geholfen werden, damit er die Struktur beherrscht:

bild_3.jpg

Der Readbefehl liefert außerhalb der CoreCell für ein numeric readout „schlau” eine Ausgabe (ohne weitere Verwendung).
Offenbar erkennt der Compiler, was er vor der Initialisierung der OBC-Verbindungen im 2. Rack tun muss; damit verkürzt sich für ihn die Strukturlänge.

Es ist zwar noch keine optimale Lösung, bringt mich aber weiter.

ciao herw