Kapitel 10: MIDI-Interface
Nun zu einem Kapitel, das eigentlich am Anfang hätte stehen müssen, aber das wäre ein echter Kaltstart geworden, denn die Aufbereitung der eingehenden MIDI-Befehle gehört zu den komplexesten Aufgaben. Neben Master Tune und Modulation müssen das Key Follow eingerichtet, Velocity ein wenig regelbar gemacht und Controller ausgewertet werden, ein VA-Synth braucht unbedingt einen monophonen Modus und Portamento, außerdem benötigen die Module verschiedene Trigger- und Gatesignale, kurz: Ein ganzer Haufen essentieller Funktionen, über die man sich sonst nur wenig Gedanken macht, soll korrekt implementiert werden.
Das MIDI-Interface
Fangen wir mal beim Eingang an. Die Noten durchlaufen zuerst einen Note Range-Begrenzer. Den gibt es als fertiges Modul, aber Noten außerhalb des eingestellten Bereichs werden damit nicht mehr ausgewertet. Wir wollen sie aber trotzdem angezeigt bekommen, also bauen wir das diskret auf und eine numerische Anzeige sowie eine Gate-LED mit ein, die bei Noten außerhalb des Bereichs rot statt grün blinkt. So was kann im Studio-Alltag viel Zeit sparen.
Der Note-Range-Begrenzer
Das Gate beinhaltet Velocity um die Hüllkurvenmodule auszusteuern, aber aus verschiedenen Gründen ist das gar nicht so vorteilhaft. Wir routen das Gate durch ein NOT, um ein einfaches 0-1 Signal zu erhalten.
Noten und Gate durchlaufen dann das Port-Gate-Voice Macro, in dem das Portamento hinzugefügt wird und die verschiedenen Trigger abgeleitet werden. Außerdem werden hier Stimmeninformationen extrahiert.
Das Macro für Gates, Voicing und Portamento
Wir verwenden dafür das MonoGP aus dem Voice Mode (zu finden in der Werksbibliothek), ein absolut geniales Macro, dessen Funktionsweise aber wohl nur der Konstrukteur selbst erklären könnte, es besteht aus recht unorthodox verschalteten Modulen und einer Core Cell. Wer uns das verständlich machen kann, kriegt den Doktorhut in Reaktorologie!
Ein Macro der besonders kniffligen Art: Das MonoGP
Es liefert nicht nur die Grundlage für einen Mono-Mode wie bei einem analogen Monosynth, sondern kann auch die Nummer der aktuellsten gehaltenen Stimme ausgeben. Das habe ich noch ein wenig aufbereitet und gefiltert (die rot markierten Module), da erst mal alle Stimmen durchgerattert werden, bevor die aktuellste übrigbleibt, mit dementsprechendem Rechenbedarf (für tiefere Einblicke in die Event-Datenströme gibt es das „Event History“ in der Bibliothek).
Wir nennen sie Current Voice. Mit anderen Macros werden die First Voice (die Nummer der ersten gespielten von mehreren gehaltenen Noten) und die Newest Voice (die Nummer der letzten gespielten Note) ermittelt. Diese Voice Numbers sind für die nächsten Aufbereitungsschritte unverzichtbar, da Reaktor die eingehenden Noten nicht zyklisch oder hierarchisch vergibt, sondern in Abhängigkeit von der Einstellung in den Instrument Properties nach bestimmten Prioritäten. Ich empfehle Reassign, das verhindert die mehrfache Auslösung einer Note. Aber im Prinzip ist es egal, und keine der Einstellungen hat eine einfach vorhersehbare Stimmenverteilung zur Folge.
Mit der Current Voice kann man nun z.B. Displays aufbauen, die mit From Voice auch im Poly-Mode einen Parameterwert numerisch oder grafisch stimmenaktuell anzeigen, also monophon. Das bauen wir bei allen modulierten Parametern ein, um die Modulationen im Auge zu behalten.
Stimmenaktuelles Display mit Current Voice Selektion
Die Merge/Value-Module dienen als Aktuator, da das From Voice-Modul dazu neigt, Werte zu übersehen, wenn sie nicht gleichzeitig mit der Voice Number eintreffen. Das ist eine Merkwürdigkeit, die ich nie so recht verstanden habe, denn auch wenn der Wert definitiv anliegt, wird er nicht unbedingt weitergegeben.
Hallo Holger,
vielen Dank für deine sehr umfangreiche Reihe über Reaktor. Ich habe bisher nur quer lesen können und einen kurzen Blick in die Struktur geworfen; trotzdem kann man unschwer erkennen, dass viel Arbeit dahinter steckt. Ich werde noch intensiv nachlesen.
Mir ist aufgefallen, dass du an genau den Stellen über REAKTOR Kritik äußerst, an denen es um Event-Verarbeitung geht.
Dies ist kein Wunder, da du, so weit ich das überblicke, ausschließlich auf dem Primary-Level arbeitest.
Hier ist die Reihenfolge der Events nun mal nicht (logisch) gleichzeitig, sondern „nur” sequentiell.
Die Reihenfolge, mit der Events verarbeitet werden, ist hoch komplex und auf der primary-Ebene nur schwer und umständlich zu kontrollieren.
Nicht alles, was logisch hintereinander ausgeführt erscheint, hat auch genau diese Reihenfolge.
Zu unterscheiden sind GUI-events, die völlig unabhängig zu jeder Zeit geschehen, audio-basierte Events (meist getaktet mit 400Hz) und natürlich audio-getaktete events mit sample-Rate 44100Hz z.B.
Wenn man absolute (und eher einfache) Kontrolle über die Reihenfolge von Events haben möchte, muss man meiner Ansicht nach auf die Core-Ebene übergehen.
Nichtsdestotrotz ist dein Ensemble sehr interessant und gibt viel Freiraum für Experimente.
Danke!
herw
@herw Hi herw, Dank zurück für das Feedback. Jep, da steckt die Freizeit von drei Monaten drin…
Für Core-Ebene braucht man solide DSP-Kenntnisse, oder halt viel Einarbeitungszeit. Als eigentlich-Musiker möchte ich da nicht Jahre mit verbringen, und ich denke, viele Andere auch nicht. Das ist eher die Domäne von Programmierern. Wenn man sich die Events mit dem „Event History“ genau anguckt, dann kann man auch auf dem Primary Level gezielt einzelne Daten filtern, verzögern usw. Aber alles kriegt man da nicht gebacken, das stimmt. Umso dankbarer bin ich für Macros wie das „Mono GP“, das hat ein Riesenproblem beseitigt. Und es zeigt, wie knifflig scheinbar einfache Prozesse sein können…
Dann noch viel Spaß beim Lesen, im letzten Teil kommt die Wavetable- und Phase Distortion- Abteilung dran.
kleiner Nachtrag zu den Send-Reiceive-Verbindungen:
dies wird leider ein schon seit Jahren vernachlässigt.
Sie sind vom Konzept her völlig falsch implemetiert, insbesondere das Kopieren liefert keine Kopie, sondern ein Durcheinander in den receive-Listen.
Schade, ein sehr mächtiges Werkzeug wird hier stiefmütterlich behandelt.
So hilft es nur, wie du beschreibst, selbst Hand anzulegen, oder höchste Disziplin beim Kopieren, Einfügen und Nichtlöschen einmal eingesetzter Send-Module.
herw
@herw Immerhin sind die Send/Receive jetzt einigermaßen editierbar, das war in der letzten Version ja eine Katastrophe. Und wenn man das Häkchen entfernt bei „automatic use of new sends“, dann klappt auch das Kopieren. Bleibt zu hoffen, dass NI das noch verbessert und weiterentwickelt, so dass man auch Events zusammen mit Audio damit routen kann, ohne den Overload zu verursachen.