Seite 1 von 1

PARTIALS FRAMEWORK (erster Kontakt)

Verfasst: 14. Juli 2011, 08:32
von herw
Als ich das Partials Framework zum ersten Mal (Juli 2010) zu Gesicht bekam, war ich erschlagen von den vielen Makros sowohl in primary wie auch in core.
An den vielen Bezeichnungen ahnte ich, dass es nicht eine kleine Ergänzung zur allgemeinen Bibliothek ist, sondern ein großes Tor zu einer professionellen Programmierung in REAKTOR öffnete. Es ist für uns User schon sehr erfreulich, dass dies nicht zu einer höheren Version von REAKTOR führt, sondern nur so „nebenbei” in der library veröffentlicht wird.
Wenn alle Erweiterungen (primary-Ebene: modale Synthese, core-Ebene: partials framework) die Versionsnummer nur um einen zehntel Punkt anwachsen lässt, dann kann auf dem Weg zu einem R6 noch viel passieren. Ich möchte damit ausdrücken, wie mächtig diese Erweiterung ist.

Nun, zum Einstieg will ich helfen, wie man sich an diese Erweiterung herantastet. Jeder wird seine eigenen Vorlieben und Projekte haben; somit kann ich nur hier meine Eindrücke schildern und jeder mag sich daran entlangziehen oder auch abweichen.
Man muss sich klar sein, dass dies eine Erweiterung für den fortgeschrittenen Leser ist, der Weg, alles zu verstehen, ist lang.
Nach elf Monaten würde ich schätzen, dass ich etwa 5% des Ganzen verstehe und sicher anwenden kann, so dass ich auch mein eigenes ergänzendes framework erstelle.
Das heißt nicht, dass es unbedingt schwer zu verstehen ist, aber ich denke die Möglichkeiten sind einfach erschlagend. Stephan Schmidt hat es im englischen Forum als ein allgemeines Hilfsmittel beschrieben unter anderem zur Steuerung der modalen Synthese als eine Anwendung.
Auf dem Weg konnte ich aber von Anfang an großen inhaltlichen wie auch praktischen Nutzen daraus ziehen; das Niveau der eigenen REAKTOR-Programmierung steigt enorm und nachhaltig an.

ciao herw

PARTIALS FRAMEWORK (erster Kontakt)

Verfasst: 14. Juli 2011, 11:16
von herw
Möchte man dauerhaft mit partials framework arbeiten, so sollte man es in seine private Bibliothek aufnehmen:
favorit 1.jpg
Sicherlich habt ihr es in einen Eurer Unterordner geladen; damit es immer schnell verfügbar ist, lokalisieren wir mit Hilfe des DISKS-Reiters den Ordner partials framework.
Im Pulldownmenu DISKS können wir den Ordner zu den Favoriten hinzufügen:
favorit 2.jpg
Nun stehen uns alle Makros ständig zur Verfügung:
favorit 3.jpg
Wir schauen einmal kurz in den Ordner hinein und finden dort fünf Unterverzeichnisse, vier davon enthalten sowohl primary- als auch core-Makros:
favorit 4.jpg
Manche davon sind prall gefüllt:
favorit 5.jpg

PARTIALS FRAMEWORK (erster Kontakt)

Verfasst: 14. Juli 2011, 11:48
von herw
Im Gegensatz zur Standard-Core Bibliothek gibt es nicht zu den core-Makros entsprechende corecells in primary, um diese in primary zu benutzen, sondern beide Teile arbeiten dagegen Hand in hand, um so ein Gesamtkonzept (serielle Datenverarbeitung) zu verwirklichen.
Das machte die Sache nicht einfach, da die beiden Ebenen in wichtigen Dingen (Initialisierung, Threadsicherheit) völlig verschieden agieren und reagieren. Max hat in einem interessanten Artikel die Thread-Sicherheit (Abfolge von GUI-events, audio-based-events und audio-events) eindrucksvoll dargelegt bzw. deren Probleme und diese auch gelöst.
Ich werde darauf in einem anderen Thread mal eingehen; das sprengt aber hier den Rahmen.

Nachdem nun das Verzeichnis immer zur Verfügung steht, fragt man sich, wie kann man mit dem System am schnellsten warm werden. Ein Blick in manche (einfache) core-Makros lässt zunächst mal erstaunen, was sie bewirken und wie man sie einsetzt; also völlige Ratlosigkeit ist normal.
Da bleibt nur der Blick in die ausführlichen Dokumentationen.
Ich hatte den unschätzbaren Vorteil, schon früh mit Max persönlich diskutieren zu können und so schon die Startschwierigkeiten ansprechen zu können. An Dokumenten lagen damals nur der oben angesprochene Artikel vor und das Dokument zum Eventbus.

Ich habe nun auch alle fünf Dokumente vorliegen und hier ist mein Vorschlag, wie man sie lesen kann:

Nein, nicht die Introduction ist meiner Ansicht nach der Ersteinstieg, sondern der Artikel über das Multiplexing; ich habe daraufhin die Dokumente mal durchnummeriert, um nicht ständig darüber nachdenken zu müssen, wo was steht.
dokumente.jpg
Das Format der Dokumente erstaunt zunächst und man denkt unwillkürlich an eine Powerpoint-Dokumentation.
Die Idee ist, dass man nicht Satz für Satz durcharbeitet, sondern durchblättert.
Insbesondere die letzten beiden Artikel sind im Inhalt anspruchsvoll. Ich habe sie zunächst auch Wort für Wort bearbeiten wollen und war schon schnell völlig vor den Kopf geschlagen, da die Inhalte ungemein intensiv und fast schon komprimiert dargestellt sind.
Nach zwei erfolglosen Anläufen habe ich schließlich für mich den richtigen Dreh gefunden:
Egal, wie lang das Dokument ist (bis zu 128 Seiten), man sollte es in einer viertel Stunde durchgelesen haben!!???!!!
mit viel ::kaffee::
Es geht! Natürlich hat man nur 0,5% verstanden, aber man hat den roten Faden aufgenommen und erahnt die Idee. Nochmaliges Schnelllesen lässt schon die wichtigen Kapitel erkennen und dann geht es ans Werk; ich verspreche, es lässt einen nicht mehr los: es ist spannende Forschungsarbeit.

Natürlich will man auch selbst programmieren und man entwickelt tausend aufregende Gedanken, was man alles mit diesem Schatz anstellen kann.
Meine Gedanken sind auch nur begrenzt, also es wäre gut, wenn die Interessierten hier oder den anderen begleitenden Threads auch einfache Lernbeispiele hinzufügen.
Ich werde mich in den folgenden Threads an den Dokumenten orientieren und sie mit Beispielen anfüllen. Das wird sich sicherlich auch über Monate hinwegziehen, aber was soll's.

Für den Anfang lest ihr vielleicht das erste Dokument im Schnelldurchgang durch. Vieles wird Euch dort bekannt vorkommen, da mein Thread über den Eventbus darauf aufbaute.

ciao herw

iteration library (Teil 1)

Verfasst: 15. Juli 2011, 12:24
von herw
Nachdem jeder das (theoretische) Skript zum Multiplexing nun gelesen hat
::kaffee::
verschaffen wir uns einen Überblick über die Anordnung und den Inhalt des Frameworks:

iteration library (Teil 1)

wir öffnen den ersten Unterordner iteration_library, finden dort den Ordner core (mit + (Grabkreuz ?) also noch ein Unter-Unterordner)
iteration_library 1.jpg
und entdecken tatsächlich auch dem Programmierer so bekannte Ausdrücke wie for, iterator, while.
Als ich eines dieser Makros zum ersten Mal in PRISM entdeckte, war ich völlig baff. Was ist das? Sollte doch jemand core erweitert haben? Natürlich habe ich sofort nachgefragt, bekam dann auch den ersten Entwurf des Skripts zugesandt, der allerdings nichts Konkretes hergab. Also try and error und immer wieder nachgefragt. Max hat dann meine einfachen Beispiele korrigiert und weitere Tipps gegeben, bis ich schließlich auch Erfolge hatte.
Ja es ist Iteration in Core möglich; besser man würde sagen, es ist ein Konstrukt, so dass der Benutzer glaubt, die Iteration würde in Core stattfinden. Das ist nur teilweise der Fall; solange eine direkte Implementation noch nicht vorliegt, muss man eine Iteration außerhalb der Core-Ebene in primary zu Hilfe nehmen. Die Kontrolle darüber hat aber fast ausschließlich die CoreCell.
Ich gehe hier noch nicht weiter darauf ein, aber wir schauen uns mal nur kurz einige Makros an:
iteration_library 2.jpg
Wir sehen offenbar einen Spezialfall einer For-Schleife mit einer vorbestimmten Abfrage, daneben eine Standard-For-Schleife.
Sehr intensiv sollte man die zugehörigen Infotexte lesen. Eine solche Erklärungsfülle ist schon einmalig und muss besonders lobend hervorgehoben werden. Hier steckt unglaublich viel Arbeit drin; übrigens auch jeder port besitzt eine ausführliche Beschreibung!!!
Typisch für die Iterationen sind die Anschlüsse „-+” und ”+-”. Sie stellen die Verbindung zum außenstehenden primary Iterator dar. Die Bezeichnungen der Ports sind zunächst etwas gewöhnungsbedürftig, und ich habe auch gleich alles mit meinen Bezeichnungen umbenannt, um aber klein beizugeben, dass das nicht sinnvoll ist, da dies dann für andere nicht mehr lesbar wäre. Also alles so lassen wie es ist.
Die geschweiften Klammern dienen für eine genestete Iteration, das Fragezeichen dient für eine Abbruchfunktion, das Dollarzeichen $ beschreibt immer Werte.
Das rechte Makro ist eigentlich nur ein Teil einer Schleife, die Abbruchbedingung muss vorbereitet werden. Wenn man mal in das andere Makro klickt, findet man wieder den allgemeinen for iterator.
Wir nehmen noch kurz vier andere wichtig erscheinende Makros hinzu:
iteration_library 3.jpg
Wir öffnen kurz den singleshot und das while-Makro, staunen über die Struktur und registrieren zunächst einmal befriedigt, dass wir dort noch andere sinnvolle Iterationen bereit gestellt bekommen. Beim Singleshot fällt mir sofort als Anwendung der Arpeggiator von FM8 ein.
Die beiden anderen Makros output filter und merge haben diese geheimnisvollen +- ports. Aus der obigen Bemerkung können wir aber auch ohne Lektüre schon schließen, dass sie irgendetwas mit der Iteration in primary zu tun haben, wobei das Verbinden zweier Iterationen schon sehr verwunderlich ist und auf komplexe Strukturen hoffen lässt (nicht abschrecken lassen!).

iteration library (Teil 2)

Verfasst: 15. Juli 2011, 13:12
von herw
::kaffee::
iteration library (Teil 2)
ein sehr kurzer Blick in den Unterordner und drei typische Makros herausgenommen, ...
iteration_library 4.jpg
... lassen uns schon an den doppelten geschweifte Klammern das Aha-Erlebnis finden, dass hier nicht viel Neues geschieht, sondern einfach die Nestung verwaltet werden soll: klar irgendwie müssen die genesteten Iterationen ja auch abgeschlossen werden.
Befriedigt legen wir diesen Ordner für später beiseite.

Wir öffnen nun noch schnell den primary-Unterordner und sind schon fast enttäuscht, dass sich dort nur zwei Makros befinden:
iteration_library 5.jpg
na ja ist ja auch klar: partials framework ist eine Erweiterung der Core-Ebene und nimmt nur in begrenztem Maße primary zu Hilfe; wobei sehr erstaunlich ist, dass alles perfekt klappt. Max hat sehr lange daran arbeiten müssen, bis nichts mehr schief ging, auch nicht in irgendwelchen vertrackten Situationen (z.B. Initiaisierung). Dies ist nur möglich, wenn man die Zusammenhänge, Unterschiede und Gemeinsamkeiten der beiden Ebenen voll verstanden hat.
Hier also nochmals ein großes Lob an Max (und auch Stephan), dass wir ein so mächtiges und abgeschlossenes und relativ einfach zu verwendendes Werkzeug bekommen.
Auffallen sollten wieder die beiden „+-” ports. Aha, da ist die Verknüpfung zur core Iteration!

Innerhalb des chain iterators ist (enttäuschend?) wenig enthalten. Der zweite chain iterator (A), soviel kann ich schon mal vorweg nehmen, dient einer Iteration in audio-core-cells (!) . Die „+-”-ports sind hier grün gezeichnet, also werden sie auch audio-Signalen bereit gestellt.

multiplexing library

Verfasst: 15. Juli 2011, 17:25
von herw
multiplexing library

Hier werden die nötigen Makros in primary und core-Ebene zur Verfügung gestellt, die die Verwaltung und Auswertung eines Eventbusses, ermöglichen.
Es gibt verschiedene ähnliche Ansätze schon seit Jahren, die im englischen Forum diskutiert wurden, oder auch in der user library entsprechende Ensembles.
Hier ist nun ein komplettes Bündel an Makros, das keine Wünsche offen lässt.
Schauen wir zunächst in die Core-Ebene:
multiplexing_library 1.jpg
Die meisten Makros dienen zum Entschlüsseln des Eventbusses {b}, so dass die Makros typischerweise entweder den Eventbus {b} (orange) selbst oder die Parameter id, #, [] und $ (gelb) enthalten. Zwei Makros (blau umrandet) hängen eng miteinander zusammen, da sie das Interface für die Datenverarbeitung der Events darstellen.
Nebenbei bemerken wir, dass das Aussenden des Busses (Makro send synchronous) wiederum einen externen Iterator erfordert (grün).
In der primary-Ebene gibt es eine ganze Reihe von Makros, diese meistens aber auch nur in Varianten, um viele Eventquellen zu verarbeiten.
Der Unterordner boolean enthält nur Hilfsmakros, so dass man sich selbst Abfragen zurechtlegen kann.

Die primary Ebene:
multiplexing_library 2.jpg
Ich greife mal nur vier Makros heraus und füge zusätzlich noch den chain Iterator hinzu, um den Zusammenhang zur iteration ibrary aufzuzeigen.
Das Makro { b } mux vereint verschiedene Eventquellen zu einem Bus. In der Mitte gibt es drei Makros, um Busse in unterschiedlicher Weise zu verwalten.
a before b: der Bus {b} wird erst dann weitergeleitet, wenn der Bus {a} vollständig gesendet wurde.
message order: ist im Prinzip dasselbe Makro wie oben, nur dass dieselbe Message (siehe erstes Skript!) zweimal gesendet wird, quasi ein order-Modul für den Eventbus.
trigger on last: ist interessant, wenn man nach Senden einer Message an eine Corecell mit Hilfe des letzten Events etwas triggern möchte, zum Beispiel eine Iteration. Daher habe ich als eine Anwendung mal den chain iterator eingefügt. Der Triggerimpuls wird über den Ein-/Ausgang ! empfangen/ gesendet.

partials library

Verfasst: 15. Juli 2011, 20:03
von herw
partials library

Tja, was soll ich sagen: ca. 140 Makros, alle sehr spezialisiert zur Steuerung der modalen Synthese. Ich kann hier auf keine einzelnen Makros eingehen.
Ich muss zugeben, dass ich mich bisher noch nicht an diesen Ordner heran traute. Ich möchte zunächst die anderen Hilfsmittel der ersten beiden Ordner vollständig verstehen.

standard library

Verfasst: 16. Juli 2011, 10:22
von herw
standard library

Hier findet man viele nützliche allgemeine Makros, die man ganz vielfältig benutzen kann. Darunter sind auch viele Makros, die man immer schon erstellen wollte, aber nicht die Lust und Zeit dazu fand.
Interessant und sofort einsetzbar sind die getriggerten Rechenoperatoren im Unterordner latched_operations, die verschiedenen Rundungen im Unterordner math und die getriggerten booleschen Operatoren.
standard library.jpg

threadsafe initialization library

Verfasst: 16. Juli 2011, 10:34
von herw
threadsafe initialization library

Das ist eine ganz raffinierte Sammlung an Makros.
Sie schafft tatsächlich und absolut sicher die Möglichkeit, den Initialisierungsprozess bis ins kleinste Detail zu planen.
D.h. es ist egal in welcher Reihenfolge man ursprünglich eine Konstante, ein GUI-Element oder sonst etwas in seine Struktur eingefügt hat, man kann auch im Nachhinein noch genau festlegen, in welcher Reihenfolge Initialisierungsevents gesendet werden sollen, unabhängig davon, was der Compiler durch den Initialisierungsalgorithmus festlegt: genial, völlige Freiheit und Kontrolle!

Ich habe es schon ausprobiert und mit einem kleinen Einführungsbeispiel sofort und einfach eingesetzt (ist schon fertig, muss nur noch „schön” gemacht werden).

Resümee

Verfasst: 16. Juli 2011, 10:36
von herw
Das war's für einen ersten Überblick.

Ich hoffe, dass damit ein möglicher roter Faden für die Interessierten unter Euch gelegt ist.

Re: PARTIALS FRAMEWORK (erster Kontakt)

Verfasst: 16. Juli 2011, 14:31
von MvKeinen
Vielen Dank herw,

Für Reaktor User ist das ne sehr aufregende Zeit gerade.

Diese library ist der Beweis für die unfassbaren Möglichkeiten von R5. Was ich hoffe ist, dass die Macher irgendwann die Früchte in Form von vielen schönen UL uploads die davon Gebrauch machen sehen werden. Ich will mir garnicht vorstellen wieviel Zeit die da reingesteckt haben. Jetzt ist es an uns das zu würdigen und das langsam zu ertasten. Je länger ich mich mit Reaktor beschäftige, desto größer ist meine Ehrfurcht vor den Machern.