MvK Monokl

[MvKeinen]

monokl.jpg

MvK Monokl:

Hier will ich mein neues Projekt beschreiben. Seit 3 Jahren arbeite ich kontinuierlich daran und nun bin ich an einem Punkt angelangt an dem ich ein paar Techniken vorstellen kann.

Der Name:

- soll an ein Monokel erinnern. Ein einzelnes Brillenglass, welches dazu geeignet ist tief in die Struktur der Dinge zu blicken. Es soll verdeutlichen, dass mit dem Synthesizer ein sehr genaues Arbeiten möglich sein soll, bei dem der visuelle Aspekt (graphisches Feedback) sehr wichtig ist.
- MONO: Für mich ist Monophonie nicht per se eine musikalische Begrenzung. Meine persönliche Erfahrung als praktizierender Musiker hat oft gezeigt, dass Beschränkungen von Funktionalität oft die Kreativität unterstützen kann. Der synth soll eine einzige Monophone Struktur bieten, die mit der genialen Reaktorpolyphonie vervielfacht werden soll. So sollen dann je nach CPU mehrere Monophone Synthesizer spielbar sein. Mein Ziel ist es 6 synthesizer paralell zu betreiben.

Geschichte:

meine ersten paar Jahre mit Reaktor (seit R4) bestanden vor allem daraus planlos unzählige Oscs miteinander zu verschalten und so interessante Klänge zu erzeugen. Und ein mittelmäßig geübter Reaktorbauer kann tatsächlich innerhalb weniger Minuten ein paar Primarymodule zusammenschustern und wirklich tolle Klänge hervorbringen. Doch wenn es darum geht ein Musikinstrument zu entwickeln so kommt man schnell an den Punkt der einen zwingt sehr sehr viel nachzudenken.

Schnell bin ich dann an den Punkt gekommen an das Panel vor lauter Elementen nicht mal mehr auf einen damals 19" Monitor passten. Nicht nur deswegen wurde das alles muikalisch unbrauchbar.

So kam dann schnell die Idee eigene Bedienelemente zu entwickeln die
1. Platz sparen
2. Funtionalitäten bieten, die mit Standartelementen nicht erreichbar sind. (Drag and Drop)

verbunden mit dem DRY-Prinzip (Dont repeat yourself) ist dann lansam die Grundlage für ein GUI-Framework für Reaktor Core entstanden. Hier werden ähnliche Bedienelemente als Subroutine behandelt die Jeweils mit einem Charakteristischen Datensatz versorgt werden. So gibt es für alle Fader zB im Graphische output und in der Audioengine nur ein einziges Macro egal ob er nun 10mal oder 478mal aufgerufen wird.
Weiterhin sollen sämtliche Modulationen sichtbar sein. Nicht nur dort wo sie entsehen (im falle eines LFOs im LFO container) sondern auch dort, wo die Modulation wirkt (am Fader) Der Datensatz der Drag and Drop Zelle beinhaltet auch die Farbe der Modulationsquelle die dann an der Fader übergeben wird. Dies kann man als Modulationsmatrix bezeichnen.

In den nächsten Tagen werde ich als erstes die grundlegenden Techniken dieser Modulationsmatrix vorstellen.

Im allgemeinen werde ich diesen Thread wirklich langsam aufbauen, da ich immernoch am Grundsystem arbeite.

Zur Organisation:
Ich werde dieses erste Posting immerwieder editieren, weil hier auch eine Art Legende und Gliederung einfügen will. In vielen Foren ist die Zeit in der man ein Posting editieren kann begrenzt. Ich hab mal versucht, ein sehr altes Posting aus einem anderen Thread zu editieren und das funktioniert. Es scheint hier also keine derartige Begrenzung zu geben. Ich hoffe, dass dies nicht geändert wird.

[herw]

[...]
Ich werde dieses erste Posting immerwieder editieren, weil hier auch eine Art Legende und Gliederung einfügen will. In vielen Foren ist die Zeit in der man ein Posting editieren kann begrenzt. Ich hab mal versucht, ein sehr altes Posting aus einem anderen Thread zu editieren und das funktioniert. Es scheint hier also keine derartige Begrenzung zu geben. Ich hoffe, dass dies nicht geändert wird.

Habe ich auch noch nicht gewusst, ich dachte ich als der mächtige Moderator hätte dieses Vorrecht allein
Nachträgliches Editieren aber bitte sehr beschränkt halten (nur bei Übersichten).
Ich bin gespannt!
und bitte ganz viel

ciao herw

[MvKeinen]

Als erstes möchte ich mal zeigen wie ich informationen aus der Audioengine im Multidisplay darstelle. Da ich schon etwas länger nicht mehr an diesem Teilbereich gearbeitet habe könnte es sein, dass es noch Verbesserungsmöglichkeiten gibt. Auch werden in der Gesamtversion noch einige Dinge anders sein, da ich die Werte der Modulationen mit der Chain Iteration von Max Zagler auslesen werde. Dies ist nötig, weil ich die informationen der GUI mit einbeziehen muss. Das alles ist aber in dieser Version nicht implementiert, damit das Prinzip klarer rauskommt und verständlicher ist.

modmux.jpg

in der engine befinden sich 16 LFOs. Ich wollte nicht 16 fader für die frequenz einfügen, daher gibt es nur einen und einen "spread" regler, der jeden LFO um den eingestellten Wert gegenüber dem linken Nachbar verschnellert. Das nur, damit man sieht, dass es sich tatsächlich um verschiedene LFOs handelt. mit rst lassen sich mittels Global reset alle lfos bei -1 neu starten.

engine.jpg

alle LFOs schreiben Ihren Wert in das [md] array. Im macro "mod mux" werden nun die daten erzeugt, die ich für die Wandlung der Audiodaten in eventsignale benötige.

1. ein Trigger für das "A to E trig"
hier brauche ich pro diplayclock # x 2 events jeweils 0 und 1 abwechselnd. Wobei # die anzahl der Modulationen ist. Im gelben Rahmen "Buffer" ist eine Schaltung die das "range" macro versorgt, welches wiederum den Output des oberen accumulator in der weise filtert, dass der Trigger 32 mal zur SR.C Triggert. Und zwar immer kurz vor der nächsten Displayclock. Da das "A to E trig" immer dann seinen Eingang A sampelt wenn "Trig" von 0 zu 1 springt ist hier das Flipflop genau richtig.

2. Die amplitude der ganzen Modualtionen.
Die "1" des flipflops wird dazu verwendet den Index von [md] eins weiterzuschalten und den Wert der Modulation auszulesen. Am Audioausgang $ wird dann jede Modulation hintereinander für 2 Samples ausgegeben.

Das A to E sampelt nun immer zur "1" vom flp den Wert A. Am Ausgang gibt es nun pro diplayclock 16(#) Events. eins für jede Modulationsquelle.

[MvKeinen]

display.jpg

hier nun die Zelle "Display"

der Ausgang "E" des A to E wird hier wieder pro displayclock gezählt und in diesem Fall an die Koordinate Y2 und zum Spass auch an den "Rotwert" geschickt.

Das XY hab ich mal nur zum Vergleich eingefügt. Es zeigt den Wert des letzten LFOs und ist manchmal etwas früher dran. Diese Latenz ist für Informationszwecke zu verschmerzen und stellt sich nicht als störend heraus. Vielleicht lässt sich da nochwas optimieren durch den "Buffer"

Gerade eben ist mir noch aufgefallen, dass das "Order" modul garnicht nötig ist.

Weiterhin ist es auch interessant diese Schaltung in Bezug auf Thread saveness zu untersuchen, da der Ausgang des A to E ja vom Audiothread übernommen wird. Bei der "großen" Lösung ist dies allerdings abgesichert, da es in der Displayzelle auch ein Array [md] gibt welches von einer Iteration ausgelesen wird.

Gruß

[MvKeinen]

Man muss auch in den Properities des Multidisplays "ignore rgb" einmal ein- und ausschalten. Das liegt wohl daran, dass die werte nicht immer aktualisiert werden.

[MvKeinen]

hier noch eine version mit 64 LFOs

[herw]

hier noch eine version mit 64 LFOs

fein! Erstaunlich ist die geringe CPU-Auslastung bei 64 LFOs.
Wenn ich das richtig sehe, werden nacheinander alle LFOs innerhalb des 25Hz-Taktes abgefragt; du erzeugst also innerhalb eines Displaytaktes eine Iteration.
Leider lässt sich das ja nicht auf eine Audioquelle ähnlich übertragen. Dann explodiert die Belastung.
Ich bin gespannt, ob du eine ähnliche engine für die Audio-Oszillatoren entworfen hast.

ciao herw

[MvKeinen]

fein! Erstaunlich ist die geringe CPU-Auslastung bei 64 LFOs.
Wenn ich das richtig sehe, werden nacheinander alle LFOs innerhalb des 25Hz-Taktes abgefragt; du erzeugst also innerhalb eines Displaytaktes eine Iteration.

genau, wobei hier 128 Samples pro displayclock zum betätigen des Flipflops verwendet werden und jedes zweite davon den index des readmoduls weiterschaltet. Die Iteration ist in diesem Beispiel noch nicht drin, weil die Daten nicht da sind die ergeben wie oft und an welchen koordinaten die Modulationen auf dem Display dargestellt werden sollen. Das liefert dann die GUI library

Leider lässt sich das ja nicht auf eine Audioquelle ähnlich übertragen. Dann explodiert die Belastung.
Ich bin gespannt, ob du eine ähnliche engine für die Audio-Oszillatoren entworfen hast.

ciao herw

ja leider. Ich werde da aber mal experimente machen

[herw]

[...]

Leider lässt sich das ja nicht auf eine Audioquelle ähnlich übertragen. Dann explodiert die Belastung.
Ich bin gespannt, ob du eine ähnliche engine für die Audio-Oszillatoren entworfen hast.

ja leider. Ich werde da aber mal experimente machen

Die Audiotables wären dafür ideal geeignet, doch wie schon woanders erwähnt, ist jeder Zugriff pro voice mit 0,1% belastet. Eine universelle engine wäre dann möglich.
Ideal sind dagegen die send-recieve-Verbindungen. Dort ist lediglich die universelle Indizierung ein Problem, was ich aber durch einen kleinen Workaround lösen kann, so dass quasi addressierte Audiosignalwege entstehen. Falls es dich interessiert, berichte ich da in meinem Projekt darüber. Audioquellen, die mit send-Modulen verknüpft sind, sind im ganzen Ensemble ohne CPU-Belastung abrufbar.

[MvKeinen]

Jetzt springe ich mal zu einem Punkt der innerhalb des Projektes eine zentale Stellung einnimmt. (Beispielensemble im folgenden Posting)

Nested chain iteration

Da es unnötig ist die Dokumentation von M.Zaglers Chain iteration hier zu wiederholen (kann ja jeder runterladen) setze ich mal vorraus, dass Interessenten wissen worum es dabei geht.

Die Dokumentation ist hier und da schonmal kritisiert worden, aber wie ich an meinem eigenen Beispiel erkennen kann, nähme eine universell-verständliche Dokumentation derart viel Zeit in anspruch, dass man sich mit dem zu behandelnden Thema selber garnicht mehr beschäftigen könnte.

Mir hat es sehr geholfen die ChainIteration nicht auf die Sinebank und Modalbank module anzuwenden, sondern auf das Multidisplay. Hierbei ist das Debuggen für mich viel einfacher.

Mein Vorhaben stellt folgende Ansprüche

- unzählige Objekte sollen darstellbar sein (>100.000)
- jede Subroutine soll nur einmal im Code existieren (sonst wärs ja keine Subroutine )

Subroutinen sind zB
- label: Parameternamen, Containernamen usw.
- symbol
- numeric readout
- fader
- drawfader
- additive switch
- exclusiv switch
usw.

Diese Subroutinen bestehen aus bis zu 4 Teilen.

0. setup (charakteristischer Datensatz)
1. UI (verarbeitung des UserInputs)
2. display (graphische Ausgabe)
3. audio (Bereitstellung des UI in der Audioengine)

wobei 1.&3. nur bei den Subroutinen existiert die auch einen Einfluss auf die Audioengine haben. Bei der Subroutine "label" ist dies zB nicht der Fall

Hier will ich erstmal nur auf 0. setup eingehen:
Im setup befindet sich also der Datensatz der Subroutine. Die große Neuerung in den letzten 2 Versionen meines Systems ist das ALLE relevanten Daten hier gespeichert sind. Um ein Panel zu erzeugen habe ich eine Art tabelarischen Grafikeditor gebaut der extrem ausladend ist und ausführlich. Der kann und soll extrem umfangreich sein, weil der Speicher der dort geschrieben wird ausserhalb des "Setup" Macros ein ROM Speicher ist. Dieser wird wenn das Panel fertig gestaltet ist in ein Eventtable geschrieben. Danach kann das riesen Setupmacro gelöscht werden. So wird es auch möglich verschiedene "skins" für das Panel zu erzeugen welche dann vom User umgeschaltet werden.

Um das Diplay zu initialisieren müssen also sämtliche Datensätze ausgelesen werden. Die Reihenfolge wird von der Eigenschaft des Mutidisplays bestimmt Objekte mit niedrigen Indices im Vordergrund darzustellen.

Die Organisation der Displayelemente ist folgende (hierarchisch)
0. container
1. cell
2. subcell

0. container sind funktionsgruppen wie Oszillator 1, Filter 2, Envelope 95
1. cells sind funktionsgruppen wie "cutoff" "amp" hier werden die Subcells gesammelt und können bis zu 4096 mal dargestellt werden. (damit ich bei einem Sequenzer die Steps nur einmal beschreiben muss)
2. subcells verweisen dann auf die Subroutinen innerhalb einer cell. Der Parameter "Cutoff" hätte dann in der ausführlichsten Form 3 Subcellen: "Label", "Fader" und "numeric"

Um diese Daten in richtiger Reihenfolge ans Display und die Audioengine weiterzugeben verwende ich eine "Nested Iteration" die über den Speicher [st] "Setup" ließt. [st] ist der ROM Speicher welcher ALLE Datensätze beinhaltet.
Die Iteratoren: (Wenn ich Iterator schreibe meine ich hier die corecellen aus dem Patials Framework, obwohl ich weiss, dass eigentlich der Primary part der Iterator ist)

Um die Iteratoren mit den richtigen Daten und Befehlen zu versorgen (startpunkt "a!", endpunkt "b" increment "+") hat der Speicher [st] einen Mainheader, sowie jeder container, celle und subcelle einen "subheader"

was ist ein Header?
Header beschreiben den Inhalt eines Speichers. Hier werden Indexintervalle, Basisindices und Mengenangaben gespeichert. Diese Header werden dann von den Iteratoren ausgelesen um "a!","b" und "+" zu ermitteln.

ich hab mal das ganze soweit reduziert, dass man das Prinzip erkennt. Dazu beschränke ich mich auf 2 Ebenen: container und cell.

primary.jpg

exe: hier wird sicher gestellt, dass das initialisierungsevent zuerst in das Macro "UI" gelangt und dann an den Primaryiterator. siehe partials doku.

UI:
0. setup ( Datensätze)
1. Datenverarbeitung (fehlt noch in diesem Beispiel)

Display:
Graphische Ausgabe

Setup:
Hier sieht man den Mainheader. Hier wird manuell angegeben wieviel indices der header belegt "#hdr"und wieviel funktionsgruppen es gibt "#ftp".
ftp: function type: der Funktionstyp eines containers wie zB oscillator. Hier muss ein funktionstyp nur einmal beschrieben werden auch wenn ich bspw 4 Oszillatoren verwenden will. Vorrausgesetzt die Oszillatoren gleichen oder ähneln sich.

Das ist aber nur der statische Teil des Mainheaders. der Dynamische Teil wird noch in den nachfolgenden Macros hinzugefügt. Dazu gibt es die erste Indexkette "[]#"

Sehen wir uns nun das nachfolgende Macro "container" an, welches die Datensätze für die container beinhaltet.

core.jpg

abkürzungen:
nt: container
cl: cell
ftp: function type

ich habe hier mal 3 nt eingefügt wobei der zweite und der dritte den gleichen ftp haben. Es gibt also 2 ftp und 3 nt. der dynamische header (gelber kasten) speichert nun den Basisindex [] auf den index []#. So haben wir schonmal den Startpunkt "a!" der nt-Iteration. Im Header des Containers speichere ich die grösse des Datensatzes []+ auf subindex 0 und den ftp auf subindex 1. []+ ist also der Increment "+" der nt-Iteration. Fehlt nurnoch der Endpunkt "b". Dazu kommen wir gleich. Im "body" wird nun der eigentliche Datensatz gespeichert, Koordinaten, Farben, Name usw.

Weiter gehts mit den Cellen:

Cellen werden in Funktionstypen gruppiert. In Abbildung 0 unter ftp1 & ftp2

Funktionstyp:

ftp.jpg

Hier haben wir fast die gleiche Struktur. Nur brauchen die cellen keinen ftp. Der dynamische Header speichert wieder den Basisindex dieser ftp. Damit hätten wir nun den Endpunkt der nt-Iteration und gleichzeitig den Startpunkt der genesteten cl-Iteration. Bis auf den fehlendne ftp gleicht der Datensatz einer Celle dem eines containers.

So, nun haben wir alles was wir für unsere genestete Iteration benötigen. Weiter gehts im nächsten Posting.

aber erstmal etwas

[MvKeinen]

message.jpg

hier nun der Iterationalgorythmus. Das Initialisierungseven "G" startet nun die nt-Iteration indem der dynamische Header ausgelesen wird. Allerdings zeigt der untere Teil der Abbildung das "read header"-macro der cl-iteration um zu zeigen wie pro container der richtige ftp ausgelesen wird. Der Ausgang der Iteratoren werden per "it<" in die "prog" macros rückgeführt um den indexintervall und somit den Increment des Iterators zu ermitteln. Die nicht-solid Einstellung der Iteratoren machen dadurch erst variable Datensatzgrößen möglich.

Im Macro "<<rout" wird nun die ganze Iteration auf eine Leitung "[]|[]" gelegt. Das ist möglich, weil alle Events der gesamten Iteration asyncron sind. Diese Leitung dient dann in der Datenverarbeitung, der Audioengine und dem Display als kombinierte Befehls und Indexleitung. Da ich die Ausgänge der Beiden iterationen im 3bit nach links verschiebe hätte ich platz für 8 Iterationen. Im kompletten system sind es 5, In diesem Beispiel 2. Es ist zwar wichtig zu wissen, dass für die indices dann "nur" noch 21Bit übrig bleiben, da durch die floatwandlung in Primary insgesamt 24Bit zur Verfügung stehen doch denke ich mal, dass mein Setuparray nicht mehr als 2.097.151 Indices haben wird Auch ganz nett ist die Tatsache, dass durch das "<<rout" macro garantiert wird, dass in der Leitung "[]|[]" niemals zwei aufeinanderfolgende Events den gleichen Wert haben und wir so diese Leitung auch über einen IC-send schicken könnten. Das ist bei meinem system aber nicht nötig, da es nur eine Primaryhierarchie gibt.

Diese ganze Iteration wird nicht nur zur Initialisierung ausgelößt, sondern auch bei Userinput durch die Mousearea. Dadurch wird dann ermittelt welche Subcelle bzw. subroutine vom User aktiviert wird, da in der grossen Version auch alle Koordinaten in den Subheadern gespeichert sind.

und so sieht dann eine celle mit 4 subcellen im der grossen version aus:

Tabellarischer Graphikeditor:

cell.jpg

[MvKeinen]

Die ersten subroutinen sind jetzt fertig:

- label: universelles Benennungsmodul
- grid: modul für die Darstellung von Balken und Rahmen.

mvkE_0.399.jpg

Bei "label" sind folgende sachen möglich:
- vertikal, horizontal
- links-, rechts- und "mittelbündig"
- Schwarz, weiss oder Farbiger Text!

hierzu hab ich sechs zeichensätze:
- schwarz
- weiss
- negativ (für farbigen Text, hier wird ein Balken beliebiger Farbe hinter den Zeichen gelegt)

dies jeweils in klein und Groß

will man einen anderen Zeichensatz verwenden muss man 128 werte in ein core ROMtable schreiben die die Pixelbreiten für die jeweiligen Zeichen enthalten. 64 für klein und 64 für groß.

[herw]

wow, mir schwirrt der Kopf; die Erläuterungen in den Core-Makros durch „Kommentar-Icons” ist hier sehr praktisch, aber auch äußerst mühevoll. Warum gibt es die eigentlich nicht auch für Corecells? Bei primary Makros und Instrumenten gibt es sie wieder. Werde ich mal nach oben weitergeben.
Wie hast Du eigentlich den Zeichensatz „eingeschleust”?


PS: kleine Zwischenbemerkungen sind auch interessant:

Auch ganz nett ist die Tatsache, dass durch das "<<rout" macro garantiert wird, dass in der Leitung "[]|[]" niemals zwei aufeinanderfolgende Events den gleichen Wert haben und wir so diese Leitung auch über einen IC-send schicken könnten.

genial einfache Idee; leider nicht von mir ich habe immer nur an gate-Befehle gedacht.

[MvKeinen]

wow, mir schwirrt der Kopf;

HA, jetzt weisst Du erst, wie es mir geht wenn ich Deine Sachen versuche zu verstehen

die Erläuterungen in den Core-Makros durch „Kommentar-Icons” ist hier sehr praktisch, aber auch äußerst mühevoll. Warum gibt es die eigentlich nicht auch für Corecells? Bei primary Makros und Instrumenten gibt es sie wieder. Werde ich mal nach oben weitergeben.
Wie hast Du eigentlich den Zeichensatz „eingeschleust”?

Der Zeichensatz steckt im Multidisplay. Dort kann man ja wie bei allen Panelelementen eine "Animation" einfügen. Damit Ich mehrere verschiedene Animationen ansteuern kann habe ich im letzten grossen Update die Möglichkeit integriert mehrere Multidisplays die übereinander liegen anzusteuern (bis zu 16). Ich möchte zB auch eine Knobanimation haben die natürlich größere Dimensionen hat als die Buchstaben. Wenn ich nur einen Zeichensatz hätte müsste jeder Buchstabe die gleiche Größe einnehmen wie der knob.

Anfangs war es mühevoll, doch jetzt hab ich eine Art graphisches Template um die Makros zu beschriften, ich schneide einfach ein Stück aus dem Screenshot einer Exceltabelle heraus. Allerdings vergrößert das die .ens-Datei natürlich. Das macht aber nichts, weil ich ja den Setupbereich am Ende komplett Rauslöschen kann. Ohne diese Beschriftungen wäre ich total aufgeschmissen. natürlich wär es schön, wenn man eine 3spaltige Tabelle als Macrobild hätte, die man von aussen beschriften kann. So könnten sich die Namen der Eingänge dann direkt an den Einträgen in dieser Tabelle richten. Ich hab es schon lange aufgegeben die Infofelder von Ein-, und Ausgängen zu benutzen. in der 2.Spalte dieser Tabelle könnte man einfache Bemerkungen eintragen. An ein wirkliche Tabellenkalkulation innerhalb Reaktor Core will ich garnicht erst denken.

[herw]

[...]
Anfangs war es mühevoll, doch jetzt hab ich eine Art graphisches Template um die Makros zu beschriften, ich schneide einfach ein Stück aus dem Screenshot einer Exceltabelle heraus. [...]

Dachte ich mir schon - gute Idee. Ich mache das manchmal, wenn ich Kommentar-Makros in core einfügen möchte, dann kopiere ich manchmal ganze Abschnitte aus WORD-screenshots hinein.