Bugtracker DMXControl 3

Zur Prüfung des Installers nach den umfangreichen Änderungen habe ich mir auch mal ein paar Projekte angesehen. Dabei ist mir das Problem unter die Finger gekommen, dass im Build 142 die Graphen des Input Assignments nicht gespeichert werden können. Welches Projekt man dabei nimmt, ist vollkommen egal.

Der Fehler lässt sich reproduzieren, wenn man zum Beispiel ein Cuelist- oder ein Macroboard-Node in ein Connectionset schmeißt und dieses Projekt dann speichern will. Dann spuckt der Kernel folgende Fehlermeldung aus:

17:14:53 WARN  ResourceManager - Unable to save Resource Graphs.xml of Type Project
System.InvalidOperationException: 'org.dmxc.lumos.Kernel.Input.v2.NameNumberIDValue' kann nicht serialisiert werden, weil dafür kein parameterloser Konstruktor verfügbar ist.
   bei System.Xml.Serialization.TypeDesc.CheckSupported()
   bei System.Xml.Serialization.TypeScope.GetTypeDesc(Type type, MemberInfo source, Boolean directReference, Boolean throwOnError)
   bei System.Xml.Serialization.ModelScope.GetTypeModel(Type type, Boolean directReference)
   bei System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping(Type type, XmlRootAttribute root, String defaultNamespace)
   bei System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(String name, Object value, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 390.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 311.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 294.
   bei org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResource(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:Zeile 480.
   bei org.dmxc.lumos.Kernel.Resource.ResourceManager.SaveResourceInternalAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\ResourceManager.cs:Zeile 219.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.<SaveResourceAsync>d__86.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 732.

Ein neues Testprojekt kann ich auf Grund der Art des Fehlers nicht beifügen. Daher verweise ich auf mein zuletzt für das Ticket  FS#4856  erstelle Projekt.

Da dieses Problem sich aus meiner Sicht unmittelbar als Testblocker herauskristallisieren würde, habe ich mich entschlossen, ausnahmsweise ein Ticket für eine Zwischenversion zu schreiben.

Detaillierte Beschreibung folgt.

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

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

Ist ein Connectionset fehlerhaft, werden die im Projekt enthaltenen Softdesks nicht geladen. Damit sind alle Connectionsets nicht nutzbar, die Elemente eines Softdesks enthalten - und nicht nur die, in denen ein Fehler aufgetreten ist. Im Log der GUI taucht dann folgender Eintrag auf:

2022-05-07 13:48:16,099 [Main GUI] ERROR Lumos.GUI.WindowManager - Error when instantiating Object from persistString: Lumos.GUI.Windows.Softdesk.SoftdeskWindow#8af8329a-c9ce-46da-8a74-ce20b5f9301a
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> org.dmxc.lumos.Kernel.Exceptions.NotExistingException: Can't find a SoftdeskModel with ID 8af8329a-c9ce-46da-8a74-ce20b5f9301a
   bei Lumos.GUI.Windows.Softdesk.SoftdeskWindow.getSoftdeskModelFromID(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Softdesk\SoftdeskWindow.cs:Zeile 67.
   bei Lumos.GUI.Windows.Softdesk.SoftdeskWindow.GetInstanceFromPersistString(String softdeskId) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Softdesk\SoftdeskWindow.cs:Zeile 41.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   bei Lumos.GUI.WindowManager.GetContentFromPersistString(String persistString) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\WindowManagement\WindowManager.cs:Zeile 1856.

Als Beispiel kann das Projekt aus  FS#4850  herangezogen werden. Auch wenn dieses nur ein Connectionset enthält und dieses einen Fehler auswirft, ist dennoch zu sehen, dass alle Elemente des Softdesks pauschal nicht geladen werden.

Ich habe in dem beigefügten Projekt ein Connectionset für ein Softdesk gebaut, bei dem die Input und Output Selectoren mit mehr als 4 Eingängen konfiguriert sind. Beim Input Selecotor sind es 5 (1..5) und beim Output Selector 6 (1..6). Speichere ich das Projekt und lade es erneut, wird es auf Grund des folgenden Fehlers nicht geladen:

13:48:02 WARN  Graph - 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.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 337.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 310.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.org.dmxc.lumos.Kernel.Resource.ILumosSaveable.loadFromManagedTree(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 802.

Da der Fehler eindeutig zuzuordnen ist, füge ich nur das Beispielprojekt bei.

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

Ich hatte im beigefügten Projekt ursprünglich zwei Cuelists angelegt. Die Cuelist 2 hatte ich dabei per Special Cue in die Cuelist 1 referenziert. Die Cuelist 1 enthält neben der Special Cue mit der Referenz zur Cuelist 2 noch zwei weitere “einfache” Cues.

Nun habe ich die Cuelist 2 aus dem Projekt gelöscht und das Projekt gespeichert. Die Special Cue in der Cuelist 1 ist aber weiterhin vorhanden.

Beim erneuten Laden des Projekts wird zwar logischerweise ein Fehler ausgeworfen, dass die Cuelist 2 fehlt und die Referenz entsprechend nicht aufgelöst werden kann. Jedoch im gleichen Zusammenhang der Inhalt der gesamten Cuelist 1 auf den ersten Blick scheinbar nicht mehr geladen. Die Cuelist 1 hat dann 0 Cues. Der Kernel wirft hierbei den folgenden Fehler aus:

07:47:42 WARN  ProjectManager - Error when loading Project 2022-04-27 - Cuelist reference.dmz: Warnings in Project
org.dmxc.lumos.Kernel.Exceptions.ProjectIOException: Warnings in Project
   bei org.dmxc.lumos.Kernel.Resource.LumosIOContext.ThrowOnWarnings() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\LumosIOContext.cs:Zeile 220.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.loadProject(String filename, Stream inputStream, Boolean loadId, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 384.
07:47:42 WARN  ProjectManager - Loading Cue Lists in Project
07:47:42 WARN  ProjectManager - Error loading complete Scenelist Cuelist 1. There could be a loss of information! in Cuelist 1
07:47:42 WARN  ProjectManager - A Cuelist with the ID 70ff8bf9-eb8c-4f62-8ae5-65370c96d2b3 doesn't exist in Go: Cuelist 2
07:47:42 WARN  ProjectManager - Loading Cue Lists in Project
07:47:42 WARN  ProjectManager - Error loading complete Scenelist Cuelist 1. There could be a loss of information! in Cuelist 1
07:47:42 WARN  ProjectManager - A Cuelist with the ID 70ff8bf9-eb8c-4f62-8ae5-65370c96d2b3 doesn't exist in Go: Cuelist 2

Füge ich der Cuelist 1 dann im Nachgang noch eine weitere Cue hinzu, wird deren Inhalt aktualisiert und es tauchen die bereits existierenden wieder auf. Auch der Project Explorer berichtigt die Zahl der in der Cuelist 1 enthaltenen Cues. Alternativ kann ich das Projekt durch manuelles Handanlegen an der Datei Scenenlists.xml wieder ohne Fehlermeldung vollständig zum Laufen bekommen, indem ich dort den zugehörigen Eintrag zur Special Cue entferne.

Im Hinblick auf die Zusammenfassung dieses Tickets, würde ich folgende alternativen Erwartungshaltungen formulieren, um das Problem zumindest dahingehend zu lösen, als dass mir nicht die gesamte Cuelist 1 um die Ohren fliegt:

• Bereits beim Löschen einer Cuelist wird geprüft, ob diese ggf. per Special Cues in anderen Cuelists referenziert ist. Ist dem so, erscheint wie beim Löschen von Geräten oder Gerätegruppen der Reference Manager, wo ich zum einen auf diesem Umstand hingewiesen werde und zum anderen festlegen kann, ob ich die zu löschende Cuelist referenzierenden Special Cues komplett löschen möchte.
• Beim Laden des Projekts bietet mir die “Fehlerbehebung” an, die defekten Special Cues zu löschen anstelle den Fehler nur zu ignorieren. Hierbei wird effektiv gesehen der Schritt nach einer Bestätigung entsprechend vom Programm ausgeführt, den ich wie beschrieben manuell vorgenommen habe.

Zur Nachtverfolgung habe ich das defekte Projekt beigefügt. Da der Eintrag im Kernel eindeutig ist, verzichte ich auf das beifügen weiterer Log-Dateien.

Lösche ich eine Cuelist aus einem Projekt, welches ich zuvor unmittelbar gespeichert habe, wird mir dies im Dirty Flag nicht angezeigt.

Ich möchte die Verknüpfungen zu den einzelnen Anwendungen von DMXControl 3 im Startmenü gerne vom Installer im folgenden Pfad ablegen lassen:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DMXControl 3.3.0\

Dass es sich hier nun um das Verzeichnis für alle Benutzer handelt, sei erstmal irrelevant, weil ich dies ja nicht explizit festlegen kann.

Scheinbar auf Grund der existierenden Registry-Einträge für die ebenfalls auf meinen PCs installierte 3.2.3 schlägt der Installer der 3.3.0 immer folgenden Pfad vor:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DMXControl 3.2.3\

Egal ob ich den Pfad auf meinen Wunschpfad ändere (im Installer trage ich ja dann nur “DMXControl 3.3.0” ein) oder ich sage generell, dass der Installer bitte keine neuen Verknüpfungen anlegen soll - in beiden Fällen landen alle Verknüpfungen im Startmenü immer im “alten” Verzeichnis, also im Verzeichnis “DMXControl 3.2.3”.

Im Anhang die Log-Datei des Installers.

Bei der Bearbeitung des Tickets bitte beachten, dass im QRM22.1 grundlegende Anpassungen am Installer beschlossen wurden, welche bis zum Release auch umgesetzt werden sollen. Hierzu gehören unter anderem die Tickets FS#2763 und FS#4708.

Beim Laden des Tickets aus  FS#4640  erscheint im Log des Kernels folgender Eintrag:

19:51:44 ERROR UserManager -
org.dmxc.lumos.Kernel.Exceptions.ItemLoadException: Unable to load PasswordHash for User
   bei org.dmxc.lumos.Kernel.User.UserManager.LoadBeforeContainers(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\User\UserManager.cs:Zeile 137.

Ich habe mehr oder minder unbeabsichtigt ein Msuikstück mit einer Länge von 76 Minuten einem leeren Projekt hinzugefügt. Im Kernel erscheinen daraufhin die folgenden Einträge:

21:07:37 ERROR LumosTools - Can't get Tags of Resource [[SOUNDFILE]]
System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.
   bei System.IO.MemoryStream.set_Capacity(Int32 value)
   bei System.IO.MemoryStream.EnsureCapacity(Int32 value)
   bei System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   bei LumosLIB.Tools.CommonTools.<CopyStreamCore>d__95.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1396.
--- 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 LumosLIB.Tools.CommonTools.CopyStream(Stream source, Stream destination, Int32 blockSize, IProgress`1 progressCallback, Boolean disposeSource) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1372.
   bei LumosLIB.Tools.CommonTools.<ToMSCore>d__81.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1218.
--- 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 LumosLIB.Tools.CommonTools.ToMS(Stream stream) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1205.
   bei LumosLIB.Tools.LumosTools.SimpleFileAbstraction..ctor(Stream stream, String name, Boolean disposeStream) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\LumosTools.cs:Zeile 573.
   bei LumosLIB.Tools.LumosTools.<GetDetails>d__42.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\LumosTools.cs:Zeile 615.
21:10:45 ERROR AudioManager - Unable to process FFT / Wave for [[SOUNDFILE]] after several tries....

Auf Grund dieses Fehlers bleiben die Background-Tasks unerledigt beim Status “Waiting” stehen, weil hier die FFT nicht generiert werden konnte. In solchen Fällen sollte der entsprechende Tasks mit einem Fehler abgebrochen werden, als weiterhin den Status “Waiting” beizubehalten.

Seit DMXControl 3.3.0 Beta 2 werden RGB-Werte für Farben vom Input Selector wieder in ein Lumos-Color-Objekt konvertiert.

Dieses Problem hatten wir bereits im Rahmen des Beta-Tests von DMXControl 3.2.2. Seiner Zeit hatte ich es im Ticket  FS#4273  berichtet. Die dort vorhandenen Screenshots sind 1.1 übertragbar, weswegen ich keine neuen Screenshots erstellt habe.

In DMXControl 3.3.0 Beta 2 kann ich im Input Selector Node keine eigenen Eingaben mehr hinterlegen. Sobald ich in ein anderes Feld klicke, werden diese wieder entfernt. Dieser Fehler existierte bis zur Beta 1 noch nicht.

Log-Dateien kann ich keine zur Verfügung stellen, weil diese Änderungen im Node nicht protokolliert werden.

Nachdem ich nun das Position Master Node grundsätzlich extern ansteuern kann, ist mir aufgefallen, dass das Node am Value Input reale Positionswerte in Grad erwartet. Dies ist insbesondere im Zusammenspiel mit einer externen Ansteuerung über Fader etc. ungünstig, wie ich es bereits im Ticket  FS#4786  angeschnitten habe. Ändere ich den Aktionsbereich des zugeordneten Position Masters, muss ich auch in den Connectionsets verschiedene Anpassungen vornehmen.

Ich sehe hier folgende Ansätze, diesen Fehler (weil wir ja eigentlich immer nur mit normierten Werten von 0 bis 1 innerhalb der Connectionsets arbeiten wollen) zu beheben:

• Der Value Input wird so angepasst, sodass er nur eine normierte Position versteht.
• Der aktuelle Input wird erhalten und ein weiterer Input ergänzt, der dann die normierte Position versteht.
• Der aktuelle Input wird erhalten und analog zum Programmer-Node zwei getrennte Inputs für Pan und Tilt ergänzt.

Öffne und schließe ich den Image chooser mehrfach in einer Sitzung, um Gobos für eine Gobo list oder für die Gobo affinity auszuwählen, reagierte die GUI nach einigen Malen nicht mehr und im Log erscheint folgender Eintrag

2022-04-15 13:05:18,330 [Main GUI] ERROR Lumos.GUI.App - Exception in WPF
System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.

In diesen Fällen beendet sich die GUI selbst und muss manuell neu gestartet werden.

Die vollständigen Logs stelle ich zu einem späteren Zeitpunkt zur Verfügung, wenn ich das Problem nochmal gezielt reproduziere.

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

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

Im beigefügten Projekt habe ich die Buttons 1.7, 2.7 und 2.8 meines Streamdecks XL belegt. Schaue ich mir das Profil in der GUI selbst an, passt die Zuordnung. Auf dem Streamdeck passt die Zuordnung zwar auf der Eingangsseite. Auf der Ausgangsseite ist aber alles um einen Button nach links und einen Button nach oben verschoben. So erfolgt die eingestellte Ausgabe für den Button 2.8 auf dem Streamdeck tatsächlich auf dem Button 1.7.

Ergänze ich in dem Projekt ein zweites Macroboard-Profil und wechsle im Macroboard-Profile-Node manuell einmal zu diesem hin- und dann wieder zurück zum ersten, passt die Anzeige auf dem Streamdeck - bis ich anfange, die Tasten zu drücken. Dann sind wir wieder bei der Ausgangslage mit dem Offset.

Dieser Fehler ist höchstwahrscheinlich durch die Auslagerung der Macroboards in ein Plugin entstanden. In der Beta 1 hat noch alles wie gewünscht funktioniert.

Das beigefügte Projekt habe ich unter DMXC 3.2.x erstellt und verschiedene Macroboard-Profile angelegt. Bedingt durch die Auslagerung in ein Plugin kann ich dieses nicht mehr laden. Es erscheint im Kernel der folgende Eintrag.

12:39:01 WARN  ProjectManager - Error when loading Project 2022-01-12 - Macroboard.dmz: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.Macroboard.MacroBoardManager.SelectProfile(String macroBoardID, String profileID, Boolean ignoreBoardNotExisting) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\MacroBoard\MacroBoardManager.cs:Zeile 338.
   bei org.dmxc.lumos.Kernel.Input.Macroboard.MacroBoardManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.loadProject(LumosIOContext context, ELoadTime time) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\MacroBoard\MacroBoardManager.cs:Zeile 441.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass29_1.<loadProject>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 337.
   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.Project.ProjectManager.loadProject(String filename, Stream inputStream, Boolean loadId, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 333.

Ignoriere ich die zugehörige Fehlermeldung in der GUI, ist das Projekt gewissermaßen kaputt. Es fehlt nicht wie in anderen Fällen nur ein Element, in diesem Fall das Macroboard-Profil, sondern deutlich mehr.

Wenn ich aber die Datei MacroBoardProfiles.xml vor dem Laden aus dem Projekt entferne, kann gibt es keine Fehlermeldung. In diesem Fall kann ich aber dann das Macroboard-Profil neu anlegen und und die Buttons im Input Assignment neu zuordnen. Ist dies erledigt, lädt das auf diese Projekt nach dem Neustart der Sitzung wieder.

Das Projekt ist nur nach DMXC 3.3 importiert. Ansonsten gab es keine Veränderungen. Bei den Logfiles habe ich dieses Mal auch die des Installers beigefüpgt - nicht, dass eine Datei fehlt.

Das beigefügte Projekt kann insofern nicht vollständig geladen werden, als dass die entsprechend zugeordneten Executoren mit ihren Einstellungen nicht geladen werden. Die Bänke sind vorhanden, aber ohne gefüllte Executoren. In den Logfiles sind zahlreiche Einträge zu finden.

Das ursprüngliche Projekt habe ich dabei nur in DMXC 3.3 Beta 2 importiert und aufgerufen. Neu gespeichert wurde es mit der 3.3 nicht.

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.

Ich möchte das aktuell gewählte Gobo eines Geräts auf dem Macro Board ausgeben und habe dazu den Ausgang “Gobo” des DMXC-Mixer-Nodes mit dem Node “Bitmap from Resource” verbunden. Dies soll eigentlich das Bild an den betreffenden Button übergeben. Stelle ich diese Verbindung her, erscheint im Kernel folgender Eintrag:

19:37:00 ERROR BitmapFromResource -
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.BitmapFromResource.processInternal(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Converter\Bitmap\BitmapFromResource.cs:Zeile 55.

Auf Grund dieser Fehlermeldung arbeiten die nachfolgenden Teile des Graphs nicht und ich sehe folglich auch kein Bild auf dem Button. Wähle ich stattdessen manuell eine Resource aus, arbeitet das Node “Bitmap from Resource” wie erwartet.

Füge ich am Gobo-Output des DMXCMixers das MacGyver-Node ein, wird im Übrigen der Name des Gobos nicht unter Image File im LumosGobo-Object geführt, sondern der Name des Gobos erscheint unter dem Ausgang “Min Value”. Schließe ich das Bitmap from Resource an diesen Ausgang an, werden mir die Gobos zumindest angezeigt, sofern ich ein Gobo des ersten von zwei Goborädern auswähle. Die Aktualisierung läuft aber nicht ganz so zuverlässig.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

in der Cuelist gespeichert.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Entscheidung aus QRM 22.1

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

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

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

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

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

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

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

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

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

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

Im Anhang die Log-Dateien der Sitzung.

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

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

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

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

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

Gleiches gilt auch für andere Master.

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

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

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

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

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

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

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

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

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

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

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

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