MODULAR X Netzwerk

[herw]

ja das klappt; ich habe mit acht Stimmen gearbeitet: ein polyphoner einfacher minisynth bestehend aus einem 4-Wave-Oszillator und einer ADSR Hüllkurve in polyphoner Version und eine MonoCell bestehend aus jeweils acht entsprechenden Synths. Das erstaunliche Ergebnis ist, dass der CPU-Verbrauch der acht monophonen Synths (ca. 0,8%) höchstens soviel verbraucht wie der polyphone Aufbau (ca. 1,0%), eher weniger. Das hatte ich nicht erwartet.

monosynths.jpg

Man erkennt die acht mono-Signale für die pitch- und gate-Events. Sie werden über einen Bus in die monophone audiocorecell eingebracht. Das werde ich weiterverfolgen.
Der Vorteil ist nun, dass ich hinter dem Achtfach-Addierer nun sofort monophone Effektmodule folgen lassen kann.

ciao herw

[herw]

Das sieht doch allein schon optisch sehr schön aus:

modular_x_v4.jpg

Ich mag diese Trennung in primary und core, insbesondere den identischen optischen Eindruck.
Im Moment funktioniert das Strippenziehen auf dem Panel. Das habe ich nochmals vereinfachen können. Der Bus {b} transportiert jetzt alles, was an events verschoben werden soll.
Auch die polyphonen Mididaten werden nun tadellos an die monophone CoreCell übergeben.
Jetzt gehe ich an diese kleinen niedlichen core-Makros, damit man auch etwas hören kann.
Sehr gut zu erkennen ist der gemeinsame Speicher S, auf den alle corecell-Container sternförmig zugreifen.

[herw]

Die Umwandlung von polyphonen Mididaten in monphone Mididaten ist ja an sich nicht schwierig.
Einzig die Organisation der zugehörigen Nachricht erforderte etwas Probierarbeit. Dabei habe ich auf der Empfangsseite aus dem partials framework ein für mich neues Makro ausprobiert: message type select.
Aber der Reihe nach: zunächst muss erstmal eine monophone Nachricht erzeugt werden.

bild_1.jpg

Mit Hilfe des VoiceInfo-Moduls wird zunächst die aktuelle Voice abgefragt und an das bus-head-Makro übergeben. Wie der Name schon sagt, wird dort der Kopf der Nachricht erzeugt. Im voice-value-Makro wird der eigentliche Wert übergeben.

bild_3.jpg

Die Nachricht selbst besteht aus fünf Daten: {id,#,type,voice,value}.
Der Identifier ist hier auf -6 gesetzt. Die Anzahl # der folgenden Daten beträgt 3, dann wird der Datentyp angegeben (hier 1 für midipitch), dann die aktuelle Stimme und schließlich der eigentlich Pitchwert.

bild_2.jpg

Da Reaktors Voice-Verwaltung sequentiell arbeitet, können die Daten voice und pitch über einen eventmerger in einen monophonen Datenstrom umgewandelt werden.
Für den Gate-Wert wird der Typ 2 angegeben usw.. Die Nachricht wird anschließend über ein einfaches merge-Modul in den Datenbus {b} eingeschleust.

[herw]

Nun die interessante Empfängerseite:

bild_4.jpg

Zunächst wird die Nachricht über den identifier -6 aus dem Bus {b} selektiert. Das Makro message type select erkennt nun den Typ T=1 (MidiPitch).

bild_5.jpg

Dann reduziert das Makro für das anschließende Auslesen die Anzahl der Daten # auf 2 und gibt nacheinander die synchronen Datenpaare {0,voice} und {1,pitch} aus. Nun kann man mit einen einfachen Router ein from-voice-Modul in core simulieren und das Datenpaar {voice,pitch} übergeben.

Anschließend schreibe ich die Pitchdaten in das gemeinsame Array S (siehe Post oben).

bild_6.jpg

Wenn ich von 512 maximal möglichen verschiedenen polyphonen Quellen ausgehe, wird der Pitchwert der Voice 1 in S[1], der von Voice 2 in S[513], der von Voice 3 in S[1025], also allgemein in S[voice*512+voice] für die voice-Nummern 1..8. Im aktuell dargestellten Testensemble ist besitzt der Pitcheingang die Nummer O#=4, also wird in die Zellen S[4], S[516], S[1028] usw. geschrieben.
Das Array S hat also eine Größe von 512·8=4096 Elementen.

Marks ACEW ist ein wertvoller Helfer, wenn es darum geht, Eventdaten aus der AudioCoreCell zu isolieren. (Dank natürlich auch an Gerald (aka Krümelmonster).
Ein ToVoice-Makro lässt sich nun natürlich ziemlich einfach erstellen, da ja ohnehin alle Daten monophon sind.

[herw]

Der erste Container MIDI 1 ist fertig.

midi_1.jpg

Er enthält sechs Ausgänge, jeweils parallel pitch und gate für polyphone, monophone und unisono Stimmen.
Manchmal vermisse ich eine core-interne Iteration sehr, zum Beispiel, wenn man die Pitchbend-Werte zu den aktuellen Pitch-Werten addiert:

midi_pitchbend.jpg

ciao herw

[herw]

Nachdem ich in den letzten Tagen sehr optimistisch über meinen Neuansatz dachte, gab es heute den totalen gedanklichen crash
Die Idee, ein array als Matrix zu missbrauchen, hat mich sehr fasziniert. Auf primary-Ebene sind dies das send-receive-Koncept und auch die audiotables.
Nun dachte ich, dass man ja das array ebenfalls in ähnlicher Form benutzen könnte. Ich habe dabei aber vergessen, dass im Gegensatz zur primary-Ebene ein core-array seine Werte nicht freiwillig hergibt, sondern nur mit Hilfe von Triggern.
Solange es sich um audio-Daten handelt, ist dies kein Problem, man kann als Trigger einfach SampleRateClock benutzen, oder auch eine niederfrequente Clock.
Nur was passiert mit einzelnen events? Woher soll der Empfänger wissen, wann ein Wert in das Array geschrieben wurde?????

Arggh, jetzt ist das ganze Konzept hinfällig. Trotzdem werde ich noch einige Tage darüber nachdenken (müssen), bis ich endgültig „nein” sage.

[herw]

[...]
Arggh, jetzt ist das ganze Konzept hinfällig. Trotzdem werde ich noch einige Tage darüber nachdenken (müssen), bis ich endgültig „nein” sage.

hmmm - es gibt vielleicht noch eine Hintertür

[herw]

hmmm - es gibt vielleicht noch eine Hintertür

sehr viel

Lösung

matrix.jpg

Es gibt zwei gleich große Arrays: das untere [S] erhält event- wie audio-Daten aus den verschiedenen Quellen. Parallel dazu wird im Array [T] der Typ der Daten gespeichert, (T=0) kein event, (T=1) einzelner events, (T=2) audio event. Der Wert T=1 existiert nur während eines einzelnen SR-Ticks (genauer für die Dauer ab dem asynchronen event vor dem nächsten ST-Tick) und springt anschließend wieder beim übernächsten auf -1 zurück.
Beim Auslesen des Arrays [S] werden in Abhängigkeit des Typs leicht unterschiedliche Leseverfahren angewendet. Der Trick war, dass die Einzel-Events zur SR.C synchronisiert werden mussten. D.h. Bei mehreren Daten, die asynchron zwischen den SR-Ticks eingelesen werden, ist nur der letzte event relevant. Das ist zwar nicht ganz optimal, aber ich denke, damit kann man leben. Entscheidend war, dass jeder einzelne event automatisch ausgelesen wird und auch wirklich nur einen Event erzeugt und zwar auch solche, die den selben Wert haben (das war die eigentliche Krücke). Nebenbei erhalte ich durch das Setzen von T=0 auch noch die Möglichkeit, den Audiostrom auszuschalten (spart CPU).
ciao herw

[herw]

Das Schreiben und Auslesen aus dem Array S mit Hilfe des Type-Arrays T klappt jetzt hundertprozentig:

bild_1.jpg

Hier wurde ein Gate-Event übertragen. Auch die Übertragung gleicher Events klappt. Im ACEW wird sehr schön angezeigt, wie der asynchrone Original-Event (state-lamp ist grau) im folgenden SR-Tick (state-lamp ist gelb) ausgelesen wird.

Auch bei SR.C synchronisierten einzelnen Events, wie sie ja zum Beispiel bei ControlRates auftauchen können, wird der folgende Tick ausgewählt:

bild_2.jpg

Im folgenden Screenshot habe ich zwei Tasten gedrückt, wobei die zweite zuerst losgelassen wurde: perfekt werden die beiden Stimmen auseinandergehalten.

bild_3.jpg

[pavel]

Schön, dass sich die Mühe gelohnt hat und du zu deinem Konzept nicht endgültig "nein" sagen musst!

[herw]

Schön, dass sich die Mühe gelohnt hat und du zu deinem Konzept nicht endgültig "nein" sagen musst!

Danke für's Mitgefühl; es ist alles neu, wenn man die Voice-Verwaltung selbst vornehmen muss. Vielleicht scheitert es ja doch an irgendeiner Sache, aber ich lerne ungemein viel. Bis jetzt scheint es zu funktionieren.

bild_1.jpg

Hier wird eine Quelle abgefragt. Das markierte Makro wird mit SR.C (C) getaktet. Es ist im Prinzip ganz einfach: beim Wert 2 taktet das nachfolgende Makro (Lesen des Arrays S) ebenfalls mit SR.C. Dann können noch die Werte 1 und -1 vorliegen; da die 1 jeweils nur für einen SampleRate-tick anliegt, gibt es auch nur einen Event beim Auslesen. Eigentlich ganz einfach
Das Schreiben in die Arrays ist ähnlich einfach.
Alles hängt im Prinzip nur von einer intelligenten Zuordnung Voice->Index ab.
Es muss jegliche Signalverarbeitung achtfach vorliegen. Das ist vom Konzept her klar, aber eben ohne Training zunächst einmal mühsam. Es fehlt noch die Routine. Ich will auch keinen Fehler machen, bevor ich andere Container erstelle. Da verschiedene Voices verschiedenen Indices zugeordnet werden müssen, möchte ich natürlich möglichst wenig Programmieraufwand treiben; die Zuordnungsroutinen sind ja im Prinzip immer gleich, also gebe ich mir sehr viel Mühe, allgemeine Macros herzustellen. Es geht nur langsam voran.

bild.jpg

Ich kann unbenutzte Container ausschalten. Dazu ist es nötig, dass die SR.C. ausgeschaltet wird. Das funktioniert auch. Unbenutzte Container wechseln die Hintergrundfarbe zu grau

[herw]

ahh - ein Durchbruch:

connections.jpg

Ich habe zunächst den Eingang 7 (das ist in diesem Fall der Gate-Eingang des SCO) probeweise mit dem Ausgang 6 (das ist der MidiPitch-Ausgang des Containers MIDI 1) verbunden und eine Taste gedrückt (Pitchwert 67).
Dann habe ich die Verbindung gelöscht (source=0), es wird wie gewünscht nichts mehr - trotz mehrfachen Tastendrucks - übertragen. Anschließend habe ich den Gateausgang von MIDI 1 (Ausgang 5) verbunden und es wurden die Gate-Events empfangen: perfekt.

panel.jpg

Das war sehr schwer, weil ich mich erst an die neue Denkweise gewöhnen muss. Es gibt viele Fallstricke, da ich immer darauf achten muss, dass bei isolierten Events die Taktung des Typenspeichers T unterbrochen wird. Das war für mich der entscheidende Durchbruch.

[herw]

knapp vorbei geschrammt an einer Katastrophe!
Ich habe den Eingang auf 8 Stimmen erweitert und zur Kontrolle, habe ich alle Stimmen einfach mal addiert, was in der monophonen Version einem Voice-Combiner entspricht. Da es sich ja nur um einfache einzelne Gatevents handelt, habe ich nichts Böses gedacht:

voicecombiner_mono.jpg

Doch beim Verbinden der 5., und 6. Stimme wurde der gelbe compiler-Balken immer länger sichtbar. Da REAKTOR bei jedem Macro-Wechsel wieder neu kompiliert, wurde dies zur Geduldsprobe. Beim Verbinden der 7. Stimme gab REAKTOR ganz seinen Geist auf, bzw. mein Geduldsfaden riss und ich brach zwangsweise ab.
Zuerst dachte ich, dass die Verknüpfung zweier Arrays Probleme machen würde, nach vielen Stunden fand ich die Ursache: durch meine eigene Voice-Verwaltung kommt ACEW wohl nicht mit der Kombination zurecht.
Gut, das ist kein Drama, da ich weiß, dass ohne ACEW alles richtig läuft.

[herw]

nach dieser Aufregung geht es jetzt ruhiger und strukturierter voran:
hier ein Blick in den core-container midi 1:

mx_midi1-bild_1.jpg

noch ist hier nichts endgültig, doch so langsam kommt Struktur in die Struktur. Ich sortiere globale und Stimm-abhängige Applikationen.
Im obersten Makro sieht man die Auswertung der Panelelemente; im Moment nur on/off und Schalter für die Aktivierung des pitchbends.
Der Schalter on/off knippst entsprechende Parameter und die SampleRateClock an und aus. Die Stimmabhängige Applikation app ist natürlich in diesem Fall nur eine einfache Addition für den Pitch-Ausgang.

[herw]

Trotz der klaren (?) Strukturierung kommen immer so „unwichtige” Zweifel, wie man die unterschiedlichen Stimmen verwaltet. Im Moment favorisiere ich die Version, dass man einen Container zunächst monophon plant und dann auf die anderen Stimmen durch Kopieren überträgt.
Es gibt natürlich auch die Alternative, jede Applikation innerhalb eines Containers für acht Stimmen gleichzeitig zu konstruieren, so zum Beispiel für jeden Ausgang eines Containers.
Ich bevorzuge jetzt aber die erste Variante, da sie (vielleicht) zeitsparender ist.
Trotzdem bin ich häufig unschlüssig und überlege tagelang, wie ich es richtig anstelle. Dabei geht viel Zeit drauf - ich hoffe nicht nutzlos.

ciao herw