UNIVERSELLER EVENT-LOOP-VERMEIDER

[Eventmanager]

Bei Eventloops frickel ich mir immer irgendwas zusammen.
Schluss damit, ich hätte gern ein Standard-Macro das Standard-Probleme wie im Bild löst (der 2MRG-Out würde am Merge ein Eventloop erzeugen.
Ich schätze in Core kann man dergleichen Geschichten effizienter lösen, als in Prim.

Wäre jemand so lieb, mir solch ein Teil zu basteln? Vielen Dank!

[herw]

Bei Eventloops frickel ich mir immer irgendwas zusammen.
Schluss damit, ich hätte gern ein Standard-Macro das Standard-Probleme wie im Bild löst (der 2MRG-Out würde am Merge ein Eventloop erzeugen.
Ich schätze in Core kann man dergleichen Geschichten effizienter lösen, als in Prim.

Wäre jemand so lieb, mir solch ein Teil zu basteln? Vielen Dank!

gerne! Womit vergleichst du im Makro comp< ? Kannst Du die gewünschte Funktionsweise bitte etwas genauer beschreiben?

Ich mache mal einen Schuss ins Blaue hinein:

bild_1.png (28.7 KiB) 3007-mal betrachtet

So wie ich deine Schaltung interpretiere, wird ein Reset (auf 0) ausgelöst, wenn ein bestimmter Wert überschritten wird (in diesem Fall 10). Ansonsten registriert der Speicher nur das Auf und Ab der Eingänge ++ und --.

[Eventmanager]

gerne! Womit vergleichst du im Makro comp< ? Kannst Du die gewünschte Funktionsweise bitte etwas genauer beschreiben?

Danke, für die Schalte, sehr aufmerksam, nur leider reden wir ein bissl aneinander vorbei. Ich suche eher eine GENERELLE Lösung, ohne jedesmal das komplette Macro einzucoren;-)
Also quasi einen Adapter den man einfach zwischen die kritische Rückverkabelung klemmt und voila!

Sagen wir, nur wenn am "Ausgang" eine Eins gesendet wird, schiesst der Adapter zum fraglichen (loopigen) Eingang und triggert das "Feedback" exakt einmal, dann ist sense.
Wenn ich hinter den Comp einen Stepfilter UND ein single delay (0.00001ms) klemme ist alles ok, ohne das Delay jedoch nicht. Also steppie+delay sind ein universeller-Ent-Looper-Adapter, nur hätte ich das gerne ohne delay aber in Prim komme ich da nicht ganz weiter.

[herw]

gerne! Womit vergleichst du im Makro comp< ? Kannst Du die gewünschte Funktionsweise bitte etwas genauer beschreiben?

Danke, für die Schalte, sehr aufmerksam, nur leider reden wir ein bissl aneinander vorbei. Ich suche eher eine GENERELLE Lösung, ohne jedesmal das komplette Macro einzucoren;-)
Also quasi einen Adapter den man einfach zwischen die kritische Rückverkabelung klemmt und voila!

Sagen wir, nur wenn am "Ausgang" eine Eins gesendet wird, schiesst der Adapter zum fraglichen (loopigen) Eingang und triggert das "Feedback" exakt einmal, dann ist sense.
Wenn ich hinter den Comp einen Stepfilter UND ein single delay (0.00001ms) klemme ist alles ok, ohne das Delay jedoch nicht. Also steppie+delay sind ein universeller-Ent-Looper-Adapter, nur hätte ich das gerne ohne delay aber in Prim komme ich da nicht ganz weiter.

genau das macht core, da ja der Speicher (counter) auf 0 zurückgesetzt wird. Bitte probiere es aus und schließe den ACEW (primary) an.

[Eventmanager]

genau das macht core, da ja der Speicher (counter) auf 0 zurückgesetzt wird.

Genau das macht deine SPEZIELLE Schalte für dieses SPEZIELLE Problem. Saubere Lösung, nur leider zu speziell. Ich habe aber ständig andere (Prim)Macros - nur das Teil-Problem (Loops) ist stets gleich und wie gesagt mittels 0ms-Delay auch UNIVERSELL lösbar, aber eben zum Preis eines Delays (das übrigens auch als reines Event-Modul mehr Leistung verbrät als simples Order-Step-Relais-Verbünde, weshalb ich darauf gerne verzichten würde.) Ich dachte deshalb an ein UNIVERSELLES Core-Macro, das ähnlich einfach dem Delay zwischen die kritische Rückverkabelung gesetzt wird und fertig.
Als Core-Laie denke ich sowas wie ein 1-displayrate-Versatz und gut ist - wobei, aha, ich teste nachher gleich mal das Display-Modul als value trigger, vielleicht gehts ja auch in Prim. Ich berichte morgen.

[herw]

genau das macht core, da ja der Speicher (counter) auf 0 zurückgesetzt wird.

Genau das macht deine SPEZIELLE Schalte für dieses SPEZIELLE Problem. Saubere Lösung, nur leider zu speziell. Ich habe aber ständig andere (Prim)Macros - nur das Teil-Problem (Loops) ist stets gleich und wie gesagt mittels 0ms-Delay auch UNIVERSELL lösbar, aber eben zum Preis eines Delays (das übrigens auch als reines Event-Modul mehr Leistung verbrät als simples Order-Step-Relais-Verbünde, weshalb ich darauf gerne verzichten würde.) Ich dachte deshalb an ein UNIVERSELLES Core-Macro, das ähnlich einfach dem Delay zwischen die kritische Rückverkabelung gesetzt wird und fertig.
Als Core-Laie denke ich sowas wie ein 1-displayrate-Versatz und gut ist - wobei, aha, ich teste nachher gleich mal das Display-Modul als value trigger, vielleicht gehts ja auch in Prim. Ich berichte morgen.

In Core denkt man anders, mehr in Richtung eines gemeinsamen Speichers (das war der allgemein gedachte Teil in meiner Struktur). In primary könnte man als Ersatz eventuell über eine gemeinsame Eventtable ( mit einer Zelle) nachdenken.
Generell ist es schwierig, die Unzulänglichkeiten der primary-Ebene durch coreCells ausgleichen zu wollen und umgekehrt.
Das Problem des Eventloops wird ja in primary automatisch gelöst, wenn man eventloops zulässt.
Ein Mischmasch der beiden Ebenen ist hier nicht nützlich. da sollte man gleich Nägel mit Köpfen machen und das Projekt jeweils direkt auf der Coreebene lösen.
ciao herw

[Eventmanager]

Die Idee mit der Display-Rate funzt nicht.
Mit erlaubten Event-Loops funzt es natürlich (auch ohne irgendwas) und am ACEW kommen exakt 2 events an (ohne Rückverkabelung nur eine - trotzdem weit entfernt von einem "Loop").
Aber es gibt doch einen TRIFFTIGEN Grund, warum Loops ausgeschaltet sind, oder bin ich hier zu übervorsichtig?

[Quietschboy]

Hallo Eventman,
die generelle Lösung einen Eventloop zu unterbrechen besteht darin einen Speicher zwischenzusetzen.
Egal ob in Primary oder Core, das Schema ist immer gleich.
Das Beispiel "selbstresettender Counter" ist prima, weil du das immer wieder brauchst.

Du hast jabselbst schon gemerkt, dass es ohne Zeitversatz nicht funktioniert, also muss irgend eine Art von Speicher dafür sorgen, dass dein Feedbackevent " abstirbt". Nur der Wert bleibt im Speicher erhalten und kann aber durch ein anderes, neues Event getriggert werden. Das Delay Modul tut das, hat aber den Nachteil, dass intern eine Clock tickt, die ständig abfragt, ob ein Event eingetroffen ist. Ausserdem ist fraglich, mit welcher Frequenz diese Clock läuft. Bei Control Rate ist die Auflösung natürlich viel zu grob und selbst bei Sample Rate hättest du für viele Anwendungen immer noch einen viel zu großen "Zeitversatz". Du brauchst einen "Event-Tick" Zeitversatz!

Die allgemeine Lösung besteht im Value Modul, oder in Core im Z-1 Macro!
Verabschiede dich einfach von der Vorstellung, deinen Counter sofort resetten zu müssen. Laß ihn, falls erforderlich, einfach vom nächsten Count-Event resetten.
In Primary gibt es dafür mehrere möglichkeiten, in Core kann man das etas eleganter lösen.
Eine praktische Lösung für Primary:
Triggerevent - Order (out1) - lese Value Modul - Compare ->True=reset Counter, False=nixmache
Order (out2) - trigger counter - counter output zurück an Value Modul

Falls das Compare doch hinter dem Counter liegen muss, vielleicht weil du nur ein bestimmtes Ergebnisevent des Counters für die folgende Strukur benötigst, könntest du das Resetevent vor dem Counter z.B mit dem "Smart Value" Macro aus Partials Framework abfragen.
Dieses funktioniert im Prinzip wie ein Value Modul, gibt allerdings nur ein Event aus, wenn auch eins vor dem Trigger eingetroffen war. Und das einmalig bis zum nächsten Val-event!

Ich kann dir im Moment leider keine Bildchen schicken, aber ich denke mit der Beschreibung müsstest du eigentlich klar kommen.

Grüße, Mark

[Quietschboy]

Eventloops sind in Reaktor vorsichtshalber standardmäßig deaktiviert, weil ein nicht zu einem Ende führender Loop Reaktor einfrieren lässt. So wie es auch in jeder anderen Anwendung passieren könnte.
In aller Regel kommst du aber mit dem Value Modul ohne Eventloops aus.

[Eventmanager]

Hey Quietschboy, danke.

Sry fürs DLY, hatte die letzen Tage persönliche Eventloops;-)
Oki, wenn ich dich richtig verstanden habe, bietest auch du eine Lösung für obiges, spezielle Prob. Ich hatte es aber zwischenlichtlich schon irgendwie hingefrickelt (auch ohne delay).

Was mich viel mehr interessieren würde und wenn ich dich richtig verstanden habe, meinst du dass man mit dem Z1 genau den gewünschten Versatz implementen kann?
Wirf mal bitte hier nen Korrektur-Blick drüber (DSP steht für display-rate was mW mit 25 herz läuft - für die meisten meiner Event-Geschichtchen schnell genug. Könnte natürlich auch ein Puls nehmen, oder Eventrate.... nur SR versuche ich zu vermeiden.

Bildschirmfoto 2015-06-23 um 16.18.44.png (8.41 KiB) 2928-mal betrachtet

Die eigentliche Frage: Wäre das die Art "Delay" die ich hin und wieder benötige, also wäre es ein "Single-Event-"Delay"" das wirklich erst triggert, wenn der untere port getaktet wird? In der Praxis, könnte bspw. die Triggerung noch vor den anderen Abläufen stattfinden (je nach struktur-platzierung/einfüge-reihenfolge...), also um sicher zu gehen, müsste ich wahrscheinlich 2 in reihe schalten, so das tatsächlich erst beim übernächsten der finale Trigger gesendet wird.
Is vielleicht Gefrickel, aber ich danke, das müsste präzise und korrekt genug sein. Oder übersehe ich was Grundlegendes?

(KA ob die Ports so rum richtig sind;-) und ist das Teil intern step (init)-gefiltert oder nicht?

[Quietschboy]

...
Was mich viel mehr interessieren würde und wenn ich dich richtig verstanden habe, meinst du dass man mit dem Z1 genau den gewünschten Versatz implementen kann?

-->Jein, nur für Core! Core selbst erlaubt sowieso keine Eventloops. Baust du in Core einen Loop, so wird automatisch ein (rotes) Z^-1 an einem Inport erstellt. In Audio Core Cells triggert dann automatisch die SR.C das rote Z^-1.
Es ist auch nicht möglich eine Core Cell zum unterbrechen eines Eventloops in Primary zu verwenden.

Wirf mal bitte hier nen Korrektur-Blick drüber (DSP steht für display-rate was mW mit 25 herz läuft - für die meisten meiner Event-Geschichtchen schnell genug. Könnte natürlich auch ein Puls nehmen, oder Eventrate.... nur SR versuche ich zu vermeiden.
Die eigentliche Frage: Wäre das die Art "Delay" die ich hin und wieder benötige, also wäre es ein "Single-Event-"Delay"" das wirklich erst triggert, wenn der untere port getaktet wird?

--> Richtig. Für Core interne Sachen. Ist der Triggerport nicht angeschlossen, so triggert auch hier in Audio Core Cells automatisch die SR.C (siehe Eingang im z^-1 Macro.

In der Praxis, könnte bspw. die Triggerung noch vor den anderen Abläufen stattfinden (je nach struktur-platzierung/einfüge-reihenfolge...), also um sicher zu gehen, müsste ich wahrscheinlich 2 in reihe schalten, so das tatsächlich erst beim übernächsten der finale Trigger gesendet wird.

--> Hab ich nicht ganz verstanden worauf du das beziehst. Erklär mal genauer

Is vielleicht Gefrickel, aber ich danke, das müsste präzise und korrekt genug sein. Oder übersehe ich was Grundlegendes?
(KA ob die Ports so rum richtig sind;-) und ist das Teil intern step (init)-gefiltert oder nicht?

--> Das z^-1 produziert selbst nur dann ein Init-Event, wennn der Triggerport nicht angeschlossen ist. Ansonsten hängt es davon ab, ob zur Initialisierung ein Init-Event am Triggerport anliegt oder nicht

Die selbe Frage wurde neulich übrigens auch im englischen Forum gestellt:
http://www.native-instruments.com/forum ... fe.258745/

[Eventmanager]

Lieber quietschboy,

jo hatte neulich nen Gedankenknoten. Das Z1 das ich beschreibe, ist ja nix anderes als ein Value- (erst dann)"trigger"-Modul. Und da ich fast ausschliesslich in Prim unterwegs, warum hier plötzlich so "core-umständlich".
Iss genau wie du schreibst - im Prinzip lässt sich jeder loop mittels einem oder mehreren Value-Modulen (+Order) sauber auflösen. Manchmal reicht ein Value_Modul, oftmals aber benötigt man mehrere (und andere "Rückschalten", eg Compair/Yes/No/If...). Es bleibt ein "Einzelfall-"gefrickel", das stets exklusiv implementiert werden will.

Mit "Reihe" und sukzessivem End-Trigger meinte ich Fälle, wo du nicht sicher bist das genau jetzt, die kritischen Events schon abgearbeitet sind und wo du stattdessen erst beim nächsten Trigger der "Clock" den tatsächlichen "In-Trigger" sendest. Das debug-show-event-init/module-order ist dahingehend dein bester Freund.
Und manchmal brauch man halt "Value_Module" die nicht bei der aktuellen "Clock" triggern, sondern erst beim nächsten "Event". Übersetzt ist das Value-Module ja nichts anderes als ein Z1 (mit "Abtastraten-trigger") - Ein modulo oder ähnliches davor und wir haben das "Ein-Event-Delay".

[Quietschboy]

In Core gibt es aufgrund der möglichen, virtuellen Gleichzeitigkeit zwei "Latch-Makros".
Das eine ist das Latch --> erst schreiben, dann lesen
das andere das Z^-1 --> erst lesen, dann schreiben
Für das Z^-1 ist ausserdem "Solid" deaktiviert, damit es von der darüber liegenden Struktur auch als "Unterbrecher" erkannt wird.

In Primary gibt es keine Gleichzeitigkeiten (ausser bei Init). Insofern gibt es auch nur EIN Latch in Form des Value-Moduls. Ich vermute es entspricht dem Z^-1. Also erst lesen, dann schreiben.
In Primary gibt es keine "aktuell Clock" sondern nur "nächste Events", bzw. Clock-events.

Deine Beschreibungen sind oft sehr schwer nachvollziehbar. Screenshots würden die Sache deutlich vereinfachen.

[Eventmanager]

Deine Beschreibungen sind oft sehr schwer nachvollziehbar. Screenshots würden die Sache deutlich vereinfachen.

War nur allgemein gesprochen, aber einen Screenie meiner Gedanken ... das wär doch mal was, aber die nächsten 10-15 Jahre wird das wohl noch nüscht;-)
Danke für deine Ausfrührungen.