Hey JPK,
danke für deine ausführliche Antwort 
Ich auch nicht
. Aber wofür?
Hier muss ich mal meine Unwissenheit offenlegen ^^. Die Chaser-Effekte in DMXC sind ja praktisch immer Lauflichter mit unterschiedlichen Timings und Block- / Stepgrößen, die man praktisch durch Fannings ja auch relativ elegant in einer loopenden Cuelist realisieren könnte. Eine ColorList mit 3 Farben könnte man ja auch durch 3 Cues und den jeweiligen Fannings auf den RGB Werten darstellen. Damit verliert man zwar die einfache Möglichkeit der Erweiterung einer weiteren Farbe zur ColorList, ohne die bestehenden Cues anpassen zu müssen, gewinnt jedoch an Flexibilität. Ich persönlich sehe gerade nicht den Vorteil, konzeptionell in statische und parametrisierbare Chaser unterscheiden zu müssen. Möchte ich einen als Cuelist erstellten Chaser nicht live ändern, erstelle ich Cues mit ablosulen Farbwerten. Gleichzeitig besteht jedoch durch euer Konzept die Möglichkeit, hier auch eine parameterisierbare CueList zu erstellen, die 3 Farbpositionen durchschaltet, der jedoch die Farben selbst absolut egal sind und sie sie sich aus 3 verschiedenen ColorMastern holt.
Ich schreibe das jetzt mal bewusst etwas provokanter: Lass solche Probleme unsere sein
Stimmt natürlich, der Kontext war einfach der Folgende: Im Stream sagt ihr, DMXC ist historisch über 15 Jahre hinweg gewachsen und ihr seid dran, so wie es die Zeit zulässt, die älteren Fenster Stück für Stück zu erneuern (z.B. von Forms auf WPF umzustellen). Und dann zeigt ihr den damals neuen ColorList Editor mit dem Choose Color Window, das leider so gar keine Parallelen zu der für meine Begriffe besseren, alten DeviceControl Color Property hat. Auch wenn ich technisch, wie bereits richtig festgestellt, absolut keine Ahnung von der kongreten Realisierung habe, würde ich mir trotzdem wünschen, irgendwann an allen Stellen im GUI, die die Farbe eines Gerätes abbilden, den gleichen Dialog zu sehen. Und wenn ihr dann solche nicen Features wie den Master - Support in diesen Dialog einmalig einbaut und es einfach dann sowohl im DeviceControl, als auch in der ColorList automatisch funktioniert, dann wäre das doch spitze, oder?
(Klar ist es komplex das kongret zu realiseren und es wird auch nicht übgerall so einfach, wie ich es mir vorstelle, funktionieren. Aber die Grundidee zu verfolgen, vlt. nicht so strick zwischen parametrisierbar und statisch zu unterscheiden, fänd ich gut)
Das ist eine Frage der Sichtweise. Ich kann entweder sagen: "Master gehen überall außer an diesen 1000 Stellen". Oder ich kann sagen: "Master gehen nirgends, außer an diesen 5 Stellen". Wir machen eigentlich letzteres. Und dann ist das nicht mehr wirklich viel zusätzliche Doku zu verwalten
Punkt für dich
Danke, dass du dir Gedanken machst. Aber wenn du das so schreibst wirkt das so, wie wenn du uns vorwirfst, hinter DMXControl 3 steckt kein Gesamtkonzept und wir würden (überspitzt formuliert) für jedes neue Feature das Rad neu erfinden. Dem möchte ich hiermit entschieden entgegen treten. Wir stimmen uns natürlich intern sowohl innerhalb der Entwickler als auch mit den anderen Vereinsmitgliedern bei den Features ab und wie diese umzusetzen sind. Es wird mehrfach darüber diskutiert, wie sich ein Konzept in die bestehenden einfügt und wo man es wiederverwenden kann.
Ja, es gibt Stellen in DMXControl 3, die sich von den Konzepten und Denkweisen her unterscheiden. Das liegt aber vor allem daran, dass wir nun auch schrittweise beim Austausch des UIs für WPF ebenfalls die Bedienkonzepte und Features hinterfragen, ob diese in der aktuellen Form sinnvoll sind. Wenn nein, werden diese umgebaut. Das wird dann eben auch Schritt für Schritt umgestellt, wodurch es unter Umständen eine Zeit lang das alte Konzept und das neue Konzept parallel gibt. Aber ja, das, was du dir hier wünscht machen wir schon und nutzen einmal implementierte Features. Aber das machen wir halt dort, wo es sinnvoll ist.
Ja - da habe ich mich im Ton und Formulierung vergriffen, ich sehe es ja genau so wie du. Es ist eher so ein emotionales Ding - ich finde eure neuen Master cool, die Fannings cool und dann kommt das Konzept der statischen ItemLists, deren Nutzen ich vermutlich einfach nicht richtig einordnen kann und auf wenige bis keine dieser coolen Features zurückgreifen kann, weil es nicht gewünscht ist. Nehmen wir mal an, jemand baut einen simplen Farbwesel aller Lampen syncron ohne Phase innerhalb einer Devicegroup mit einem neuen Effekt. Hätte man (wie auch immer) die Farbdefinition bspw. wie im DeviceControl realisiert, wäre zumindest in der Theorie bspw. auch ein Fanning im Farbwert möglich, die man danach in den Chaser schickt (also Wechsel basierend auf Fanned- oder eben Parameter Master Werten, wenn der Anwender es wünscht)
In diesem konkreten Fall Master in den Cuelist-Eigenschaften zulassen gibt es hier gewisse Limitierungen im Hintergrund, die dem entgegen stehen (teilweise auch vom Konzept her). Deshalb wurden diese auch nicht an dieser Stelle integriert.
Ich habe dazu beim Überfliegen leider bisher kein Ticket gefunden. Gibt es dafür aus aktueller Sicht Realisierungschancen, sich das zumindest einmal anzusehen?
Aber: Da du die Master auch im Input Assignment hast, sprich über einen Node die Werte eines Masters abrufen kannst, stehen dir da alle möglichen Shenanigans (sprich wilden Verdrahtungen) offen, die du dir ausdenken kannst. Eine Möglichkeit ist da auch, den Wert eines ParameterMasters auf den FadeFactor einer Cuelist zu legen. Damit kannst du dann auch die Ausführungsgeschwindigkeit einer Cuelist anpassen. Willst du stattdessen die Effektgeschwindigkeit der Effekte in der Cuelist anpassen, schickst du den Wert halt in den SpeedFactor. Damit solltest du eigentlich schon ans Ziel kommen.
Die Idee ist gut aber ich möchte ja nicht für jede Cuelist einzeln eine manuelle Input Assignment verdrahtung machen. Das bringt die Komplexität mit sich, dass Cuelists und Input Assignement immer manuel synchron gehalten werden müssen. Gibt es eine Möglichkeit die aktiven oder gar alle Cuelists abzufangen, wie bspw. bei den Dynamic Executors? Es gibt zwar einen "All Cuelists" Node, dennoch braucht es glaub immer einen selector vorher, damit der cuelistnode angesprochen werden kann. Mit einer Liste an Id´s kann er glaub ich nicht umgehen
BTW: Bisher speichere ich Moving Head Positionen als einzelne Cue in einer Cuelist innerhalb einer Cuelistgroup mit single list running. D.h. die Überblendzeit (Release Time) steht selbst auch in den Cuelists selbst hart codiert. Komm ich an die irgendwie im Input Assignement oder anders ran, um die Bewegungsgeschwindigkeit auch ohne den Moving Speed Parameter der physikalischen Geräte live zu ändern?
