Erkennen und Unterdrückung von Initialisierungen

[herw]

Für all diejenigen, die sich mit den Initialisierungen herumschlagen, habe ich mal ein Ensemble mit dem Makro von Dietrich Pank (REAKTOR Entwicklerteam) hoch geladen:

catch soft init 2018-03-11.ens.zip

1.png

[Quietschboy]

Ich persönlich hadere etwas mit dem Macro von Dietrich.

Aber erstmal zur Funktion:

Der Inport "Primary Init" muss mit einer Primary Konstante verbunden, und möglichst on TOP, ganz oben, in der Core Cell stehen.

Die Bundle-Outports Hard, Soft und Any geben die entsprechenden Init-events aus - als "Trigger", also jedesmal:
Hard: "Hard Init", "Full Init", "INIT"
Soft: "Soft Ini"t, "Re-Init"
Any: beide, also Hard- und Soft Init

Die Gated-Outports HardG, SoftG und AnyG geben das Gate zu den entsprechenden Initialisierungsarten aus und dienen also zur Unterdrückung solcher Events.
Hierbei sind allerdings auch gleich noch post-init events (Order Module Out2+3, Iteration, Snap Array und noch eins zwei anderen Module) betroffen, die mit diesem Gate mit rausgefiltert werden. Das sollte man wissen. Muss nicht stören, kann aber.

Eintreffende Hard-Init-Events alleine, also ohne deren post-init events, lassen sich grundsätzlich per ES-Module ohne belegten Eingang filtern:

Hard Init Blocker in Core.jpg

Für Soft-Init Events ist das nicht der Fall !!! Die Re-Initialisierung existiert seit R6 nicht mehr in Core. Ausgenommen sind Reaktor5 Legacy Cells, die das alte Initialisierungsschema von Reaktor 5 beibehalten! Soft Init events tauchen also in Core nur noch nacheinander an den Core Cell Eingängen auf (from Top to Bottom, in R5 Legacy Cells gleichzeitig) und lassen sich nur über eine Top/Bottom-Port Lösung diskret fangen. Das heißt, das ES Modul ist zum Fangen von Soft-Init Events nutzlos, da es keine Gleichzeitigkeit zweier Cell-Inports für soft-init mehr gibt und Core selbst keine soft-init events mehr generiert!
Die Fiber "Soft" in Dietrich´s Macro kann also nur als reiner Trigger, nicht zum fangen, verwendet werden, wobei der logische Zeitpunkt, bzw. die Reihenfolge des Erscheinens während eines re-init von der Position des Core Cell Inputs "Primary Init" zu den in Korrellation stehenden anderen Event Inports abhängt!

Die Fiber "SoftG" kann außerdem nur dann zum blocken aller soft/re-init (incl. post init) events aller Inports dienen, wenn der Inport "Primary Init" an oberster Stelle der Core Cell liegt (TOP). Ansonsten können nur die Ports welche unterhalb stehen, für die Filterung berücksichtigt werden. Für Ports oberhalb dürften nur die post-init events gefiltert werden, während die eigentlichen init events durchflutschen.

Dietrich´s Macro benötigt zudem eine ständige Abfrage mit SR (im Dup Filtr) , welche das erste Sample nach Init bestimmt. Also das Ende von post-init, bzw., wie Dietrich es nennt, "any init past".
Hier sehe ich auch keinen anderen Lösungsweg das Ende für post-init in Core zu deklarieren, wobei ich es für theoretisch möglich halten würde, dass es normale Reaktorevents zwischen post-init und dem nächsten Sample Tick geben könnte. KÖNNTE.
Was könnte es denn sein? MIDI, OSC und GUI. Ich gehe jede Wette ein, dass die Sample-synchronisiert sind und dementsprechend frühestens zum ersten Sample nach Init auftreten können. Für CLOCKS gilt das allemal. Aber wer weiss?
Auf jeden Fall besteht die Möglichkeit mit entsprechenden Blockern schon in Primary eine SR-Abfrage in Core zu umgehen. Indem man erst gar keine unnötigen init und post-init events nach Core lässt.

[herw]

Dankeschön für deine Erklärungen; der LegacyMode war mir immer schon ein Buch mit sieben Siegeln. So ist es für mich endlich klarer.
Dass sich primary und core an dieser Stelle beißen, ist nur noch nervig, aber auch nicht verwunderlich, da ja beide verschiedene „Väter” haben.

[128bpm]

Mal kurz OT.

Ihr beide habt ja schon viel Erfahrung mit Reaktor. Wäre C++ nicht eine Alternative für euch?

[herw]

Mal kurz OT.

Ihr beide habt ja schon viel Erfahrung mit Reaktor. Wäre C++ nicht eine Alternative für euch?

nö, nachdem ich gefühlt zehn Programmiersprachen kennen und lernen musste, durfte, hat es mir gereicht. Ich finde Reaktor als grafische Programmiermöglichkeit gerade richtig; bloß keine Befehlsstrukturen mehr schreiben. Strippenziehen macht viel mehr Spaß.

[Quietschboy]

Irgendwie musste ich ja jetzt mal Ordnung in meine ganzen rumfliegenden Init Macros bringen.
Hier sind jetzt schonmal ein paar wichtige dabei. Einige beinhalten auch nur ein oder zwei Module und treten unverpackt ständig in Library Ensembles auf. Alte Bekannte, sozusagen. Die Umverpackung hier dient somit teilweise einfach nur zur Erläuterung.
Die Makros haben teils recht lange Namen bekommen, so dass die Funktion für jeden eindeutig zu erkennen ist. Aber das läßt sich ja ändern...

Init Macro Sammlung 01.jpg

Init Macros 01 (Forum).zip

[herw]

Dankeschön; das ist doch mal was für die ultimative Intiailisierungeslibrary.

[herw]

erwähnen muss man unbedingt, dass beim Abfangen des re-init in einer CoreCell mit Hilfe einer von primary „importierten” Konstanten-Initialisierung sowohl in Marks als auch Dietrichs Version die CoreCell nicht im R5-Legacy-Mode laufen darf, sonst wird der re-init nicht geblockt.
hier mal am Beispiel von Marks Version:

aktivierter legacy mode

Bild 1.png

deaktivierter legacy mode

Bild 2.png

[Quietschboy]

Äh, ja , stimmt. Re-Init ließ sich in R5 einfacher abfangen. Mal schauen, vielleicht hänge ich die R5 Core Init Macros der Vollständigkeit halber noch an. Oder hat sie jemand parat?