Bugtracker DMXControl 3

Der DMXCMixer-Node gibt am Strobe-Output keinen Double-Wert aus, sodass nachfolgende, numerisch arbeitende Nodes wie der Compare-Nodes mit den ausgegebenen Werten nicht direkt arbeiten können. Hierzu muss der Wert erst unnötigerweise mit einem Format-Node konvertiert werden. Dieses Verhalten ist insofern unschön als dass es zum einen nicht von außen ersichtlich und zum anderen sich im direkten Vergleich mit dem Intensity-Output nicht gleich verhält. Der Intensity-Output gibt direkt einen Double-Wert aus.

Der Blick in den Code zeigt, dass der DMXCMixer offensichtlich von vorn herein unterschiedliche Datentypen erhält. Denn abgesehen von den verschiedenen Parametern Dimmer (Intensity) bzw. Strobe gibt es keine Unterschiede.

Ich habe den Output “Child ID” des Device Group Nodes mit dem Input “List” des List Selector verbunden. Möchte ich nun durch diese Liste durchschalten, erscheint bei jeder Umschaltung der folgende Eintrag im Kernel. Als Wert für die Umschaltung übergebe ich ganzzahlige Werte (also int-Werte) mittels des Counter-Nodes im Bereich 0 bis 10.

13:16:20 ERROR AbstractNode -
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.ListSelectorNode.processInternal(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Logic\ListSelectorNode.cs:Zeile 93.
   bei org.dmxc.lumos.Kernel.Input.v2.AbstractNode.process(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Node\AbstractNode.cs:Zeile 230.

Oftmals werden Weißtöne in Geräten nur als Farbpreset hinterlegt. Aus der WhatApp-Diskussion vom 17.10.2021 ging hervor, dass diese Fälle im DDF dann ebenfalls als virtuelles Farbrad angelegt werden sollten.

Um die Eingabe zu erleichtern und insgesamt einheitlich zu halten, sollte eine Möglichkeit geschaffen werden, dass man für den Farbwert auch einen Wert wie 3270K oder 4500K für Weißtöne eintragen kann. Die HAL verhält sich dann analog zur bereits existierenden Variante für LEE-, Chromagel oder Supergel-Farbfilter.

Ggf. wäre aber zu beachten, dass es Geräte gibt, die die Farbpresets für weiß trotzdem als linear einstellbaren Bereich abbilden.

Das Aktivieren und Deaktivieren von Bänken über den Menüpunkt “Bank > Aktive” ist aktuell nicht möglich. Der Befehl wird nicht durchgereicht, sodass sich auch der farbige Balken nicht ändert.

Ich habe den folgenden, angepassten DDF-Code vom DDF “BriTeQ - BT-Strobe 1500” aus der DDFLib.

<functions>
  <strobe dmxchannel="0">
    <range type="linear" mindmx="0" maxdmx="5" minval="0" maxval="0"/>
    <range type="linear" mindmx="38" maxdmx="255" minval="1" maxval="12"/>
  </strobe>
</functions>

Wie zu sehen ist, wird der Wertebereich 6 bis 37 komplett ausgeklammert. In diesem Wertebereich liegen Funktionen, die nicht verwendet werden sollen. Dem entsprechend wäre meine Erwartungshaltung die folgende:

• Frequenz 0 → DMX-Wert 2 bzw. 3
• Frequenz 1 → DMX-Wert 1 linear ansteigend bis
• Frequenz 12 → DMX-Wert 12

Füge ich den DDF-Code nun aber in DMXControl ein, lautet der DMX-Wert aber stattdessen 15 und damit voll in dem Bereich, den ich nicht ansprechen möchte. Auch alternative Implementierungen wie

<step type="open" mindmx="0" maxdmx="5"/>

führen zu dem gleichen, nicht erwarteten Ergebnis, dass der DMX-Wert bei 15 liegt.

Auf Grund des folgenden Log-Eintrags kann die GUI nicht gestartet werden. Wenn ich das richtig lese, fehlt eine Datei im Installer.

2021-08-30 18:45:48,515 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Exception when initializing Manager SettingsManager: Die Datei oder Assembly "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
System.IO.FileNotFoundException: Die Datei oder Assembly "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Dateiname: "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985"
   bei LumosLIB.Tools.I18n.T.LoadCatalog(CultureInfo culture, String dir)
   bei LumosLIB.Tools.I18n.T.InitializeCatalog(CultureInfo culture, String startupPath) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\I18n\T.cs:Zeile 94.
   bei Lumos.GUI.Settings.SettingsManager.org.dmxc.lumos.Kernel.Run.IManager.initialize() in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Settings\SettingsManager.cs:Zeile 96.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.ManagerInitAction(TManager m) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 646.

WRN: Protokollierung der Assemblybindung ist AUS.
Sie können die Protokollierung der Assemblybindungsfehler aktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) auf 1 festlegen.
Hinweis: Die Protokollierung der Assemblybindungsfehler führt zu einer gewissen Leistungseinbuße.
Sie können dieses Feature deaktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] entfernen.

2021-08-30 18:45:48,529 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Error in Startup
org.dmxc.lumos.Kernel.Exceptions.KernelPanicException: Error in Startup
2021-08-30 18:45:48,529 [Main GUI] INFO  DMXControl 3 GUI - GUI closing!

Im Anhang finden sich die vollständigen Logs inklusive die des Installers.

Im beigefügten Projekt ist das Expression-Node mit drei Variablen x, y und z konfiguriert. Da scheinbar beim Laden des Projekts die Variable z mit dem zugehörigen Input nicht rechtzeitig geladen wird, wird die Verbindung zu diesem Input gelöscht. Der Kernel zeigt an dieser Stelle den folgenden Eintrag.

2021-08-27 10:08:46,945 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Input.v2.InputManager - Unable to add Edge to Graph: Missing port.
Parametername: e
System.ArgumentException: Missing port.
Parametername: e
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdges(IEnumerable`1 edges, Boolean processGraph, Boolean reassignLevel) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 335.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 308.
   bei org.dmxc.lumos.Kernel.Input.v2.InputManager.org.dmxc.lumos.Kernel.Project.IProjectResourceUser<org.dmxc.lumos.Kernel.Input.v2.IGraph>.LoadItem(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\InputManager.cs:Zeile 1623.

Im Anhang findet sich das Projekt sowie die vollständigen Logfiles.

Ich habe in meinem Club22-Projekt mehrfach einen Count-Down ins Softdesk eingebaut, um die Zeit in Minuten und Sekunden bis zum Auslösen einer Aktion ausgeben zu können. Das Umbauen eines entsprechen Werts benötigt hier aber das im Anhang beigefügte Connectionset. Ausgangspunkt ist der Fade-Output des Cue-Nodes. Im Rule of Three-Node geschieht die Umrechnung des Prozentwerts in Sekunden. Die nachfolgenden vier Nodes übernehmen die Aufteilung in Minuten und Sekunden. Der größte Nachteil an diesem Aufbau ist, dass ich beim Ändern der Fadezeit der Cues das Rule of Three manuell anpassen muss und auch nicht mit wechselnden Fadezeiten arbeiten kann.

Um dies zu vereinfachen und universeller zu gestalten, schlage ich die Implementierung eines Count-Down-Nodes vor. Der Name Count-Down ist aber aktuell nur ein Arbeitstitel - vielleicht gibt es hier noch einen besseren.

Dieses Node ist wie folgt aufgebaut:

• Eingänge
  • Fadewert in % als dynamisch verändernder Wert wie er zum Beispiel aus dem Cue-Node kommt
  • Zeitbezugswert als fester Wert in Sekunden, welcher entweder manuell gesetzt oder aus einem anderen Node übergeben wird
  • Zeitwert als dynamischer Wert in Sekunden oder Millisekunden, wenn die Quelle diesen bereits zur Verfügung stellt
• Ausgänge
  • Zeitangabe in HH:MM:SS als String, abhängig von der eingestellten Vorlage
• Einstellungen
  • Angabe des Zeitformats aus einer Auswahl von fest vorgegeben Vorlagen wie SS, MM:SS, HH:MM:SS, etc.
  • Angabe der Einheit auf der Eingangseite für die Zeit in Sekunden oder Millisekunden, sofern sich das nicht aus dem ankommenden Wert “herauslesen” lässt
  • Zählrichtung, also absteigend (klassischer Count-Down) oder zunehmend (Stopp-Uhr)
  • Ggf. ein benutzerdefiniertes Prefix oder Suffix

Der Project Explorer bietet in DMXControl 3.2.2 aktuell noch folgende Shortcuts. Diese sind in DMXControl 3.3 nicht mehr vorhanden:

• Strg+X, Strg+C, Strg+V
• Entf

Im Anhang befindet sich das Logfile der Alpha 4, wo ich exemplarisch in einem leeren Projekt das Kopieren und Einfügen über die Tastatur mit einer Szenenliste probiere.

Im Zuge der Programmierung des Projekts für den Club22 fiel mir auf, dass die DMX-Refreshrate sowohl in DMXControl 3.2.2 als auch in DMXControl 3.3 sichtbar absackt, wenn ich in:

• DMXControl 3.2.2 die Farbe über einen Parametermaster mittels des Swatooth-auf-Hue-Workaround live manipulieren möchte
• DMXControl 3.3 direkt hierfür die Colormaster verwende.

Um das Problem zu zeigen habe ich das beigefügte Projekt aufgebaut. Darin sind 375 Generic RGB und eine Gerätegruppe sowie 4 Cuelists enthalten:

• 1: Trapezoid-Effekt auf Dimmer und Colormaster 1 und 2 auf Farbe in einer Cue
• 2: Trapezoid-Effekt mit gleichen Parametern aus Cuelist 1 auf Dimmer
• 3: Colormaster 1 und 2 auf Farbe
• 4: Farbe fest entsprechend der aktuellen Einstellung der Colormaster programmiert, einmal über RGB und einmal über HSV

Führe die Cuelists aus, erhalte ich folgende DMX-Refreshraten entsprechend der Statusmeldung des Kernels:

• nur 1: 21,2 Hz bei 20% CPU-Auslastung und ~16250 DMX-Werten / Sekunde
• nur 2: 25,4 Hz bei 20% CPU-Auslastung und ~27500 DMX-Werten / Sekunde
• 2 und 3: 22,7 Hz bei 19,5% CPU-Auslastung und ~16800 DMX-Werten / Sekunde
• 2 und 4 (RGB): 29,5 Hz bei 18,8% CPU-Auslastung und ~18200 DMX-Werten / Sekunde
• 2 und 4 (HSV): 29,3 Hz bei 17,8% CPU-Auslastung und ~18300 DMX-Werten / Sekunde

Die CPU lief während der Ausgabe mit einem Takt von 1,39 GHz, weil der PC auf Akkubetrieb lief. Selbst im Netzbetrieb vermeldet der Kernel einen merklichen Unterschied, wo die CPU mit 3,15 GHz getaket ist:

• nur 1: 55,9 Hz bei 11,3% CPU-Auslastung und ~21700 DMX-Werten / Sekunde
• 2 und 4 (HSV): 67,1 Hz bei 8,6% CPU-Auslastung und ~21050 DMX-Werten / Sekunde

Dieser Effekt verstärkt sich mit entsprechend zunehmender Anzahl an Geräten im Projekt bis hin zu dem Punkt, dass es bei der Nutzung der Colormaster oder dem Pendant des Workarounds in DMXControl 3.2.2 hier die DMX-Ausgabe merklich sichtbar stockt, während der Weg über das Starten einer Cuelist mit fest eingestellter Farbe beim gleichen Effekt deutlich runder läuft.

Da dieses Problem aktuell noch beide Versionen von DMXControl 3 betrifft, habe ich als “betrifft Version” DMXControl 3.2.2 gewählt.

Ich habe ein Projekt erstellt, in dem insgesamt 672 Geräte und 28 Gerätegruppen gepatcht und in zahlreichen Ordnern abgelegt.

Das Laden des Projekt schlägt jedoch mit einer Fehlermeldung fehl. Ignoriere ich diese, fallen gibt es folgende Fehler:

• die Zuordnung der Geräte und den Gerätegruppen zu den Ordnern schlägt ca. zu 80% fehl
• in den beiden Stage Views fehlen Icons von Geräten und Gerätegruppen

Spannenderweise liegen die Positionsinformationen der Icons in den Stage Views grundsätzlich noch vor. Ziehe ich die fehlenden Icons wieder in die Stage View, werden diese an der richtigen Position eingefügt.

Lade ich das gleiche Projekt mit der 3.3 Alpha 4, so funktioniert das Projekt ohne Probleme.

Im Anhang findet sich das betreffende Projekt sowie die Logs eines Durchlaufs einer Sitzung.

Um festzulegen, ob der Launcher nach dem normalen Schließen von DMXControl 3 noch weiter ausgeführt werden soll, soll der Schließen-Dialog entsprechend der Absprache im QRM vom 15.05.2021 einen weiteren Eintrag erhalten. Mit diesem Eintrag in Form eines Hakens kann man festlegen, ob der Launcher geschlossen werden soll oder nicht.

Da die bereits vorhandenen Einträge auch in den allgemeinen Einstellungen der GUI hinterlegt sind, sollte die Option für den Launcher ebenfalls dort enthalten sein.

Durch diese Option kann der Launcher auf die Exit-Codes reagieren und zum Beispiel visualisieren, wenn die GUI abgestürzt ist.

Lade ich die Cue 1 aus dem exemplarischen Projekt aus  FS#4553  für die Änderung in den Programmer und ändere zum Beispiel den Dimmer nachträglich von 0 auf 100% oder passe die Position von 0; 100 auf 0; 50 an, so kann ich die Cue nicht über den Update-Button aktualisieren. Dies kann ich nur über die Eintrage “Merge” oder “Replace” vornehmen.

Die beigefügten Logfiles zeigen die Tätigkeit bis zur Änderung der Werte. Das Aktualisieren der Cue erfolgte nicht.

Ich lade exemplarisch das beigefügte Projekt. Wenn ich dann die GUI “hart” neustarte, das heißt die Anwendung über den Taskmanager schließe und die GUI neu starte, werden die Icons der Devic Groups in der Stage View nicht an ihrem ursprünglichen Platz anzeigt. Stattdessen befinden sich beide Icons der Device Groups übereinander gestapelt im Null-Punkt oben links in der Stage View. Die Icons der Geräte selbst befinden sich dagegen an ihrem ursprünglichen Platz.

Im Anhang finden sich die Logs der Sitzung sowohl vor als auch nach dem Neustart der GUI. Kernel und Umbra liefen die ganze Zeit durch.

Zu der Frage ob das Masterfenster beibehalten werden soll oder nicht, wurde im QRM-Meeting vom 15.05.2021 folgendes verabredet:

1. Das Masterfenster bleibt als separates Fenster erhalten und ist auf dem bekannten Weg erreichbar.
2. Die Master werden auf Basis der neuen Executor-Controls automatisch in dem Masterfenster und alle horizontal nebeneinander anlegt.
3. Das Masterfenster erhält verschiedene Filter, um die Master nur anhand ihres Typs oder / und anhand von bestimmten Werten anzuzeigen.
4. Die Anzeige der Group Master orientiert sich weiterhin an den Einstellungen der jeweiligen Device Groups, ob ein Group Master angezeigt werden soll oder nicht.
5. Die Belegung der Buttons etc. ist nicht konfigurierbar und basiert auf Basis der Standardeinstellungen, mit denen ein Master auch einem Executor zugeordnet wird.
6. Aus den verschiedenen Master-Ordnern kann man das Masterfenster direkt mit einem gesetzten Filter öffnen, um zum Beispiel nur die Group Master oder nur die Parametermaster anzuzeigen.

Aktuell ist ein lineares Fanning mit dem Positionmaster und einem festen Wert nicht möglich. Bei der Eingabe von zum Beispiel {Positionmaster 1} > 0;0 erscheint folgende Fehlermeldung.

2021-05-15 19:25:01,506 [51] ERROR LumosLIB.Tools.gRPC.GrpcTools - Unable to Serialize Element of Type: org.dmxc.lumos.Kernel.Scene.Fanning.LinearFannedValue
2021-05-15 19:25:01,516 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.DuplexStreamHandler - Exception in Delegate Invocation: Void _setProgrammerValue_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.SetProgrammerValueRequest]) => org.dmxc.lumos.Kernel.Net.gService.Programmer_gService.Void _setProgrammerValue_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.SetProgrammerValueRequest])
System.Runtime.Serialization.SerializationException: Unable to Serialize Element of Type: org.dmxc.lumos.Kernel.Scene.Fanning.LinearFannedValue
   bei LumosLIB.Tools.gRPC.GrpcTools.ToObjectData(Object obj, EFallbackEnforcement fallbackEnforcement) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Tools\GRPC\GrpcTools.cs:Zeile 307.
   bei LumosLIB.Tools.gRPC.GrpcTools.ToPropertyValue(Object value) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Tools\GRPC\GrpcTools.cs:Zeile 149.
   bei org.dmxc.lumos.Kernel.Net.gService.Programmer_gService.ReadPropertyValueData(IUserContext uc, String groupId, String propertyId) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Net\gService\Programmer_gService.cs:Zeile 217.
   bei org.dmxc.lumos.Kernel.Net.gService.Programmer_gService._setProgrammerValue_RequestReceived(Object sender, RequestEventArgs`1 e) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Net\gService\Programmer_gService.cs:Zeile 268.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass3_0`1.<InvokeFailSafe>b__0(EventHandler`1 a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 28.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0`1.<InvokeFailSaveGeneric>b__0(TDelegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 62.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 82.

Hierbei friet die GUI ein und ist nicht mehr bedienbar. Ich muss die GUI hierzu abschießen und dann nach dem Neustart den Programmer leeren, um weiterarbeiten zu können. Ein Fanning über zwei Positionmaster entsprechend {Positionmaster 1} > {Positionmaster 2} ist dagegen möglich. Im Bereich des Colormasters tritt ein vergleichbarer Fehler ebenfalls nicht auf.

Im Anhang die Logfiles der Sitzung, bis die GUI einfriert und über den Taskmanager geschlossen werden muss.

Zum besseren Verständnis der Arbeitsweise der Color (List) Chaser, Gobo (List) Chaser, dem Position (List) Chaser und ggf. weiteren List Chasern sollen die in einer eigenen Kategorie anzeigt werden.

In dem Zusammenhang wurde auch diskutiert, die List Chaser um “List” zu erweitern. Ob dies am Ende sinnvoll ist, muss technisch entschieden werden.

Damit man beim Color Chaser auch eine Hintergrundfarbe setzen kann, soll der Color Chaser als zusätzlichen Parameter die Blend Modes erhalten, wie man sie auch schon aus den Matrix-Effekten kennt.

Um das Standardverhalten des Color Chasers nicht zu verändern, wird als Default Blend Mode “Multiply” gesetzt.

Im Positionlist-Fenster werden die Positionen aktuell mit bis zu acht Nachkommastellen angegeben und auch immer beim Anpassen auf die Anzahl angehoben. Hier stellt sich die Frage, ob eine solch hohe Genauigkeit erforderlich ist, weil diese auch die Übersichtlichkeit und Werteingabe / -änderung darunter leidet.

Lege ich zuerst eine Itemlist an und füge dann erstmalig den zugehörigen Effekt hinzu, dann wird trotzdem die entsprechende Default List angelegt. Beispiel:

1. Neue Colorlist anlegen
2. Color Chaser auf Geräte anwenden
3. Default Colorlist wurde trotzdem angelegt und dem Effekt zugeordnet

Die Frage ist an dieser Stelle: ist dieses Verhalten so in Ordnung? Oder soll geprüft werden, ob eine entsprechende Itemlist existiert und hier dann die erste genutzt werden?

Lege ich den Positionlist-Effekt auf eine Gruppe von Moving Heads, kann ich den Mittelpunkt des Effekts nicht über Pan und Tilt verschieben. Der Effekt durchgängig zentriert und müsse aktuell durch eine Änderung der Positionlist erfolgen.

Hierzu habe ich im beigefügten Projekt eine Cuelist hinterlegt, die das Problem zeigt.

Über das Tray-Menü des Launchers kann ich mit den Kernel und den Umbra nicht in den Vordergrund holen. Hierzu muss ich das Hauptfenster des Launchers direkt öffnen und die Einträge direkt umschalten.

Ändere ich die Faderposition aller Master (-typen) im Masterfenster oder klicke auf die zugehörigen Buttons, so werden die angezeigten Werte und die Fader bei den Klicks auf die Buttons nicht aktualisiert.

Die Funktionen werden aber wie erwartet ausgeführt.

Füge ich einem leeren Projekt Executoren zu und ordne die Executor Pages zu und möchte dieses speichern, so ist dieses mit dem folgenden Logeintrag nicht möglich.

2021-05-14 23:48:59,565 [40] ERROR org.dmxc.lumos.Kernel.Project.ProjectManager - Can't save content of ExecutorManager
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Project.ExecutorManager.Save(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Project\ExecutorManager.cs:Zeile 745.
   bei org.dmxc.lumos.Kernel.Project.ExecutorManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.saveProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Project\ExecutorManager.cs:Zeile 948.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass30_1.<saveProject>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 476.

Marcel hat eine neue Version der Nodle_USB.dll erstellt. Diese Anpassung muss in DMXControl 3 selbst noch entsprechend vorgenommen werden.

Die neue Version wird im Nodle Config Tool bereits verwendet.

Füge ich einem Projekt Geräte hinzu, während in der Stage View die Option “Show Device / Group Number” oder “DMX-Adress” aktiviert und diese sichtbar ist, wird die folgende Fehlermeldung im Log der GUI ausgegeben.

2021-05-10 19:12:45,308 [Main GUI] ERROR org.dmxc.lumos.XNAViews.StageView.StageView - Der Wert darf nicht NULL sein.
Parametername: text
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: text
   bei Microsoft.Xna.Framework.Graphics.SpriteFont.MeasureString(String text)
   bei org.dmxc.lumos.XNAViews.StageView.StageView.DrawIconStrings(RectangleF bounds, Single bottom, Single right, Single& bottomOut, Single& rightOut) in D:\Jenkins\workspace\Lumos_Pipeline_master\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1391.
   bei org.dmxc.lumos.XNAViews.StageView.StageView.Draw(Rectangle clipingRectangle) in D:\Jenkins\workspace\Lumos_Pipeline_master\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1139.

Das Hinzufügen der Geräte selbst erfolgt dabei wie erwartet, weswegen ich keine (weiteren) Logfiles beifüge.

Durch die Einführung von neuen Fanning-Operatoren wird die Liste der möglichen Fannings im Tooltip “Value not valid” immer länger. Wir sind aktuell bei 14 Fannings angelangt. Hier sollte die Anzahl auf ein paar gebräuchliche Fannings reduziert werden, zum Beispiel auf

• -8 # 8
• -8 > 8

Alternativ greift der Tooltip nur den Fanningoperator auf, den der Nutzer aktuell verwenden möchte. Damit lässt sich der Tooltip auf 4 Zeilen reduzieren.

Beim Testen des Chaser 2 sind mir mehrere Punkte aufgefallen. Diese habe ich allesamt mit der Cuelist des beigefügten Projekts nachgestellt. Die hier genannten Punkte sind gleichermaßen im Projekt zu finden.

1. Doppelschritt im Playmode In Out
Wähle ich den Playmode In Out, bleibt der Chaser 2 am inneren und äußeren Punkt jeweils zwei Takte stehen. Beim Bounce ist dies nicht der Fall.

2. Speedmaster ohne Funktion
Der Speedmaster hat keine Auswirkungen auf die Wiedergabegeschwindigkeit des Chaser Effekts.

3. Zeitsprung Playmode Normal
Im Playmode Normal und Reverse findet der Wechsel bzw. die Umschaltung zwischen dem ersten und zweiten Gerät in der Device Group nicht nahtlos statt. 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 allerdings erst gut mit realen Geräten zu sehen, wie zum Beispiel mit meinen Moving-Bars.

4. Fanning-Operator ? auf Duration
Hier wäre die Erwartungshaltung, dass die Duration eines jeden Steps entsprechend der Angabe variiert wird. In dieser Cue habe ich exemplarisch den Fanning-Operator ? genutzt, es betrifft hier aber im Endeffekt jeden Fanning-Operator

5. Fanning-Operator > auf Fade
Analog zum Parameter Duration sollte auch hier der Fanning-Operator eine Auswirkung zeigen, nämlich hier mit einem zunehmenden Fade zu jedem Step: beim 1. Gerät kein Fade, beim letzten Gerät 500ms.

6. Absturz bei Duration 0
Trage ich bei Duration als Wert 0ms ein, stürzt der Chaser mit folgendem Logeintrag ab und gibt keine Werte mehr aus. Hier sollte der mögliche / zulässige Wertebereich angepasst werden. Dieser Fehler kann reproduziert werden, wenn die entsprechende Cue in den Programmer geladen wird.

2021-05-02 00:06:13,928 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.DuplexStreamHandler - Exception in Delegate Invocation: Void _deleteProgrammerAttachable_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.DeleteProgrammerAttachableRequest]) => org.dmxc.lumos.Kernel.Net.gService.Programmer_gService.Void _deleteProgrammerAttachable_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.DeleteProgrammerAttachableRequest])
System.DivideByZeroException: Es wurde versucht, durch 0 (null) zu teilen.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.Chaser.AbstractChaserPattern.doUpdateChaser(Int64 timeInMs, Int64 delta, Int32 duration, Int32 fadetime, Int32 deviceCount, Int32 length, Int32 stepSize, Int32 breakSteps, Int32 breakTime) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\Filter\Chaser\Pattern\AbstractChaserPattern.cs:Zeile 43.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.ChaserFilter2.doFilter(IPropertyValue input, Int64 timeInMs, Int64 delta) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\Filter\Chaser\ChaserFilter2.cs:Zeile 219.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.AbstractEffectFilter.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\Filter\AbstractEffectFilter.cs:Zeile 58.
   bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1.getPropertyValue(Int64 timeInMsAbs) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 409.
   bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 352.
   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\Lumos\src\Kernel\Scene\Fade\FadeDecorator.cs:Zeile 95.
   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\Lumos\src\Kernel\Scene\Delay\DelayDecorator.cs:Zeile 37.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AutoFadeDecorator.triggerFade() in D:\Jenkins\workspace\Lumos_Pipeline_master\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\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\Lumos\src\Kernel\Scene\Fade\AbstractFadeDecorator.cs:Zeile 65.
   bei org.dmxc.lumos.Kernel.Scene.SceneFadeTicker.register(IProcessable value) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Scene\SceneFadeTicker.cs:Zeile 71.
   bei org.dmxc.lumos.Kernel.Mixer.Register.MixerRegister.registerFadeable(IProcessable value) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Mixer\Register\MixerRegister.cs:Zeile 147.
   bei org.dmxc.lumos.Kernel.Mixer.Register.MixerRegister.pushProcessableValue(IProcessable value) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Mixer\Register\MixerRegister.cs:Zeile 215.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.playSceneEntry(ISceneEntry[] entrys, HALTimestamp ts) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 1265.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.playSceneEntry(ISceneEntry[] entrys) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 1213.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.deletePropertyAttachable(String attachableID) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 562.
   bei org.dmxc.lumos.Kernel.Net.gService.Programmer_gService._deleteProgrammerAttachable_RequestReceived(Object sender, RequestEventArgs`1 e) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Net\gService\Programmer_gService.cs:Zeile 334.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass3_0`1.<InvokeFailSafe>b__0(EventHandler`1 a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 28.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0`1.<InvokeFailSaveGeneric>b__0(TDelegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 62.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 82.

Der Dateiname des Zip-Archiv mit dem Log-Dateien wird eigentlich nach dem Schema

DMXControl3Logs_YYYYMMDD_hhmmss.zip

generiert - bzw. sollte so generiert werden. Aktuell ist es so, dass “füllende” Nullen nicht berücksichtigt werden. Die führt dazu, dass folgende Dateinamen herauskommen, die sich am Ende nicht chronologisch nach dem Dateinamen sortieren lassen:

DMXControl3Logs_202148_831.zip    -->  DMXControl3Logs_20210408_080301.zip
DMXControl3Logs_2021430_1247.zip  -->  DMXControl3Logs_20210430_120407.zip
DMXControl3Logs_202151_23199.zip  -->  DMXControl3Logs_20210501_231909.zip

Folglich muss hier einmal das Format überprüft werden, welches für die Ausgabe des Datums und der Uhrzeit herangezogen wird.

In dem Projekt aus  FS#4522  habe in der Stage View zwei neue Device Groups aus einer Auswahl erzeugt. Einmal über den Button in der Menüleiste und einmal über das Kontextmenü. Bei beiden Wegen wird die neue Device Group angelegt, jedoch nicht automatisch wie bisher auch der aktuellen Stage View hinzugefügt.

Das Ergebnis ist im beigefügten Projekt zu sehen.

Möchte ich ein Gerät aus dem Projekt löschen, welches in einer Device Group eingebunden ist, kann ich dies nicht direkt im Device-Ordner machen. Das Reference Error Window erhält nicht die notwendigen Parameter bzw. gibt diese zurück, sodass das Gerät nach der Auswahl einer Aktion gelöscht wird. Auf Grund dieses Problems kommt das Fenster erneut hoch und das Gerät ist weiterhin im Projekt enthalten.

Im Anhang findet sich ein Projekt mit 10 Geräten, wo ich probeweise wie auf dem Screenshot zu sehen versucht habe, die Geräte AX5 (9) und (10) zu löschen.

Beim Beenden des Kernels soll eine Liste mit Metadaten über alle verfügbaren Projekte im Projekt erstellt und gepflegt werden, die zum Beispiel für den Launcher auf Read Only Basis zur Verfügung gestellt wird. Die Liste soll folgende Inhalte haben:

• Name des Projekts
• Ersteller
• Zuletzt gespeichert
• ggf. Projekttyp (Userprojekt, Auto-Backup)

Ggf. enthält die Liste auch eine MD5-Prüfsumme, sodass immer nur die Metadaten aktualisiert werden, wo eine Änderung tatsächlich stattfand (beim Starten des Kernels prüfen)

Um eine schnelle Startmöglichkeit in verschiedenen Netzwerk-Konstellationen zum Beispiel für die GUI zu erhalten, soll wie in der Entwicklersitzung am 28.04.2021 besprochen ein Startparameter implementiert werden, um eine Network ID zu übergeben.

Um die Anzahl der Verknüpfungen im Startmenü auf Wunsch zu reduzieren, soll der Installer folgende Auswahloptionen für die Verknüpfungen erhalten:

• Verknüpfungen auf dem Desktop
  • DMXControl 3 starten
  • DMXControl 3 Launcher
• Verknüpfungen im Startmenü
  • DMXControl 3 starten
  • DMXControl 3 Launcher
• Zusätzliche Verknüpfungen
  • DMXControl 3 GUI
  • DMXControl 3 Kernel
  • DMXControl 3 Umbra

Die Ausgestaltung der Auswahlmöglichkeiten kann frei gewählt werden. Vorrangig soll damit erreicht werden, dass wie in der Entwicklersitzung am 28.04.2021 besprochen, auf Wunsch die Verknüpfungen für GUI, Kernel und Umbra im Startmenü angelegt werden.

Durch die Verwaltung der Projekte im Kernel können nun nicht mehr die klassischen Dialoge zum Laden und Speichern von Projekten verwendet werden. Ein eigener Dialog ist hierfür erforderlich, der sich in seinem Grundaufbau möglicherweise an den Add Device Dialog anlehnen kann.

Der Projektmanagement-Dialog sollte unter anderem folgende Funktionen anbieten:

• Importieren und Exportieren von Projekten, die auf anderen PCs genutzt werden
• Organisation der Projekte in einem Baum mit folgenden Merkmalen
  • Strukturierung der Projekte in mehreren (virtuellen) Ordnern
  • Auflistung der zuletzt genutzten Projekte
  • Favoriten
• Anzeige von Informationen zum Projekt wie Titel, Beschreibung, Autor, letzte Speicherung
• …

Beim Sichten der GUI-Logs zum Ticket  FS#4506  ist mit folgender Eintrag beim Shutdown-Prozess aufgefallen:

2021-04-26 20:02:06,996 [Main GUI] ERROR Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Themes.ThemeManager.checkCorrectFontUnit(Control parent) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 212.
   bei Lumos.GUI.Themes.ThemeManager.SetThemeInAllControlsTools(Control parent, AbstractGUITheme theme) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 316.
   bei Lumos.GUI.Themes.ThemeManager.Parent_ContextMenuStripChanged(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 435.
   bei System.Windows.Forms.Control.OnContextMenuStripChanged(EventArgs e)
   bei System.Windows.Forms.Control.set_ContextMenuStrip(ContextMenuStrip value)
   bei System.Windows.Forms.Control.DetachContextMenuStrip(Object sender, EventArgs e)
   bei System.ComponentModel.Component.Dispose(Boolean disposing)
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.ToolStrip.Dispose(Boolean disposing)
   bei System.Windows.Forms.ContextMenuStrip.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.ComponentModel.Container.Dispose(Boolean disposing)
   bei System.ComponentModel.Container.Dispose()
   bei Lumos.GUI.Windows.InputLayer.v2.InputLayerForm.Dispose(Boolean disposing) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\InputLayer\v2\InputLayerForm.Designer.cs:Zeile 24.
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei WeifenLuo.WinFormsUI.Docking.DockPane.Dispose(Boolean disposing)
   bei WeifenLuo.WinFormsUI.Docking.DockPane.Close()
   bei WeifenLuo.WinFormsUI.Docking.DockPaneCollection.Dispose()
   bei WeifenLuo.WinFormsUI.Docking.DockPanel.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.ContainerControl.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.Form.Dispose(Boolean disposing)
   bei Lumos.GUI.Windows.MainForm.Dispose(Boolean disposing) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\MainForm.Designer.cs:Zeile 22.
   bei System.Windows.Forms.Form.WmClose(Message& m)
   bei System.Windows.Forms.Form.WndProc(Message& m)
   bei Lumos.GUI.Windows.MainForm.WndProc(Message& m) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\MainForm.cs:Zeile 531.
   bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Beim Sichten der GUI-Logs zum Ticket  FS#4506  ist mit folgender Eintrag aufgefallen:

2021-04-26 19:57:29,477 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_closed of type Picture and source Default could not be loaded!
2021-04-26 19:57:29,478 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_closed of type DeviceImage and source Default could not be loaded!
2021-04-26 19:57:29,480 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_closed of type Icon and source Default could not be loaded!
2021-04-26 19:57:29,481 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_closed of type Symbol and source Default could not be loaded!
2021-04-26 19:57:29,484 [Log-Thread] DEBUG org.dmxc.lumos.XNAViews.TextureManager - Added Texture: lock_closed
2021-04-26 19:57:29,485 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_open of type Picture and source Default could not be loaded!
2021-04-26 19:57:29,486 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_open of type DeviceImage and source Default could not be loaded!
2021-04-26 19:57:29,487 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_open of type Icon and source Default could not be loaded!
2021-04-26 19:57:29,489 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_open of type Symbol and source Default could not be loaded!
2021-04-26 19:57:29,491 [Log-Thread] DEBUG org.dmxc.lumos.XNAViews.TextureManager - Added Texture: lock_open

Ich habe das folgend beigefügte Projekt gebaut, in dem ich über das Input Assignment den Manual Beat Node mit der Taste Q (keine Tastenkombination) triggern möchte. An den Outputs werden nur die Anzahl der Beat Signale hochgezählt. Die Berechnung oder gar Aktualisierung der Outputs für Hz, BPM, s etc. findet nicht statt. Dabei macht es keinen Unterschied, ob ich das Beat-Tool sowohl über die Taste 1 über das Input Assignment oder per Mausklick in der GUI aktiviere oder deaktiviere.

Eventuell steht auch folgender Log-Eintrag der GUI mit in diesem Zusammenhang:

2021-04-26 19:59:43,762 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.Beat_gClient - LearnManualBeat
Grpc.Core.RpcException: Status(StatusCode=DeadlineExceeded, Detail="Server didn't respond.")
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   bei Lumos.GUI.Net.gClient.Beat_gClient.<LearnManualBeat>d__6.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Net\gClient\Beat_gClient.cs:Zeile 69.

Dieses Verhalten bzw. Problem besteht auch in DMXControl 3.2.2, ist also in dem Sinne nicht zwingend ein neues Problem.