Toggle Button mit Trigger Funktion

[MUZON]

Hallo wieder ein kleines Problem.

Wie kann ich Signal von einem Button im Toggle Modus, zu einem Trigger umwandeln.

Der Toggle gibt ja ein Null bei nicht aktiviert, und eine Eins bei aktiviert, ich möchte das am ende der kette (aus was soll die bestehen?) immer zuerst eine Eins und dann eine Null erhalte, und so soll es laufen:

ich Drücke Button im Toggle Modus, und erhalte zuerst eine Eins die nach einer kurze zeit auf Null herunter steigt
ich drücke erneuert Button und erhalte wieder eine Eins die nach kurze zeit auf Null herunter steigt

Sozusagen egal was ich mit Button im Toggle Modus mache on oder off , dass ich immer eine Eins erhalte nach der dann eine Null folgt und auch bleibt, biss ich wieder drücke.

[herw]

ToggleToTrigger.jpg

ciao herw

[Quietschboy]

Hi,
das Primary-Pendant zu Herw´s Vorschlag wäre das Value Modul:

toggel - trigger.jpg

allerdings fehlt auch hier, wie in der Core Lösung, deine gefragte Null.
Falls du diese wirklich brauchst, könntest du z.B. ein HOLD hintendranhängen:

trigger 1 dann irgendwann 0.jpg

Für das Hold Modul kannst du zwar mit einer Konstante am H-Eingang die Wartezeit in Millisekunden angeben, aber da die tatsächliche Wartezeit zur Control-Rate synchronisiert ist, stimmt dies nur in etwa. Oder anders formuliert: Die Null wird erst mit dem nächsten Control-Tick nach Ablauf der am H-Eingang anliegenden Waretezeit ausgegeben.

Noch eine andere Lösung wäre die Verwendung des Order Moduls. Hier wird die Null am zweiten Value Modul sofort nach der Eins getriggert. Also dann, wenn der Zweig am ersten OutPort des Order Moduls bis zum bitteren Ende durchgerechnet ist. Ich denke das wäre die einfachste und effizienteste Weise deinen "Trigger mit Reset" durchzuführen, sofern die Null wirklich SOFORT folgen darf.

trigger 1 dann sofort 0.jpg

Gruß Mark

[herw]

oh sorry, ich habe den Text nicht genau genug gelesen und dachte, es sollte ausschließlich eine 1 gesendet werden. Durch eine kleine Änderung lässt sich das in core ganz einfach lösen: zeitgleiche Events in core werden an mehrere CoreCell-Ausgänge von oben nach unten ausgegeben:

ToggleToTriggerGate.jpg

Dies entspricht in etwa der primary Lösung. Im primary muss man aufpassen, wie das order-Modul und das merge-Modul die value-Werte beim global reset verarbeiten; dort werden nämlich zuerst eine 0 und dann eine 1 gesendet! Core sendet in der gezeigten Lösung beim global reset nur eine 0.
Man kann dieses Event noch zusätzlich unterdrücken, wenn man möchte:

ToggleToTriggerGate2.jpg

Die primary Lösung sendet übrigens die beiden events in Abhängigkeit, wie die gesamte Schaltung verdrahtet wurde. Würde man zum Beispiel dieselbe Schaltung nochmals verwenden, dann kann das Senden der 0 und der 1 auch völlig gemischt gesendet werden. Core sendet dagegen beide events immer direkt hintereinander (ausprobieren!)

ToggleToTriggerGate3.jpg

ciao herw

[Quietschboy]

Im primary muss man aufpassen, wie das order-Modul und das merge-Modul die value-Werte beim global reset verarbeiten; dort werden nämlich zuerst eine 0 und dann eine 1 gesendet!

hm, wie meinsten das? Kann ich nicht ganz nachvollziehen, da der 2. Ausgang am Order definitiv nach dem ersten abgearbeitet wird.
Ein Testensemble mit einem Init Debugger und meinem AudioCoreEventWatcher zeigt in beiden Messinstrumenten an, daß auch bei der Initialisation zuerst die 1 und danach die 0 kommt.

toggel - trigger init.ens

Die primary Lösung sendet übrigens die beiden events in Abhängigkeit, wie die gesamte Schaltung verdrahtet wurde. Würde man zum Beispiel dieselbe Schaltung nochmals verwenden, dann kann das Senden der 0 und der 1 auch völlig gemischt gesendet werden.

Was aber eigentlich nichts an der Reihenfolge der Eins und der Null ändern dürfte.

Gruß
Mark

[herw]

Im primary muss man aufpassen, wie das order-Modul und das merge-Modul die value-Werte beim global reset verarbeiten; dort werden nämlich zuerst eine 0 und dann eine 1 gesendet!

hm, wie meinsten das? Kann ich nicht ganz nachvollziehen, da der 2. Ausgang am Order definitiv nach dem ersten abgearbeitet wird.
Ein Testensemble mit einem Init Debugger und meinem AudioCoreEventWatcher zeigt in beiden Messinstrumenten an, daß auch bei der Initialisation zuerst die 1 und danach die 0 kommt.

toggel - trigger init.ens

ui der „normale” eventwatcher liefert beim global reset tatsächlich zuerst eine 0 und dann eine 1 das ist ganz übel. Da vertraue ich dem init debugger und deinem ACEW mehr. Übrigens ganz tolle Arbeit und hat mich hier auch überzeugt (großes Lob)!

Die primary Lösung sendet übrigens die beiden events in Abhängigkeit, wie die gesamte Schaltung verdrahtet wurde. Würde man zum Beispiel dieselbe Schaltung nochmals verwenden, dann kann das Senden der 0 und der 1 auch völlig gemischt gesendet werden.

Was aber eigentlich nichts an der Reihenfolge der Eins und der Null ändern dürfte.

naja kommt darauf an, ob man anschließend mehrere Events direkt miteinander verknüpft. Da verlasse ich mich lieber auf core; dort kann man zeitgleiche Events definieren. Aber wem sag ich das?
ciao herw

PS: ich bin übrigens so begeistert von deinem ACEW, dass ich ihn in ein Extra-Instrument gepackt habe, so dass er unabhängig vom Hauptpanel arbeitet.

[Quietschboy]

Danke für das Lob! Dabei finde ich den Primary Part des ACEW etwas schluderig hingewürgt. Eigentlich hätte ich das auch lieber in Core gemacht, aber ich dachte mir, das wäre doch mal wieder eine schöne Übung für Primary Außerdem gibt es noch offene Fragen bezüglich Floats und andere Zahlen in Reaktor, die auch den ACEW betreffen. Aber das wäre, denke ich, genug Stoff für einen neuen Thread.

PS: ich bin übrigens so begeistert von deinem ACEW, dass ich ihn in ein Extra-Instrument gepackt habe, so dass er unabhängig vom Hauptpanel arbeitet.

GUTE IDEE! So schön die Übersicht auch ist, nimmt er doch viel Platz weg. Ich komme auch so langsam auf den Geschmack ihn für Primary Testzwecke zu "mißbrauchen". Das eine oder andere Lichtchen ist mir mit dem ACEW schließlich schon aufgegangen:
Z.B., daß während der Initialisation in Primary nicht nur alles gleichzeitig feuert, sondern auch überall in der Struktur die Events gleichzeitig existieren!!!!!
Unglaublich, aber war. Das erklärt auch , warum an dem Merger oben, hinter deiner EventCoreCell, nur die Null durchrasselt. Die Eins am oberen Eingang wird überschrieben, weil gleichzeitig (was ja im Normalbetrieb unmöglich ist). "Gleichzeitige Existenz" ist vielleicht etwas verwirrend formuliert. Richtiger wäre wohl zu sagen, daß bei Modulen mit mehreren In Ports auf das Eintreffen aller anderen Events "gewartet", und erst dann das Ergebnis ausgegeben wird - Wenn man sich die Struktur als einen Irrgarten vorstellt, in dem jedes Event alle seine möglichen Verzweigungen abschreiten muß.
Die Gleichzeitigkeit gilt natürlich nicht zu den letzteren Schritten der Initialisierung (Order: Out2+3, Iteration, etc, - wie´s in der initialisation.pdf steht).

Grüße und auch ein DICKES LOB ZURÜCK für deinen Modular, herw! Hammerhart!
Mark