MvK Monokl

[MvKeinen]

Jetzt mal eun etwas Theoretisches Posting.

Ich hab jetzt (mal wieder) eine Erweiterung meines Grundsystems vor mir. Glücklicherweise ändern sich die grundlegenden Mechaniken nicht. Auch werden die Verschiedenen Speicher nicht angestastet. Es wird nur die Indexierung innderhalb dieser Speicher umorganisiert. Das sind die Dinge die nicht wirklich Spass machen, da ich bei so einer Umorganisierung teilweise einen ganzen Tag oder mehrere nichtmal mehr Reaktor starte, sondern stundenlang vor MS-Excel brüte.

Meine Spassrangliste in diesem Reaktorprojekt ist woe folgt:
- Core Audio (schon seit fast einem Jahr nicht mehr )
- Core Event (95% der Arbeitszeit)
- Excel (macht am wenigsten Spass)

Doch wenn ich das richtig sehe könnte ich in ca. 1-2 Wochen wieder an die Audioengine kommen, ich will unbedingt so bald wie möglich eine extrem abgespekte Version des Synthies in die UL hochladen. Erstens, um nach den vielen Dingen die ich hier und im offiziellen Forum gelernt habe auch mal etwas zurückzugeben und zweiten um ein "breiteres" Feedback zu erhalten.

Doch auch für kleine Versionen muss das "Framework" vollständig sein. Zu der oben Beschriebenen nested Iteration kommen noch ein paar Ebenen dazu, denn wenn ich den kompletten Synth per Polyphonie vervielfachen will muss ich noch eine "Voice" iteration oben draufkleben

Dazu möchte ich demnächst ein paar Gedanken zur Speicherorganisation hier verlieren.

Grundsätzlich gilt, dass Iteration und Speicher in Reaktor core ein extrem Leistungsfähiges Gespann ergeben kann.

Die "natur" des Speichers wird durch die Kriterien bestimmt: Wann, Wo in welcher Reihenfolge wird der Speicher beschrieben, bzw ausgelesen.

"Natur":
- ROM
- flüchtig
- Halbflüchtig
- Mischformen

Da in meinem System unzählige Daten hin und hergeschoben werden musste ich mir schnell über die Kriterien und die "natur" des Speichers im Klaren werden. Dabei gilt, dass Paralelles Schreiben und Lesen weitaus belastbarer und Leistungsfähiger ist. Die Iteration und deren asynchrone Events geben uns nun die Möglichkeit Lese- und Schreibaktionen zu serialisieren. Das verschafft einem die Möglichkeit den Speicher selber paralell zu organisieren was bei grossen Speichern weitaus besser ist. Bildlich kann man sich das so vorstellen:

speicher.jpg

Nimmt man das Beispielensemble "ChainIT.ens" würde hier für die Darstellung von Zellen die Containeriteration []nt den Gelben Befehl übernehmen und die genestete cell-iteration []cl die Lila Befehlskette. Dies geschieht nun für jeden Container hintereinander.

Insgesamt würden mich allgemeine Vermutungen zu Vor- und nachteilen von Sternförmigen bzw. Kettenförmigen Speichern interessieren.
Ich hatte mal den Punkt, an dem ich das Projekt fast aufgeben musste, da Reaktor ab einer bestimmten Anzahl von seriellen Speicherzellen eine Ewigkeit zum Kompilieren brauchte. Die anzahl von R/W-Order modulen in einer Kette scheint da ausschlaggebend zu sein.
Ich meinte mal in den Eventbus Threads hier gelesen zu haben, dass auch dort eine Sternförmige Verteilung besser ist.

Gruss

[herw]

[...]
Insgesamt würden mich allgemeine Vermutungen zu Vor- und nachteilen von Sternförmigen bzw. Kettenförmigen Speichern interessieren.
[...]

wenn ich einige Stunden in meinen eMails suche, finde ich wohl auch eine Post von Max Zagler über eine lineare Liste mit Hilfe des Partials Framework; soll ich nachschauen? Wenn man das framework (lesen, schreiben, löschen etc.) einer Liste hat, dann hat man automatisch auch FIFO (Schlange), LIFO (Stack) und Ring.
Es gibt auch noch ein posting über geordnetes Initialisieren, d.h. man kann explizit festlegen, was als erstes, zweites etc. initialisiert wird; nicht ganz einfach zu verstehen, aber sehr leicht anzuwenden.

ciao herw

[MvKeinen]

wenn ich einige Stunden in meinen eMails suche, finde ich wohl auch eine Post von Max Zagler über eine lineare Liste mit Hilfe des Partials Framework; soll ich nachschauen? Wenn man das framework (lesen, schreiben, löschen etc.) einer Liste hat, dann hat man automatisch auch FIFO (Schlange), LIFO (Stack) und Ring.
Es gibt auch noch ein posting über geordnetes Initialisieren, d.h. man kann explizit festlegen, was als erstes, zweites etc. initialisiert wird; nicht ganz einfach zu verstehen, aber sehr leicht anzuwenden.

ciao herw

mich interessiert das grundsätzlich alles. Wenn Du irgendwann Zeit findest das zu suchen, dann natürlich gerne!

[MvKeinen]

es geht ganz gut weiter. die Umorganisation der Iteration, bzw. deren vervollständigung war recht kompliziert. Um weitermachen zu können muss ich Funktionsweisen in das Grundsystem einfügen die erst zu einem späteren Zeitpunkt abgerufen werden. Bei der Fertigstellung der "switch" subroutine zB musste ich eine "rückkopplung" der Datenverarbeitung mit dem Initialisierungsvorgang herstellen, damit die Funktionalität von "Stacked macros" ermöglicht wird. So muss die Subroutine "switch" bei einem bestimmten Untertyp einen Teil der Initialisierung des Displays wiederholen um die neue Ansicht darzustellen. Und mal wieder ist die Indexierung das schwierigste an der ganzen sache, das klappt jetzt aber fast, ich denke in den nächsten tagen hat sich das geregelt.

hier mal ein Bild des jetzigen standes. Das hat noch nichts mit dem Synth zu tun, den ich dann bauen will, sondern soll ein Testfeld für die Subroutinen sein, die in jeder erdenklichen Form funktionieren sollen.

So gibt es den "additiven" und den "exklusiven" Switch. Bei additiv können mehrere Elemente an & ausgeschaltet werden. Beispiel Steuerung der Tonhöhe eines Oszillators. Hier soll es die Möglichkeit geben die Tonhöheabhängigkeit von Midi UND Sequenzer zu aktivieren. Das ermöglicht dann die Transponierung des Sequenz durch Midi oder umgekehrt. Hier muss man dann mit Bitshifting Arbeiten Und so sind dann Switchmatrizen von 24 Elementen möglich. Doch es soll theoretisch unbegrenzt sein. Daher erkennt das System dann wieviel Idices nötig sind umd verteilt diese dann automatisch in das Speichersystem. So sind dann auch riesige Switchmatrizen möglich. (siehe oberer Switch)

Die switches "a,b" werden dann die "Stacked macro" switches sein. Die Switches in den unteren Containern "0-6" sind normale exklusive. Alle werden von der gleichen Subroutine Dargestellt und berechnet.

ver0431.jpg

[herw]

Die switch-Matrix mit der eingestellten Kombination gefällt mir am besten.
Denke daran, dass REAKTOR im Augenblick maximal 200 Control-Rate-Quellen versteht; hier mal ein Ausschnitt der bis jetzt gültigen Grenzen:

Control-Rate modules:
When the accumulated amount of used modules of this type exceeded a number of 200 (modules added and activated in structure, yellow module lamp is on), they were ignored while processing a control rate event - that means e.g. you could only have 150 "A to E" + 50 "System Info" working modules:
– "LFO"
– "Slow Random"
– "A to E"
– "Event Smoother"
– "Hold"
– "Multi-Tap Delay"
– "System Info"
...

Dieser Beschränkung ist beseitigt, wartet aber noch auf Veröffentlichung.

ciao herw

[MvKeinen]

interessant, allerdings ist es bisher nicht geplant überhaupt ein Modul mit CR-clocked Ausgang zu benutzen. von den aufgelisteten benutze ich nur ein System info für die Displayclock. Die CR existiert bei mir soweit garnicht.

Mit einer eventuellen Switchmatrix würde ich dann eher dinge steuern wollen deren Ursprung alle in der einen großen Audiocorezelle sind. Doch sind das bisher nur Dinge die ich rein theroretisch ausprobiere, damit ich nicht irgendwann das System ändern muss wenn ich doch mal sowas brauche.

[MvKeinen]

So hier nun mal ein Upload, der das ganze System in den Grundzügen zeigt.

ich werde mich in diesem Post erstmal nur auf die Bedienung beschränken und dann nach und nach die Interna etwas beschreiben.

ver0448.jpg

Fertig sind die Subroutinen:

- Grid: Anordnung von bis zu 9 Balken um Funktionsgruppen optisch voneinander zu trennen.
- Label: Beschriftung von Funktionsgruppen
- Symbol: Darstellung von symbolen bzw. switch

Wobei "symbol" bisher die einzige ist die man als User editieren kann.

0: ein additiver Switch von 504 elementen die alle ein und ausgeschaltet werden können. Hier ist die "draw" Option aktiviert (nur um mal zu Zeigen dass es geht. Sie ist vor allem für ON/OFF sequenzen wichtig. bedeutet: der Zustand des Elementes auf das man Klickt bestimmt die Usereingabe wenn die Maus nachfolgend bei gehaltener Maustaste über andere Elemente zieht. Wenn ich also ein Element welches "On" ist klicke sind alle folgenden Editierungen "OFF" und umgekehrt. Rechtsklick resettet die ganze Subcelle.
1: ein selektiver Switch welcher nur ein element aktiviert.
2: Stacked macro.

Manchmal zickt das "Stacked Macro" etwas vor allem nachdem man switch 0 (additiv) per rechtsklick resettet. Der fehler ist mir schon klar und wird als nächstes angegangen.

Ich möchte dann nächste Woche etwas über die Primary Struktur schreiben und auch die Verschiedenen Speicher Erläutern.

Gruss

[MvKeinen]

So, nach etwas Urlaub und Abstand zum Projekt (sehr erfrischend) hier mal ein kleines Bildchen der neuesten Subcelle. Es handelt sich um ein Sample-darstellungsmodul. Voraussetzung ist, dass das Sample als Eventstream in das System einfließt. Hierzu dient ein Eventtable in welches man auch MONO wav.Dateien laden kann. Immer wenn ein neues Sample geladen wird wird es von einem Iterator ausgelesen und von der weiter oben beschriebenen Iteration analysiert. Da das System die Größe der Darstellung skalierbar hält hängt diese Iteration von der Cellenbreite ab.

Iteration: a<b wobei b=16*Cellenbreite in Pixel. So habe ich dann 16 Befehle pro pixel. Diese Befehle werden gleichmäßig auf das Sample verteilt und pro Pixel dann der Minimal- und Maximalwert des Samples ermittelt. Diese Werte stellen dann den Anfangs- und Endpunkt der vertikalen Striche dar.

In dem Bild sieht man den Vergleich zwischen der Darstellung des Eventtables (orange) und der meines Systems (türkis). Ich schätze, dass innerhalb des Eventtables zur Darstellung ein ähnlicher Algorythmus verwendet wird.

sample.jpg

[herw]

interessant; ich arbeite gerade an einem ähnlichen Kleinprojekt: Darstellung von Hüllkurven auf Multidisplays.
ciao herw

[MvKeinen]

interessant; ich arbeite gerade an einem ähnlichen Kleinprojekt: Darstellung von Hüllkurven auf Multidisplays.
ciao herw

das hab ich vor Ewigkeiten auch schonmal probiert, mit wenig Erfolg. Das Problem war die fixe Gesamtbreite und die Variable Breite der einzelnen Phasen. Irgendwann demnächst steht das auch wieder auf dem Plan.

[herw]

interessant; ich arbeite gerade an einem ähnlichen Kleinprojekt: Darstellung von Hüllkurven auf Multidisplays.
ciao herw

das hab ich vor Ewigkeiten auch schonmal probiert, mit wenig Erfolg. Das Problem war die fixe Gesamtbreite und die Variable Breite der einzelnen Phasen. Irgendwann demnächst steht das auch wieder auf dem Plan.

ne das ist kein Problem, das habe ich vor gefühlten Jahrhunderten schon mal in Primary gemacht.
Man muss sich nur entscheiden, ob man die Gesamt-Zeitdauer auf des gesamte Display verteilt oder der Displaylänge einer festen Zeitspanne zuweist.
Die Anzeigen von NI sind dagegen unterirdisch.

ciao herw

[MvKeinen]

hier mal ein kleines Update:

bin jetzt bei Versionsnummer H_0.581

der Buchstabe beziffert die Frameworkgeneration. Wird diese geupdated stehen grundsätzliche Änderungen der Datensatz-header an, was vor allem in Excel passiert. hier geht es um Indexierungen der Datensätze. Diese wiederum steuern die komplette Funktionalität des Systems. In Reaktor selber ist sowas seit Version G sehr angenehm, weil ich ab dieser Version sämtliche Vorgänge Zentralisiert habe und dadurch die Modifikationen sehr schnell gehen. Die Version H ist die Vorletzte während derer ich das komplette System aufbauen werde um die letzten nötigen Änderungen am Basissystem zu sammeln und schlussendlich ganz am Ende zu integrieren. Die Dezimalzahl ist die fortlaufende Versionsnummer des gesamten Projektes und fing irgendwann kurz nachdem Partial Frameworks rausgekommen ist mit 0.001 an und wird immer wenn ich die Notwendigkeit sehe unter neuem namen zu speichern um ein tausendstel erhöht.

Das Bild des derzeitigen Panels soll stilistisch ohne Wertung bleiben. Es lohnt sich einfach noch nicht Zeit in den Zeichensatz, die Potianimationen und die Auswahl der Farben zu stecken. Des weiteren soll es vorerst als Testfeld für jede erdenkliche Form der einzelnen Subroutinen herhalten die für jeden Fall gerüstet sein sollen und auch in Dimensionen funktionieren sollen die mit der Realität vermeintlich (noch) nichts zu tun haben. Wenn man allerdings Zeit in die Gestaltung investiert kann man schon sehr ordentliche Panels erstellen.

panel0581.jpg

wie gesagt farblich nicht gerade sehr einadend für meinen Geschmack

[MvKeinen]

hier nun die Primary Struktur:

struc0581.jpg

ROT: exe'UI
execution USER INPUT

hier werden alle Befehle die möglicherweise eine Iteration auslösen müssen durchgeleitet. Der Iterationbefehl geht dann über ! raus NACHDEM die Quelle des Befehls in die nachfolgende Datenverarbeitung geschickt wird. Das Macro arbeitet hier wie ein Order modul:

exeUI.jpg

früher hab ich mir viel Mühe gegeben an dieser Stelle mühsam alle Bedingungen zu beachten ob, oder ob keine Iteration nötig ist. Ich hab da den Satz "a primary Event is a very costly good in Reaktor" oder so ähnlich überbewertet. Der satzt stimmt zwar vollständig, bedeutet aber nicht, dass man riesige Strukturen erstellen soll mit extrem viel Routing um Events zu verhindern, die sowieso verhungern. Jedenfalls ist das mein jetziger Stil welcher sich meistens auszuzahlen scheint. Wenn jemand mehr weiss, bitte bescheid sagen.

[MvKeinen]

Gelb: Memory:

memory.jpg

hier wird ALLES gespeichert.

Die Klangdaten aller 6 Stimmen und auch des Masterbereiches im SVA Indexierung automatisch. D.h. Immer wenn ich im tabellarischen Grafikeditor Subcellen hinzufüge wird die Indexierung automatisch berechnet und auch an den audiopart geschickt.
Das Setup wird im Master-Event table gespeichert. Beim fertigen Produkt kann man dann das Mastertable rauslöschen und auch den gesamten Setupbereich der Datenverarbeitung und hat dann auf einmal ein halb so grosses Ensemble was genauso funktioniert. Diese Technik ermöglicht mir das neueste Vorhaben was ich auch schon konzipiert habe und auf das ich am Ende meines Nächtlichen Rundganges beschreiben möchte

Wie üblich bei SVAs wird hier jeder Wert bei Initialisierung an das System zurückgegeben.

[MvKeinen]

Grün: Audio

bisher nur Platzhalter

Pre-mono:
Monophone Audiocelle die globale modulatoren beinhalten wird:

2 lfos
3 envs
1 Sequenzer

diese Modulatoren können dann in der nachfolgenden Polycelle auf alle Stimmen gleichermaßen wirken. Gerade bei Multitimbralen sachen sehr mächtig und sensationellerweise von mir noch nirgendwo anders gesehen. Gibts sicher irgendwo, denn ich weigere mich zu glauben, dass ich der einzige bin der die Idee hatte. "lass uns doch einfach OSC1 von Stimmen 2-5 mit dem gleichen Sequenzer steuern" " wie wärs den globalen LFO auf dem Cutoff von Filter2 von stimme 6 zu legen und gleichzeitig mit dem selben LFO die LFO1frequenz von Stimme 2 zu modulieren?"

Poly:

Polyphone Audiocelle

Post-mono:

Mastereffekte

In einer älteren Version hab ich ca. 60% der Struktur fertig. Hier will ich aber erstmal nur die Envelope zeigen:
(funktioniert noch nicht, aber das wird schon)

envelopes.jpg