Wunsch der vollständigen Softwareunterstützung von vielversprechenden Features (wie z.B. die neuen Master)

Hallo,

Quote from ToWi48

Aber gleichzeitig wurde im Stream das Konzept der Item List als neues Feature in der v3.2.x vorgestellt, das aktuell m.M.n. ein bisschen Konträr zum neuen Master- und bestehendem Cuelistkonzept ist.

Nach lesen dieser Aussage scheint es mir, dass du die unterschiedlichen Konzepte von Master, ItemLists und Cuelists noch nicht vollständig durchdrungen hast. Siehe dazu weiter unten meine Beschreibung dazu:

Quote from ToWi48

dass sicher ohne den Einsatz eines Pluginentwicklers sonst gar keinem zur Verfügung stünde.

Um das etwas zu korrigieren: Eigentlich ist nur die PositionList extern entstanden. Die anderen ItemLists (also GoboLists und ColorLists) sind intern entwickelt worden und von uns integriert worden. Und bei den PositionLists stammt vor allem das UI zum Einstellen von Extern, die PositionList selbst (also die Datenstruktur dazu) stammt auch von uns.

Quote from ToWi48

Aber konzeptionell sehe ich da aktuell keine Möglichkeit, bspw. das coole Masterkonzept zu integrieren

Ich auch nicht . Aber wofür? Die beiden Features Master und ItemLists sind für unterschiedliche Dinge gedacht. Master dienen dazu, einen Live-Wert zentral zu verwalten (wobei dieser Wert eben eine Zahl, eine Farbe, eine Position oder eine Geschwindigkeit sein kann). Mit diesen Live-Werten kann man Live vor allem Geräteparameter oder Effektparameter anpassen. ColorLists / GoboLists / PositionLists wiederum sind feste Listen von Werten (Farbe, Gobos, Positionen). Diese sind bewusst nicht live anpassbar sondern immer nur über den jeweiligen ListenEditor. Diese Listen dienen z.B. als Quelle für die Gobo Affinity, die Positionssteps, die ein Effekt abfahren soll oder die Liste der Farben, die ein ColorChaser durchlaufen soll. An diesen Stellen will man ja gerade, dass sich diese Listen in sich nicht live ändern. Diese beiden Konzepte widersprechen sich also nicht sondern ergänzen sich (ein Livewert auf der einen Seite vs. eine Liste mit festen Werten auf der anderen Seite). Und so sollte auch offensichtlich sein, dass beide überhaupt nichts mit einer Cuelist zu tun haben und dementsprechend auch hier keinem Konzept entgegen stehen könnten.

Quote from ToWi48

es nutzt aktuell diesen unschönen Windows Color Selector und wenn man es irgendwann mal durch den DMXC Color Picker austauschen möchte, steht man ggf. vor dem Problem der Migrierung der alten Werte von bereits gespeicherten Projekten.

Ich schreibe das jetzt mal bewusst etwas provokanter: Lass solche Probleme unsere sein Darüber musst du dir nicht den Kopf zerbrechen, denn du hast keinen Einblick in den Code und kannst daher auch kein Wissen darüber haben, wie die Strukturen im Hintergrund aussehen Nur, weil das Einstellfenster der unschöne Windows Color Picker ist, heißt das noch lange nicht, dass auch die Datenstrukturen im Hintergrund angepasst werden müssten, wenn man das UI-Element austauscht. Tatsächlich wäre das sogar recht schlechtes Software Design, weil man nicht offen für Veränderungen und Erweiterungen ist. Wenn es Änderungen (auch Breaking Changes) gibt, dann gehen die vielleicht mit einer Anpassung im UI einher. Aber der Auslöser dafür sind eigentlich immer Änderungen im zu Grunde liegenden Konzept. Dieses führt dann sowohl zu der möglichen Migrierung von Projekten als auch der Anpassung des UIs. Und ja, wir hatten in der Vergangenheit schon Breaking Changes (z.B. die Anpassung bei den Subproperties wie Pan und Tilt). Solche Änderungen versuchen wir so gut es geht zu vermeiden. Aber manchmal geht das nicht anders. Im Falle der SubProperties war es z.B. ein inkonsistentes Verhalten von DMXControl 3, was zu vielen Problemen (auch beim Laden von Projekten) geführt hat. Deshalb haben wir das angepasst, genau wie eine minimale Anpassung im UI.

Quote from ToWi48

allein schon aus dem Grund, um weniger Doku darüber pflegen zu müssen, wo es überall eben nicht funktioniert

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

Quote from ToWi48

Vereinheitlicht bitte architektonisch solche Konzepte, wo es möglich ist, so, dass man die bereits investierte Arbeit eurerseits an möglichst vielen Orten in DMXC nutzen kann.

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.

Quote from ToWi48

Ich hoffe ihr integriert die neuen Masterfeatures weiter, da sie vor allem bei Liveveranstalltungen m.M.n. Gold wert sind

Ich verstehe, dass du von den Mastern begeistert bist und diese sind tatsächlich ein vielseitiges Feature. Ich nutze sie selbst gerne . Aber manchmal hat man gewisse Randbedingungen und ein Umbau ist nicht so einfach / nicht mit vertretbarem Aufwand umsetzbar. 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.

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.

Viele Grüße
JP

Hallo,

Quote from ToWi48

. 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.

Bei wenigen Scheinwerfern mag das mit den mehreren cuses ja noch gehen.
Will man aber auf mehreren Scheinwerfern ein Farbliste durchlaufen lassen und dies linear (in der gelisteten Reihenfolge) oder random ist der Color Chaser in Verbindung mit der Color Item List ein mit ein paar Klicks die schnellere Lösung, Auch wenn es mehr Farben sein sollen, wird der Aufwand mit einzelnen Cues schon gewaltig.
Ich habe unter anderen eine Matrix mit 150 RGB-Pixeln, die als Lauflicht anzusteuern wäre ohne das Tool der Color Chaser, Color scroll und ohne Color Item List wahnsinnig zeitaufwendig.

Aber so hat jeder seine Vorlieben was er lieber verwendet, ich bin froh diese Tools zu haben.

Hier mal ein paar Beispiele:

Sooo, jetzt komme ich endlich dazu zu antworten:

Quote from ToWi48

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.

Für ganz einfache Fälle stimmt das. Aber sobald das etwas komplexer wird, ist das mit loopenden Cuelists nicht relativ elegant, sondern deutlich aufwändiger als mit Effekten bzw. Filtern (siehe dazu den nächsten Abschnitt).

Quote from ToWi48

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.

Jein. Ein ColorChaser hat ein wiederholendes Pattern über die Scheinwerfer hinweg. Sprich, wenn ich 3 Farben abbilden möchte, muss ich richtigerweise 3 Cues anlegen. Aber innerhalb der Cues muss ich jedem dritten Scheinwerfer die gleiche Farbe geben. Das ist zwar noch möglich aber bei einer Anzahl an Scheinwerfern größer 12 schon nervig zu machen. Nun stelle ich fest, dass ich doch noch eine vierte Farbe in dem Chaser haben möchte. Jetzt muss ich hergehen und jede einzelne Cue anpassen und dabei nun jedem vierten Scheinwerfer die gleiche Farbe geben.... oder ich ändere einfach die Farbliste und füge dort eine weitere Farbe ein. Was ist nun flexibler ?

Zwei weitere Dinge spielen hier noch rein. Zum einen verwenden wir ColorLists nicht nur bei den Effekten. ColorLists werden beispielsweise auch verwendet, um häufig benutzte Farben im ColorControl im unteren Teil von DMXControl 3 hinterlegen zu können. So hat man häufig genutzte Farben schneller im Zugriff. Hier machen wir also genau wieder das, was du oben anfragst: Die Verwendung von Features an mehreren Stellen, soweit sinnvoll Du kannst die Auswahl der verwendeten Standardfarben ganz einfach in den Einstellungen definieren, siehe nachfolgendes Bild:

Der weitere Punkt ist: In DMXControl 3 haben wir häufiger mal versucht, dem User die Wahl zu lassen, auf welchem Wege er zum Ziel kommt. Frei nach dem Motto "Viele Wege führen nach Rom". So gibt es z.B. auch aktuell drei Wege, um einen Effekt auf eine Geräteeigenschaft anzuwenden. Und wenn man das Input Assignment hinzunimmt, hat man sowieso praktisch alle Optionen und könnte darin sogar (mit einigem Aufwand) ganze Anwendungen programmieren (ich hatte mal aus Spaß angefangen, Tetris im Input Assignment nachzubauen und das nur aus Zeitgründen eingestellt). Diese vielen Wege sind vielleicht schwieriger zu dokumentieren, aber so kann jeder so ein bisschen nach dem eigenen Workflow arbeiten. Oder eben wie oben beschrieben gibt es die Situation, dass in dem einen Fall der eine Weg schneller ist und im anderen Fall der andere Weg. Das ist auch ein Teil (aber nicht ausschließlich) meiner Aussage "die Konzepte widersprechen sich nicht, sie ergänzen sich".

Quote from ToWi48

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.

Ja, da hast du definitiv recht und das ist ein Ziel, was wir verfolgen. Das wird aber jetzt erst einmal schlimmer werden, bevor es besser wird. Wie in dem Livestream und auch schon weiter oben gesagt, ersetzen wir alle Fensterelemente durch WPF. Dabei führen wir teilweise auch neue Konzepte / neue Fenster ein. An manchen Stellen können wir dann die neuen Fenster auch ganz gut integrieren und die alten ersetzen. An manchen Stellen müssen wir erst das umschließende Fenster ersetzen, bevor wir Komponenten davon ersetzen. So wird es nun teilweise eine Mischung aus alten und neuen Fenstern geben, die für die gleichen Dinge zuständig sind aber an unterschiedlichen Stellen eingesetzt werden. Das können wir erst mit der Zeit mit vertretbarem Aufwand austauschen.

Quote from ToWi48

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?

"Automatisch funktionieren" tut nur manchmal etwas Viel häufiger hat man den Fall, dass man aktiv Komponenten durch andere austauschen muss. Und dann geht halt das Umbauen los und man muss Adaptierungen etc. einbauen und das ist häufig mit Aufwand verbunden. Wenn man dann noch weiß, dass man dann das umschließende Fenster eh irgendwann ersetzen muss und ab dann die gemachten Umbauarbeiten für die Tonne sind (weil das eben im neuen Fenster eh ganz anders ist), lässt man es lieber erst einmal so wie es ist und baut es dann um, wenn man an der Stelle unterwegs ist. Also noch einmal klar dazu gesagt: Alle Windows Forms Fenster bleiben (bis auf wenige Ausnahmen) unangefasst, wenn man etwas neu macht. Werden die Windows Forms Fenster dann ersetzt, werden hier die neuen Controls und Features verwendet. Außer natürlich die neuen Konzepte widersprechen den alten und man kann das alte Control nicht mehr bis zum Umbau verwenden. Dann wird das gleich ersetzt.

Quote from ToWi48

Aber die Grundidee zu verfolgen, vlt. nicht so strick zwischen parametrisierbar und statisch zu unterscheiden, fänd ich gut

Das kommt halt wie gesagt auf die Stelle darauf an. Auch bei den Standard Farben will ich ja gerade, dass diese fix sind und sich nicht ändern. Genau wie auch bei der Gobo-Affinity mit den Gobos. Hier etwas parametrisierbares einzubauen widerspricht eigentlich dem Konzept

Quote from ToWi48

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)

Dir steht das ja weiterhin zur Verfügung. Nimm dazu halt einen anderen Effekt bzw. baue es in Cuelists. Siehe "viele Wege führen nach Rom" Konkret kannst du einen 1D Effekt verwenden, der das dann macht.

Quote from ToWi48

Gibt es dafür aus aktueller Sicht Realisierungschancen, sich das zumindest einmal anzusehen?

Aus aktueller Sicht erst einmal nicht, weil wir gerade nicht an dieser Stelle (Cuelists) unterwegs sind. Es sind erst einmal andere Fenster (und zugehörige Unterfenster) wichtiger. Sobald wir zu den Cuelists kommen, werden wir aber auch noch einmal (wie bereits bei den anderen Fenstern) das Konzept prüfen und ggf. Anpassungen wie z.B. die Unterstützung von Mastern prüfen.

Quote from ToWi48

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

Fairer Punkt. Der Cuelist Node braucht eine einzelne ID, um richtig zu funktionieren. Aber eine andere Idee: Du kannst seit DMXControl 3.3.1 auch Cuelist Groups auf Executoren legen. Dabei lassen sich dann diese Cuelists gemeinsam ansprechen (u.a. gemeinsam starten, stoppen,...). Dabei gibt es auch die Möglichkeit, den Fader umzustellen. Da kannst du dann den FadeFactor aller Cuelists in der Gruppe einzustellen. So kannst du also über einen Executor alle FadeFactor-Werte gemeinsam einstellen. Du müsstest also nur eine zusätzliche CuelistGroup erstellen und alle Cuelists dort reinpacken, deren FadeFactor du anpassen möchtest.

Quote from ToWi48

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?

An die Zeit nicht. Aber eben wie gesagt über den FadeFactor kannst du die Geschwindigkeit einstellen, denn alle drei Zeiten der Cue werden live mit dem FadeFactor der Cuelist multipliziert.