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.