InterPHase by MvKeinen

[herw]

es scheint so, dass sich beim GRS auf der Empfängerseite value und id vertauschen.

das xy-Modul sendet im Gegensatz zum maus-area aber einen Initialisierungsevent?
Wenn du den Eindruck hast, dass sich in deinem Eventbus identity id und der eigentliche Wert value vertauschen, dann musst du die Initialisierung tatsächlich gründlich untersuchen.
Eigentlich kann das nicht passieren, wenn die Ausgabe des Wertes direkt an die Ausgabe der Identity gekoppelt ist. Dann muss es auf der Empfängerseite einen Fehler beim Erkennen von Id und val geben.
Ich benutze zur Analyse sehr gerne den Eventmonitor, da er als eigenständiges Instrument existiert und verfolge in einer Kette alle laufenden Events.
Wenn du die (farbigen) Empfänger einfach kopierst und dann in deine eigentliche Struktur einsetzt, werden die Daten anstandslos in den Eventmonitor übertragen; das ist sehr praktisch.

Die Initialisierung ist nicht so einfach, wie sie manchmal beschrieben erscheint.
Ohne eine konkrete Untersuchung mit isoliertem Beispiel kann man theoretisch wenig dazu schreiben.
Max Zagler hat sein framework auch mehrfach geändert, was zeigt, dass auch er nicht vor Überraschungen verschont blieb.

Kannst Du das Problem zum Vertauschen von Id und value so isolieren, dass es in einem stark reduzierten Beispiel erscheint?. Dann wird sich sicherlich eine Lösung finden.
Ein framework zum Eventbus muss sehr sorgfältig und gegen alle Unwägbarkeiten abgesichert sein. Das erfordert manchmal sehr ungewöhnliche Datenverzweigungen.
Konkreteres kann ich jetzt nicht sagen: also bitte ein Beispiel oder eine konkrete Beschreibung, dann springe ich schon darauf an.

Dein Projekt ist so umfangreich und zeitintensiv, dass du nicht ungeduldig werden solltest. Nicht die Schnelligkeit ist das Ziel, sondern die absolute Funktionssicherheit.

ciao herw

[MvKeinen]

ja das XY modul sendet korrekte Init Events.

Ich hab jetz ein minimales Testensemble gebaut um den Fehler einzuschränken. das einzige was ich am Eventbus von der Version aus dem Workshop geändert habe ist, dass ich auf der Empfängerseite ebenfalls die "zyklische" id weitergabe (immer +1) eingebaut habe wie es auch schon beim sender ist.

idchain.jpg

idchain2.jpg

daran kann aber nicht liegen, weil der Fehler auch auftritt wenn ich die ids durch konstanten direkt vergebe.

das Ensemble sieht so aus:

bustest.jpg

betätigt man den Switch GRS mehrere Male, so sieht man am Monitor, dass immer abwechselnd ein bzw. zwei events empfangen wird (werden). Somit funktioniert die Datenweitergabe abwechselnd. schließt man die Ausgänge des XY moduls direkt an den Monitor ist es korrekt.

Keine Ahnung woran das liegen könnte...

Gruss und danke schonmal. ich werd im nächsten posting das Ensemble anhängen, wegen beschränkung auf 3 dateien.

[MvKeinen]

hier noch das Ensemble.

[herw]

hier noch das Ensemble.

schau ich am Wochenende mal hinein; ich denke aber, das Problem ist einfach zu lösen ich habe nur im Moment keine Ruhe

[MvKeinen]

Eine Lösung hab ich jetzt gefunden, das Problem allerdings nicht.

wenn ich die Anzahl der Eingänge der Mergemodule auf die tatsächlich gebrauchten reduziere kommt der Fehler nicht mehr vor.

teillösung.jpg

Das heisst, dass wohl bei Initialisierung zu viele Events auf den id strang geschict werden.
das kann ich mir nicht erklären. Auch wenn ich jetzt weiterarbeiten kann würd ich sehr gern wissen warum das so ist...

[zama]

Eine Lösung hab ich jetzt gefunden, das Problem allerdings nicht.

wenn ich die Anzahl der Eingänge der Mergemodule auf die tatsächlich gebrauchten reduziere kommt der Fehler nicht mehr vor.

Hi,

1. Während der Initialisierung verhält sich Primary wie Core, nämlich synchron, d.h. Merger lassen beispielsweise nur ein einziges
Event durch, selbst wenn an allen Eingängen Events ankommen.

Das Order-Modul erzwingt am 2. und 3. Ausgang allerdings ein für Primary (meiner Meinung nach) logischeres asynchrones Verhalten.

2.In der send Cell ist zwar nichts an die Eingänge 2 - 9 des input merge m10 Macros angeschlossen, das bedeutet allerdings nicht, dass
dort keine Events erzeugt werden. Während der Initialisierung senden diese Ports Events (mit dem Wert 0) und zwar wie oben
angesprochen, synchron.

Dieses Verhalten kann man mit einem einfachen Router unterbinden:

suppress_init.png

Da nichts von außen an diese Ports angeschlossen ist, wird der Signalfluss durch den Router genommen. Der Router sendet aber nie ein
Event, da der Ctl-Eingang immer false ist!


1. & 2. ->
Von den synchronen Initialisierungsevents, die an den Eingängen 2 - 9 ankommen interessiert nur das unterste am Eingang 9. Das ist 0.
Von der send Cell werden also die Events id = 9 und val = 0 gesendet. Diese Events sind allerdings synchron, da sie nicht durch
Order-Module (2. / 3. Ausgang) gehen. Der Merger ignoriert das obere Event (id) und lässt nur die 0 durch. Der Bus "verschluckt" sich also,
da die 0 im receiver als id interpretiert wird.

In diesem Fall sollte man den Trick mit dem Router verwenden, oder wie du es gemacht hast einfach die Merger so verkleinern,
dass keine ungewuenschten Initialisierungsevents über den Bus gehen.

[herw]

Danke! Ich wollte es gerade auch posten.
Man kann diesen Initialisierungseffekt auch sichtbar machen, indem man mal an den untersten Eingang val9 von außen den Wert 1 anlegt, ohne den Router und den suppress-init-Quickbus zu benutzen. Dann werden (nur) beim Initialisieren drei Werte (x, y und die 1) gesendet.
Dasselbe passiert auch, wenn man an den Merger (in der CoreCell) unten eine Konstante anschließt

Der Merger ignoriert das obere Event (id) und lässt nur die 0 durch. Der Bus "verschluckt" sich also,
da die 0 im receiver als id interpretiert wird.

gemeint ist der primary-merger hinter der send-corecell.
Initialisierung ist echt vertrackt und man wird in jeder REAKTOR-Version immer wieder neu darüber nachdenken müssen.

Dieser genial einfache Trick (suppress init) muss einfach mal irgendwo (zum Beispiel hier ) erwähnt werden!
(ich liebe Eventbusse)

ciao herw

[MvKeinen]

Danke für die Erklärungen! Das mit dem Global reset ist schon manchmal "überraschend" für mich, allerdings will ichs nicht groß kritisieren, weil ich merke, dass er einen schon dazu zwingt die ganze Sache durchweg sauber zusammenzuschustern. Seitdem ich immerwieder einen Switch betätige beim Aufbauen erklärt sich mir auch einiges besser.

Vielen Dank für die Lösung! Werd gleich mal weiterschrauben

[herw]

Der Dank gilt einzig und allein Max

ciao herw

[MvKeinen]

Der Dank gilt einzig und allein Max

ciao herw

meinst du Max Zagler von dem Du im Eventbus Thread geschrieben hast?
Habt Ihr euch im Internationalen Forum ausgetauscht? Wenn ja gibt es da diverse Threads?

@zama:

Berlin ist Reaktorstadt

[herw]

meinst du Max Zagler von dem Du im Eventbus Thread geschrieben hast?

ja

Habt Ihr euch im Internationalen Forum ausgetauscht? Wenn ja gibt es da diverse Threads?

nö-nö

[MvKeinen]

WOW das partials Framework macht mich fertig .....

Im positivsten Sinne. Ich muss aber beim Sequenzer aufpassen, dass ich mich nicht verzettele. Der Eventbus funktioniert wunderbar. Ich kann mir garnicht vorstellen wie ich das ohne überhaupt soweit "gebracht" habe.

nochmal an dieser Stelle Danke an "zama" und "herw"

Der Bus hat mich gezwungen meine Struktur zu verändern (verbessern). Durch die neue Anordnung spare ich sage und schreibe 20 "Snap Value Arrays" 80 IC send->recieve Verbindungen.

Jetzt muss ich etwas Pause machen, andere Prioritäten, freu mich aber jetzt schon auf die nächste Phase, die zum Ziel hat eine Uploadfähige Version hinzubekommen.

Dann will ich das auch mal im internationalen Forum präsentieren für mehr feedback. Da möchte ich aber den richtigen Zeitpunkt abwägen, denn bisher hat mich die Familiäre Athmosphere hier weitergebracht, als das viele Schreiben und Lesen was dort unweigerlich nötig wäre. Ich hab da (EDIT: ich meine jetzt nicht speziell das NI Forum) nicht immer nur gute Erfahrungen gemacht.

[MvKeinen]

Jau, wollte mal den aktuellen Stand zeigen. Da fehlt noch so einiges, bin aber gerade wieder mit Hochdruck dran

Ansicht 1: Pitch

v0.3.jpg

Ansicht 2: Velo/Gatetime

v0.3B.jpg

[MvKeinen]

jau, wollte euch mal den bisherigen Stand der GUI meines Reaktorprojektes zeigen. Sound ist noch fehlanzeige.

Das "besondere" ist eine Modulationsmatrix die mit Drag n' drop funktioniert. Die modulationsquellen werden in ihrer jeweiligen Farbe durch Animation am Modulationsziel dargestellt. Weiss nicht genau, aber es könnte sein, dass es das in Reaktor noch nicht gibt. Das bringt ne tolle übersicht und lässt einen (hoffentlich) auch sounds schnell verstehen die man vor jahren gebaut hat.

https://vimeo.com/55749183

gruss D

[herw]

jau, wollte euch mal den bisherigen Stand der GUI meines Reaktorprojektes zeigen. Sound ist noch fehlanzeige.

Das "besondere" ist eine Modulationsmatrix die mit Drag n' drop funktioniert. Die modulationsquellen werden in ihrer jeweiligen Farbe durch Animation am Modulationsziel dargestellt. Weiss nicht genau, aber es könnte sein, dass es das in Reaktor noch nicht gibt. Das bringt ne tolle übersicht und lässt einen (hoffentlich) auch sounds schnell verstehen die man vor jahren gebaut hat.

https://vimeo.com/55749183

gruss D

ja sehr schön; sieht schon sehr professionell, wenn auch ein wenig „knibbelig”, aus; wenn ich das tonlose Video richtig interpretiere, erstellst du durch Anklicken einer Modulationsquelle und eines Ziels einen Signalweg; dieser öffnet quasi einen „Kanal”, in dem du Modulationsstärke etc. einstellen kannst. Ist das ganze Sequenzer-basiert oder mehr ein Modularsynthesizer? Die Bedienung scheint sehr eingängig und relativ einheitlich zu sein. Manches sieht allerdings auch überfrachtet aus (rechts die Hüllkurvengeneratoren mit unterlegtem Display). Vielleicht könnte man nach der Einstellung von Parametern auch wieder Teile ausblenden? Aber was soll's; du hast sehr viel Energie in eine neue Bedienoberfläche gesteckt.
Sehr sehr viele innovative Darstellungstricks! Bin gespannt, wie das ganze klingt und funktioniert.

ciao herw