MvK Monokl

[MvKeinen]

Orange: UI (User Input)

ui.jpg

eine der beiden Grossen Eventcellen. Die andere befindet sich im Panel "display" diese beiden Eventcellen haben eine Bewegte Geschichte hinter sich. Früher habe ich alle gestalterischen Sachen alle in der anderen Eventzelle gehabt, also form farbe coordinaten usw. Jetzt jedoch ist das alles im Macro "setup" ganz links zu finden. Dies macht die Technik das ganze Setup in einer einzigen Textdatei zu speichern erst möglich und auch die idee die ich am Ende beschreiben will, die mich übrigens je mehr ich drüber nachdenke wirklich vom Sockel haut.

Nun zum setup:

setup.jpg

hier wird das setup array beschrieben [st] welches gerade 1337 indices umfasst. Der speicher wird hier so Paralell wie möglich gehalten (weiss nicht ob paralell der fachlich richtige ausdruck ist). Nur wenn downstream was gelesen werden muss was upstream zum gleichen zeitpunkt geschrieben wurde ist es nötig das R/W order Module zu verwenden. Das ist ja sehr logisch. Vermeidet man so möglichst viele R/W order module kann man eine weitaus größere Speicherstruktur erreichen ohne dass die Kompilierungszeit sehr ansteigt. Nach meiner Erfahrung. Ich habe hier mal ein Megamonsterdisplay erstellt welches über 20.000 Indices im Stup array belegte und es war kaum ein unterschied zu spüren.

Natürlci hkann ich nicht alles erklären hier, aber Grundsätzlich schneid ich mal an.

header:
hier gibt es einen Statische header welcher die Konstanten links oben speichert:
#shdr: größe des statischen headers
#reg: Anzahl der Regionen (Mouse Areas)
#ftp: Anzahl der container funktionstypen..... diese sind im gelben Kasten zu sehen
#gra: Anzahl der Farb/Symbol/Namesgruppen
#Fnt: Anzahl der Schriftarten
#[]pFnt: Anzahl der Zeichen pro Schriftart

usw.

das alles ist natürlci hschön Dokumentiert:

setupindexierung.jpg

per "ref" (refresh) wird dann der Iterator manuell gestartet um diesen Speicher dann in das Master Event table in "Memory" zu schreiben.

Edit: jetzt mach ich mal Pause. Morgen gehts weiter, ich muss noch meine Envelope Weitermachen

[herw]

mir schwirrt der Kopf: brauchst du nicht für die merge-ADSR exponentielle Kabel ?

ciao herw

PS : Übrigens bist du spät ins Bett gekommen, was man an den Buchstabendrehern sieht

[MvKeinen]

mir schwirrt der Kopf: brauchst du nicht für die merge-ADSR exponentielle Kabel ?

ciao herw

PS : Übrigens bist du spät ins Bett gekommen, was man an den Buchstabendrehern sieht

setup2.jpg

der statische Header (macro links oben) ist also dazu da den variablen Teil des headers und des "bodys" zu beschreiben, damit die ausführenden Elemente wissen wo sie Ihre Information herholen sollen. Hier wird in bestimmen Macros der Header gelesen und so der Basisindex der verschiedenen Teilbereiche (colour, font, containers, cells, subcells) ermittelt. Als nächstes kommt der Variable Header. Im Bildchen ist das die Rote Indexkette deren Größe variabel ist weil eine beliebige Anzahl von Containerfunktionstypen anfügbar sein soll. Die Blaue Kette ist für die Indexierung des "bodys" zuständig.

sieht man ins Macro "container" rein:

container.jpg

sieht man, dass der Basisindex des bodys (blau) in den variablen header (rot) geschrieben wird.

so wird sichergestellt, dass in einen fest bestimmbaren Speicherplatz die Basisadresse jedes Datensatzes gelesen werden kann. Ich brauche dazu nur den statischen und den variablen header.

Die Container sind die größten Einheiten und dienen als Gruppierung im Display und in der Audioengine.
Beispiele:
- Oscillator
- Filter
- usw.

Vielmehr sind das die Containerfuntionstypen. Container sind eigentlich nur verweise auf diese (Gelb) . So muss ich wie in meinem Beispiel einen Typen nur einmal beschreiben. Ich tendiere eher dazu gleichförmige Container zu benutzen, diese aber multifunktionell zu gestalten. Also lieber 2 gleiche Filter die jeweils mehrere typen beinhalten. Das ergibt mehr Freiheit beim Klänge bauen und dazu noch die Möglichkeit einen (Bsp:) Oscillator auf den anderen zu kopieren, was bei meinem System sehr einfach zu realisieren ist. im oberen Bild sieht man die Vier Funktionstypen die es gerade gibt rechts neben dem Container Macro. "control" "automation" "modules" "sample"

[MvKeinen]

ntcell.jpg

die Container werden also im Bild links mit folgenden Kriterien versehen:

V?: [0...1]
gibt an ob der Container für jede Voice einzeln angezeigt und im SVA gespeichert wird (true) , oder ob es sich um einen Mastercontainer handelt der auf alle Voices gleichermaßen Einfluss nimmt (false). Bei einem normal polyphonen Synth wär hier das meisste false. Bei meinem 6fach multitimbralen Monosynth ist das meisste true, also für jede Voice individuell einstellbar und nur die monophonen Bereiche (globale Modulatoren, Post-mixer Bereich und Effektwege) false. Die Indexierung des SVAs wird im Analysevorgang der Initialisierung (siehe später) automatisch errechnet.
n:
region. Nummer der mouse area unter der sich der Container befindet.
ftp:
Adresse des Containerfunktionstypen. Im Beispiel haben die 3 container "Module 1-3" den gleichen Funtionstypen (2:module) ein Multifunktionscontainer welcher Osc, Sampler oder Input sein kann
_X/_Y: [1...1024]
größe des Conatainers in Pixel
i#:
Anzahl der Ausführungseinheiten. Hier kann man angeben wie oft dieser Container angezeigt wird. (Noch) nicht implementiert auf Containerebene aus verschiedenen Praktikabilitätsgründen allerdings funktioniert das wunderbar auf Cellenebene (siehe später)
X+/Y- [0...1023]
Abstand zum Nachbar definiert durch ->X/->Y
->X/->Y [0...1023]
hier kann man den Container an den Nachbarn "anschließen" ->X: rechts daneben. ->Y drunter

[st]: Setup array
[nt]: Container-koordinaten zwischenspeicher der in den Containerzellen die Dimensionen des containers speichert (Macro [nt] rechts unten) um sie den Cellen (eine Ebene drunter) zur Verfügung zu stellen.

Wie schon angesprochen muss hier der Speicher seriell erfolgen damit den Cellen (im Setuparray flussabwärts) zur Initialisierung den Wert haben.

nun zum Datensatz des Containers:

ntcelltable.jpg

noch nicht erwähnt sind hier:
[]+:
Size of dataset. dies steuert den Increment der Containerebene der genesteten Iteration Darf nicht null sein. Dadurch wird sichergestellet, dass der Wert der Iteration gleich der Basisindex des Datensatzes ist.
View:
hier kann man für 24 mögliche "Views" angeben ob der Container angezeigt wird oder nicht.

Die nächsten paar Einträge haben mit den Koordinaten und dem Verhalten bei "vermehrung" des Contaners zu tun. Da es wie gesagt auf Containerebene nicht Implementiert ist beschreib ich das erst auf Zellenebene.

lbl/sym/col 0-3: index 9-20 im Datensatz
Label-, Symbol- und Farbadressen des Containers. Entspricht dem länglichen Macro in der mitte oben. der eintrag fwd? bezieht sich auch auf die "vermehrung" und gibt an ob der Index pro Ausführungeinheit um eins erhöht wird oder nicht. so kann entweder jede Ausführungeinheit die gleichen Namen, Farben und Symbole (false) oder jeweils fortlaufende Namen, Farben und Symbole (true) lesen. Hier wird also nicht direkt eine Eigenschaft spezifiziert, sondern auf eine Zentrale Sammlung von Eigenschaften hingewiesen. so kann ich im Zentralen Farbspeicher leicht die Farbe von vielen verschiedenen Containern und Cellen bestimmen. Was bei Auswahl von Standartfarben zB praktisch ist.

ab index 21 kommt der "body" der mit "subcellen" siehe bild macro "grad X/Y" gefüllt wird. Von solchen Macros kann man beliebig viele einfügen. Durch die fortlaufende Indexierung über []+ wird sichergestellt, dass alles gut wird.

pro Container haben wir nun im Beispiel eine Subcelle. Sie beschreibt den Balken am Kopf der Container.

modules.jpg

So eine Subcelle stellt den Verweis auf eine Subroutine mit charakteristischem Datensatz dar. In diesem Fall eine Subroutine die nur auf displayebene eine Rolle spielt und sehr einfach ist. Es können zwei Farben und alphawerte beschrieben werden.

weiterhin:
Layer n+:
Id des Multidisplays. Pro region (mouse area) stehen bis zu 16 layer zur Verfügung. Das system hätte zwar kein Problem damit alles auf einem Multidisplay darzustellen, will man jedoch verschiedene Zeichensätze der Multidisplays ansprechen, so müssen mehrere Layer verwendet werden. Im Beispiel sind es 4 verschiedene Zeichensätze.
- Knob big
- Knob small
- fonts
- symbols

die beiden oberen einträge beschreiben den Stil der Gradiation und die Richtung.
s=0.1
gradiation erfolgt von Farbe/Alpha 0 zu 1
s=0.1.0
gradiation erfolgt von Farbe/Alpha 0 zu 1 zu 0

auswirkung siehe Display screenshot.

jetzt sind eigentlich schon recht viele Aspekte und Möglichkeiten angesprochen worden. Demnächst werd ich dann noch ein paar andere Subcellen beschreiben sowie deren Header (dieser steuert die komplette funktionalität des systems). Aber dann auf den Initialisierungsvorgang und das Koordinatensystem eingehen.



prost!

[herw]

Lieber David,
ich bemühe mich ja zu verstehen, aber das kann ich nur ansatzweise nachvollziehen (nicht missverstehen, es ist sehr schwer). Das ist kein Vorwurf, aber ich kann mir bei den vielen Abkürzungen und Makros überhaupt nicht vorstellen, was das letztendlich auf dem Panel und später auch hoffentlich im Audiobereich bewirkt.
Die Universalität, die du offensichtlich hier perfektioniert hast, ist für Außenstehende nur noch staunend zu erfahren.

Also stelle ich mal ganz doofe Fragen:

- Sind Primary und Core so stark getrennt, dass du nur noch multipictures, Mausareas zur Bedienung benutzt, der Rest aber in einer einzigen großen Corecell stattfindet? (wäre genial)
- In den mittlerweile alten Videos hattest du uns vorgeführt, wie Controllergruppen (Hüllkurven, LFO) etc. den Oszillatoren und Filtern etc. frei zugeordnet werden konnten. Handelt es sich dann um ein frei gestaltbares modulares System oder sind die Zuordnungen schon vorgegeben, können aber unsichtbar und abschaltbar gemacht werden?
- und nun die Gretchenfrage: was kommt für uns (arme) user dann mal heraus?

ciao herw

Übrigens habe ich deine Art, die Corecells durch Piktogramme aus Excel aufzumotzen, wärmstens dem Entwicklerteam empfohlen. Das wäre ein schönes feature.

[MvKeinen]

Lieber David,
ich bemühe mich ja zu verstehen, aber das kann ich nur ansatzweise nachvollziehen (nicht missverstehen, es ist sehr schwer). Das ist kein Vorwurf, aber ich kann mir bei den vielen Abkürzungen und Makros überhaupt nicht vorstellen, was das letztendlich auf dem Panel und später auch hoffentlich im Audiobereich bewirkt.
Die Universalität, die du offensichtlich hier perfektioniert hast, ist für Außenstehende nur noch staunend zu erfahren.

Ich hoffe nicht den Eindruck zu machen ich wollte Eindruck schinden. Das System ist so gigantisch geworden, dass eine koplette, allgemeinverständliche Dokumentation einen riesen Umfang hätte. Daher hab ich in den letzten Postings "irgendwo" mal angefangen um mir selbst klar zu werden, wie das alles gegliedert werden sollte. Es wird auch noch viel verständlicher wenn die Macros "Massacre" und "Data" beschrieben werden. Daher dank ich dir für die Fragen. Übrigens ist die Dokumentation in Threadform auch nich dazu geeignet allgemeinverständlich zu sein. Ich denke da eher an die PDF-Slides-Methode des Partials Framework. Das hab ich auch schon grob begonnen. Wenn dein Modularsystem für dich vielleicht relativ einfach erscheint so sind die Interna für mich zB komplett nicht nachzuvollziehen. Das liegt glaub ich vor allem an den unterschiedlichen Denkmustern der Programmierer und auch an der Verwurzelung im eigenen Projekt. Daher ist jede Frage die von aussen kommt auch ein Gewinn für das Projekt.

Bevor ich die Fragen Beantworte erstmal zu den Zielen des Ganzen:

1. Bau eines 6-fach multitimbralen monophonen synths.
Jede Stimme:
- 3 klangmodule, die jeweils Osc, Sampler oder Audio-in sein können
- 2 filter
- 1 inserteffekt
- 3 Env, 3 LFO, 2 Modsequencer
- note/vel/gate Sequencer
- Drag and drop Modulations- und Syncmatrix
Global:
- 3 Env, 3 LFO, 2 Modsequencer
- note/vel/gate Sequencer
- 16 Automations slots
- "Click and rotate" editierung der fader per Midi endless knob

- Mastereffekte
- Sendeffekte

funktionell ist hier ca. 80% des Sachen schon fertig nur noch nicht auf das neuste System (siehe 2. upgegradet)

2. Framework:
für die
- Darstellung,
- Editierung,
- Speicherung und
- Bereitstellung von Daten und Funktionen.

Der Grundatz des Frameworks ist ALLE Charakteristika in einem Eventtable abzulegen. Die Textdatei reicht, um das Gesamte System zu konfigurieren. Der Setup teil (großes Macro) kann wegfallen. Das Rahmenensemble (Events) bleibt immer gleich. Der Audiopart kann durch einfache Adressierung versorgt werden indem die eingehenden Befehle gefiltert werden. zB: container 2, Switch 5. Oder man könnte auch einfach alle Fader zentral auslesen (mit den dazugehörigen min/max werten) Die Programmierung der Audioengine muss dann je nach Projekt erfolgen.

Also stelle ich mal ganz doofe Fragen:

- Sind Primary und Core so stark getrennt, dass du nur noch multipictures, Mausareas zur Bedienung benutzt, der Rest aber in einer einzigen großen Corecell stattfindet? (wäre genial)

Ja. Zusätzlich gibt es 16 Host-Automations-Slots die in die Modulationsmatrix integriert werden können.

- In den mittlerweile alten Videos hattest du uns vorgeführt, wie Controllergruppen (Hüllkurven, LFO) etc. den Oszillatoren und Filtern etc. frei zugeordnet werden konnten. Handelt es sich dann um ein frei gestaltbares modulares System oder sind die Zuordnungen schon vorgegeben, können aber unsichtbar und abschaltbar gemacht werden?

jeder Fader kann modulationsziel sein. Im Analysevorgang der initialisierung werden Fader durch einen Eintrag in ihrem Datensatz als potentielles Modulationsziel "angemeldet" und können dann per drag&drop mit einer Modularionsquelle beschickt werden. Da alles Zentral passiert (subroutinen) gibt es im Diplayteil nur ein Makro "Fader". Das wäre auch im Audioteil möglich, allerdings ohne Oversampling nur die "Bereitstellung" von Daten und nicht die Verrechnung mit den Modulationen. Mit Oversampling (theoretisch gedacht) könnte das genial sein, weil ich durch das Framework alle notwendigen Daten hätte um das durchzuführen. Da hab ich aber noch nichts ausprobiert und es scheint mir auch schwierig zu sein.

Der Modulations-, Sync- und Gateteil soll komplett modular sein
Der Signalweg des Audiopart soll erstmal fest vorgegeben sein, wenn es auch Optionen zum Signalrouting geben wird.

- und nun die Gretchenfrage: was kommt für uns (arme) user dann mal heraus?

erstmal eine Abgespeckte Version des Synths.

langfristig ein Programm für WIN/MAC mit dem man ein Panel zeichnen kann für Reaktor. Die Rahmenbedingungen für das Grundsystem stehen. Die einzelnen Subroutinen müssen noch erstellt werden. Da hab ich bisher ca. 10 von ca. 20-30.

Wenn das System von einer einzigen Textdatei Konfigurierbar ist dann kann die Textdatei auch von einem Grafikprogramm kommen. Man muss nur die Chrakteristika der Subroutinen und die Koordinaten, Funktionstypen, Farben und so weiter per Maske oder Grafikeditor eingeben können, die Datei ausspucken und in das Eventtable laden. Dann noch die Objektzahl der Displays anpassen und kann dann anfangen mir einfachen recievemodulen die Audioengine zu bauen. Sogar für Primarysynths möglich.

ciao herw

Übrigens habe ich deine Art, die Corecells durch Piktogramme aus Excel aufzumotzen, wärmstens dem Entwicklerteam empfohlen. Das wäre ein schönes feature.

Ja das würde arbeit sparen wenn man die Macros innerhalb Reaktor so beschriften könnte wie eine Tabelle. vielleicht auch eine Spalte für die Eingabe von Konstanten die dann "dafault signal" für den jeweiligen Input sind. Aber sicher auch schwierig da die Rahmenbedingungen festzulegen. Ich weiss auch nicht ob das viele Builder benutzen würden.

bs dahin mal:

[MvKeinen]

hier sieht man die nächsten funktionen (subgruppen)

- fader
- numeric readout
- drawbars

panel0596lo.jpg

demnächst mach ich mal weiter mit der Doku

[herw]

Ich habe mir nochmals die Abbildung ntcell.jpg vom 1. Dezember angesehen. In der Struktur gibt es zwei Makros, die zwar Eingänge aber keine Ausgänge haben; was passiert da denn? Jedes Makro muss ja eine Außenwirkung haben, denn globale Busse gibt es ja (leider) in Core noch nicht.

Ciao herw

PS bei deinem und bei meinem Großprojekten fällt mir immer wieder unangenehm auf, dass die Entwicklungszeit bis zum Upload endlos lange dauert. So schön ein Großprojekt auch ist, aber manchmal sehne ich mich einfach danach, nur mal nebenher ein kleines Ensemble zu erstellen. Ich brauche einfach das Gefühl, dass ich etwas geschafft habe. Ich glaube, ich muss mal nebenbei ein kleines abgeschlossenes Projekt angehen.

da fällt mir übrigens ein: wie komplex sind deine Hüllkurvengeneratoren?
- zeitverzögertes Gate-Event
- tonhöhenabhängige Zeiten
- Kurvenformen

[MvKeinen]

Ich habe mir nochmals die Abbildung ntcell.jpg vom 1. Dezember angesehen. In der Struktur gibt es zwei Makros, die zwar Eingänge aber keine Ausgänge haben; was passiert da denn? Jedes Makro muss ja eine Außenwirkung haben, denn globale Busse gibt es ja (leider) in Core noch nicht.

Ciao herw

in dem genannten Beispiel geht es darum den Speicher auf "Sternförmige" Weise zu beschreiben. Hier werden bei "General Reset" Konstanten in den Speicher geschrieben. Die SPÄTER durch eine Iteration Flussaufwärts ausgelesen werden.

paralelmemory0.jpg

oft verwende ich ich folgende Methode. Hier wird ein Datensatz von der ersten Iteration gelesen, analysiert und prozessiert und danach von der 2. Iteration ausgelesen.

paralelmemory1.jpg

wenn die Anzahl der Macros "write something" wie in meinem Beispiel ins Uferlose wächst hat die serielle Verbindung des Arrays seine Grenzen (compilierungszeit) . Mit beschriebener Methode sind speichergebilde möglich die an große und Komplexität richtung unendlich gehen Auch die Compilierungszeit sinkt extrem. Ab einer gewissen Anzahl solcher Macros die mit R/W modulen serialisiert sind geht die compilierungszeit richtung 20-30 Sekunden und steigt mit Hinzufügen weiterer Macros exponentiell. Mit meiner methode gibt es damit keine probleme mehr. Wie schon gesagt hatte ich mal ein verschwenderisches Panel erstellt mit weit über 1000 Datensätzen welches nur 2 Sekunden zum Kompilieren brauchte. Die Multidisplays hatten da zusammen die anzahl von ca. 80.000 Objekten
Das ist allerdings nur ein Teil der Arbeit in richtung kurze Kompilierungszeit. Der andere Teil hat mit dem Mergen von verschiedenen Eventquellen zu tun und da ist mir in den letzten Tagen ein durchbruch gelungen indem ich ganz strickt durchgesetzt habe, dass es im gesamten Ensemble nur eine Eventquelle gibt die Befehlsfunktion auführen darf. Alle anderen Eventquellen: Midi, Mouse area, Automationsbus werden vom Primaryiterator "abgeholt". Da gibt es irgendwo ein eiziges "latch" was zwar funktionell nicht nötig wäre, was aber nun die Ladezeit des Ensembles von ca.50 Sekunden auf 2 Sekunden runterdrückt. Dazu will ich mehr schreiben nachdem ich hier das "setup" fertigdokumentiert habe.

PS bei deinem und bei meinem Großprojekten fällt mir immer wieder unangenehm auf, dass die Entwicklungszeit bis zum Upload endlos lange dauert. So schön ein Großprojekt auch ist, aber manchmal sehne ich mich einfach danach, nur mal nebenher ein kleines Ensemble zu erstellen. Ich brauche einfach das Gefühl, dass ich etwas geschafft habe. Ich glaube, ich muss mal nebenbei ein kleines abgeschlossenes Projekt angehen.

Da gehts Dir wie mir. Und wenns auch Paradox klingt, das ist einer der Gründe warum ich seit Jahren fast jeden Tag wie ein verrückter an dem System sitze. Ich will bald einen Punkt erreichen, an dem ich ca. einen tag brauche um ein komplexes Panel zu bauen um mich dann nurnoch um den Audiopart kümmern zu müssen.

da fällt mir übrigens ein: wie komplex sind deine Hüllkurvengeneratoren?
- zeitverzögertes Gate-Event
- tonhöhenabhängige Zeiten
- Kurvenformen

Noch nicht sehr komplex. Ich habe als grundlage die core-envelope aus "2-osc" genommen.

env.jpg

dann hab ich noch ne "Hold"-Phase dazugebaut und die Parameter modulierbar gemacht. Das war vor ca. 2 Jahren. Funktioniert gut. Und da ich im neuen System die Tonhöhe als Modulationsquelle habe können mit meinem Modulationsystem auch tonhöhenabhängige Zeiten realisiert werden.
Mit Kurvenformen hab ich noch nichts versucht. Linear für steigend, exponentiell für fallend schien mir bisher OK. Da muss ich aber noch einiges ausprobieren.

[MvKeinen]

Ich bin jetzt noch auf eine weitere Vermutung in bezug auf kürzere Kompilierungszeiten gekommen:

die Gruppierung von Funktionen innerhalb von Coremacros scheint sich auch auf die Schnelligkeit auszuwirken. Wenn man also Verschiedene Branches innerhalb eines Macros zusammenlegt erhöht das die Kompilierungszeit. Besser ist es diese Branches auch in der Anorgnung der Macros zu trennen.

Wie gesagt, bisher nur eine Vermutung.

Kann das jemand bestätigen?

Gruß

[MvKeinen]

Die Zuweisung von Modulationsquellen funktioniert jetzt mit drag and drop. In folgendem Video werden 2 Bänke mit jeweils 8 Hostautomationsreglern als Quelle benutzt.

Also bisher nur die Zuweisung. Modulationstiefe kommt als nächstes.

nähere Beschreibung in der Info des Videos:

https://vimeo.com/81807242

[herw]

Beeindruckende graphische Oberfläche! Sieht nicht mehr so frickelig aus wie im letzten Jahr.
Übrigens falls du mal dynamische Datentypen im modular framework benötigst, ich habe da noch irgendwo eine Posting von Max.

ciao herw

[MvKeinen]

Danke fürs ansehen!

Ja, ich hab alles ein bischen grösser gemacht. Das ist allerdings alles sehr variabel. Durch die Organisation in subroutinen und deren Datensätze kann ich jedes Element individuell gestalten ohne eine weitere Subroutine hinzuzufügen. Ich muss nur den Datensatz im setupbereich verändern.

hier der Datensatz eines Faders mit modulation. Die subroutine die damit versorgt wird stellt sozusagen eine Mousearea innerhalb der grossen Mousearea dar. hier geht es nur um die Funktion des Faders und nicht um die praphische ausgabe. Dafür gibt es wieder andere Subroutinen die sich automatisch auf den Fader beziehen können (Beispiel numeric value, value bar usw.) so können sehr leicht mit derselben Subroutine sehr unterschiedliche Darstellungsformen realisiert werden.

faderset.jpg

Das Posting von Max würde mich sehr interessieren.

[MvKeinen]

ich hab in den letzten Tagen eine Veränderung in der Datenverarbeitung des Projektes vorgenommen die relativ kompliziert war. Ziel war es Funktion und Grafische Ausgabe zu "entkoppeln". Einerseits ermöglicht das beliebig viele unterschiedliche grafische elemente einer Funktion zuzuordnen, (die Funktion "Fader" steuert numerische Ausgabe und Balkengrafik) was bei dem letzten Video schon sichtbar war. Neu hinzugekommen ist jetzt, dass mehrere Funktionen gleicher Art auf ein und denselben Wert zugreifen können. Jetzt ist es also möglich mit beliebig vielen Fadern den gleichen Wert zu editieren. Dazu gibt es nun eine Funktionsindexierung die eindeutig alle Elemente einer Gruppe zusammenfasst.

Anwendungsbeispiel: Mit meiner version der "stacked macro" lassen sich so Ansichten realisieren, in denen manche Elemente grösser dargestellt werden und andere sehr klein. Beispielsweise eine Sequenceransicht die eine Grosse Version des Sequencers und andere sachen nur zur Information in klein zeigt.

Video hier: https://vimeo.com/82632572

[herw]

super, so langsam solltest du mal die Verträge mit NI aushandeln für REAKTOR 6.1

ciao herw