Bugtracker DMXControl 3

Wenn ich eine Cuelist, ein Softdesk oder eine Stage View über das Menü oder über die Schnellzugriffsleiste neu erstelle, könnte ich es mir als hilfreich erachten, wenn dieses Element dann direkt im Bearbeitungsmodus geöffnet wird. Das bedeutet

• eine neue Cuelist wird direkt im Cuelist Editor,
• ein neues Softdesk wird direkt im Softdesk Designer und
• eine neue Stage View wird direkt geöffnet.

Aktuell muss ich hier die Einträge nochmals aufrufen, damit ich die Bearbeitung der Elemente entsprechend vornehmen kann. Insbesondere im Falle eines neu angelegten Softdesk könnte dies wie eingangs gesagt durchaus hilfreich sein.

Aus der Projektbesprechung vom 14.03.2021 ging der mehrheitliche Wunsch hervor, dass eine namentliche Nennung der beteiligten Personen für Entwicklung, Übersetzung etc. erfolgen soll. Die Art und Weise ist dabei noch nicht final festgelegt, ob diese Nennung direkt in der Software oder im Wiki oder auf der DMXC-Homepage erfolgt.

Wie bei den Menüeinträgen zur Cuelist, Softdesk und Stage View sollte der Eintrag Macroboard Profile aus Konsistenzgründen ebenfalls dahingehend erweitert werden, dass man aus den neuen Untermenüpunkten direkt ein vorhandenes Macroboard-Profil öffnen und ein neues anlegen kann.

Ich lege ein neues Projekt und füge einem neuen Softdesk mehrere Controls hinzu. Dann schließe ich nur die GUI, während das Softdesk weiterhin im Designer geöffnet und das Projekt noch nicht gespeichert ist. Nach dem Neustart der GUI (den Kernel habe ich nicht beendet) sind alle neu eingefügten Controls verschwunden. Habe ich alternativ statt neue Controls hinzuzufügen auch nur bereits existierende Controls geändert (zum Beispiel verschoben), sind diese Änderungen ebenfalls nach dem Neustart der GUI weg.

Folglich fehlt ein entsprechender Befehl vom Softdesk Designer an den Kernel, das aktuelle Softdesk beim Beenden der GUI zu speichern. Denn wenn ich den Softdesk Designer vor dem Schließen der GUI manuell schließe, wird das Softdesk entsprechend im Kernel zwischengespeichert.

Aus den beigefügten Log-Files geht nicht hervor, dass das Softdesk beim Schließen der GUI automatisch gespeichert wird. Dafür wird aber in Folge dessen bemängelt, dass das in der ersten Session noch angelegte Control nach dem Neustart der GUI fehlt:

2021-03-29 11:31:46,518 [Main GUI] ERROR Lumos.GUI.WindowManager - Error when instantiating Object from persistString: Lumos.GUI.Windows.Softdesk.Designer.SoftdeskDesigner#c8aa2b0d-a9e3-4e64-98ef-47dcf6744d18
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> org.dmxc.lumos.Kernel.Exceptions.NotExistingException: Can't find a SoftdeskModel with ID c8aa2b0d-a9e3-4e64-98ef-47dcf6744d18
   bei Lumos.GUI.Windows.Softdesk.SoftdeskWindow.getSoftdeskModelFromID(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Windows\Softdesk\SoftdeskWindow.cs:Zeile 71.
   bei Lumos.GUI.Windows.Softdesk.Designer.SoftdeskDesigner..ctor(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Windows\Softdesk\Designer\SoftdeskDesigner.cs:Zeile 83.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
   bei System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   bei System.Activator.CreateInstance(Type type, Object[] args)
   bei Lumos.GUI.WindowManager.GetContentFromPersistString(String persistString) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\WindowManagement\WindowManager.cs:Zeile 1817.

Ein (Beispiel-) Projekt kann nicht zur Verfügung gestellt werden, weil wie oben beschrieben zu keinem Zeitpunkt etwas gespeichert wurde.

Aktuell wird durch die Großschreibung der Namen verschiedener Ein- und (ggf.) Ausgänge mitgeteilt, dass diese eine bestimmte Aktion direkt triggern wie beispielsweise die Inputs Go, Go Back, Go Next etc. des Cuelist Nodes. Im Zuge der weiteren Internationalisierung von DMXControl 3 kann aber nicht mehr sichergestellt werden, dass in weiteren Sprachen ebenfalls eine Unterscheidung über die Groß- und Normalschreibung des Namens erfolgen kann.

Auf Grund dieser Problematik wurde in der Entwicklersitzung vom 31.03.2021 vereinbart, dass die Input Hubs und (sofern erforderlich) die Output Hubs durch eine andere Farbe entsprechend hervorgehoben werden und statt des Gelbs eine andere Farbe erhalten.

Dabei kann zum Beispiel das Bank Node als entsprechende Vorlage dienen, weil hier auch die Hilfetexte entsprechend vorbereitet sind. Nach der Implementierung des ersten Beispiels unterstütze ich selbst gerne beim Umbauen und Erweitern der weiteren Nodes (deswegen auch die Zuweisung).

Verschiebe ich Objekte (Cuelists, Devices) in Verzeichnisse, so wird dieses zwischen den GUIs nicht synchronisiert.

Nachdem ich mir den dritten Blocks meines Live-Tutorial “Clubshow mit DMXControl 3” nochmal angesehen habe, ist mir erst bewusst geworden, wie häufig ich eigentlich in die Properties eines Nodes springe, um dort die Zuordnung einer Cuelist, eines Masters etc. zu ändern. Diese Änderung ist immer mit vergleichsweise vielen Mausklicks verbunden:

• Einem Doppelklick (2) zum Öffnen der Properties (egal ob das Node ausgewählt ist oder nicht) oder drei Klicks, wenn man über das Kontextmenü geht.
• Zwei Klicks (3 und 4), um den Auswahldialog zu Öffnen.
• Ein Klick (5) zur Auswahl des neuen Objekts.
• Zwei Klicks (6 und 7) um beide Dialoge mit OK zu schließen.

Diese Tätigkeit kommt immer dann zum Tragen, wenn man eben ein vorhandenes Connectionset vervielfältigt und die Kopien entsprechend anpasst. Aus diesem Grund wünsche ich mir eine Möglichkeit, insbesondere bei den Wrapper-Nodes die Zuordnung eines Objekts wie Cuelist, Master, Executor nach der Auswahl des Nodes in der Graphenansicht direkt vornehmen zu können, ohne hierzu in die Properties springen zu müssen. Ideal wäre hier folgender Ablauf:

• Ein Klick (1) zum Auswählen des entsprechenden Nodes.
• Ein Klick (2) zum Aufrufen der Liste der verfügbaren Cuelists, Master etc.
• Ein Klick (3) zum direkten Ändern der Zuordnung ohne weitere Bestätigung.

In meinem Live-Tutorial “Clubshow mit DMXControl 3” habe ich mir Connectionsets mit einem Button inkl. entsprechendem Feedback gebaut. Aktuell muss ich bei der Anpassung der Kopie dieses Connectionsets für die Nutzung des Button 2 hier sowohl den Button 2 auf der Inputseite als auch auf der Outputseite per Drag&Drop ersetzen.

Um die Anpassung einer Kopie eines Connectionsets weiter zu beschleunigen, wünsche ich mir eine Möglichkeit, den Input und Output eines Buttons, Sliders etc. in einem Rutsch ersetzen zu können - gerade unter dem Gesichtspunkt, wenn diese in einem Connectionset mehrfach verwendet wurden.

In manchen Situationen kommt es vor, dass die Aktualisierung des Input- und Output-Baumes von außen nicht automatisch angestoßen wird, wenn das Input Assignment Fenster geöffnet ist. Ein Beispiel ist hier das Deaktivieren des Group Masters, wie in meinem Live-Tutorial "Clubshow mit DMXC3" bei 23:36 zu sehen. Diese Verschwinden erst, wenn ich das Fenster schließe und neu öffne. Ein weiteres Beispiel ist, dass die finalen Namen von neu angelegten Cuelists etc. nicht durchgereicht werden, sodass im Baum noch “New Cuelist” steht.

Unabhängig von der Tatsache, dass die beiden zuvor beschriebenen Punkte als Fehler zu werten sind und hierzu noch entsprechende Tickets folgen, wäre hier dennoch ein entsprechender Button hilfreich, um die Aktualisierung beider Bäume analog zum Refresh-Button im Project Explorer auch manuell anstoßen zu können.

Im Network Explorer gibt es bereits das Icon für Autoposition. Dieser Button sollte genauso wie ein neuer Button für “Show the whole graph” in der Menüleiste der Graphenansicht mit aufgenommen werden, da beide Funktionen aktuell nur über das Kontextmenü zu erreichen sind.

Aktuell werden die Zeiten beim Trapezoid-Effekt für alle vier Segmente (Fade up, Top, Fade down, Bottom) als absolute Zeitwerte eingegeben. Dies macht die Nutzung von Speedmastern an dieser Stelle unübersichtlich, weil ich in jedem der vier Parameter mit den Speedmastern rechnen muss. Und das teilweise doppelt, da ich zum einen erst die Gesamtgeschwindigkeit reduzieren und dann noch den Wert für die vier Parameter anpassen muss.

Um hier eine effektivere Nutzung des Speedmasters oder auch die einfachere Festlegung der Gesamtwiederholdauer zu ermöglichen, würde ich mir folgende zusätzliche Parameter im Trapezoid-Effekt wünschen:

• Neuer Parameter zur Umschaltung zwischen den absoluten Zeitanteilen in Millisekunden und den relativen Zeitanteilen in % oder 0 bis 1 für die Dauer der vier Segmente. Je nach Einstellung dieses Parameters werden die vier Parameter umgeschaltet.
• Im Falle der Wahl des Parameters “relative Zeitanteile” erscheint der neue Parameter Dauer (Duration), in dem die Gesamtdauer eines Durchlaufs angegeben wird, wo wie eingangs gesagt auch der Speedmaster zum Einsatz kommen kann.
• Parameter zum Festlegen des Bezugspunkts für den Takt. Aktuell liegt dieser Punkt fest beim Beginn des Fade Ups. Grundsätzlich lässt sich dieser Punkt zwar über den Offset-Parameter verschieben, aber spätestens bei ungleichen Dauern der vier Segmente muss man zu einem Taschenrechner greifen, um genau den Punkt “Ende Pause Top” zu bestimmen.

Im QRM-Meeting vom 16.03.2021 wurde vereinbart, dass das Fenster des Add Interface Dialogs um einen zusätzlichen Zweig über dem Zweig der Non Auto Detect Interfaces erweitert wird, in dem alle automatisch erkannten Interfaces gesammelt werden, die auch noch nicht in Verwendung sind. Das zugehörige Stichwort wie auch in dem ursprünglichen Ticket  FS#4369  beschrieben, ist “Discover-Mode für Auto-Detect-Interfaces”. Dieser Modus ist ein zusätzlicher Entwicklungsstrang parallel zum Punkt “Anpassung des Add Interface Dialogs selbst”.

Über die Buttons half und double kann man den aktuellen BPM-Wert faktorisieren. Hier wäre es gut, wenn dieser Faktor angezeigt wird. Ein typisches Anwendungsbeispiel ist, dass ich mehrere Speedmaster zwar gleichzeitig Lerne bzw. Synchronisiere, aber jeden Speedmaster einzeln faktorisiere.

Aktuell existiert im Executor-Fenster grundsätzlich der Button “Add Page”. Dieser sollte für den Live-Betrieb aber abschaltbar sein, um dort nicht versehentlich neue Seiten anzulegen.

Eventuell könnte eine Variante sein, diese Option in die Properties des Zweigs für die Executor Pages.

Die Ausgangssituation für diesen Vorschlag ist folgender: Ich habe zum Beispiel zwei Gerätegruppen, wo in der einen Gruppe 7 Geräte und in der anderen 18 Geräte enthalten sind. Die Geräte sind in ihrer Reihe allesamt mit dem gleichen Abstand versehen und beginnen mit dem jeweils 1. Gerät auf der gleichen Seite. Hierdurch steht die zweite Reihe entsprechend nach “hinten” über. Vergleichbar wäre das mit zwei unterschiedlich lang abgeschnittenen LED-Stripes, wo beide auf der einen Seite auf der gleichen Höhe starten.

Für diese Anordnung möchte ich nun einen Effekt bauen, der zwar auf beiden Gruppen parallel läuft, sich jedoch auch auf beiden Gruppen auf die gleiche Anzahl von Geräten (zum Beispiel Wiederholung alle 5 Geräte) streckt.

Um einen solchen Effekt mit den aktuellen Möglichkeiten zu realisieren, müsste ich den Effekt auf beide Gruppen einzeln anwenden und dabei die Parameter individuell an die Anzahl der Geräte abstimmen. Ein Griff zum Taschenrechner ist unumgänglich. Den Group Handling Modus “Parallel Groups” kann ich ich an dieser Stelle nicht nutzen, weil hierdurch der Effekt bei der 1. Gruppe auf 7 und bei der 2. auf 18 Geräte gestreckt wird.

Um diesen Punkt besser abzudecken kam mir der Gedanke zu diesem neuen Modus, bei dem ich über den Zahlenparameter eben angebe, wie groß diese “virtuelle” Untergruppe ist. Dem entsprechend wird der Effekt bei N+1, 2xN+1, 3xN+1 wiederholt. Passt die Größe der Gruppe nicht zu der Angabe, wird hinten abgeschnitten.

Ich habe mehrere Cues programmiert, wo ich die Farbe explizit im HSV-Modell angeben musste. Dies war in der Vielzahl allerdings recht umständlich, da ich im Device Control bei jedem erneuten Anwählen einer Gerätegruppe oder eines Geräts immer erst das Farbmodell umschalten musste.

An dieser Stelle könnte das Device Control entsprechend unterstützen, indem es sich merkt, welches Farbmodell zuletzt verwendet wurde. So muss ich nur noch umschalten, wenn ich bewusst wechseln möchte. Eine separate Einstellung hierfür, um das favorisierte Farbmodell vorzugeben, sehe ich hier nicht.

Aktuell verfügen Cuelists nur über die Play Modes “Once”, “Loop”, “Bounce” und “Random”. Hier vermisste ich kürzlich den Play Mode “Reverse”, woraufhin ich die Reihenfolge der Cues selbst anpassen musste, um das gewünschte zu erreichen.

Mittlerweile gibt es ja beim neuen Chaser weitere gute Play Modes. Die Play Modes “Switch” und eben “Reverse” kann ich mir ebenfalls sehr gut als Play Modes für Cuelists vorstellen. Vielleicht lassen sich auch noch weitere Play Modes vom Chaser auf die Cuelists adaptieren - inklusive der Icons.

Bislang verfügt der Color Bar nur über einen Output, um Objekte anzusprechen. Im Zuge der Implementierung der Colormaster wäre es sinnvoll, wenn die Color Bar auch einen Input erhält, damit sie die aktuellen Werte der Colormaster etc. anzeigen kann.

Wenn ich mit dem Compare-Node Werte vergleiche, muss ich Nachgang noch weitere Nodes einfügen, wenn mit dem zu prüfenden Wert weiterarbeiten möchte. Üblicherweise ist das ein Input Selector.

Um die Connectionsets zu vereinfachen, schlage ich vor, den Compare-Node um einen zusätzlichen Eingang mit dem Namen “Val” zu erweitern. An diesen Eingang schließe ich einen beliebigen Wert an, mit ich im Anschluss weiterarbeiten möchte. Dieser muss aber nicht zwingend der Wert sein, auf den ich die Prüfung laufen lasse und kann daher auch ein String sein. Deswegen sehe ich aktuell keinen Sinn darin, ein vergleichbares Verhalten über eine Einstellung festzulegen.

Nutze ich den Val-Eingang, wird am Ausgang statt True / False bei Erfüllung der Prüfbedingung der am Val-Eingang anliegende Wert ausgegeben. Ggf. ist zu überlegen, ob das Node eine Einstellung erhält, bei der festlegt wird, welcher Wert bei Nichterfüllung der Prüfbedingung anliegen soll.

Bislang verfügt das Position Control nur über einen Output, um Objekte anzusprechen. Im Zuge der Implementierung der Positionmaster wäre es sinnvoll, wenn das Position Control auch einen Input erhält, damit sie die aktuellen Werte der Positionmaster etc. anzeigen kann.

Dieses Ticket steht im ähnlichen Kontext wie das Ticket FS#4603.

Für mein Club22-Projekt bestand die Anforderung, dass automatisch eine Reihe von unterschiedlichen Cuelists nach Ablauf einer vorgegeben Zeit durchwechseln. Da die Cuelists zum Teil auch aus mehreren Cues bestehen, war es nicht möglich, alles in einer Cuelist abzubilden. Um das Umschalten der Cuelists nach einer vorgegebenen Zeit anzustoßen, habe ich mir nun weitere Cuelist gebaut, die durch Befehle per Special Cues die Cueslists umschalten.

Dieser Weg ist zwar durchaus praktikabel und hat seine Daseinsberechtigung - allerdings ist dieser für den beschriebenen Anwendungsfall “bessere Sound-To-Light-Steuerung” ein wenig zu aufwendig.

Daher kam mir der Gedanke, ob man die Cuelist Groups dahingehend erweitern kann. Das ginge dann in die Richtung, dass ich die Cuelists, welche regelmäßig durchgeschaltet werden sollen, in eine gemeinsame Cuelist Group einfüge. Die Cuelist Group erhält die zusätzliche Option, die enthaltenen Cuelists

• nach einer vorgegebenen Zeit
• entsprechend verschiedener Play Modes analog zu den Cuelist

automatisch durchzuschalten.

Ob der Nutzer die Möglichkeit zum Starten auch aus der normalen GUI erhält, wäre zu diskutieren. Im jeden Fall sehe ich hier eine Erweiterung des Cuelist Group Nodes um die Eingänge

• Go bzw. Play
• Time
• Play Mode

Ich habe in dem beigefügten Setup mehrere Gruppen in Gruppen abgelegt. Die Gruppe “Complete Setup” enthält alle Geräte, indem ich dieser Gruppe die untergeordneten Gruppen zugeordnet habe. Nun möchte ich auf der Gruppe “Complete Setup” Werte für zwei Funktionen abspeichern. Da die Werte eben nun auf der Gruppe “Complete Setup” liegen, wäre meine Erwartungshaltung, dass im Programmer Filter eben nur die Gruppe “Complete Setup” aufgeführt wird, wie es auch im Device Control der Fall ist.

Aktuell ist es aber so, dass die untere Ebene im Programmer Filter aufgelistet wird. Auch werden die Eigenschaften der jeweiligen unteren Gerätegruppen aufgeführt und mir zum Abwählen angeboten. Hier sehe ich ein Konsistenz-Problem, wenn ich feingliedriger Abwählen kann als im Device Control “eingestellt” ist sowie meine Einstellungen mit Hilfe des Programmer Filter nicht mehr korrigieren (also filtern) kann.

Grundsätzlich besteht dieses Problem auch jetzt schon, wenn ich manuell mehrere Gruppen auswähle.

DMXControl 3 kann auf zahlreichen Wegen diverse Informationen und Signal von außen erhalten. Dies sind neben diversen Hardware-Komponenten wie MIDI, Streamdeck, MPA-Pulte auch datenbasierte Inputs wie zum Beispiel das OSC- oder das MQTT-Protokoll. Nahezu jeder Input bringt verschiedene grundlegende erforderliche Konfigurationsoptionen mit. Solche grundlegenden Konfigurationen sollten alle an einem zentralen Ort zusammengefasst werden, der hier exemplarisch als External Input Manager bezeichnet wird.

Im Falle des MQTT-Nodes würden beispielsweise die Einstellungen für Host-Adresse, Benutzername, Passwort und Port zentral in den External Input Manager wandern, da diese sonst aktuell bei mehrfacher Verwendung des Nodes jedes Mal individuell zu hinterlegen wären.

Ist das MPA-Plugin aktiviert, ergänzt es entsprechend ein Icon im Einstellungs-Fenster. Der Name des Icons lautet hier allerdings einfach nur “Plugin”. Es wäre gut, wenn der Titel in “MPA” oder ähnlich versehen wird, damit auch direkt zu erkennen ist, was sich hinter dem Icon befindet.

Aktuell verfügen die Macroboard-Profile über kein Eigenschaften-Fenster, wie es eben Devices oder Cuelists der Fall ist. Im Eigenschaften-Fenster der Macroboard-Profilen könnte ich mir aktuell folgende Parameter vorstellen:

• Name
• Macroboard-Profil-Nummer

Insbesondere der Parameter “Profil-Nummer” kann hilfreich sein, wenn man über eine numerische Zuordnung der Profile zu einem Macroboard arbeitet, wie zum Beispiel beim Durchblättern durch mehrere Seiten (respektive Profilen).

Optional würde ich folgende Einstellmöglichkeiten in den Raum werfen:

• Statisches Hintergrundfarbe oder -bild
• Verhalten der Buttons (Push oder Toggle)
• Anzahl der Buttons pro Zeile und Spalte

Im beigefügten Projekt habe ich eine Seitenumschalten zwischen zwei Macroboard-Profilen realisiert, indem ich via eines Counters die Nummern der Macroboard-Profile hoch- bzw. herunterzähle. Die Profile im Projekt sind für ein Stream Deck XL gebaut.

Wechsele ich nun die Seite, muss ich die betreffenden Button 4.8 (Seite vor) bzw. 4.7 (Seite zurück) zweimal drücken. Beim Verlassen der Seite wird der Ausgangswert des Button 4.8 bzw. 4.7 von “True” nicht mehr zurück auf “False” gesetzt. Zu sehen ist dies in dem Connectionset “Page-Navigation”.

Ob dieses Problem mit DMXControl 3.3 auch noch besteht, kann ich erst nach der Freigabe der Aplha 8 prüfen. In der Alpha 7 lässt sich das Projekt auf Grund des mittlerweile behobenen Fehlers aus Ticket  FS#4670  nicht öffnen.

Zur Zeit werden die Konfigurationsdaten im Standard-Verzeichnis unter

C:\Users\[User]\AppData\Roaming\DMXControl Projects e.V\

grundsätzlich ohne jeden Bezug zu einer Programm-Version abgelegt, welches (seit je her)

DMXControl

heißt - möglicherweise, weil es zu Zeiten von DMXControl 2 ähnlich war. Dies birgt aber den Nachteil, dass man nach dem Starten einer neueren Version nicht mehr ohne weiteres auf ältere Version zurückgehen kann. Einige Konfigurationsdaten werden verändert und sind dann nur noch für die neue Version verständlich. Zwar kann man hier mit Hilfe der Umgebungsvariablen aushelfen, jedoch ist fraglich, wie häufig von dieser Gelegenheit gebraucht gemacht wird.

Aus diesem Grund schlage ich vor, eine Unterscheidung nach Minor-Versionen von DMXControl 3 zu implementieren und die Konfigurationsdaten in den Verzeichnissen wie folgt aufzuteilen:

• DMXControl (alle Versionen bis einschließlich 3.2.x)
• DMXControl 3.3
• DMXControl 3.4
• …

Bei der Installation einer jeweils neueren Version fragt der Installer ab, ob die bestehenden Konfigurationsdaten übernommen werden sollen. Das Verzeichnis der UserDevices wird grundsätzlich kopiert, sollte das Verzeichnis noch nicht existieren.

Können durch diverse Filter (voreingestellte Filter oder durch manuelle Textfilter aus Suchmaske) keine passenden Ergebnisse gefunden werden, soll hierauf durch einen Text wie “No results found” hingewiesen werden. Im Fall der Gobo List ist es aktuell so, dass dann man nur ein leeres Fenster sieht.

Der neue Dialog zum Auswählen eines Hintergrundbildes für die Stage View sollte aus meiner Sicht wie der neue Sound Selector die Möglichkeit erhalten, eine Bilddatei direkt aus dem Dateisystem auszuwählen. Damit entfiele der bislang notwendige Umweg, das gewünschte Hintergrundbild erst anderweitig ins Projekt ins Projekt importieren zu müssen und würde sich zudem eben an die Möglichkeiten im neuen Sound Selector angleichen.

Möchte ich den One Shot Trigger nutzen und füge diesen entsprechend der “Vorgaben” in eine Cuelist ein, funktioniert dieser erst nach dem erneuten Laden des Projekts. Erstelle ich eine neue Szene (egal ob komplett neu oder eine Kopie) mit dem Trigger einer Cuelist hinzu und führe die Cuelist im Anschluss direkt aus, werden die Cues übersprungen. Offenbar überprüft der Trigger nicht die aktuellen Parameter des vorausgehenden Effekts, sobald die Cuelist gestartet wird.

Die einfache Reproduktionsanleitung:

• Beliebigen Effekt wie Chaser oder Triangle auf den Dimmer eine Device Group legen und als Cue in einer neuen Cuelist abspeichern. Trigger ist follow, alle anderen Zeiten 0ms.
• Dummy-Cue mit One Shot Trigger einfügen. Wiederholung beliebig setzen, alle anderen Zeiten auf 0ms.
• Proforma eine dritte Cue zum Beispiel Dimmer 100%, Farbe blau einfügen. Trigger “follow”, Trigger Value 1s, Fade 0ms, Delay 0>5s.
• Cuelist abspielen. ⇒ Ergebnis: man sieht nichts. Auch die letzte Cue “Full on” wird nicht (mehr) vollständig ausgeführt, sofern die Cuelist auf “Release when last cue ends” gesetzt ist.
• Projekt speichern, schließen und erneut laden.
• Cuelist wieder abspielen. ⇒ Ergebnis: Trigger arbeitet wie erwartet und man kann ihn dann auch beliebig verändern. Die letzte Cue wird ausgeführt.

Da es keinerlei Einträge für den Zeitraum gibt, in dem ich dieses Projekt gebaut habe, füge ich keine Logfiles bei. Zur Reproduktion des Fehlers kann das beigefügte Projekt verwendet werden, indem man aus der existierenden Cuelist die Cue mit dem Effekt und die Cue mit One Shot Trigger kopiert und erneut einfügt. Alternativ einfach die Zeiten des Effekts ändern.

Ich habe festgestellt, dass der Parameter “Play Mode” des Color Chasers sich ausschließlich auf die Wiedergabereihenfolge der zugeordneten Color List bezieht. Ich habe bei aktiviertem “Use Device Index” aber keine Möglichkeit, eben diesen zu beeeinflussen. Egal ob Play Mode “Normal”, “Bounce” oder “Reverse”: die optische Laufrichtung des Color Chasers bleibt immer die selbe.

Daher wünsche ich mir für den Color Chaser im Endeffekt alle Parameter zusätzlich, die in den neuen Chaser Einzug erhalten haben:

• Fade Curve
• Break Steps
• Break Time
• Size
• Step Size
• Play Direction (Play Mode für Device Index)

Hinter dem Parameter Play Direction versteckt sich zum einen eben die bis dato fehlende Ansteuerung des Device Index, zum anderen aber auch die bereits für den einfachen Chaser implementierten Play Modes inklusive der Möglichkeit, per csv-Datei weitere eigene zu hinterlegen. Wenn ich dies richtig überblicke, können die Play Modes des neuen Chasers 1:1 auf den Color Chaser zur Ansteuerung des Device Index übertragen werdem.

Durch dieses Update könnte es eventuell sein, dass der bis dato vorhandene Parameter “Index Offset” überflüssig wird, weil er in einer der neuen aus dem neuen Chaser übergeht.

Stand heute gibt es beim PWM Static nur die Möglichkeit, eine Gruppe von Geräten entsprechend der Position des zugeordneten Parameter Masters “aufzufüllen”. An dieser Stelle wünsche ich mir die Möglichkeit, eine feste Anzahl von Geräten (zum Beispiel 3) mittels des Parameter Masters innerhalb der Gerätegruppe hin- und herzuschieben. Beim Minimal- bzw. Maximalwert des Parameter Masters leuchten dann immer drei Geräte am entsprechend korrespondierenden Ende der Gerätegruppe. Bei 50% würden in der Mitte vier Geräte leuchten (die beiden mittleren mit 100%, die äußeren mit je 50% leuchten), wenn Fade auf True gesetzt ist und die Gruppe eine gerade Anzahl von Geräten umfasst.

Hierzu bedarf es neben dem zusätzlichen Parameter für “Size” auch einen weiteren Eintrag für den Parameter “Direction”, der beispielsweise “Group” lauten könnte. In diesem Zusammenhang wäre zu überlegen, ob nicht eine Umbenennung des Parameters “Direction” in “Play Mode” erfolgt.

Im dynamischen PWM-Effekt müssen diese Ergänzungen nicht vorgenommen werden, weil sich dieses Szenario mit dem neuen Chaser abbilden lässt, sofern der Effekt eben automatisch laufen soll.

Beim Verfassen des Tickets FS#4759 ist mir aufgefallen, dass der neue Chaser um vier weitere Play Modes erweitert werden kann:

• Fill from left (>)
• Fill from right (<)
• Fill from center (<>)
• Fill to center (><)

Diese vier zusätzlichen Play Modes stammen aus dem dynamischen PWM-Effekt. Aus meiner Sicht sind diese vier anderen Play Modes der einzige Unterschied, der zwischen dem neuen Chaser und dem dynamischen PWM-Effekt existiert. Von daher würde ich in diesem Zusammenhang vorschlagen, den dynamischen PWM-Effekt nach der Übernahme der oben genannten Play Modes in den neuen Chaser zu entfernen.

Im Zuge der Freischaltung der Funktion “Gruppen in Gruppen” (siehe  FS#674 ) soll das Group Handling dahingehend erweitert werden, dass

• eine nachvollziehbare Ansteuerung auch über n Ebenen möglich ist und dabei nicht für jeden Anwendungsfall eine neue Gruppe angelegt werden muss
• ggf. auf unterschiedlichen Ebenen ein unterschiedliches Group Handling ausgewählt werden kann
• das Group Handling weitere Funktionen anbietet

Das beigefügte Projekt soll einen exemplarischen Aufbau zeigen, bei dem die Ansteuerung der insgesamt 100 Beam-MHs und 12 Spot-MHs am Ende durch ein verbessertes und erweitertes Group Handling deutlich variantenreicher erfolgen soll, ohne zusätzliche Gruppen anliegen zu müssen. Insgesamt gibt es bis zur Device-Ebene drei Gruppen-Ebenen. Folgende Szenarien sollten exemplarisch anhand eines Lauflichts einfach darstellbar sein, wobei sich diese Liste ggf. bei weiteren Überlegungen noch beliebig weiterspinnen lässt:
* Lauflicht innerhalb eine gesamte Zeile über die 25 Spalten hinweg (25 Geräte, Laufrichtung links rechts), egal ob nur bezogen auf eine Zeile oder ein paralleles Lauflicht über alle fünf Zeilen
* Lauflicht innerhalb eines Blocks, beginnend oben links, endend unten rechts
* Lauflicht über die fünf / sechs Zeilen hinweg (Laufrichtung oben unten), egal ob nur bezogen auf eine Spalte oder parallel auf allen 20 Spalten
* Lauflicht über alle 24 Einzel-Zeilen, wo immer fünf bzw. drei Geräte gemeinsam ein- und ausgeschaltet werden
* Lauflicht über die vier Blöcke, wo immer 28 Geräte gemeinsam ein- und ausgeschaltet werden
* Gegenläufige Lauflichter aus der oberen Gruppe heraus, wo Zeilen 1, 3 und 5 links-rechts und Zeilen 2 und 4 rechts-links wiedergegeben werden

Ich habe eine einfache Cuelist mit zwei Cues gebaut, die in Schleife wiedergegeben wird:

1. Cue 1: Dimmer [100%], Farbe [ColorMaster 1]
2. Cue 2: Dimmer [100%], Farbe [ColorMaster 2]

Beide Color Master habe ich mir in den verschiedenen Modi RGB, CMY und HSV in eine Executor Page geliegt.

Jenachdem, welchen Color Master Typ ich nutze, um die Farbe einzustellen, ändert sich der Farbübergang zwischen den beiden Cues. Entweder direkt oder entlang des Farbkreises. Dass die Kombination des Farbtypes / Farbmodells den Fade beeinflusst, ist grundsätzlich bekannt (siehe Ticket FS#4279).

An dieser Stelle kann es zu Verwunderungen führen, wenn eben dieses Verhalten nicht bewusst ist. Die Verwunderung kann noch größer sein, wenn man einmal die Farbe per Fader festlegt (der als HSV konfiguriert ist) und dann die Farbe per Button setzt - innerhalb eines Executorzugs. Auch dies beeinflusst den Farbübergang.

Grundsätzlich kann man diesen Punkt dokumentieren, bis er sich bei der Umsetzung des Tickets FS#4279 “erledigt”. Die Frage ist aber, ob dies ein praktikabler Weg ist und ob es nicht besser wäre, dem ColorMaster eine Einstellung mitzugeben, dass er die Farbe nur intern in einem bestimmten Farbmodell vorhält.

Aus der Erfahrung heraus gibt es für LED-Scheinwerfer eine Reihe von Farben, die man gerne wiederverwendet, weil man weiß, dass sie auf den Geräten gut aussehen. Solche Farben sind aber oft Mischfarben. Diese Mischfarben kann man mit einem Fader jedoch nur schwer schnell und reproduzierbar “treffen”.

Grundsätzlich besteht die Möglichkeit, diese Farben in mehreren Cuelists zu speichern, gerade wenn man sie über mehrere Geräte unterschiedlich aufrufen möchte. Um das Projekt flexibler zu gestalten, kam mir daher der Gedanke, dass man durch die Kombination eines Color Masters auf einem Executor mit einer selbst definierten Color List ggf. vereinfachen könnte. Hierzu wähle ich statt eines Faders wie Hue, Saturation, Red oder ähnlich eine meiner vorbereiteten Color Lists aus. Auf Basis dieser Color List erhält man im Bereich des Faders statt des Faders untereinander angeordnete Buttons mit den Farben aus der ausgewählten Color List. Damit ließen sich eigene Farben entsprechend schneller anwählen und man benötigt für einen Color Master auch nur einen Executor-Zug.

Erstelle ich ein Fanning mit den Fanning-Operatoren ?, ?? oder ?# in Kombination mit einem Master, so werden die Werte kontinuierlich neu berechnet, obwohl ich den zugehörigen Master gar nicht anfasse. Das Problem ist mir unter anderem bei folgenden Eingaben aufgefallen:

• Dimmer: 0 ? {ParameterMaster 1}
• Color: 255; 255; 255 ?# {ColorMaster 1}

Die Erwartungshaltung ist an dieser Stelle eigentlich, dass die Werte nur neu berechnet werden, wenn

• die entsprechende Cue erneut aufgerufen wird
• man den Wert des zugehörigen Masters ändert

Wähle ich bei einem Gerät mit zwei Goborädern (hier Futurelight DMH-160) von beiden Goborädern je ein Gobo aus, erscheint im Programmer die folgende Anzeige statt des Klartext “1: Gobo 2, 2: Gobo 7” inklusive des zugehörigen Icons (siehe Bild 1).

Wechsele ich über das Gobo Control in der Gesamtübersicht auf nur ein Gobo, sieht die Anzeige wieder sauber aus. Es fehlt hier aber auch die Vorschau des Gobos (siehe Bild 2). Hierzu erscheint in den Logs der GUI parallel folgender Eintrag:

2022-02-24 18:19:28,125 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource ICON-001189.png of type Symbol and source Default could not be loaded!
2022-02-24 18:19:28,127 [Log-Thread] DEBUG org.dmxc.lumos.XNAViews.TextureManager - Added Texture: ICON-001189.png

Grundsätzlich die Datei dem Programm sowohl im Installationsverzeichnis als auch über das Projekt entsprechend vor.

Beim Arbeiten mit den neuen Chaser ist mir aufgefallen, dass folgende zusätzlichen Parameter den neuen Chaser noch weiter aufwerten und flexibler gestalten würden:

• Repeat size: Legt fest, ab welcher Geräte-Nummer innerhalb der Gruppe das ausgewählte Muster wiederholt wird. Umfasst meine Gruppe acht Geräte und ich trage in diesem Parameter “4” ein, habe ich beim Play Mode “Normal” quasi zwei Chaser über nur vier Geräte.
• Offset Steps: Legt wie der Name schon sagt einen Offset in Schritten fest. Füge ich den Chaser bei einer Gruppe von acht Geräten zweimal auf den Dimmer ein und trage bei einem der beiden Chaser für diesen Parameter eine “3” ein, folgt dieser Chaser dem anderen mit entsprechenden Verzug von drei Schritten. Damit sind zwischen den beiden hellen Geräten zwei Geräte dunkel.

Mir ist wohl bewusst, dass ich diese Muster grundsätzlich auch mittels eigens programmierter Chaser erstellen kann. Dies ist aber meiner Meinung nach für solche generischen Parameter aber eher der umständliche Weg.

Der Übersicht halber habe ich dieses Ticket mal mit den bereits exitsierenden Tickets zum Chaser verknüpft, die auf eine Funktionserweiterung abzielen.

Beim Einfügen des bereits existierenden List Selectors kam mit der Gedanke zu folgendem neuen Node auf: dem “Item List” Node.

Das Item List Node gehört zur Kategorie der Wrapper-Nodes und ermöglicht das Arbeiten mit im Projekt existierenden Item Lists wie Gobo List, Color List oder Position List. Entsprechend der gewählten Liste stellt es die folgenden Ein- und Ausgänge zur Verfügung.

Eingänge

• Item List: Wählt die Item List mit der entsprechenden ID oder dem Namen
• Select: Übergabe eines ganzzahligen Werts zur Auswahl eines bestimmten Objekts in der Item List
• Previous: Auswahl des vorherigen Objekts
• Next: Auswahl des nachfolgenden Objekts

Ausgänge

• Name: Name der zugeordneten Item List
• ID: ID der Item Liste
• Items: Ausgabe der Liste der enthaltenen Werte wie die verschiedenen Farben bei einer Color List, Gobos der Gobo List etc.
• Item count: Anzahl der Objekte in der Liste
• Selected Item: Ausgabe des ausgewählten Eintrags

Ein möglicher Anwendungsfall für das Item List Node wäre zum Beispiel die “zentrale” Verwaltung von Farben für den Status eines Buttons im Softdesk oder auf einem Makro Board. Bis jetzt ist ein üblicher Weg, die verschiedenen Farben in einem Input Selector zu hinterlegen. Verwendet man die gleichen Farben mehrfach muss auch der Input Selector mehrfach konfiguriert werden. Mit Hilfe des Item List Nodes würde die Farbdefinition zentral im Project Explorer erfolgen. In den betreffenden Connectionsets greift man dann nur noch den Index der Liste auf. Möchte man die Farben im Nachgang nochmal ändern oder mit einer weiteren Farbe arbeiten, muss man hier auch nicht mehr alle Input Selecotren einzeln anfassen und die Farbe hinterlegen. Es muss stattdessen nur dafür gesorgt werden, dass der benötigte Index am Item List Node ankommt, wenn es nicht bereits vorher schon der Fall war.

Ich habe meiner DMX-Ausgabe weitere Art-Net-Interfaces hinzugefügt, sodass ich nun insgesamt 4 Instanzen habe. Diese wurden aber nun “frei Schnauze” in die Liste einsortiert, sodass meine Liste nun wie im beigefügten Screenshot aussieht. Hier sollte bitte nach Möglichkeit automatisch immer einer Sortierung der Einträge auf Basis des Herstellers, dann des Modells und dann der Serien-Nummer erfolgen, weil man sich sonst gerade im Fall der Art-Net-Konfiguration im Kreis dreht, wenn die später hinzugefügte Instanz mitten in der Liste eingefügt wird.

Das Ändern der Reihenfolge der Instanzen in der Config-Datei “DMXInterfaceMgmtConfig.xml” hat leider nicht ausgereicht, um die Darstellung in der GUI entsprechend zu beeinflussen.

Im beigefügten Projekt habe ich in der Cue 1 der Cuelist 1 einen Chaser auf die Gerätegruppe (Device Group) gelegt. Ändere ich nun die Sortierung der Geräte in dieser Gerätegruppe über das Kontextmenü und sortiere sie zum Beispiel zufällig, wird der Chaser trotz Play Mode “Normal” beim erneuten Starten der Cuelist nicht aktualisiert. Aktuell kann ich die Sortierung nur per Drag ‘n’ Drop oder über die Buttons Up und Down ändern. Über letzte habe ich die zur Zeit aktive Reihenfolge realisiert: 1 - 4, 13 - 16, 5 - 12.

Regelmäßig unregelmäßig kam es in bei mir im York vor, dass ein Tastendruck im Softdesk teilweise mit mehreren Sekunden Verzögerung umgesetzt werden. Dieses Problem kommt und geht über den Abend, ohne dass nicht explizit Änderungen am ausgeführten Projekt durchgeführt werden.

@patme hat in der heutigen Beta-Testerrunde berichtet, dass ihm dieses Problem bei einem seiner letzten Langzeit-Testläufe mit DMXControl 3.3.0 Beta 2 ebenfalls unter die Finger gekommen ist.

Mehreren Nutzern ist aufgefallen, dass der Cuelist Monitor nach dem Laden eines Projekts erst auf die Eingaben per Touchscreen reagiert, wenn man in ihn initial einmal mit der Maus geklickt hat. Beispiele für diese Aussagen sind folgende Threads:

• https://forum.dmxcontrol-projects.org/index.php?thread/16136/&postID=135955#post135955
• https://forum.dmxcontrol-projects.org/index.php?thread/16526/&postID=138901#post138901

Ich baue mir aktuell mehrere Cuelists mit einer höheren Priorität, bei ich laufende Cuelists gezielt für folgende Lichtstimmungen überschreibe:

• Moderationslicht
• Einmarsch
• Siegerehrung
• Spiegelkugel-Ambiente

In allen Fällen nutze ich für die jeweiligen Lichtstimmungen meist die gleichen Geräte, die sonst auch für die allgemeine Show mitlaufen. Habe ich nun solche Mehrfachverwendungen, muss ich aktuell immer manuell dafür sorgen, dass ich in den zugehörigen Cuelists zum Beispiel die Gobos und Prismen herausnehme oder den Strobe gezielt auf 0 setze, wenn ich eine “saubere” Ausgabe haben möchte. Sprich: auch wenn ich einen Strobe-Effekt abfeuere, soll das Gerät für das Moderationslicht nicht mit stroben. Dies wird insbesondere bei Moving Heads mit ein paar mehr Funktionen immer aufwendig.

Um die Programmierung zu vereinfachen, würde ich mir eine Möglichkeit wünschen, bei der ich gezielt festlegen kann, dass für in der Cuelist nicht verwendete Funktionen automatisch die Grundwerte von den verwendeten Geräten herangezogen werden. So müsste ich dann für das Spiegelkugel-Ambiente nur Dimmer, Position, Farbe und Iris festlegen. Andere Funktionen wie Gobo oder Prisma werden beim Starten auf die Werte gesetzt, die die Geräte als Default einnehmen (Gobo offen, kein Prisma, kein Strobe).

Im Ticket  FS#3722  kam der Wunsch auf, die Ports der Art-Net-Ausgabe etwas sinnvoller zu sortieren, dass immer direkt 8 Universen am Stück adressiert werden. Durch das neue Ausgabe-Plugin hat sich dieser Dialog in der Hinsicht vereinfacht.

Als Folgeproblem hat sich aber nun durch das neue Ausgabe-Plugin für Art-Net ergeben, dass jedes weitere immer mit dem 1. DMX-Universum angelegt wird - und war sowohl innerhalb der Übersicht der DMX-Interfaces als auch in den erweiterten Einstellungen selbst. Um das Anlegen mehrerer Art-Net-Interfaces zu vereinfachen und zu beschleunigen, sollte hier an beiden Stellen bei den DMX-Universen automatisch “hochgezählt” werden. Net und Subnet bleiben konstant.

Der Wunsch resultiert aus folgendem Anwendungsfall heraus: ich möchte zum Beispiel einen Moving-Head für eine Szene sehr exakt positionieren, um ein Objekt oder eine Person optimal zu beleuchten. Die grobe Position kann ich noch mit Hilfe des Position Panel oder auch über eine Abschätzung der Positionswerte finden. Geht es aber dann daran, die Position auf ein paar Zentimeter genau einzustellen, muss ich aktuell immer die Werte für Pan und Tilt im Device Control ändern. Die Regler für Pan bzw. Tilt sind hier ebenfalls nicht feinfühlig genug.

Grundsätzlich ist es zwar möglich, dass ich mir im Vorfeld ein entsprechendes Connectionset für diesen Anwendungsfall baue. Dies benötigt jedoch jedes Mal Zeit, wenn man ein neues Projekt erstellt oder muss es in vorhandenen Projekten nachpflegen. Darüber hinaus beschränkt sich dies dann auch immer nur auf bestimmte Funktionen.

Daher wünsche ich mir, dass unter anderem im Device Control die Möglichkeit geschaffen wird, über Tastatur-Shortcuts oder über Buttons mit der Maus die Werte für die Gerätefunktionen inkrementell und mit einer feinen Abstufung zu ändern.

Fallen Graphen im Input Assignment etwas umfangreicher aus, verschwinden die Inputs und Outsputs zwischen den teilweise großen Nodes. Um die Inputs und Outputs besser im Graphen zu finden, wäre es gut, wenn diese farblich hervorgehoben werden.

Beim Eingeben von längeren Tags für ein Projekt können sich durch Tippfehler schnell Fehler einschleichen und man findest das Projekt nicht über diesen Tag. Zudem benötigt die Eingabe von längeren Tags entsprechend mehr Zeit.

Hier fände ich es gut, wenn mir bei der Eingabe die zuletzt genutzten Tags automatisch vorgeschlagen werden. Konkret dachte ich da ein Verhalten analog

• zu unserem Forum beim Verlinken eines Nutzers oder
• beim Schreiben einer News, wo nach dem Eingeben einer bestimmten Anzahl an Zeichen in den Tags ebenfalls die bisher verwendeten Tags vorgeschlagen werden

Projekte, die ich angepinnt und damit als Favorit markiert habe, sollten in der Liste der Projekte farblich hervorgehoben oder anderweitig von den nicht angepinnten Projekten separiert werden. Der Stern finde ich als Hinweis drauf ein bisschen zu wenig.

Dieses Ticket steht in gewissen Teilen auch im Zusammenhang mit Ticket FS#4927, da ich von meiner Seite davon ausgehe, dass die angepinnten Projekte immer oben in der Liste angezeigt werden.