MODULAR X Netzwerk

[herw]

puhh - das ist alles viel schwieriger als gedacht. Zum Beispiel arbeite ich (immer noch) an dem MIDI Container. Er stellt sich als richtig bockig dar; allerdings nicht im wirklichen Sinn, nur dass ich erst langsam hinter die eigentlichen Abläufe schaue.
Nachdem der poly-Modus völlig klaglos arbeitet, erstelle ich nun den mono-Modus. Er ist eigentlich identisch mit dem unisono-Modus, da ich im mono-Modus alle acht Stimmen parallel mit denselben Werten laufen lasse. Der unisono-Modus verstimmt lediglich den Pitch.
Ich muss für den mono-Modus verschiedene Varianten parat halten (ähnlich denen im MONARK). Dazu ist es zum Beispiel nötig das pitch-Maximum (oder -Minimum) aller Stimmen zu bestimmen. Dies geschieht durch einen getriggerten Vergleich. Dieser gemeinsame Trigger hat mich glatt 10 Stunden genervt, bis ich es endlich soweit hatte, dass trotz mehrerer gleichzeitg gedrückter Tasten und gemischtem Loslassen immer das aktuelle pitch-Maximum berechnet wird:

pitch_max.jpg

Man sieht im ACEW für die Eventnummern 1-9, dass ich einen Dreiklang greife. Nun lasse ich die mittlere Taste los (voice 4); es wird das Maximum unverändert gehalten. Danach lasse ich die oberste taste los, es wird das neue Maximum berechnet, das ist in diesem Fall der niedrigste Ton. Schließlich lasse ich auch die letzte Taste los, der Maximumwert ist 0.

Ohne ACEW hätte ich das alles niemals durchschaut, da ich ja in einer audio Corecell arbeite und singuläre events analysieren muss.
Dank an Mark und Gerald!

[herw]

Nach einer fast dreimonatigen Schaffenspause traue ich mich mal wieder an mein Projekt. Ein Grund der langen Pause war, dass ich starke Zweifel am monophonen Konzept habe. Faszinierend ist es, das eigene Voicemanagement unter Kontrolle zu haben. Andererseits scheue ich aber auch die lange Entwicklungszeit aller weiteren Container. Der Sinn des monophonen Ansatzes war, alle Audiosignal-Verarbeitungen in einer einzigen AudioCoreCell unterzubringen. Dies umfasst sowohl die polyphonen Signale, wie auch die monophonen Effektsignale. Der Vorteil ist, dass dann auch Feedbackschleifen möglich sind. Auch voice-Vertauschungen wären zu realisieren. Andererseits ist der Nutzen nun auch nicht wieder so groß. Damit das Projekt nicht wegen Unüberschaubarkeit im Sande verläuft, habe ich mich entschlossen, doch eine polyphone und eine monophone CoreCell zu benutzen. Das Konzept ist schon erprobt; falls mal REAKTOR 7 in Core monophone, wie auch polyphone Signale unterscheiden kann, werde ich das Konzept wieder aufgreifen.
Ich denke, dass mein Ansatz einfach zu unhandlich ist. In den meisten Fällen müsste ich umständlich immer jede Quelle mehrfach parallel verwalten. Der Nutzen ist eher gering.
So bin auch auch von der Anzahl der Stimmen unabhängig.

Ich hoffe, dass ich jetzt wieder einen Schub ins Projekt bekomme

ciao herw

[Eventmanager]

Ich denke, dass mein Ansatz einfach zu unhandlich ist.

Ich zumindest präferiere GUI vor Featuritis.

Ich denke, du hast den beeindruckensten Synth der Weltgeschichte geschaffen.
"Beeindruckend" läuft in vielen Sprachen synonym zu "furcht-" zumindest zu "respekteinflössend".
Man rennt nicht 14 km in den Dschungel um einen Säbelzahntiger zu erledigen, wenn man innerhalb hundert Meter einen Elch finden kann. Es sei denn man "WEISS" das das Säbeltiger-FLeisch exorbitante Kräfte verleiht! Der Geschmack allein zaubert nur bei den Wenigsten eine Nutzen/Risiko Bilanz hervor, die den Vernunft-Einflüsterungen widersteht.

Ein monophoner Synth mit 4 Millionen Knöpfen - man muss schon sehr, sehr puristisch sein um da freiwillig ne Extrarunde zu drehen.

Ich gehör zu den Menschen die solche goldenen Kälber gerne schlachten um die Filets in eigener Sülze zu verarbeiten, aber selbst ich schreck zurück: Das Ding ist ZUUUUUU beeindruckend.

Die gute Nachricht ist: Niemand wagt sich an ein Monster, aber Monster-Kralle, Monster-Finger, Monster-Rippe.... steht alles ganz, ganz weit oben auf dem Delikatessen-Plan.

[herw]

Ich denke, dass mein Ansatz einfach zu unhandlich ist.

Ich zumindest präferiere GUI vor Featuritis.

Ich denke, du hast den beeindruckensten Synth der Weltgeschichte geschaffen.
"Beeindruckend" läuft in vielen Sprachen synonym zu "furcht-" zumindest zu "respekteinflössend".
Man rennt nicht 14 km in den Dschungel um einen Säbelzahntiger zu erledigen, wenn man innerhalb hundert Meter einen Elch finden kann. Es sei denn man "WEISS" das das Säbeltiger-FLeisch exorbitante Kräfte verleiht! Der Geschmack allein zaubert nur bei den Wenigsten eine Nutzen/Risiko Bilanz hervor, die den Vernunft-Einflüsterungen widersteht.

Ein monophoner Synth mit 4 Millionen Knöpfen - man muss schon sehr, sehr puristisch sein um da freiwillig ne Extrarunde zu drehen.

Ich gehör zu den Menschen die solche goldenen Kälber gerne schlachten um die Filets in eigener Sülze zu verarbeiten, aber selbst ich schreck zurück: Das Ding ist ZUUUUUU beeindruckend.

Die gute Nachricht ist: Niemand wagt sich an ein Monster, aber Monster-Kralle, Monster-Finger, Monster-Rippe.... steht alles ganz, ganz weit oben auf dem Delikatessen-Plan.

Das Witzige an meiner ursprünglichen Idee des Modulars war, dass ich es leid war, für neue Ensemble-Konzepte immer einen neuen Versuchsaufbau zu erstellen. Eigentlich wollte ich sehr viele kleine spezielle Ensembles entwickeln, die für ganz bestimmte Klangfarben, - effekte oder Spezialaufgaben eingerichtet sind (Gitarrenklang, Orgel, Piano etc.).
Der Modular sollte eigentlich nur eine Testumgebung für mich persönlich sein.

[Eventmanager]

Der Modular sollte eigentlich nur eine Testumgebung für mich persönlich sein.

[Quietschboy]

Hehe, mangels Band wollte ich für mich und meinen Kumpel nur mal eben schnell einen kleinen Looper basteln, damit wir uns selbst begleiten können.
Das fünfte Jahr Entwicklungszeit ist gerade angebrochen.....

[herw]

Endlich habe ich wieder den Einstig und etwas Zeit gefunden. Die Initialisierung der polyphonen und monophonen core-Container steht.
Nun geht es an die ersten Signalverarbeitungen. Ich muss den Eventbus von Max Zagler erweitern (siehe in Max' Skript „event blocks and the {b} event bus” Seite 53ff). Ich führe so genannte indizierte Nachrichten ein. Wenn man es mathematisch beschreiben will, so handelt es sich eigentlich um doppelt indizierte Nachrichten. Ein einfaches Beispiel ist der Control-Container, der unter anderem die Transparenz und die Farbe der Kabel steuert. Jede Transparenzänderung wurde bisher über IC-send-receive-Verknüpfungen übertragen. Jetzt geht es konsequent über den gemeinsamen Bus {b}. Hier wird fast jede monophone Event-Information übertragen (es gibt auch einen polyphonen Eventbus für MIDI).
Man könnte natürlich jegliche Änderung eines Panelelements des Control-Containers immer wieder mit allen anderen Parametern gemeinsam übertragen. Ich will aber nur einzelne Events senden. Das Beispiel Transparenz-Farbe erscheint mir einfach genug, um Erfahrung zu sammeln.
Eine Nachricht besteht zunächst mal aus dem Identifier (hier -3), dem Hauptindex. Er routet auf der Empfängerseite die folgende Nachricht in den passenden Core-Container. Dann muss die Anzahl der folgenden Event genannt werden. Die dritte Komponente ist der Eventtyp t (z.B. 0 für Transparenz und 1 für Farbe) und schließlich der eigentliche Wert.
Wenn ich also die Transparenz auf 40% setzen möchte, lautet die Nachricht (-3|2|0|0,4). Setze ich die Farbe auf lila (Farbe 5), so würde ich (-3|2|1|5) senden. Es liegt keine Redundanz vor, da ich sonst immer wieder die Werte für Transparenz und Farbe senden müsste. Die reine Werteabfrage wäre etwas einfacher, aber ich müsste im weiteren Verlauf erkennen, welche Änderung nun wirklich stattgefunden hat.

ind_message.jpg

Bei vielen Parametern ist dieser Ansatz noch praktischer. Entscheidend ist, dass ich sehr viele Event-Nachrichten über einen einzigen Bus senden kann, egal wie komplex und vielfältig die Events strukturert sind.

ciao herw

[herw]

auf der Empfangsseite nehme ich das Makro message type select zusammen mit einem Router:

type_select.jpg

(siehe in Max' Skript „event blocks and the {b} event bus” Seite 54)
Ich habe es auf die beiden Ausgabeparameter T (Typ) und Wert $ reduziert.

[herw]

hier ist mal ein Beispiel einer polyphonen Nachricht, in diesem Fall die Übertragung von MIDI-pitch und MIDI-gate:

polyphone_nachricht_4.jpg

polyphone_nachricht_1.jpg

Innerhalb des {e}-mux muss ich durch den Index [] die zusätzlichen Parameter C# und # triggern.

polyphone_nachricht_3.jpg

die Nachricht wird trotz der Gleichzeitigkeit von pitch- und gate-event einwandfrei übertragen:

polyphone_nachricht_2.jpg

[herw]

Ich habe die Eventquellen um 1 verschoben, um einen „toten” event in der Zelle 0 zu bekommen.

bild1.jpg

Zur Kontrolle und um wieder in die Materie hineinzukommen, kontrolliere ich die ankommenden events in der AudioCoreCell (ich nenne sie vorerst SYSTEM):

bild2.jpg

Ich habe vorübergehend zwei Ausgänge hinausgelegt. Dort werden die Daten der beiden Arrays T und S an den ACEW übergeben. Siehe hierzu die Post vom 9.8.2014! Das hat mich zwei Tage gekostet, um die ganze Systematik wieder nachzuvollziehen.
Da mir und vielleicht auch dem ein oder anderen Leser die Funktionsweise, wie man Events aus einer AudioCoreCell hinausbekommt, nicht geläufig ist, schreibe ich es hier nochmals auf:
Die beiden Datenausgänge werden an das Core-Makro ACEW 2.0 Core 4P übergeben. Dieses Makro übergibt die Daten in einem Bus an die drei notwendigen Audioausgänge, um einen Eventausgang zu emulieren.

bild3.jpg

Außen wird dann in der primary-Ebene an das Makro ACEW 2.0 for ACC 4P übergeben.

bild4.jpg

[herw]

Nun zur eigentlichen Analyse. Wie schon oben erwähnt, werden die Systemdaten mit dem Bus {-6} übertragen und gelangen über ein raw-receive-gate-Makro in die CoreCell:

bild5.jpg

So sieht's dort im Innern aus:

bild6.jpg

Das Makro message type select (partials framework) habe ich im Gegensatz zum Original von unnötigen Ausgängen befreit. Alle Systemdaten stehen mir am Router zur Verfügung.
Diese Daten sollen nun in das Array S geschrieben werden. Als Beispiel nehme ich mal den Midipitch. Er soll im Feld S[1] zu Verfügung stehen.

bild7.jpg

Das entspricht in meinem bisherigen modular framework den primary-send-Modulen.
Damit ich später einzelne (primary-) Events und Audioevents unterscheiden kann, muss ich gleichzeitig den Datentyp an das Feld T übergeben:

bild8.jpg

[herw]

Das Makro single event type war ja eine spannende Sache. Wie rufe ich in einer AudioCoreCell aus einem Array automatisch (primary-) Events ab?
Wir sehen beim letzten Bild, dass das Makro zwei Eingänge besitzt, die SR-Clock und den eigentlichen Event.

bild9.jpg

Der Event übergibt den Wert 1, die Clock jeweils -1. Beim Auslesen wird später nur beim Typ T=1 ein Wert ausgegeben.
Ich teste das mal, indem ich über den MidiPitch-Trigger die Werte aus den beiden Arrays ablese:

bild10.jpg

Sieht gut aus:

bild11.jpg

Ich drücke auf dem Keyboard die Tasten Q, W und E; das entspricht den Pitchwerten 60, 62 und 64. Sie werden asynchron zur SampleRateClock empfangen („state” ich nicht gelb gekennzeichnet) und das Array T erhält synchron zur SampleRateClock die Events 1 und -1.

aber ...

Natürlich ist nicht gedacht, dass mit einem midipitch-Wert getriggert wird; der Speicherinhalt muss selbständig ausgegeben werden.
Daher dient diese Triggerung nur, um das Problem sichtbar zu machen. Mir ist auch nicht klar, ob durch sequentielle Anordnung und durch die modulare Verknüpfung es zu eventloops kommen kann.
Ich drücke nun nach der Initialisierung (pitch=0) wiederum die Tasten Q, W und E und siehe da, es ergibt sich erstaunliches:

bild12.jpg

Beim Drücken von Q wird nicht der Wert 60 bergeben, sondern der vorhergehende, bei den nachfolgenden Tasten entsprechend: Problem!
Das liegt an der Art, wie die Arrays verknüpft sind, nämlich sternförmig und nicht seriell.
Würde man seriell verknüpfen, ...

bild13.jpg

dann erhält man den aktuellen Wert:

bild14.jpg

Mir ist zu diesem Zeitpunkt nicht klar, ob man das beim modularen Aufbau konsequent durchhalten könnte, daher habe ich die sternförmige Anordnung gewählt und wir schauen nun auf die Lösung, die das Auslesen der Daten allein durch Triggerung durch das Feld T durchführt.

[herw]

Man kann sich diese nachträgliche Ausgabe auch nützlich machen, indem man das Feld T direkt triggern lässt; auch das Feld T gibt zu nächst den alten Wert aus (also -1), daher gelangt nun der midipitch-Trigger nicht zum Feld S!

bild15.jpg

man erhält nur noch die Werte mit der SampleRate-Clock

bild16.jpg

So geschieht es auch in der endgültigen Fassung. Um den Originalevent ebenfalls anzuzeigen, habe ich den direkten midi-Event zusätzlich eingefügt:

bild17.jpg

Man erkennt nun sehr schön, wie zunächst der asynchrone Originalwert ausgegeben wird und anschließend der SR-Clock-synchrone Wert:

bild18.jpg

Der Wert bei T=-1 wird unterdrückt, so dass auch tatsächlich nur ein Event ausgegeben wird.
Damit wird das primary-receive-Modul emuliert.
Im Innern des Makros input wird geichzeitig auch ein Audiosignal (für T=2) abgearbeitet:

bild19.jpg

Die Makros output und input sind nun für jegliche Eventquellen vorbereitet, so dass ich sie universell einsetzen kann.
Ich schreibe nun zunächst nur die pitch-, gate- und pitchbend-Werte in das Feld. Zum Testen reicht das, später ergänze ich andere Systemdaten.

[herw]

und so sieht die Endfassung aus

bild20.jpg

und hier die synchrone Ausgabe von Pitch- und Gate-Werten

bild21.jpg

und das Ganze klappt auch polyphon.
Ich bin sehr zufrieden mit meinem heutigen Werk

[herw]

puuhh, was für ein Tag. Heute habe ich mir richtig viel Zeit genommen (letzter Ferientag) und etwa 16 Stunden am Stück gearbeitet.
Ein kleines Testensemble mit MIDI, ADSR und SCO funtioniert. Es gab einige Krücken zu bewältigen. Mark (Quietschboy) hat mich durch Diskussionsbeträge angespornt, so dass ich die Kondition aufbringen konnte. Mir ist noch nicht kar, ob es ein Vorteil ist, die Signalverarbeitung in zwei CoreCells unterzubringen. Aber ich denke nicht, dass es ausufert. Ich bin sehr froh, dass mein neues Konzept wirklich funktioniert. Ich musste im Midi-Container sogar Einzelevents und Audioevents mischen, ganz wie es die send-receive-Verknüpfungen im primary auch beherrschen.
Übrigens zeigt der CPU-Verbrauch in REAKTOR 5.9.2 etwas mehr als in den alten Versionen an. Die Eventverarbeitung wird nun stärker mit berücksichtigt (der gelbe Balken beim Compilieren). Manche Ensembles kommen dabei wohl ins Schleudern, wie ich im BetatesterTeam höre.
Naja egal, wohl nicht mein Problem.

ueberblick.jpg

sieht doch niedlich und harmlos aus ?
jetzt brauche ich eine große Mütze Schlaf!

ciao herw