der MODULAR

[herw]

macht Spaß

X1-01.jpg

[herw]

Man muss sich Zeit lassen; mir fallen immer wieder andere haptische Aspekte ein. Den Midi-Container werde ich auch nochmals überarbeiten müssen

X1-02.jpg

ein Lust-Gefühl nach plug'n'play kommt schon auf

X1-03.jpg

[Illya F.]

Hey, sieht doch schick aus und du bist da ja schon richtig weit mit dem Teil.

Ich bin gerade dabei alle meine Rechner, bis auf den Hauptrechner, auf ein anderes Betriebsystem umzustellen und habe von daher nicht so richtig den Kopf frei für Reaktor.

Was mir aber noch von vor ein paar Tagen hängen geblieben ist bez. dem Modular:
Ich bastelte vor Wochen an dem keyscaling von Parametern per Event-Tabel. Vorteil: Man kann so unterschiedliche Werte eines Parameters pro Taste auf der Klaviatur haben. Man kann das natürlich auch übertreiben und für jedweden Parameter umsetzten, so dass man dann den gesammten Satz an Parametern eines Synth. pro Taste hat (Drum Mode), aber das kann dann ja jeder für sich selbst realisieren. Mir geht es nur darum, das auch in den Modular hier hinein zu bringen.
Für polyphon spielbare Klänge, nebst Leuten die gerne auch beidhändig spielen, ist das auch sinnvoll. Beispiel: Unten auf der Klaviatur soll es mehr nach düsterer vor sich hin grummelnder Fläche klingen und über den weiteren Verlauf nach oben hin aber bitte ein glitzernder Noise-Choir mit Gebimmel im Gepäck werden, mit anderen Hüllkurvenzeiten versteht sich. Alles geht so nicht, aber man kann sich dabei den ein oder anderen Layer sparen.

Problem:
So ein Modul geht natürlich in die Breite. Von meinen letzten Experimenten in die Richtung kann ich momentan nur sagen, dass es, je nachdem wieviel Oktaven man da nun abdecken will, schon so breit wie dein X1-03 Bild da oben werden kann. 2 Tables ließen sich da von der Höhe her aber sicher unterbringen, wenn es bedienbar bleiben soll, zuzüglich ein paar Reglern, Buttons und einem Textfeld in das man dann noch hinein schreibt was man da gerade mit steuert. Letzeres ist deshalb sinnvoll, weil man diese Module wohl eher außerhalb des sichtbaren Bereiches parken wird und man auch gerne ohne den Kabeln nachzugehen wissen will, welches von den eventuel 5. E-Table Modulen nun was steuert (Wie bei einem (virtuellen) Mischpult. Da will man ja auch noch nächsten Tag wissen, welches Signal an welchem Kanalzug anliegt.)

Das war es auch schon. Momentan bin ich, wie oben schon gesagt, anderweitig beschäftigt. Bei mir ist das auch keine Sache von 1-2 Stunden so etwas zu basteln, da ich mit den Tables immer noch ein wenig auf Kriegsfuß stehe (funktionieren tut es natürlich, aber es soll dann ja auch simple nutzbar sein). Wenn das keiner machen will, dann werde ich das demnächst, wenn du den Modular freigibst und ich mit meinem Kram hier fertig bin, gerne angehen, denn ich brauche das für zukünftige basteleien eh.

Gruß,
Illya

[herw]

Wenn ich das richtig verstehe, dann meinst Du keytracking, egal ob für die Hüllkurve oder einen Filter oder sonst etwas eingesetzt. Geht das nicht mit einem Rechenausdruck, der Pitch-abhängig die Parameter ändert? Das wäre doch einfacher, als für jeden einzelnen Ton sich einzelne Werte auszudenken und in eine Table zu schreiben?
Ich bin für alle Vorschläge offen; noch gibt es die Gelegenheit, Einfluss zu nehmen - nee ohne Scherz, das System ist so angelegt, dass man beliebige Größen für Container erstellen kann; Parameter-verstecken sollte allerdings durch einen gescheiten Algorithmus ersetzt werden, der eine globale Steuerung ermöglicht.
Es ist gut, wenn einige hier mal Vorschläge und Kritik machen. Schließlich soll es ein Projekt für die ganze REAKTOR-Gemeinde sein. Ich geb' mir alle Mühe, dass es gut wird.

ciao herw

[Illya F.]

Geht das nicht mit einem Rechenausdruck, der Pitch-abhängig die Parameter ändert? Das wäre doch einfacher, als für jeden einzelnen Ton sich einzelne Werte auszudenken und in eine Table zu schreiben?

Ich bevorzug es mal eben mit der Maus den Parameterverlauf den ich haben will einzuzeichnen. Wenn du so einen Verlauf (siehe Bild unten) in eine Funktion gießen willst und das dann für einen ganz anderen Verlauf beim nächsten mal alles mühsam neu berechnen willst, dann tue das. Ich brauche mit der Maus dafür nur ein paar Sekunden und ein wenig länger für die Feinarbeit. Es hindert einen auch keiner ein paar Presets in den Tables zu haben, also für lin. log. u. exp. Verläufe, ist ja kein Ding und die brauch man ja auch, nur eben nicht ständig, deshalb ist das mit der Maus einzeichnen sinnvoll.

Hier das Bild. Ich habe zur Veranschaulichung einmal eine Klaviatur darunter gebastelt, die macht so natürlich noch nicht viel Sinn, aber so versteht man das besser denke ich. Wer damit nichts anfangen kann und das nicht braucht, muss sich da ja keinen Kopf machen. Ich jedenfalls werde mir das für den Modular genau so als Modul basteln. Wie man hier auch sieht, ist X dabei die Notennummer und Y der Wert.

keysc_2.jpg

Ach so, fang jetzt aber nicht extra an so etwas zu basteln, weil das kann dann ja der Rest der Leute auch selber machen. Würde da jetzt keine Zeit drauf vergeuden, sondern nur die normalen Mudule zu Verfügung stellen. Dann können wir anderen auch schneller loslegen und unsere Ideen da selbst einbauen. Spart Zeit und desto früher können wir dann auch selber loslegen und schauen ob die eigenen Ideen umsetzbar sind. Freue mich auch schon richtig darauf. Sag mal, eigentlich bist du doch schon fertig, oder?

Gruß, die Kaffeesch.....

Überhaupt, wo ist denn Peter? Der hätte doch bestimmt auch noch einiges beizusteuern.

[herw]

Ja das ist natürlich etwas anderes, ich hatte eher an einen gleichmäßigen linearen oder exponentiellen Verlauf gedacht.
Eine Integration in den Modular ist natürlich machbar, nimmt aber viel Platz weg, aber natürlich möglich, da man nicht auf bestimmte Modulgrößen festgelegt ist.

Die Abbildungen in den vergangenen Posts sind nur Entwürfe; da klingt noch nichts. Damit fange ich erst in den nächsten Tagen an. Ich denke aber bis zum Ende des Monats eine klingende Version fertig zu haben.
Ich hoffe, möglichst viel aus den alten Versionen übernehmen zu können. Hauptneuerung wird bei den Containern sein, dass sich alle Panelelemente einen Eventbus teilen. Dies muss nicht so sein, ist aber für mich ein zusätzlicher Anreiz. Einfachste Verkabelung ist die Maxime.

ciao herw

[herw]

[midi 01]

Das erste Modul, um das ich mich immer wieder gedrückt habe. Ich war nie zufrieden über die Auswahl der Midiinformationen, die ich ausgewählt hatte. Polyphoner Aftertouch und Velocity werden in der Basisversion nur von wenigen genutzt. Viel wichtiger sind Portamento und mono/poly.
Ich habe zwar immer nach dem Modul von James Walker Hall geschielt, doch ist das so komplex aufgebaut, dass ich mich nicht daran traute, entsprechende Vereinfachungen zu machen. Schließlich bin ich aber in der Building-Block-Library fündig geworden
Ich habe die Panelelemente neu arrangiert. Ich musste auch mit Knobman einige Skins neu herstellen: die Ein- und Ausgangsbuchsen, Buttons und Switches, damit der Stil einheitlich ist.
Um die Übertragung der Panelevents zur eigentlichen Applikation brauche ich mich nun nicht mehr zu kümmern, da der Eventbus ja schon vorbereitet ist. Die Adressen der Panelelemente werden automatisch vergeben. Egal wie viele oder welche Panelelemente man verwendet; alle werden einfach an den Multiplexer angeschlossen.

X1-04.jpg

[herw]

Übersichtlichkeit ist Trumpf!

X1-05.jpg

Hier sieht man den (roten) Bereich, um den man sich kümmern muss, wenn man eine eigene Applikation schreiben möchte. Die Panelelemente wurden hier über einen Eventbus zugeführt. Das muss nicht unbedingt sein, hilft aber in der Übersicht.

X1-06.jpg

Das Makro {e} receive empfängt die Busdaten und verteilt sie an isolierte Ausgänge; die Werte werden dann verarbeitet und schließlich wieder nach außen an die send-Module übergeben. Das Makro (m3) soft switch ist übrigens ein Core-Esatz für einen primary Mehrfach-Switch. Er wird nur durch einen Event gesteuert. Somit wird kein Reset ausgeführt.

X1-07.jpg

So sieht der fertige Container nun aus. Ein Funktionstest konnte natürlich nur teilweise durchgeführt werden, da ja weitere Container noch fehlen. Aber ich bin guter Zuversicht, dass es wie geplant funktioniert.
Die Buchsen und Buttons musste ich nochmals überarbeiten, da REAKTOR leider skins nicht einheitlich im Panel anordnet. So liegen die skins der Buttons um zwei Pixel weiter links als die skins für alle anderen Panelelemente (switches, picture, multipicture). Das ist ärgerlich, da ich nun zwei skins mit demselben Inhalt verwalten muss. Zumindest hat sich die Mühe gelohnt, da ich alle Elemente ja nur einmal erstellen musste und nun wiederverwerten kann.

[herw]

Heute habe ich mir ein schwieriges Modul vorgenommen, einen Oszillator. Hier musste ich noch einen zyklischen Schalter realsieren, der auf Events zyklisch die Wellenformen durchsteppt. Die Umschaltung erfolgt wieder durch einen soft-switch.
So sieht's aus:

SCO 01.jpg

Der Platz war wirklich sehr knapp.

[herw]

X1-08.jpg

[herw]

und nun der Test auf plug&play:

X1-09.jpg

es dauert 29 Sekunden, um ein vergrößertes, sofort spielbares Ensemble zu schaffen!

Es lebe Plug & Play!
Alles klappt wie geplant. Ich musste nur vier Strippen in der Struktur ziehen und die zusätzlichen Container an den rechten Platz rücken.

ciao herw

[verstaerker]

kann man das Teil egtl irgendwie ausprobieren?

[herw]

kann man das Teil egtl irgendwie ausprobieren?

nein, im Moment ist mir das noch zu früh; da der User sehr viele Freiheiten haben soll und einfachste Bedienung angesagt ist, muss ich extremste Nutzung ausprobieren und sofort jeweils korrigieren.
Ein kleines Beispiel: wie du dem gezeigten mini-Ensemble entnehmen kannst, besitzt es nur 20 Eingänge. Ein offenes System kennt die Zahl der gewählten Eingänge nicht. Das ist noch kein Problem, da die Zahl automatisch berechnet wird. Das Snapvalue-array-Modul muss dagegen für sehr viele Eingänge vorbereitet sein (bis zu 1024). Es ist nicht klar zum Beispiel, was mit den Werten geschieht, die nicht direkt abgespeichert wurden. Das muss ich erforschen, insbesondere die self-Iteration; ein Betatest ist da noch zu früh.
Ich denke, dass ich das Ende des Jahres für eine Veröffentlichung vorsehe.

ciao herw

[herw]

kann man das Teil egtl irgendwie ausprobieren?

nein, im Moment ist mir das noch zu früh; da der User sehr viele Freiheiten haben soll und einfachste Bedienung angesagt ist, muss ich extremste Nutzung ausprobieren und sofort jeweils korrigieren.
Ein kleines Beispiel: wie du dem gezeigten mini-Ensemble entnehmen kannst, besitzt es nur 20 Eingänge. Ein offenes System kennt die Zahl der gewählten Eingänge. Das ist noch kein Problem, da die Zahl automatisch berechnet wird. Das Snapvalue-array-Modul muss dagegen für sehr viele Eingänge vorbereitet sein (bis zu 1024). Es ist nicht klar zum Beispiel, was mit den Werten geschieht, die nicht direkt abgespeichert wurden. Das muss ich erforschen, insbesondere die self-Iteration; ein Betatest ist da noch zu früh.
Ich denke, dass ich das Ende des Jahres für eine Veröffentlichung vorsehe.

ciao herw

Dieses „kleine” Problem hat mich ungefähr zehn Stunden Forschung gekostet.
Das Problem tauchte auf, wenn durch snapshot-Wechsel das Multidisplay wieder aufgefrischt wurde. Es zeigte sich, dass zwar alle Daten (über 8000!) korrekt ausgegeben, jedoch über den Verbindungsbus zwischen Snapvalue array und Multidisplay nicht korrekt übertragen wurden.
Allein diese Fehlerquelle zu entdecken, hat mehrere Stunden gedauert. Wie will man 8000 Daten verfolgen? Auch der Eventwatcher kommt da an seine Grenzen, da er nur eine Zwischenspeicherungen macht; das EventHistory-Makro ist dort besser.
8000 Daten kann niemand recht verfolgen. Also habe ich die Datenanzahl extrem verkleinert und schließlich die Fehlerquelle gefunden.
Dann wiederum einige Stunden des Herumexperimetierens, Vergleiche mit dem modular m1 (der in dieser Hinsicht perfekt funktioniert) und dann Erkennen der eigentlichen Ursache.
Die Lösung ist dann (wie immer) völlig einfach gewesen; sowohl die Datenmenge (von 8000 auf 44!!!, also keine Redundanz, nur veränderte Daten werden übertragen) konnte ich reduzieren, als auch die Ensemblestruktur vereinfachen. Manchmal ist mein Sicherheitsdenken bzgl. der Datenübertragung einfach zu übertrieben. Reaktor macht schon alles richtig (ich staune darüber immer wieder).

Jetzt kann es weitergehen
ich bin knapp zwei Wochen vor dem Zeitlan.

[herw]

Hier mal ein kleiner akustischer Eindruck ; die Klänge wurden nur mit dem oben abgebildeten Modular erzeugt.

01.mp3.zip

02.mp3.zip

noch nix Besonderes, aber für mich eine kleine Unterbrechung

ciao herw