Deutsches Reaktor Forum

Hallo,

ich wollte mich mal wieder ein wenig in Core üben und dachte ich könnte ja mal den primary Sequenzer nachbauen.
Leider stoße ich dann beim autom. Reset auf Probleme mit Event-Loops.
Der Counter soll sich bei einem externen Rst Signal zurücksetzen und natürlich auch nachdem er einen bestimmten Wert erreicht hat von selbst.
Das Screenshot zeigt bereits das Problem. (Z Anzeige am Compare Eingang).
Warum das passiert ist mir schon irgendwie klar, aber nicht wie man so etwas lösst.
Was muss ich denn zwischen dem Counter Ausgang und dem Reseteingang schalten damit es zu keinem Loop-Problem kommt?

hi,
die meiner meinung nach einfachste variante bestünde darin, das "Wrapping" innerhalb des Counters zu erledigen und den beim wrap resultierenden Resetwert auch dort direkt in die OBC- kette zu schreiben. Dazu müßtest du nur den Counterwert am write modul durch den resetwert ersetzen. Du wirst dann auch kein Zwangs- z-1 mehr sehen. Das nötige "Delay" ist schon dadurch gegeben, daß der OBC Speicher erst mit dem nächsten, eintreffenden Clock Event gelesen wird.
Alternativ und der Übersichtlichkeit wegen schöner ist es natürlich, wenn du das OBC nach draussen weiterführst, ein write modul anhängst und dort auch das wrapping ausführst.

Der Router in deinem Screenshot nach dem Compare >4 erzeugt übrigens kein event (außer beim init)!

Hast dunschonmal den ACEW Debugger ausprobiert? Ist in solchen Angelegenheiten äußerst hilfreich.

Hallo,

dank dir für deine Hilfe.
Habs leider immer noch nicht.
Das mit dem Compare >4 nur bei 0 hatte falsch ja.
Am Router gehört unten natürlich noch ein Latch.

In dem Counter gibt es 2 Writes.
An beiden habe ich das so versucht wie du es beschrieben hast mit dem Ergebniss, dass der Counter bei dem 2ten Trigger aufhört zu zählen.
Was mache ich nur falsch?
Hier mal das Innere des Counters (es ist auch der Core Counter aus der Reaktor Library)
Unten habe ich extra nochmal mein Ensemble angehangen.

In dem Ensemble kann ich deinen Versuch leider nicht sehen.
Aber zunächst nochmal: Dein Ansatz mit dem Feedback-Loop kann nicht funktionieren.
Das "Z" entspricht dem Z-1 Makro in der Library, welches Reaktor hier notwendigerweise eingefügt hat, da du es nicht selbst getan hast. Denn in Core darf es keine Eventloops wie in Primary geben. Solche Verbindungen müssen unterbrochen werden. Die Unterbrechung erledigt ein OBC-Speicher mit einem Write- und einem Read-Modul.
Der Wert eines in ein Z-1 eintreffenden Events wird im OBC Speicher gespeichert und das Event endet dort! In deinem Beispiel entspräche das "Stp".
Nun bedarf es eines Triggers oder einer Clock, um diesen Speicher wieder auszulesen. Dafür tickert im Z-1 Modul eine Sample Clock, sofern der Clock-Eingang an nichts angeschlossen ist. Dummerweise stehen in einer Event Core Cell aber alle Uhren still! Auf gut deutsch: Dein Stp-Event erreicht niemals das Compare Modul und auch nicht das Latch. Es bleibt im "Z" stecken...
Das Z-1 Makro funktioniert als logischer Unterbrecher übrigens auch nur deshalb, da der Parameter "Solid" ausgeschaltet ist. Wenn ich das richtig interpretiere, bedeutet das, daß die Makrogrenzen für die darüberliegende Ebene "unsichtbar" sind.

Nochmal zum Counter: Der obere Counter Ausgang ist nur ein Testausgang für den ACEW.
Der eigentliche Counterausgang ist in meinem Beispiel der -1 Ausgang. Wurde der Counter auf 1 resettet, so wird beim nächsten Clock Tick auch schön brav eine 1 ausgegebnen (und nicht 2).
Kleines aber wichtiges Detail: Das Wrap Signal, (also Reset auf 1) muß am unteren Eingang des Mergers angeschlossen sein, damit es das normale Countersignal (wäre Wert 5 beim Wrap) überschreibt.
gruß,
mark

Ach ok jetzt verstehe ich das Z - ich dachte das wäre nur eine Event-Loop Warnung.
Naja bin halt wirklich Core-Noob.
Dein Ensemble funktionert - allerdings schaltet der Reset Button von außen jetzt nicht auf 1 zurück sondern schaltet den Counter einfach vorwärts.

allerdings schaltet der Reset Button von außen jetzt nicht auf 1 zurück sondern schaltet den Counter einfach vorwärts.

Oh, ääh, ja, hab den knob aus versehen an den threshold eingang des separators angeschlossen.

Ich habe dir auch noch die Lösung mit Z-1 Makro unterschlagen. Ich mag das Z-1 halt nicht
Persönlicher Geschmack...

Ja das hätte mir auch auffallen sollen.
Allerdings am Input funktioniert es auch nicht richtig.
Der Button bewirkt dann erst einmal eine Schaltung vorwärts um dann erst mit dem nächsten Clocksignal zu resetten.

Die 2te Variante probiere ich gleich mal aus

Nachtrag:
Auch in der 2ten Variante von dir reagiert der Reset Button nicht richtig.
Er hat 2 Fehler: 1. schaltet er erstmal den Counter um eine Stufe weiter und 2. resettet er erst mit dem nächsten Clocksignal.
Der Reset von außen muss aber zwingend sofort resetten - so wie in meiner Version.

Kann sein, daß ich dir dein Reset zerschossen habe.
Aber ich glaube Du schaffst das!

Ich versuche es seit einer halben Stunde.
Entweder ich versuche nicht über den -1 Ausgang zu gehen - dann geht der Reset wie gewollt aber der Counter zählen von 2-4
Oder ich belasse es so dafür resettet der Button erst mit der nächsten Clock.

Ich bekomm es einfach nicht hin. :/

NACHTRAG:
Ich habe es jetzt.
Den Reset Button habe ich wieder genauso eingebaut wie ich es ursprünglich hatte.
Das Problem war, dass du den Reset Eingang im Counter als letzten Schritt nicht mehr hinzugemerged hattest.
Außerdem habe ich es wieder mit dem normalen Ausgang und nicht mit -1 probiert.
So sieht letzten Endes die Lösung aus.
Auf deine Idee die Abfrage nach innen zu verlegen und einfach mit als Reset hinzuzumergen bin ich einfach nicht gekommen.
Ich werde den Wert für die Compare Abfrage noch nach außen legen damit man schnell auch von außen einstellen kann ab wann der Sequenzer sich automatisch wiederholt.
Also nochmal danke - jetzt kann es weiter gehen

Hast du gemerkt, daß der Reset Button auch den Clock Osc triggert und somit auch ein Clock Event an die Core Cell schickt? Welches wiederum den OBC Speicher ausliest?
Was, wenn zuerst die Clock und danach erst das Reset Event den Counter erreicht? (weil asynchron)

Nimm dir den ACEW zu Hilfe! Kann ich dir nur wärmstens empfehlen.
Ist in der UL zu finden.

Schau mal in das Ens hier rein.
Ich will dich jetzt nicht komplett aus der Bahn werfen, aber vielleicht ist das ja trotzdem interessant für dich.
Das Wrapping im Counter ist hier per Bit Operation gelöst.
Das BIT AND spart ein paar CPU Cycles gegenüber dem Compare.
Allerdings funktioniert das nur, wenn die Anzahl der Countersteps einer Zahl der Reihe 2 hoch n entspricht. Das wäre bei dir ja mit 4 gegeben. Desweiteren muß der Zähler Null-basiert laufen. Also von 0-3.
Die Anwendung ist eigentlich easy.
An den einen Eingang des BIT AND Moduls schließt du das zu wrappende Signal und an den anderen die sogenannte Mask an. Das ist nichts weiter als eine einfache Konstante mit der Anzahl der Steps minus 1. Oder genauer gesagt 2 hoch n minus 1.
Im Beispiel also 2 hoch 2 = 4, minus 1 = 3

Damit der Counter am Ausgang wieder 1-basiert läuft, wird lediglich 1 zuaddiert.
Stattdessen würde ich aber eher die Vergleiche für die Latches hinter dem Counter auch Null-basiert stricken. Spart das +1.

Hmm.. rein theoretisch hast du absolut recht!
Aber bis jetzt war alles komplett syncron und selbst wenn es das nicht ist ist doch die Asyncronität derart gering, dass man das praktisch gar nicht mitbekommt.
Davon abgesehen möchte ich mir ja so wie so die Möglichkeit offen halten den Sequenzer unabhängig vom Clock-Signal zu resetten.
Genau deshalb musste das Reset auch sofort schalten und nicht erst bei der nächsten Clock.
Mit solchen unterschiedlichen Reset-Sachen kann man nämlich letzten Endes ziemlich coole Sachen machen - gerade beim Sequenzer.
Der ACEW ist wirklich toll und ist jetzt immer auch direkt in meinem Start Ensemble.
Der Sequenzer scheint auch sauber zu sein - jedenfalls kann ich keine Doppel-Events oder Asyncronitäten damit feststellen.
Wie gesagt ich möchte den Sequenzer ja mit Hinblick auf Audio nutzen.
Wenn ich damit genau rechnen müsste - wäre dein Einwand absolut berechtig - dann müsste man definitiv auf so etwas achten.

Ich möchte mich nochmal bei dir für die Zeit, die du für mich geopfert hast bedanken - du hast mir wirklich sehr geholfen!

Nachtrag:
Ja so schnell vergeht die Zeit.
Schwubs schon hast du einen neuen Post geschrieben.
Klingt echt interessant - wird sofort ausprobiert!

Aber bis jetzt war alles komplett syncron und selbst wenn es das nicht ist ist doch die Asyncronität derart gering, dass man das praktisch gar nicht mitbekommt.

Es geht um Eventreihenfolgen. Denn knapp vorbei ist auch daneben. Ich wette mit dir, du hast bei einem Reset über den Button in deinem obigen Beispiel "counter OK" zwei events am Counter Ausgang! Unmessbar kurz hintereinander, aber es sind zwei, und womöglich mit verschiedenen Werten! Und DAS ist wichtig. Der ACEW zeigt sie dir.
Schlecht ist es oft, wenn der eigentlich falsche Wert zuletzt kommt, oder irgendwo downstream events gezählt werden.

Genau deshalb musste das Reset auch sofort schalten und nicht erst bei der nächsten Clock.

In deinem Beispiel ist Druck auf Reset = ein Clock Tick
Aber du hast schon recht. Normalerweise würde man das Resetevent an den Counterausgang durchreichen (mergen).

Dank dir nochmal für die Hilfe.
Wie gesagt du hast absolut recht, dass ein doppeltes Event 1. unsauber ist 2. zu Problemen führen kann.
Aber in meinem Beispiel als Audio Sequenzer absolut ausreichend.
Ich habe ihne getestet und er arbeitet absolut korrekt syncron auch mit diesem kleinen Fehler.
Den Fehler jetzt noch auszubügeln und trotzdem alle Anforderungen so zu belassen wie ich ihn möchte ... hmm... dafür reicht mein Core "Wissen" leider nicht aus.

Aber was das wichtigste für mich ist - ich habe jetzt endlich so einen Sequenzer wie ich es eigentlich von dem primary Sequencer schon erwartet habe.
Und zwar Einen Eingang für Start Step und einen für End Step.
Das war früher echt nervig die Range die man abspielen wollte dann mit den Eingängen zum Startpunkt zu verschieben und ein zusätzliches Reset von außen für den Endpunkt zu setzen.
Jetzt kann ich einfach bestimmen von wo bis wo der Sequenzer wiederholt.
Mir ein Rätsel warum, die das nicht auch im primary so gemacht haben.
Dann hätten sie sich auch die 6,8,12,16 Step Module sparen können.
Die Anzahl der Eingänge hätten sie dann einfach so wie auch bei anderen Modulen in den Proberties einstellbar machen können.
Denn meiner ist quasi ein 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 und 16 Step Squenzer in einem.
Und wenn ich ganz cool bin verdoppele ich die Eingänge und habe einen 32 Step Sequenzer.
Dann kann ich auch die Laufrichtung von außen bestimmen.
Oder auch automatisch, wenn der Starteingang größer ist als der Endeingang.
Besser gehts nicht.
Ich überlege sogar eine Art Link-Ein- und Ausgang, sodass man mehrere Sequenzer mit einander verbinden kann und über den Link werden die nötigen Infos automatisch so gesendet, dass die verschiedenen Sequenzer Module nach einander durchgeschaltet werden.
Aber das ist im Moment nur so eine Idee.

PrinzThomas hat geschrieben:Dank dir nochmal für die Hilfe.

Gerne!