helmsklamm hat geschrieben:ich hab mal alles irrelevante entfernt, das das bild nich unötig strippig is.
ja das dachte ich mir! Sorry ich konnte mir das nicht verkneifen, aber wir hätten ohne Bild noch stundenlang diskutieren können und uns herrlich missverstanden
eines vorweg: aus deiner Struktur kann man erkennen, in welcher Art und Weise Du die Events verarbeitet haben möchtest; nur passt diese Denkweise leider gar nicht zum primary level, sondern ist typisch für das Denken in Core. Also wechsle zur dunklen Seite der Macht und ergib dich dem Core
Du möchtest, dass die Fader-Positionen der letzten Einstellungen gespeichert werden und dann beim Starten auch richtig initialisiert werden. Sie werden auch gespeichert jedoch nicht dort, wo sie sein sollen.
Ich kann noch nicht einmal Deine Struktur nachbauen, um das zu beweisen, denn dazu müsste ich die Reihenfolge kennen, mit der Du die einzelnen Strippen gezogen hast.
Deine Denkweise ist: alles findet gleichzeitig statt und ist dann auch gleichzeitig verfügbar. Dies ist falsch für primary level (aber in Core richtig!).
Beispiel:Das Trigger-Value-Modul zum Fader LS übermittelt bei jeder Änderung den Index 1 über das Merge-Modul zum Indexeingang des Multidisplays. Der Trigger übermittelt auch die Balkenbreite Deines Bars über die Koordinaten X1 und X2 (senkrechter Balken; für diejenigen, die das Modul noch nie benutzt haben: der Eingang Obj legt fest, um welche Art von Objekten es sich handelt; -1=Obj bedeutet bars (Balken)). Die Änderung des Faders übermittelt auch noch direkt über ein Merge-Modul den eingestellten Wert an Y1 (Höhe des Balkens).
Das sind während des Betriebs schon vier Werte, die an das Objekt 1 (Idx=1) übermittelt werden sollen. Durch den Event bei Idx werden diese Werte nachfolgend eingeschrieben. Was aber, wenn die Werte bei Y1, X1, X2 schon vor dem Idx-Event eintreffen? Dies kann man deiner Struktur nicht entnehmen. Du kannst es testen, indem Du alle vier Eingänge an den event-watcher klemmst und genau beobachtest, in welcher Reihenfolge die Events eintreffen; die Reihenfolge hängt davon ab, in welcher Weise du die Struktur erstellt hast (Einfügen der Module, Strippen-Ziehen); zur korrekten Abspeicherung muss der Idx-Event der
erste sein (Handbuch S.321, letzter Satz beim ersten Spiegelpunkt). Um das zu sichern, muss man den LS-Fader-Event mit Hilfe eines Order-Moduls aufsplitten, so dass der erste Event zunächst den Index übermittelt und dann über Trg-Value-Module der zweite Event sicherstellt, dass die aktuellen Werte an den entsprechenden Eingängen liegen und es so zur korrekten Speicherung kommt.
Wahrscheinlich hast du dabei durch diverse Änderungen und Neueinfügungen und Löschungen nicht bei allen drei Fadern darauf geachtet. Beim Starten muss auch noch berücksichtigt werden, dass die Konstanten selbstverständlich auch noch Events aussenden.
Das heißt, das was gleichzeitig erscheint ist nicht gleichzeitig. Du findest im Modular Mini 2 in der dritten Ebene des Makros
VW Grafik eine solche Steuerung:
In Core dagegen würden zum Beispiel die Events für Idx, X1 und X2 gleichzeitig innerhalb eines Event-Core-Moduls bereitgestellt; bei der Übergabe an das primary-level braucht man kein Order-Modul, da der oberste Ausgang den ersten Event liefert; d.h man ordnet die Ausgänge zum Beispiel in der Reihenfolge Idx, X1, X2 an. Es ist dann auch nicht schwer, noch Y1 entsprechend einzubauen. Die Konstanten kann man im Core-Modul direkt festlegen.
Warum wurde beim Bewegen des Faders alles korrigiert? Nun die Korrektur ist nur scheinbar, da jeweils die vorangegangenen Werte übertragen wurden, die sich natürlich im Bild schwer ablesen lassen.
Willst Du die Werte in einem Snap-Value-Modul speichern, musst Du in ähnlicher Form die Werte bereitstellen. Du findest im Modular Mini ein entsprechendes Makro direkt vor dem Makro
VW Grafik.
Du musst die Steuerung des Multi-Display genau erforschen, um dann eine korrekte Struktur aufzubauen.
ciao herw
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
