Bugtracker DMXControl 3

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.

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.

Ich habe mit der Alpha 7 ein neues Projekt erstellt. Wenn ich dieses speichere, schließe und sowohl innerhalb der laufenden Sitzung als auch nach einem kompletten Neustart von DMXC, kann ich im Anschluss die Namen der Geräte und Gerätegruppen nicht mehr ändern. Der Zweig im Projekt Explorer aktualisiert sich nicht. Aktualisiere ich den Baum durch öffnen eines anderen Ordners oder mittels des Refresh-Buttons, ist der alte Name wieder da. Ändere ich den Namen über die Properties, hängt sich die GUI auf, sodass ich sie hart beenden muss.

Ist ein Gerät ein einer Gerätegruppe verknüpft und ich möchte dieses löschen, so klappt dies aktuell nicht. Ich lande gewissermaßen in einer Schleife, die ich jedoch manuell abbrechen kann, wenn ich im Reference error window auf “nein” klicke. In diesem Zusammenhang fällt auf, dass das Dropdownmenü nicht mit den richtigen Werten gefüllt wird.

Um Geräte aktuell aus dem Projekt zu entfernen, muss ich dieses erst aus der Gerätegruppe entfernen, bevor ich es löschen kann.

Die direkte Verknüpfungen für GUI, Kernel und Umbra im Startmenü starten nur Launcher und holen diesen in Vordergrund, ohne jedoch die jeweils ausgewählte Anwendung auszuführen.

Die Verknüpfung für die GUI enthält folgende Angaben:

• Ziel:

  "C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Launcher\DMXCLauncher.exe" --gui

• Ausführen in:

  "C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\GUI"

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
• …