Bugtracker DMXControl 3

Das Art-Net-4-Plugin kann beim Start des Kernels nicht initialisiert werden mit folgender Meldung im Kernel:

19:24:14 ERROR AssemblyManager - Unhandled Exception when loading Types in Listener org.dmxc.lumos.Kernel.Plugin.PluginManager: Unable to load one or more of the requested types.
Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Das System kann die angegebene Datei nicht finden.

Datenstand ist das Beta-Paket aus dem Forum vom 04.12.2024 und auch den letzten Jenkins-Jobs.

Ticket wurde nach Rücksprache von @JPK nun nochmal hierher übernommen und dient vornehmlich als Reminder.

Ich nutze auf zwei Laptops die Art-Net 4 Ausgabe. In beiden Laptops habe ich die gleiche Art-Net-Konfiguration, um zwischen beiden Laptops teilweise oder auch vollständig wechseln zu können.

Wenn ich die Art-Net- / DMX-Ausgabe an den drei möglichen Stellen einzeln oder auch an allen drei Stellen komplett ausschalte, wird die Art-Net-Ausgabe nict komplett abgeschaltet. Dies mündet folglich in Störungen auf dem DMX-Bus, wenn ein anderer Laptop den Port des Art-Net-Nodes “übernehmen” soll. Die Lösung war hier das Treffen der Netzwerkverbindung zu den Art-Net-Nodes.

Mit der alten Art-Net-Ausgabe (in DMXControl 3.3.1) konnte ich den Wechsel noch ohne Probleme durchführen und eben auch die Art-Net-Ausgabe vollständig abschalten.

Der Installer liefert die Datei libartnet-1.dll möglicherweise im falschen Verzeichnis aus, welche gemäß der Logs aber für das Art-Net-Ausgabeplugin benötigt wird.

2019-03-16 19:13:55,326 [19] ERROR org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager+DMXInterfaceBag - Error setting interface DMXIM: ID Artistic License#ArtNet#0 enabled state to True:
System.DllNotFoundException: Die DLL "libartnet-1.dll": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden.
   bei org.dmxc.lumos.Kernel.DMX.ArtNetWrapper.artnet_new(String ip, Int32 verbose)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetInterface.OnEnable() in D:\Jenkins\workspace\Lumos_3.2_Release\DMXPlugins\ArtisticLicenseArtNet\src\ArtNet.cs:Zeile 180.
   bei DMXLIB.AbstractDMXInterface.set_Enabled(Boolean value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\DMXLIB\AbstractDMXInterface.cs:Zeile 91.
   bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.DMXInterfaceBag.SetEnabledInternal(Boolean state) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Plugin\DMXInterfaceBag.cs:Zeile 226.
2019-03-16 19:14:17,088 [Log-Thread] DEBUG org.dmxc.lumos.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2019-03-16 19:14:17,123 [Main-Process-Chain] ERROR org.dmxc.lumos.Kernel.Plugin.PluginManager - Exception DllNotFoundException occured 20 times.

Gemäß Installer-Log liegt die Datei in folgendem Verzeichnis:

Zielverzeichnis: C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\Kernel\Plugins\api-dlls
Wird entpackt: libartnet-1.dll... 100%

Füge ich das Art-Net-Ausgabeplugin neu hinzu, werden die Send- und Recieve-Universen aus meiner Sicht ungünstig adressiert. Im konkreten sieht das wie folgt aus:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 4 - 7

Device 2

• Send U5 - U7: Universes 8 - 11
• Revice U5 - U7: Universes 12 - 15

Möchte ich nun ein 8-Port Art-Net-Node ansprechen, muss ich hier im Device 2 mindestens die Universen für Send neu sortieren. Ich könnte zwar mein Art-Net-Node auch irgendwie umkonfigurieren, aber persönlich finde ich diese Stückelung innerhalb eines Subnet nicht geschickt. Mein erster Vorschlag wäre folgende Standard-Konfiguration:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 8 - 11

Device 2

• Send U5 - U7: Universes 4 - 7
• Revice U5 - U7: Universes 12 - 15

Waren die DMX-Interfaces eine Zeit lang aktiv und werden dann über den Main-Switch abgeschaltet, meldet der Kernel wiederkehrend folgende Exception. Es ändert daran auch nichts, dass ich die DMX-Interfaces über den Main-Switch wieder einschalte.

21:41:15 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:18 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:20 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:23 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833

Ob es einen Zusammenhang zum Ticket  FS#5326  gibt, vermag ich nicht zu beurteilen. Deswegen habe ich dieses separate Ticket angelegt. Im Anhang finden sich die Logdateien, woraus der Zeitraum hervorgeht, wo ich den Main-Switch betätigt habe. Die Logs enthalten auch die DMX-Interface-Konfiguration.

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.

Sobald ich das Art-Net-Plugin selbst manuell abschalte oder der Kernel es beim Herunterfahren automatisch abschaltet, erscheint im Log immer der folgende Eintrag.

17:51:13 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.

Aktiviere ich es danach wieder, arbeitet es soweit auch wie erwartet. Die Meldung erweckt jedoch gerade beim Überprüfen der Einstellungen den Eindruck, als ob etwas kaputt ist.

Deaktiviere ich die DMX-Interfaces über den Main-Switch, fliegt im Kernel die folgende Exception

20:54:46 ERROR DMXInterfaceBag - Error setting interface Serial: ArtNet, Model: Art-Net, Vendor: Artistic License enabled state to False:
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
   at System.Collections.Generic.List`1.Remove(T item)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.RemovePort(ArtNetInterface port) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 147
   at org.dmxc.lumos.Kernel.DMX.ArtNetInterface.OnDisable() in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNet.cs:line 150
   at DMXLIB.AbstractDMXInterface.set_Enabled(Boolean value)
   at DMXInterfaceMgmtLIB.DMXInterfaceBag.SetEnabledInternal(Boolean target, Boolean byHeartbeatRestart, Boolean byMainSwitch) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\DMXInterfaceMgmtLIB\DMXInterfaceBag.cs:line 267

Ich gebe in die Kommandozeile (Commandline) folgenden Befehl ein:

select executorpage 2 item 6

Die Kommandozeile führt den Teil “select executorpage 2” zwar aus, der Teil “item 6” ist nicht implementiert und liefert kein Ergebnis. Der Befehl wird aber in Gänze mit grün als erfolgreich ausgeführt gekennzeichnet.

Es braucht einen automatischen Zeilenumbruch für “große” Befehle und / oder Kommentare.

Ich lege ein neues Art-Net-Interface an oder aktiviere ein ggf. vorhandenes (wieder). In beiden Fällen erscheint im Kernel nach einigen Aktionen in der Stage View die folgende Fehlermeldung:

19:55:34 FATAL MainProcessRunable - Main Runnable seams stuck in an endless loop! You might have to restart DMXC... Please report this!

Sobald diese Fehlermeldung erscheint, kann ich in der GUI war Geräte in der Stage View auswählen. Setze ich aber die Farbe auf einer Gerätegruppe, werden diese Werte nicht mehr von den einzelnen Geräten wiedergegeben. Das Herunterfahren des Kernels klappt dann auch nicht mehr, da dieser keine Kommandos mehr entgegen nimmt.

Die beigefügten Logs zeigen den Ablauf:

1. DMXC 3.3.0 RC4 starten ohne zuvor konfigurierte DMX-Interfaces
2. Beliebiges Projekt laden
3. Art-Net-Interfaces einrichten
4. Ein paar einfache Aktionen in der Stage View
5. Auftauchen des Fehlers
6. Schließen der GUI und manuelles Anstoßen des Beenden des Umbras
7. Hartes Schließen des Kernels

Siehe oben

Füge ich das Ausgabeplugin für EasyView hinzu, um darüber EasyView direkt anzusprechen, wird die Konfiguration zwar ordungsgemäß gespeichert, beim (erneuten) Starten von DMXControl 3 - egal ob Kernel und GUI getrennt oder im NoNetwork-Modus - wird EasyView nicht automatisch mit gestartet. Rufe ich EasyView im Nachgang manuell auf, verbleibt EasyView im Demo-Mode.

Der folgende Log-Eintrag taucht beim Starten des Kernels regelmäßig auf:

2019-04-09 22:11:39,807 [Main] WARN  org.dmxc.lumos.Kernel.Plugin.PluginManager - Timeout when fetching Interface List from DMX Interface Factory Enttec
System.TimeoutException: Timeout für den Vorgang wurde überschritten.
   bei DMXLIB.FactoryTimeoutDecorator.get_Interfaces() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\DMXLIB\FactoryTimeoutDecorator.cs:Zeile 105.
   bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.loadInterfaces(IDMXInterfaceFactory factory) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Plugin\AbstractPluginManager.cs:Zeile 1246.

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

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

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.

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.

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.

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.

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

• Zero Pan
• Zero Tilt

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.

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

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.

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.

In gewissen Situationen habe ich gleich mehrere Cuelists, die ich gemeinsam live manipulieren möchte, wie unter anderem Timing (Fade Factor), Effect speed, Limit, Temp. Aktuell muss ich hierzu entsprechend viele Executoren anlegen, kann aber dann die Werte immer noch nicht für mehrere Cuelists gemeinsam setzen.

Um dies zu ermöglichen kamen mir hier zwei mögliche Ansätze in den Sinn:

• Es wird ein neuer Executor-Typ “Cuelist Group” eingeführt. Für alle in dieser Cuelist Group enthaltenen Cuelists kann man dann gemeinsam alle verfügbaren Werte gemeinsam ansprechen. Zusätzlich erhält man Zugriff auf die Funktionen wie “Alle starten” oder “Alle stoppen”, die das Cuelist Group Node bereits anbietet. Dieser Ansatz würde dann auch zu dem Ticket  FS#4325  passen, die genannten Funktionen auch im Node direkt hinzuzufügen.
• Man kann einem Executor mehrere Elemente zuordnen. An dieser Stelle würde es dann ggf. keine Differenzierung geben, dass es bei den Cuelists erlaubt ist, bei den verschiedenen Mastern aber nicht.

Die Werte für Fade Factor und Speed Factor einer Cuelist umfassen bekanntermaßen einen Wertebereich von 0% bis 1000% (also 0 bis 10). Dies müsste der Cuelist Group Executor an dieser Stelle eigentlich auch unterstützen.

Vom Workflow ist es (zumindest für mich) einfacher, einen Effekt mit einer geringeren Geschwindigkeit zu programmieren und diesen dann auf Wunsch zu beschleunigen als immer von der maximalen Geschwindigkeit auszugehen (Stichwort Headroom).

Unter diesem Gesichtspunkt wurde bereits das Ticket  FS#4325  verfasst, dass sich hier aber vorrangig auf eine funktionelle Erweiterung des Cuelist Group Nodes im Input Assignment bezieht.

Auf Grund einer System.OutOfMemoryException kam es zu einem Absturz der GUI. Logeintrag bei Systemzeit 2018-04-19 20:51:43,531. Log für Kernel und GUI im Anhang beigefügt.

Getestet mit Build 1492

Nach dem Start der GUI passierte es häufig, dass abgesehen von der Menüleite oben und dem Schnellzugriff links keine weiteren Fenster anzeigt wurden (Bild 1). Bei einem Reset des Layouts verdeckt der Project Explorer die Fenster im angehängten Screenshot, jedoch nicht in der vollen Fenstergröße (Bild 2 und Bild 3). Erst nach einem Neustart von DMXControl 3.2 ist das Layout vollständig resettet.

2019-01-26 12:48:10,385 [1] ERROR Lumos.GUI.WindowManager - 
System.InvalidOperationException: Invalid Content: ActiveContent must be one of the visible contents, or null if there is no visible content.
   bei WeifenLuo.WinFormsUI.Docking.DockPane.set_ActiveContent(IDockContent value) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockPane.cs:Zeile 174.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.Activate() in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 736.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetParent(Control value) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 881.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetPane(DockPane pane) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 816.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetPaneAndVisible(DockPane pane) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 781.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetDockState(Boolean isHidden, DockState visibleState, DockPane oldPane) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 582.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.set_PanelPane(DockPane value) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 444.
   bei WeifenLuo.WinFormsUI.Docking.DockPanel.Persistor.LoadFromXml(DockPanel dockPanel, Stream stream, DeserializeDockContent deserializeContent, Boolean closeStream) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockPanel.Persistor.cs:Zeile 617.
   bei WeifenLuo.WinFormsUI.Docking.DockPanel.LoadFromXml(Stream stream, DeserializeDockContent deserializeContent) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockPanel.Persistor.cs:Zeile 799.
   bei Lumos.GUI.WindowManager.LoadWinFormUITheme(ThemeBase winFormUITheme) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosGUI\src\WindowManagement\WindowManager.cs:Zeile 854.

Ich füge einem neuen leeren Projekt zum Beispiel vier Clay Paky Alpha Spot QWO 800 hinzu und stelle eine beliebige Strobe-Frequenz bei geöffnetem Shutter und voller Helligkeit ein. Ist der Programmer hierbei geschlossen, kann ich Änderungen in der gesamten GUI soweit wie gewohnt vornehmen.

Sind Stage View und Programmer parallel geöffnet, reagiert die GUI deutlich verzögert, insbesondere die Control Windows und das Device Control, wo ich Werte über Regler einstellen kann. Im ungünstigsten Fall wird der Inhalt des Device Controls nicht aktualisiert bzw. nicht aufgebaut. Dies ist mir insofern zum Verhängnis geworden, dass ich eine Cue über “Edit in Programmer Blind” live nicht anpassen konnte.

Zur Zeit ist es nicht möglich, im Standard-Theme zwischen absoluten Werten (ABS) und relativen Werten (REL) umzuschalten. Dies klappt nur im Dark Theme.

Mit der Beta 5 habe ich häufig insbesondere beim Speichern des aktuellen Projekts das Problem, dass die GUI abstürzt. Folgender Eintrag im Log der GUI zu finden.

2022-12-23 16:24:17,453 [Log-Thread] DEBUG Lumos.GUI.Run.GuiRunManager - InformSaveProject [before=True] took 105 ms
2022-12-23 16:24:17,531 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.User_gClient - UserContext of current User changed
2022-12-23 16:24:17,540 [92] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.
System.InvalidOperationException: Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.
   bei Lumos.GUI.Facade.User.UserContextFacade.ProcessDeviceChangedMessage(UserContextChangedMessage message) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\User\UserContextFacade.cs:Zeile 43.
   bei Lumos.GUI.Facade.GUISession.UserContextFacadeUpdater.<ProcessChange>d__3.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\GUISession\FacadeUpdaters.cs:Zeile 38.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Facade.GUISession.FacadeContainer`2.<ProcessChangeMessage>d__21.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\GUISession\FacadeContainer.cs:Zeile 142.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   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.User.UserManager.<OnUserContextChanged>d__65.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\User\UserManager.cs:Zeile 282.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_1(Object state)
   bei System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Der Kernel führt zu dem Zeitpunkt des Absturz folgende Aktionen aus:

2022-12-23 16:24:17,475 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Saving Project FS#4944 - Master window
2022-12-23 16:24:17,484 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - saveProject KernelInputManager.
2022-12-23 16:24:17,796 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Resource.FileAccessUtil - Deleted D:\Arbeit\MSK event GbR\Software\DMXControl 3.3.0\Kernel\Temp\b42fdf64-174b-4edc-97eb-b4cb45012ba3.tmp
2022-12-23 16:24:17,796 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Project FS#4944 - Master window successfully saved.

Mehr durch Zufall musste ich feststellen, dass die GUI direkt beim Start mit dem folgenden Logeintrag abstürzt, wenn statt des 3.3er-Kernels der 3.2.3er-Kernel läuft. Auch wenn die Konstellation eher ungewöhnlich ist, sollte diese trotzdem keinen Absturz hervorrufen.

2023-01-07 20:22:54,057 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig
System.Net.Sockets.SocketException (0x80004005): Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig
   bei System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   bei System.Net.Sockets.Socket.Bind(EndPoint localEP)
   bei LumosProtobuf.Udp.UdpListener.StartListen() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UdpListener.cs:Zeile 41.
   bei LumosProtobuf.Udp.UmbraDiscoveryClient.StartDiscovery(IReadOnlyCollection`1 listenAdresses) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraDiscoveryClient.cs:Zeile 66.
   bei org.dmxc.lumos.Kernel.Net.AbstractGrpcManager.NetTools_NetworkChanged(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\AbstractGrpcManager.cs:Zeile 175.
   bei org.dmxc.lumos.Kernel.Net.AbstractGrpcManager.StartupFinished() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\AbstractGrpcManager.cs:Zeile 167.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.InformManagerStartupFinished(TManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 372.
   bei System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.DoManagerTopDown(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 142.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.startManager() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 340.
   bei Lumos.GUI.Run.GuiRunManager.startupGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Run\GuiRunManager.cs:Zeile 62.
   bei Lumos.GUI.Program.runGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Program.cs:Zeile 194.
   bei Lumos.GUI.Program.Main(String[] param) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Program.cs:Zeile 160.

Reproduzieren lässt sich dies, in dem ich den 3.2.3er Kernel manuell starte und dann Umbra und GUI über den Launcher aufrufe.

Das Setzen der Reihenfolge für eine Device Group ist im Project Explorer ausschließlich über einen Doppelklick möglich. Im Kontextmenü zur Device Group fehlt ein entsprechender Eintrag mit der Beschreibung “Set Order of Devices” (siehe Bild 1). Damit ist die Funktion für die Device Group aktuell noch eine versteckte Programmfunktion.

Bei der Cuelist Group gibt es dagegen richtigerweise einen entsprechenden Eintrag im Kontextmenü zur Cuelist Group (siehe Bild 2).

Geräte wie Tilt-Bars oder ähnliche - wo also nur eine von zwei Bewegungsachsen vorhanden sind - können vom Position Control aktuell nicht angesteuert werden.

Beim Anlegen einer neuen Gruppe aus ausgewählten Geräten wird diese neue Gruppe bei mehreren StageViews immer in der zuerst angelegten StageView eingefügt, aber nicht in der, in der die Geräte für die neue Gruppe ausgewählt wurden.

Folgende Vorgehensweise führt zu einem Absturz der GUI:

• Einfügen eines neuen Device zum Projekt
• Ändern verschiedener Werte in der StageView
• Anschauen dieser Werte in der ChannelOverview
• Direktes Löschen des Geräts aus dem Projekt, ohne den Programmer etc. zurückzusetzen

Dies ist vielleicht nicht ein alltägliches Szenario. Es ist mir beim Überprüfen der DDFs unter die Finger gekommen.

Aktuell fehlt die Möglichkeit, eine Polygone als Effekt auf Position zu legen. So können mit nur einem Effekt Dreiecke, Vier- / Rechtecke, Fünfecke etc. zu erstellen. Folgende Parameter sollte der Effekt haben:

• Anzahl der Seiten / Anzahl der Ecken
• Breite und Höhe des Polygons
• Frequenz (Geschwindigkeit)
• Drehung der Figur (Index)
• Phase

Optional könnte der Effekt um die Möglichkeit erweitert werden, über den Parameter Radius die Ecken abzurunden, um abgerundete Rechtecke zu erhalten. Zur Vermeidung von Komplikationen muss der maximale Wert des Radius in Abhängigkeit der Breite / Höhe dynamisch berechnet werden.

EDIT Arne: Was auch geil wäre ist, wenn man das Polygon rotieren lassen könnte, also neben dem festen “Index” noch eine “Rotation” Eigenschaft. Damit könnte man seine Scanner ein drehendes 4-Eck fahren lassen. Das soll die GrandMa mal nachmachen

Es wäre hier von Vorteil, wenn die betreffende Szene entsprechend gekennzeichnet wird, dass für diese der Cue Timing Editor aktiv ist. Ggf. kann dieses durch Einfügen einer zusätzlichen Spalte erfolgen, wo dieser analog zu den Spalten “Cue active”, “Autoprepare” und “Take fades” aktiviert und deaktiviert werden kann. Hierbei wird der Haken automatisch gesetzt, sobald man in den Cue Timing Editor Werte eingetragen und dieses geschlossen hat.

Folgendes wurde behoben:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wird im Cue Timing Editor für eine Cue eine Fade- und / oder eine Delay-Zeit eingetragen, können diese Werte fortan nur noch dort geändert werden. Ändert man nachträglich die Werte direkt in den betreffenden Spalten in der Cuelist, haben die Werte vom Cue Timing Editor weiterhin bestand.

Es fehlt hier die Möglichkeit, den Cue Timing Editor zu deaktivieren oder zurückzusetzen, zum Beispiel einfach durch löschen aller Einträge in den Feldern.

Aktuell können die Werte vom Cue Timing Editor nur durch das Ersetzen der komplett neu erstellten Szene zurückzusetzen werden. Die Cue nur im Programmer zu editieren reicht nicht aus.