Bugtracker DMXControl 3

Ich möchte mir den aktuellen Farbwerrt eines Color Masters auf dem Buttons eines Macroboard Profiles anzeigen lassen und habe dazu den Ausgang “Value” des Color Masters direkt mit dem Eingang “Background Color” des Draw Bitmam Nodes verbunden.

Während der Color Master am Ausgang “Value” den Wert “1; 1; 1” als LumosColor-Objekt ausgibt, erwartet der Eingang “Background Color” des Draw Bitmap Nodes einen RGB-Wert. Folglich bleibt der Button effektiv gesehen dunkel, da ja “1; 1; 1” im RGB-Farbraum mit dem Wertebereich 0 bis 255 effektiv gesehen schwarz ist.

Im Hinblick darauf, dass wir im Input Assignment weitestgehend mit normierten Werten arbeiten wollen, sollte der Draw Bitmap Node als Folge dessen das LumosColor-Objekt an beiden Eingängen für die Farbe verstehen.

Der neue Fadertyp “Limit” für die Executor-Variante der Cuelist ist in den Einstellungen des Executors noch nicht in der Auswahlliste für den Fader enthalten.

Wenn ich eine neue Gobo Affinity sowohl in einem neuen, leeren Projekt als auch in einem Projekt mit bereits gepatchten Geräten erstelle und hierzu das zu Grunde liegende Gobo auswählen möchte, so wird in dem Auswahlfenster kein Inhalt angezeigt - egal ob der Halen “Included in project” gesetzt ist oder nicht oder ob ich etwas in das Suchfeld eintrage.

Das zusammenstellen der Gobos für eine Goboliste funktioniert dagegen. Dort werden die verfügbaren Gobos angezeigt.

Im Anhang habe ich die Logfiles beigefügt, die den Punkt für ein leeres Projekt protokollieren.

Wie im beigefügten Bild zu sehen, entspricht die Höhe des Kontextmenüs zur Executor Page im Executor-Fenter nicht den allgemein üblichen Abmessungen. Dies gilt sowohl für das Standard Theme als auch das Dark Theme.

Das 3Dconnexion Plugin muss auf DMXControl 3.3 portiert und dann wieder dem Installer hinzugefügt werden.

Ich habe mir eine Cuelist gebaut, die als Blackout fungiert. Dies bedeutet, diese Cuelist setzt den Dimmer für eine Gerätegruppe auf 0. Durch eine Priorität von “11” überschreibe ich meine normalen Cuelists mit Effekten. Nun habe ich einige Cuelists, die mit Werten wie “21” bzw. “31” eine höhere Priorität verfügen und somit die Blackout-Cuelist überschreiben.

Führe ich die Cuelists mit den Prioritäten “21” bzw. “31” aus, füllt sich der Log der Kernels regelmäßig mit den folgenden Einträgen - obwohl die besagte Cuelist “MHS BLK Blackout” gar nicht ausgeführt wird:

21:15:30 WARN  DMXUniverseArray - Setting a DMX Value from an inactive Source: MHS BLK Blackout

Der Grund für dieses Ticket ist also, dass zahlreiche Logeinträge generiert werden, obwohl es mangels inaktiver Cuelist gar keinen Grund dafür gibt, diese Einträge zu generieren.

Ich möchte mit einem einzigen Fader den Wert eines Position-Masters ändern. Dazu baue ich mir ein Positions-Objekt mittels des Format-Nodes zusammen und habe dies mit “{0:0.##}; {1:0.##}” parametriert. Erhält das Position Master Node diesen Wert, gibt der Kernel folgende Fehlermeldung aus:

19:11:23 WARN  EventTools - Exception in Delegate Invocation: Void <AddDefaultPorts>b__37_3(org.dmxc.lumos.Kernel.Input.v2.GraphNodePortID, System.Object) => org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.Void <AddDefaultPorts>b__37_3(org.dmxc.lumos.Kernel.Input.v2.GraphNodePortID, System.Object)
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.ArgumentOutOfRangeException: Input must be <= inMax [0]
Parametername: input
Der tatsächliche Wert war 0,5.
   bei LumosLIB.Tools.LumosTools.RuleOfThree(Double input, Double inMax, Double inMin, Double outMax, Double outMin, ERuleOfThreeBehavior behavior) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosLIB\src\Tools\LumosTools.cs:Zeile 544.
   bei org.dmxc.lumos.Kernel.Master.PositionMaster.set_Value(Position value) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Master\PositionMaster.cs:Zeile 170.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setInputaValue() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:Zeile 189.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.<AddDefaultPorts>b__37_3(GraphNodePortID sender, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:Zeile 236.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Delegate.DynamicInvokeImpl(Object[] args)
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0.<InvokeFailSafe>b__0(Delegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 136.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 180.

Das Position to Pan/Tilt Node versteht die so erstellten Werte dagegen und arbeitet erwartungsgemäß.

In den Optionen für die Cuelist Group ist der Eintrag “Intelligent settings” wieder sichtbar. Da diese Funktion nicht genutzt werden soll und auch nicht genutzt werden kann, müsste die einmal ausgeblendet werden.

Die Einstellung “Number of Executors” kann ich nicht erreichen, wenn ich die Einstellungen für die Executor Page im Project Explorer über das Kontextmenü zum Zweig “Executor Page” aufrufe (siehe Bild 1). Wähle ich stattdessen den Weg über die Settings, liegt die Einstellung vor und arbeitet auch wie erwartet (siehe Bild 2).

Um das Ticket  FS#4525  nicht nochmal komplett zu öffnen, ziehe ich den dort vermerkten Punkt 3 mit etwas abgewandelter Beschreibung nochmal auf, nachdem er mit im Kontext von  FS#4771  bewusst (wieder) aufgefallen ist:

Zwischen dem ersten und zweiten Gerät in der Device Group nicht nahtlos statt findet der Wechsel bzw. die Umschaltung zwischen dem. Hier gibt es einen kurzen Augenblick, bei dem das Gerät 1 bereits aus aber das Gerät 2 noch nicht an ist und so ein Blitz entsteht. Dieser Punkt ist gut in dem beigefügten Projekt sowohl in der Stage View als auch auf meinen LED-Bars in Realität zu sehen. Ich habe hier

• einen Custom Chaser mit nur zwei Schritten, wo das Group Handling auf 2 gesetzt ist sowie
• einen einfachen Chaser mit Playmode Normal, jedoch mit einem “hohen” Wert für das Group Handling

in der Cuelist gespeichert.

In der Summe ist das Phänomen mit (allen) anderen Playmodes reproduzierbar und fällt zunehmend stärker auf, umso größer der Wert für das Group Handling ist.

Mit ein bisschen gefummel habe ich aus dem Code herausgefunden, dass die Definition innerhalb der csv-Datei für den Custom Chaser wie folgt aussehen muss:

ChaserDefinitionFile
MyChaser:
1;0;1;0;0;1;0;1
0;1;0;1;1;0;1;0

Hier stellt sich mir die Frage, ob das so gewollt ist, oder ob es ein Tippfehler handelt. Denn gefühlt wäre das etwas ungewöhnlich, auch wenn ich es grundsätzlich dokumentieren kann. Die Frage wäre, ob es alternativ möglich wäre, den Namen in “” zusetzen.

Werden gewisse Elemente wie zum Beispiel Nodes im Input Assignment durch Alternativen ersetzt, erhält das betreffende Node einen Hiidden-Flag. Dieses Flag sorgt dafür, dass diese Nodes für neue Projekte nicht mehr zur Verfügung stehen. Bestehende Projekte können aber noch geladen werden.

Der Nutzer wird im Form eines ToDos darauf hingewiesen, dass diese Element in der zukünftigen Version entfernt wird.

Um die Nutzer bei der Verwendung der Funktion “Zeitpunkt für Aktivierung der DMX-Ausgabe selbst festlegen” aus Ticket  FS#4015  zu unterstützen, aber auch bei weiteren Punkten wie

• Grandmaster, Gruppenmaster etc. unter einem bestimmten Wert
• Blackout aktiv
• Freeze aktiv
• Cuelist-Intensität auf 0

sollen alle Warnungen und Änderungen mit einem “Schweregrad” bzw. Warning-Level versehen werden.

Zur Protokollierung, welche Funktion die Warnung generiert oder das Dirty Flag setzt, soll ein Interface gebaut werden, über das die Wichtigkeit der Änderung an einen zentralen Manager weitergereicht wird. Wie detailliert die Rückmeldung an den Nutzer erfolgt, kann dieser über eine Einstellung festlegen. Diese Einstellung greif dabei die verschiedenen Level der Schwere der Warnung oder der Änderung am Projekt auf.

Arbeitet man mit mehreren Seiten, wird der Button der aktuellen ausgewählten Seite immer mittig dargestellt. Dies ist auch der Fall, wenn das Executor-Fenster breit genug ist und alle Buttons dargestellt werden können. Daher sollte aus meiner Sicht das Schieben der Buttons erst aktiviert werden, wenn die Breite des Fensters nicht ausreicht, um alle Buttons darzustellen. Steht genügend Platz zur Verfügung, sollten die Buttons einfach nur statisch zentriert angezeigt werden.

Füge ich eine Special Cue ein, so wurde die in DMXControl 3.2.3 standardmäßig so benannt, welche Aktion beim hinzufügen dieser Special Cue eingestellt war. Zum Beispiel:

• Audio: Play: Jack Ü - to ü [vs. Skrillex & Diplo feat. AlunaGeorge].mp3
• Cuelist: Go: DMH EFF laufend 4-fach

In DMXControl 3.3.0 Alpha 9 werden aktuell stattdessen die Namen vergeben, welche in den Optionen der Cuelists voreingestellt sind.

Ich habe in einer Cuelist als eine der ersten Szenen eine Audiodatei eingefügt, welche “innerhalb” der Cuelist wiedergegeben werden soll. Alle nachfolgenden Cues mit dem Trigger “Timecode” werden aber nicht ausgeführt weil entweder der Timecode der Audiodatei nicht übergeben wird oder der Trigger selbst einen internen Fehler aufweist.

Reproduzieren lässt sich dies mit dem beigefügten Projekt. Logeinträge mit eventuellen Fehlermeldungen sind in allen drei Komponenten nicht vorhanden. Der Kernel protokolliert nur erwartungsgemäß, wenn die Audiodatei gestartet bzw. gestoppt wurde.

Die neuen Executoren unterstützen aktuell noch keine Multi-Touch-Eingabe. Diese Funktion soll auch Basis der Implementierung im Softdesk übernommen werden.

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.

Ist das Projekt zum Ablauf des eingestellten Timers nicht “Diry”, das heißt, das Dirty Flag ist nicht gesetzt, wird das automatische Speichern zu diesem Zeitpunkt ausgesetzt. Der Timer wird aber neu gestartet.

Entscheidung aus QRM 22.1

Kann ein Projekt nicht erfolgreich abgespeichert werden, wird das Dirty Flag trotzdem auf “Projekt unverändert” zurückgesetzt. Aus meiner Sicht sollte das nicht so sein und erst den Status “Projekt gespeichert” annehmen, wenn im Kernel der Logeintrag

00:00:40 INFO  Messages - Message from ...: Saved Project to GUI Undefined, Path MyProject.dmz

erscheint. Ein typisches Beispiel ist, um das Problem schnell zu reproduzieren, das Projekt mittels 7zip oder ähnlich “anzusehen”, wodurch DMXC keine Schreibrechte mehr auf die Datei hat. Siehe hierzu auch mein Ticket  FS#4651 .

Aktuell gibt es in den Einstellungen für den Executor zu den Cuelists noch den Eintrag “Release at zero”. Dieser funktioniert nicht und wurde mittlerweile durch “Auto Stop” abgelöst.

Verschiedene DMX-Interfaces, wie zum Beispiel das Nodle U1 oder das Nodle R4S werden nach dem Beenden des Kernels nicht automatisch abgeschaltet, wenn diese zuvor aktiv waren. Die Status-LEDs gehen nicht aus.

Ich habe ein Softdesk mit mehreren Controls angelegt. Von diesen habe wiederum einige gelöscht und den Softdesk Designer geschlossen. Speichere und schließe ich das Projekt und lade ein neues, bleibt das gelöschte Softdesk Control noch im Input Assignment erhalten, wie im beigefügten Screenshot zu sehen.

Da ich das Problem nicht direkt im gleichen Kontext wie Ticket  FS#4577  sehe, habe ich dieses neue Ticket erstellt.

Im Anhang findet sich das Projekt sowie die Logs der Sitzung.

Ich habe zwei DMX-Interfaces hinzugefügt und diese dann deaktiviert (siehe Bild 1). Aktualisiere ich die Ansicht, werden zwar beide Interfaces durch die grau hinterlegten Zellen als deaktiviert gekennzeichnet (siehe Bild 2). Der Haken wird aber wieder gesetzt, was dann zu Verwirrung führt.

Dieser Fehler steht aber nicht im Zusammenhang mit Ticket  FS#3864  bzw. darf nicht als solcher verstanden werden.

Im Anhang die Log-Dateien der Sitzung.

An aktuell zwei Stellen ist mir aufgefallen, dass das Anzeigeformat unter den folgenden Punkten noch fortlaufend ist und nicht wie angedacht im Format [Universum.Adresse].

• Konfiguration der DMX-Interfaces: nach dem Aktualisieren der Liste (siehe Bild 1)
• Add device dialog: im Projekt existieren bereits Geräte und man fügt zu einem späteren Zeitpunkt weitere hinzu (siehe Bild 2)

An weiteren Stellen, wie zum Beispiel in den Device Properties oder im Patching Dialog werden die DMX-Adressen im gewünschten Format [Universum.Adresse] angezeigt.

Ich nutze den Sparkle-Effekt, um damit die Farbe einer Gerätegruppe zu steuern. Trage ich unter Peak beim Sparkle-Effekt zum Beispiel einen ColorMaster ein, erscheint bei Bestätigung der Eingabe der folgende Fehler und der Effekt bleibt stehen.

20:33:53 WARN  SceneFadeTicker - Exception triggering Item: start or end value have wrong type!
System.ArgumentException: start or end value have wrong type!
   bei org.dmxc.lumos.Kernel.PropertyValue.Fade.AbstractFader`1.fade(Object startValue, Object endValue, Double percent) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Fade\AbstractFader.cs:Zeile 53.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.SparkleFilter.doFilter(IPropertyValue input, Int64 timeInMs, Int64 delta) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Filter\SparkleFilter.cs:Zeile 180.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.AbstractEffectFilter.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Filter\AbstractEffectFilter.cs:Zeile 58.
   bei org.dmxc.lumos.Kernel.PropertyValue.AbstractPropertyValue.getPropertyValue(Int64 timeInMsAbs) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:Zeile 402.
   bei org.dmxc.lumos.Kernel.PropertyValue.AbstractPropertyValue.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:Zeile 338.
   bei org.dmxc.lumos.Kernel.Scene.Fade.FadeDecorator.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\FadeDecorator.cs:Zeile 96.
   bei org.dmxc.lumos.Kernel.Scene.Delay.DelayDecorator.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Delay\DelayDecorator.cs:Zeile 38.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AutoFadeDecorator.triggerFade() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AutoFadeDecorator.cs:Zeile 33.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AbstractValueFadeDecorator.triggerFade(Boolean& deregister) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AbstractValueFadeDecorator.cs:Zeile 201.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AbstractFadeDecorator.trigger() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AbstractFadeDecorator.cs:Zeile 65.
   bei org.dmxc.lumos.Kernel.Scene.SceneFadeTicker.processBag(ProcessableTickerBag bag, Int64 now) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\SceneFadeTicker.cs:Zeile 218.

Gleiches gilt auch für andere Master.

Mache ich das Gleiche zum Beispiel mit dem Chaser-Effekt, kann ich den ColorMaster nutzen, um die Farbe zu steuern. Entsprechend Patricks Aussage müssen hier Code-Segmente explizit kopiert werden.

Um etwas mit dem List Selector zu spielen, habe ich mir das im beigefügten Projekt enthaltene Connectionset gebaut. Über die Buttons “previous” und “next” kann ich die Geräte der zugeordneten Gerätegruppe durchschalten. Für einen schnellen Überblick einfach das letzte Fensterlayout laden.

Hierbei musste ich aber feststellen, dass die Liste, welche das Device Group Node generiert, nicht der Reihenfolge der Sortierung der Geräte innerhalb der Device Group entspricht. Die erwartete Sortierung entspricht dem, wie die Geräte in der Stage View von links nach rechts positioniert sind. Selbst eine einfache alphabetische Sortierung der Geräte entsprechend ihres Namnes oder auf Basis der Gerätenummer findet nicht statt. Somit ist es in der aktuellen Version etwas unintuitiv, das gewünschte Gerät aus der Liste herauszusuchen.

Ändere ich bei einem bereits einmal gespeicherten und wieder geöffneten Projekt zum Beispiel bei einer Auswahl von Devices in der Stage View die Einstellung “Enabled”, so friet die GUI ein. Um weiterarbeiten zu können, muss ich den Prozess “hart” über den Task Manager beenden.

Dieses Ticket beschreibt den eigentlich beobachteten Fehler aus Ticket FS#4683. Im Nachhinein betrachtet war es dort die gleiche Vorgehensweise, nur eben mit dem Eintrag “Mirror horizontal”. Hier war das Projekt zum Zeitpunkt des Auftreten des Fehlers zuvor ebenfalls innerhalb der Sitzung nochmal neu geladen worden.

Im Anhang befindet sich das Projekt sowie die Logfiles, wobei die der GUI nur bis zu dem Zeitpunkt erfasst sind, bis diese über den Taskamanager beendet wurde.

Beim Reproduzieren des Fehlers aus Ticket  FS#4709  habe ich ein einziges DDFs aus verschiedenen Verzeichnissen einem neuem Projekt hinzugefügt. Bedeutet:

1. DDF aus Verzeichnis A dem Projekt hinzugefügt
2. DDF in ein anderes Verzeichnis verschoben und leicht modifiziert
3. DDF aus Verzeichnis B dem Projekt hinzugefügt
4. …

Aus diesem Grund befand sich das DDF beim Speichern des Projekts nicht mehr im Verzeichnis A. Dies bemerkt der Kernel und trägt eine Fehlermeldung im Log ein:

23:43:06 WARN  FileBackendDatastore - Following Resources could not be saved in Project:
{ "type": "DDF", "name": "Icons\\Eurolite LED BAR-6 QCL RGBA (9 channel).xml" }
{ "type": "DDF", "name": "Images\\Eurolite LED BAR-6 QCL RGBA (9 channel).xml" }
23:43:07 INFO  Messages - Message from SKI-DSK-TCM900A: Saved Project to GUI SKI-DSK-TCM900A, Path 2022-01-22 - DDF Folders.dmz

In der GUI gibt es dazu keinerlei Hinweise, dass beim Speichern des Projekts nicht (mehr) alle benötigen Daten gefunden werden konnten. Gerade in Hinblick darauf, wenn zukünftig noch mehr Dateien für das Projekt benötigt werden, sollte bereits beim Speichern ein solcher Hinweis erscheinen.

Möglicherweise steht dieses Ticket ein Stück weit auch im Zusammenhang mit  FS#4651  oder kann im gleichen Aufwasch behoben werden.

Durch einen dummen Zufall ist mir aufgefallen, dass DDFs, welche sowohl im Verzeichnis “Icons” und / oder “Images” liegen, ebenfalls einem Projekt hinzufügt werden können. In diesem Fall übernimmt DMXControl 3 beim Speichern sogar diese zusätzlichen Pfade, wie in dem beigefügten Projekt zu sehen ist.

Um den Fehler gezielt zu reproduzieren, habe ich bewusst den DMX-Mode bei den Devices 2 und 3 angepasst, damit ich die Software entsprechend zum erneuten Laden der verfügbaren DDFs bewegen konnte.

Aus meiner Sicht sollte dies unterbunden werden. DDFs haben ausschließlich direkt im Verzeichnis “UserDevices” zu liegen, nicht in den Unterordnern “Icons” oder “Images”. Eigene Ordner werden im Übrigen bereits ignoriert.

Für den Position Master sollen folgende Buttons hinzugefügt werden:

• Zero Pan
• Zero Tilt

Ist ein Button mit “Empty” belegt, sollten diese so gestaltet werden, dass diese farblich deutlich zurückhaltend gestaltet sind. Aktuell muss man sehr genau schauen, welche Button mit einer “richtigen” Aktion belegt sind.

Im Kernel wird in einer der ersten Zeilen des Logs die genaue Versionsnummer vermerkt:

2022-01-06 16:40:37,100 [Main] INFO  org.dmxc.lumos.Kernel.Run.KernelRunManager - DMXControl V3.3.0.887 Alpha8 starting! (x86)

Ein solcher äquivalenter Eintrag fehlt im Log des Umbras. Hier kann man nur über

2022-01-06 16:51:20,132 [Main] INFO  Umbra.Run.UmbraRunManager - Umbra Build Time: 06.01.2022 13:32:25 UTC

darauf schließen, welcher Build der aktuellen Programmversion zu Grunde liegt.

In der Titelleiste des Umbras erscheint zwar die Version richtig, nämlich DMXControl V3.3.0.887, der weitere Zusatz ist aber bei “Alpha 7” stehen geblieben.

Ich habe ein Gerät mit einer 1×6 Matrix (6 Pixel horizontal in einer Zeile). Ändere ich hier die Ausrichtung der Matrix oder möchte diese auf einer Ebene spiegeln, friert die GUI ein. Nach dem Abschießen der GUI lässt sich der Kernel daraufhin auch nicht mehr per Kommandozeile vollständig herunter fahren.

In Vorbereitung auf den heutigen Stream habe ich mir den Temp-Fader nochmal angeschaut, nachdem die Info kam, die Funktion sei nun vollständig implementiert. Im Zuge dieses Tests sind gleich zwei Dinge aufgefallen, die sich am besten mit dem beigefügten Projekt reproduzieren lassen.

1. Die Steuerung der Intensity der Cuelists ist kaputt gegangen. Die Executoren 1.1 und 1.3 übergeben die Werte zwar an die Cuelists. Eine Umsetzung findet aber nicht mehr statt.
2. Temp-Fader wird nur aktualisiert, wenn die Cuelist auf Executor 1.3 eingefadet, zwischen den Cues übergefadet oder ausgeblendet wird. Ist die Cue zu 100% eingeblendet, wirkt sich der Temp-Fader nur noch als zusätzlicher Intensity-Regler für Helligkeit, aber nicht für den Grad der Einmischung der Werte.

Zum zweiten Punkt wäre folgende Erwartungshaltung. Ist die Cuelist auf Executor 1.1 aktiv, soll der Temp-Fader zu jedem Zeitpunkt bestimmen

• den Wert, wie weit die Farbe eingemischt wird zwischen 0% und 100% grün / blau alternierend.
• den Winkel, wie “hoch” die Geräte schwenken zwischen 0° und 95° (dies ist besser live zu sehen).

Hinzu kommt, dass beim Überblenden der Cuelist auf Executor 1.3 nicht von Cue 1 nach Cue 2 übergeblendet wird. Stattdessen Blitzen die im Hintergrund gesetzten Werte (Defaultwerte oder die Cuelist auf Executor 1.1) auf und faden mit der gesetzten Fadezeit der Cue 1 bzw. Cue 2 aus. Für dieses Verhalten ist der Wert des Temp-Faders irrelevant.

Durch die neuen Master kamen weitere Icons in der sowieso extrem breiten Menüleiste des Project Explorers hinzu. Dadurch rutschen häufiger benötigte Icons noch weiter nach rechts.

Daher wäre der Wunsch unabhängig vom Ticket FS#3360, dass diese vier Icons für die vier Master in ein Dropdown-Menü zusammengefasst werden, dessen Obertitel “Add Master” ist.

Legt man eine neue Color-, Gobo oder Positionlist an, erscheint hierzu immer der Auswahldialog “New Item List”, wo über das dort enthaltende Dropdown-Menü der Typ ausgewählt wird.

Tendenziell ist dieser Auswahldialog “New Item List” aber eigentlich überflüssig. Die dortigen Einträge können auch in das Kontextmenü des Project Explores überführt werden, so wie es bereits bei den Mastern der Fall ist.

Aktuell ist keine Ausgabe über das “neue” Art-Net-Ausgabeplugin möglich.

Beim Start des Kernels gibt es folgenden Eintrag:

23:29:31 WARN  AssemblyManager - Unable to remove Zone.Identifier from File C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Plugins\ArtisticLicenseArtNet.dll
System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Plugins\ArtisticLicenseArtNet.dll:Zone.Identifier:$DATA' was denied.
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.ThrowIOError(Int32 errorCode, String path)
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.ThrowLastIOError(String path)
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.SafeDeleteFile(String name)
   bei Trinet.Core.IO.Ntfs.AlternateDataStreamInfo.Delete()
   bei org.dmxc.lumos.Kernel.AssemblyScan.AbstractAssemblyManager.TryRemoveZoneIdentifierIfExisting(String file) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosLIB\src\Kernel\AssemblyScan\AbstractAssemblyManager.cs:Zeile 436.

Sobald ich das Plugin deaktiviere, erscheint der folgende Log-Eintrag:

23:31:52 ERROR ArtNetFactory -
System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.Sockets.Socket".
   bei System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   bei System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\mos_DMXPlugins_Pipeline_master_2\ArtisticLicenseArtNet\src\ArtNetManager.cs:Zeile 704.

Im Anhang befinden sich die Logs einer Sitzung sowie die Konfiguration des ausgeschalteten Plugings.

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 Überprüfung des im Ticket  FS#4415  wollte ich dieses nach dem Import entsprechend in DMXControl 3.3 Alpha 7 laden. Dies ist aber auf Grund der folgenden Meldung im Kernel nicht möglich:

2021-12-02 19:14:23,620 [12] ERROR org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter - Error in Reading KeyValue Pair: Attribute

   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateManagedTree(XmlElement node, Double version, EIOFlags flags, List`1 errors) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 146.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateManagedTree(XmlElement node, Double version, EIOFlags flags, List`1 errors) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 127.

In den beigefügten Logs ist die vollständige Fehlermeldung enthalten. Das entsprechende Projekt liegt ebenfalls bei.

Grob zusammenfasst beinhaltet das Projekt folgendes:

• 20 Geräte, zugeordnet zu 4 verschiedenen Gerätegruppen
• 1 Cuelist
• 2 Makroboard-Profile, wobei nur das erste eine entsprechend einfache Zuweisung im Input Assignment besitzt

Öffne ich das Projekt aus  FS#4656  und starte dann einmal nur die GUI neu, ist das Executor-Fenster komplett leer. Es werden sowohl keine Executor Pages als auch die Executoren selbst nicht angezeigt.

Klicke ich aber auf “Add Page”, merkt das Fenster, dass bereits Executor Pages im geladenen Projekt existieren und beginnt entsprechend nach dem “höchsten” Executor zu zählen. Auch die Seitenzahl beginnt nicht bei 1.

Ich habe mir eine Cuelist mit fünf Cues gebaut, wobei das Tracking standardmäßig aktiv ist:

1. Cue 1 - blue > red
2. Cue 2 - static white
3. Cue 3 - green > blue
4. Cue 4 - static red
5. Cue 5 - static violett

Mit dieser Cuelist führe ich folgende Schritte aus:

• Ich lasse die manuell via Go getriggert per Executor bis zur 5. Cue durchlaufen.
• Ich drücke mehrfach den Pause- / Back-Button. Die Anzeige unter “Current cue” springt ab dem zweiten Klick mit jedem weiteren Klick Cue für Cue zurück - und zwar in der Reihenfolge, wie die Cues in der zugeordneten Cuelist angeordnet sind. Den Button drücke ich so lange, bis unter “Current cue” die “Cue 2” aufgeführt wird. Die Zeile ist grau hinterlegt.
• Ich klicken auf Go. Der blaue Balken beginnt, sich von links aus aufzubauen. Das gleiche Verhalten zeigt die Cuelist selbst auch.

Mit dem Klick auf Go führt die Cuelist aber nicht wie vom Executor suggeriert die “Cue 2” aus, sondern die der “Cue 5” vorhergehende “Cue 4”. Erst wenn ich das Tracking deaktiviere wird auch die “Cue 2” tatsächlich ausgegeben.

An dieser Stelle sollte ich aus meiner Sicht die Cuelist nicht anders verhalten, als wenn ich die “Cue 2” in der Cuelist selbst manuell per “Load” vorauswähle und dann mit dem Klick auf Go (egal ob Cuelist oder per Executor) aufrufe. Sprich: in beiden Fällen (egal ob Tracking aktiv oder nicht) sollte die “Cue 2” ausgeführt werden, so wie es mir auch in der Anzeige im Executor oder in den Progress-Balken der Cuelist suggeriert wird.

Um das unterschiedliche Verhalten darzustellen, enthält das beigefügte Projekt die Cuelist zwei Mal - einmal mit aktiven und einmal mit deaktiviertem Tracking. Beide Cuuelists sind direkt per Executor aufrufbar, wenn das letzte Fensterlayout geladen wird.

Ich habe mir ein Projekt erstellt, um die verschiedenen Executor-Typen zu testen und zu dokumentieren. Die Belegung der verschiedenen Seiten ist in den beigefügten Screenshots zu sehen. Die verschiedenen Executoren enthalten dabei auf allen Seiten mehrfach die gleichen Elemente, damit ich insbesondere auch die zahlreichen Buttons prüfen kann. Soweit ich das überblicke, werden diese Informationen auch richtig in die Datei “ExecutorMemberWrappers.xml” geschrieben.

Beim erneuten Laden des Projekts direkt aus der laufenden Sitzung heraus oder auch beim Laden des Projekts nach einem Neustart von DMXC werden die Belegung der Executor-Pages augenscheinlich unvollständig bzw. gar nicht geladen - insbesondere bei den “hinteren” Executor-Pages (im aktuellen Beispiel Group Master, Parameter Master etc.). Beim Betätigen des Faders des Executor 2.1 (Executor Page Group Master) kann man aber erkennen, dass eine Verknüpfung im Hintergrund noch existiert. Die Fader der Executoren 2.2 und 2.3 bewegen sich mit. Gleiches fällt auf, wenn man die Belegung der Executoren ändern möchte. Es wird erst beim zweiten Ablegen eines Elements auf den Executor wirklich das neue Element angezeigt.

Im Anhang findet sich neben den Screenshots des Sollzustands das zugehörige Projekt sowie die Logfiles, die nach dem Neustart und Laden des Projekts generiert wurden.

Man kann in den Einstellungen der Executoren festlegen, dass ein Fader und Buttons nicht belegt sind. In diesem Fall könnte aus meiner Sicht die Übersichtlichkeit erhöht werden, wenn diese bei der Einstellung “Empty” ausgegraut werden, also optisch in den Hintergrund treten. Gerade ein unbelegter Fader zeigt dies nicht offensichtlich genug.

Das beigefügte Projekt enthält drei Softdesks mit zahlreichen Steuerelementen. Beim ersten Laden klappt in der Regel alles noch einwandfrei, wenn die letzte Fensteranordnung aufgerufen wird, die alle drei Softdesks anzeigt. Wenn ich aber die nachfolgend genannten Schritte ausführe, findet die GUI zwei der drei Softdesks nicht, obwohl diese zuvor noch geöffnet werden konnten. Die zugehörigen Fenster bleiben leer.

1. Projekt über “Close Project” schließen.
2. Ein neues, leeres Projekt erstellen lassen.
3. Beigefügtes Projekt erneut öffnen und letzte Fensteranordnung aufrufen.

Ursprung dieses Tickets war, dass bei meinen Projekten aus DMXC 3.2.2 die noch deutlich umfangreicheren Softdesks bereits beim ersten Laden des Projekts nach dem Start der Sitzung nicht aufgerufen werden konnten, was zur Folge hat, dass das gesamte Projekt nicht mehr funktioniert. Hinterlege ich im Projekt die Softdesks einzeln in einem separaten Projekt ohne weitere Inhalte, indem ich die über die Datei “SoftdeskMaster.xml” auskommentiere, konnten alle Softdesks für sich einzeln geladen werden. Sobald aber alle “aktiv” sind, klappt dies nicht. Spannenderweise wechselst dies auch durch, wenn ich die Reihenfolge der Einträge in der Datei “SoftdeskMaster.xml” ändere.

Im Anhang findet sich das vereinfachte Testprojekt mit den speziell für dieses Ticket angelegten Softdesk sowie die Log-Dateien für einen kompletten Durchlauf, wie er oben beschrieben ist.

Kann der Kernel ein Projekt nicht speichern, weil es durch andere Anwendungen schreibgeschützt ist oder nicht gefunden werden kann, erhält der Nutzer keine Info mehr darüber. Hier sollte unbedingt eine Fehlermeldung in der GUI erscheinen, wie es auch aktuell in DMXC 3.2.x der Fall ist.

Analog zu den zusätzlichen Befehlen zum Herunterfahren des Kernels (siehe Ticket  FS#4394 ) sollten diese aus Konsistenzgründen auch im Umbra hinterlegt werden. Aktuell wären diese zusätzlichen Befehle “quit” und “close”.

Auf das Ticket  FS#4647  aufbauend ist es bei einer bereits angelegten Executor-Seite nicht mehr möglich, die Anzahl der Executoren zu ändern. Die angebotene Option in den Einstellungen für die Seite wird nicht berücksichtigt.

In den Einstellungen für die Executor-Seiten kann ich festlegen, wie viele Executoren ist pro Seite nutzen möchte. Dieser Wert wird jedoch ignoriert. Egal welchen Wert ich einstelle, es werden grundsätzlich acht Executoren pro Seite angelegt.