Bugtracker DMXControl 3

Versuche ich für den Plasma-Effekt die Frequenz beliebig zu ändern, hat dieser Wert keinen Einfluss auf den Effekt. Er läuft also aktuell trotz beliebiger Frequency mit der gleichen Geschwindigkeit weiter.

Das beigefügte Projekt enthält mehrere unterschiedliche Moving-Heads mit Gobos, die sich stellenweise ähnlich sind. Wähle ich bei einem beliebigen Gerät aus der Gruppe zum Beispiel ein Balken-Gobo aus, so wird in DMXControl 3.2.1 stattdessen bei den anderen Geräten dasjenige Gobo gewählt, welches sich im gleichen Slot - zum Beispiel Slot 7 - befindet.

Eine Überprüfung mit DMXControl 3.2.2 Beta 2 zeigte aber, dass hier die automatische Goboauswahl funktioniert und jedes Gerät einen Balken anzeigt.

Ich patche ein Gerät mit mehr als einem DMX-Kanal auf die letzten Adressen eines DMX-Universums, zum Beispiel einen Hazer mit zwei DMX-Kanälen auf die DMX-Adresse 511 oder einen einfachen RGB-Scheinwerfer mit drei DMX-Kanälen auf die DMX-Adresse 510. Bestätige ich dies im Add Device Dialog, so setzt DMXControl beide Geräte auf die DMX-Adresse 1 des nächsten DMX-Universums, also 2.1. Folglich muss ich bei diesen Geräten die DMX-Adresse manuell korrigieren.

Ein Gerät mit nur einem DMX-Kanal (Dimmer, Nebelmaschine) kann ich dagegen auf die DMX-Adresse 512 setzen. Dies wird beim Bestätigen wie gewünscht umgesetzt, alasi auf die DMX-Adresse 1.512.

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)

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

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.

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

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.

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.

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.

Nachdem ich ein Projekt geschlossen habe, stand plötzlich folgende Meldung im Kernel:

18:55:59 FATAL DMXControl 3 Kernel - Unhandled Exception: Der Wert darf nicht NULL sein.
Parametername: projectID
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: projectID
   bei org.dmxc.lumos.Kernel.Project.SceneListManager.GetSceneListGroupByID(String sceneListGroupID, String projectID) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\SceneListManager.cs:Zeile 396.
   bei org.dmxc.lumos.Kernel.Project.SceneListManager.GetSceneListGroupByID(String sceneListGroupID) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\SceneListManager.cs:Zeile 381.
   bei org.dmxc.lumos.Kernel.Net.gService.Parameter.ScenelistGroupParameterLookup.Find(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Parameter\ScenelistGroupParameterLookup.cs:Zeile 11.
   bei org.dmxc.lumos.Kernel.Net.gService.Parameter.AbstractIParameterableLookup`1.<ParametersAsync>d__2.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Parameter\AbstractIParameterableLookup.cs:Zeile 17.
--- 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 org.dmxc.lumos.Kernel.Net.gService.Parameter_gService.<_parameters_RequestReceived>d__13.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Parameter\Parameter_gService.cs:Zeile 118.
--- 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()
An unhandeled Exception has occoured. DMXControl 3 Kernel has to be terminated. Press Enter to exit.

Trotz dieser Meldung konnte ich aber ein anderes Projekt laden, dieses wieder schließen und dann das Projekt laden, was ich als erstes bearbeitet hatte. Sprich der Kernel ist nicht abgestürzt. Bewusst war mir diese Fehlermeldung aber noch nicht unter die Finger gekommen.

Beim Hinzufügen eines Effekts aus der Reihe der gespeicherten Effekte musste ich feststellen, dass dies keine Parameter mehr beinhalten, wenn ich mir diese in der GUI per Edit ansehe und auch auf eine Funkion anwende. Vergleiche ich zudem die zugehörige Datei “SavedAttachables.xml” (die ich von DMXC 3.2.3 übernommen habe) vor dem Start und nach dem Beenden, so sind die zugehörigen Parameter der gespeicherten Effekte auch nach dem Beenden nicht mehr enthalten.

Bis zur Beta 3 zeigte der Kernel direkt in der Konsole an, ob ein Projekt erfolgreich gespeichert wurde. Mit der Einführung der neuen Project Administration fehlt dieser Eintrag nun. Man muss nun in die Logs-Files schauen, um die Info zu erhalten.

2022-10-05 14:27:37,312 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Project.ProjectManager - Saving Project 2022-09-13 - Selectors
2022-10-05 14:27:37,344 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - saveProject KernelInputManager.
2022-10-05 14:27:37,692 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Resource.FileAccessUtil - Deleted D:\Arbeit\MSK event GbR\Software\DMXControl 3.3.0\Kernel\Temp\284bdc1b-3b86-4515-9367-72d3c834f189.tmp
2022-10-05 14:27:37,692 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Resource.AbstractIOContext - Calling ResetDirty on 45 elements

Hier bitte ich daher, einen der zuvor aufgeführten Einträge wieder in die Konsolenausgabe durchzureichen.

Seit der Beta 5 habe ich mit dem USB Energy Fixer das Problem, dass dieser nicht richtig und deswegen wiederholt ausgeführt wird. Jedes Mal werden die entsprechenden Admin-Rechte jedoch angefordert. Der Rückgabecode wird auch als Fehlermeldung in der GUI ausgegeben.

2022-12-26 13:01:06,849 [14] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - Incorrect USB energy settings - Found incorrect USB energy settings for Nodle interface!
trying to start USBDMXEnergyFixer.exe as Admin on my own to fix registry settings automatically.
Registry-Key: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_16D0&PID_0833'
2022-12-26 13:01:09,860 [Main] WARN  DMXInterfaceMgmtLIB.AbstractDMXInterfaceManager - Timeout when fetching Interface List from DMX Interface Factory DMXControl Projects e.V.
System.TimeoutException: The operation has timed out.
   at DMXLIB.FactoryTimeoutDecorator.get_Interfaces()
   at DMXInterfaceMgmtLIB.AbstractDMXInterfaceManager.LoadInterfaces(IDMXInterfaceFactory factory) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\DMXInterfaceMgmtLIB\AbstractDMXInterfaceManager.cs:line 1398
2022-12-26 13:01:16,181 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - Incorrect USB energy settings - Found incorrect USB energy settings for Nodle interface!
trying to start USBDMXEnergyFixer.exe as Admin on my own to fix registry settings automatically.
Registry-Key: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_16D0&PID_0833'
2022-12-26 13:01:19,196 [Log-Thread] WARN  DMXInterfaceMgmtLIB.AbstractDMXInterfaceManager - Timeout Exception when getting Interfaces from Factory DMXControl Projects e.V..
System.TimeoutException: The operation has timed out.
   at DMXLIB.FactoryTimeoutDecorator.get_Interfaces()
   at DMXInterfaceMgmtLIB.AbstractDMXInterfaceManager.IsInterfaceAvailable(String interfaceId) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\DMXInterfaceMgmtLIB\AbstractDMXInterfaceManager.cs:line 194
2022-12-26 13:01:29,502 [14] ERROR org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - EnergyFixer returned Error: -2147450726
2022-12-26 13:01:29,506 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - USBDMXEnergyFixer done - unknown ReturnCode from USBDMXEnergyFixer.exe, Code: -2147450726
2022-12-26 13:01:29,514 [Log-Thread] WARN  org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - Execution of Interfaces took 22674 ms in Factory NodleUsbInterfaceFactroy
2022-12-26 13:01:32,703 [56] ERROR org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - EnergyFixer returned Error: -2147450726
2022-12-26 13:01:32,707 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - USBDMXEnergyFixer done - unknown ReturnCode from USBDMXEnergyFixer.exe, Code: -2147450726
2022-12-26 13:01:32,709 [Log-Thread] WARN  org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - Execution of Interfaces took 19541 ms in Factory NodleUsbInterfaceFactroy
2022-12-26 13:01:33,626 [64] ERROR org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - EnergyFixer returned Error: -2147450726
2022-12-26 13:01:33,628 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - USBDMXEnergyFixer done - unknown ReturnCode from USBDMXEnergyFixer.exe, Code: -2147450726
2022-12-26 13:01:33,633 [Log-Thread] WARN  org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - Execution of Interfaces took 17455 ms in Factory NodleUsbInterfaceFactroy

Wenn ich den Registry-Eintrag über DMXControl 3.2.3 setzen lasse, wird der USB Engergy Fixer in DMXC 3.3 Beta 5 nicht mehr aufgerufen. Zudem trat das Problem mit der Beta 3 nicht.

Ich habe gestern mit meinem Live-Show-Projekt über einen längeren Zeitraum ein wechselndes Ambiente gebaut und zwischendurch immer mal wieder Licht live gedrückt. Beim Heraussuchen der Logdateien für einen anderen Fehler bin ich auf die mit rund 170 MB sehr große Logdatei des Kernels aufmerksam geworden.

Der folgende Eintrag wurde über den genannten Zeitraum über 1,2 Millionen Mal in die Logdatei geschrieben - sogar noch als vorletzter Eintrag bevor der Kernel final geschlossen wurde.

2023-01-06 19:31:14,781 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - Processing Queue of Graphs contains 11 elements
[...]
2023-01-06 22:50:18,081 [114] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - Processing Queue of Graphs contains 50 elements
2023-01-06 22:50:18,095 [Main] INFO  DMXControl 3 Kernel - Kernel closing!

Diese Logeinträge werden generiert, sobald ich das Projekt geladen habe, selbst wenn nach dem Laden noch nichts aktiv ausgegeben wird.

Das zugehörige Projekt umfasste zu dem Zeitpunkt 114 Connectionsets sowie 18 Bänke. Für das Debugging stelle ich das Projekt über die Cloud zur Verfügung, benannt entsprechend mit der Nummer dieses Tickets.

Mit der Veröffentlichung der Beta 6 kommt nun immer folgende Fehlermeldung im Kernel, wenn ein Projekt Executoren enthält, denen ein Element zugeordnet sind:

21:02:46 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Executor.ScenelistExecutorMemberConfiguration could not be loaded: Number, Name
21:02:46 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Executor.ExecutorMemberConfiguration could not be loaded: Number, Name

Trotz dieser Fehlermeldung stimmt die Zuordnung der Executoren aber und auch die individuelle Konfiguration der Buttons wird richtig geladen.

So war es auch im Zuge des Zusammenfügen der Logs für  FS#5035 . In den dort beigefügten Logfiles ist die genannte Fehlermeldung ebenfalls enthalten, als ich das Projekt aus FS#4772 öffnete. Dieses enthält drei Executoren, denen eine Szenenliste zugeordnet ist.

Ich habe den Chaser auf eine Gruppe von 10 Geräten gezogen und den Play Mode auf “Random” gesetzt. Wähle ich bei “Size” einen Wert, der der Anzahl der Geräte dieser Gruppe entspricht oder darüber hinaus geht - im aktuellen Beispiel also >= 10 - hängt sich der Chaser mit folgender Fehlermeldung auf:

20:14:36 WARN  SceneFadeTicker+TickerParallelBag - Exception triggering Item: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.Chaser.RandomChaserPattern.GetNextIndex(Int32 deviceCount) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\Chaser\Pattern\RandomChaserPattern.cs:line 61
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.Chaser.RandomChaserPattern.GetNextStep(Int32 deviceCount, Int32 length) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\Chaser\Pattern\RandomChaserPattern.cs:line 25
   at 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_3.3\Lumos\src\Kernel\PropertyValue\Filter\Chaser\Pattern\AbstractChaserPattern.cs:line 69
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.ChaserFilter2.doFilter(IPropertyValue input, Int64 timeInMs, Int64 delta) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\Chaser\ChaserFilter2.cs:line 215
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.AbstractEffectFilter.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\AbstractEffectFilter.cs:line 47
   at Lumos.Kernel.Scene.Entry.FilterAdapter.PropertyValueFilterRuntimeDecorator.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Entry\FilterAdapter\PropertyValueFilterRuntimeDecorator.cs:line 103
   at org.dmxc.lumos.Kernel.PropertyValue.AbstractPropertyValue.getPropertyValue(Int64 timeInMsAbs) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:line 401
   at 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_3.3\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:line 367
   at 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_3.3\Lumos\src\Kernel\Scene\Fade\FadeDecorator.cs:line 94
   at 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_3.3\Lumos\src\Kernel\Scene\Delay\DelayDecorator.cs:line 41
   at org.dmxc.lumos.Kernel.Scene.Fade.AutoFadeDecorator.triggerFade() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Fade\AutoFadeDecorator.cs:line 35
   at org.dmxc.lumos.Kernel.Scene.Fade.AbstractValueFadeDecorator.triggerFade(Boolean& deregister) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Fade\AbstractValueFadeDecorator.cs:line 205
   at org.dmxc.lumos.Kernel.Scene.Fade.AbstractFadeDecorator.trigger() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Fade\AbstractFadeDecorator.cs:line 91
   at org.dmxc.lumos.Kernel.Scene.SceneFadeTicker.TickerParallelBag.processBag(ProcessableTickerBag bag, Int64 now) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\SceneFadeTicker.cs:line 350

Ich setze im Softdesk einen Color Picker ein, um die Farben meiner LED-PARs individuell zu steuern. Wähle ich direkt eine Farbe aus (alte Farbe violett, neue Farbe grün), wird diese Farbe aktuell sofort aktiv gesetzt. Im Live-Betrieb sieht das meiner Meinung nach nicht schön aus. Deswegen der Wunsch, dass die Color Picker eine einstellbare (ggf. globale) Fadezeit erhalten, da ja auch an den meisten anderen Stellen in DMXControl 3 gefadet wird.

Die Fadezeit wird im übrigen dann nicht berücksichtigt, während der Auswahlpunkt mit der Maus gehalten wird. Liegt der Startpunkt allerdings nicht am Punkt der aktuellen Farbe, wird hier selbstverständlich gefaded.

Getestet mit Alpha 3, Build 11

Aktuell fehlt die oben genannte Funktion komplett. Diese sollte dann auch einfach über das Kontextmenü erreichbar sein.

Getestet mit Alpha 3, Build 11

Persönlich finde die aktuelle Arbeitsweise zum Auswählen der Controls im Softdesk sehr ungeschickt. Ich kann ein oder mehrere Controls nur über ein Auswahlrecht anwählen. Dies finde ich von Arbeitsweise her als eher ungünstig und weniger intuitiv. Ein einfacher Klick auf das Control führt aktuell auch im Designer die entsprechende Aktion aus des Controls, obwohl ich tendenziell dies an dieser Stelle für das Einrichten des Softdesks eigentlich nicht benötige.

Daher ist mein Wunsch an dieser Stelle, im Designer den Fokus auf die Einrichtung zu legen, sodass ich die Controls nach einem einfach Auswählen per Klick einstellen und ändern kann. Folglich habe ich das Ticket direkt mal mit dem Status “Usability Relevant” versehen.

Getestet mit Alpha 3, Build 11

Es fehlt ein Raster, welches im Rastermaß entsprechend einstellbar ist. Das interaktive Raster bei kleineren Softdesks zwar hilfreich, bei größeren Softdesks mit mehr als 40 Buttons dürfte ein festes Raster aber die bessere Wahl sein, vor allem weil sich so schneller eine akkurate Anordnung der Controls (auch übergreifen über mehrere verschiedene Softdesks) erzielen lässt.

Getestet mit Alpha 3, Build 11

Aktuell kann ich die Größe und Position der Controls nur durch ziehen und schieben verändern, jedoch nicht über die Eingabe von konkreten Werten. Der Punkt “Layout” bleibt trotz eines ausgewählten Controls leer.

Getestet mit Alpha 3, Build 11

Erstelle oder ändere ich ein Softdesk und habe mein Projekt noch nicht gespeichert, sind alle Änderungen an dem betreffenden nach einem Schließen und Neustarten der GUI weg.

Getestet mit Alpha 3, Build 11

Der Standard-Stil für die Controls ist von der Benennung her sehr kryptisch und sollte auf “Standard” oder “Default” umbenannt werden.

Getestet mit Alpha 3, Build 11

Der Softdesk Designer, insbesondere das Property Grid ist aktuell per Default noch nicht in englischer Sprache und muss entsprechend übersetzt werden.

Getestet mit Alpha 3, Build 50

Ich lade das beigefügte Projekt, lege ein neues Softdesk an und erstelle im Input Assignment den im Screenshot gezeigten Graphen. Danach speichere ich das Projekt, schließe DMXControl 3, starte das Programm neu und öffne das Projekt. Dies wird aber nur zum Teil erfolgreich geöffnet. Der besagte Graph ist defekt, da beim Laden des Softdesks ein Fehler vorliegt. Entferne ich das Softdesk vor dem Speichern und Neustarten, tritt die Fehlermeldung auch nicht auf.

Projekt und Logfiles im Anhang.

Diese Fehler ist unabhängig vom Ticket  FS#3408 .

Getestet mit Alpha 3, Build 55

Wähle ich im Softdesk Designer ein Bedienelement wie Button oder Slider aus, schließe den Designer und öffne das gleiche Softdesk im Live Mode, bleibt das gleiche Bedienelement ausgewählt.

Getestet mit Alpaha 3, Build 55

Im Fenstertitel bzw. in der Registerkarte wird der falsche Titel angezeigt.

Verändere ich über das Property Grid im Softdesk Designer die Größe eines beliebigen Elements, so ist die Breite oder Höhe nach dem Bestätigen der Eingabe und erneutem Auswählen des Elements um 5 Pixel geringer (je nachdem welche Eigenschaft ich geändert habe).

Dies wirkt sich auch auf die Funktion zum automatischen Anordnen der Elemente mit einem bestimmten Abstand aus. Für einen gewünschten Abstand von 10 Pixeln muss ich einen Wert von 5 Pixeln eintragen.

Ich kann die Softdesk-Elemente aktuell noch nicht in verschiedenen Ebenen anordnen. Dies fällt insbesondere dann auf, wenn ich mit einer Groupbox mehrere Buttons oder Slider optisch zusammenfassen möchte: die Buttons verschwinden im Hintergrund.

Aktuell können die Buttons nur mit einer Textzeile beschriftet werden. Es wäre hilfreich, wenn der Text wie beim “alten” Softdesk auch an der Größe der Buttons umgebrochen wird und hierdurch mehrzeilig ausfallen kann.

Im GUI-Log ist mir folgende Warnung aufgefallen, auf Grund dessen das Softdesk nicht im Projekt gespeichert werden kann:

2019-03-20 22:15:13,618 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to save project in SoftdeskManager
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
   bei System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
   bei System.Windows.Forms.Control.Invoke(Delegate method)
   bei Lumos.GUI.Windows.Softdesk.SoftdeskManager.SaveSoftdeskModelFile(SoftdeskModel model) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Softdesk\SoftdeskManager.cs:Zeile 329.
   bei LumosLIB.Tools.LumosTools.ForEach[T](IEnumerable`1 source, Action`1 action, Boolean parallel) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Tools\LumosTools.cs:Zeile 1195.
   bei Lumos.GUI.Windows.Softdesk.SoftdeskManager.saveProject(LumosGUIIOContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Softdesk\SoftdeskManager.cs:Zeile 300.
   bei Lumos.GUI.Run.GuiRunManager.<>c__DisplayClass34_0.<saveProject>b__0(IGuiManager m) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Run\GuiRunManager.cs:Zeile 337.

Die Hintergrundfarbe des Softdesks kann nicht festgelegt werden. Im hellen Theme ist dieser standardmäßig in einem hellen Grau.

Ich habe dem Softdesk einen Button hinzugefügt. Ändere ich die Hintergrundfarbe des Buttons auf gelb, wechselt die Textfarbe automatisch von weiß auf schwarz. Als Eingabehilfe wäre dies zwar ok, jedoch wechselt die Textfarbe auch nachträglich, wenn ich die Hintergrundfarbe des Buttons über einen Graphen wie [Cuelist State] > [Rule of Three] > [HSV to Color] > [Button] anspreche.

Die Erwartungshaltung ist hier, dass ich selbst dauerhaft die Textfarbe des Elements (hier weißer Text bei einem gelben Button) festlege und es keine Automatismen gibt, welche die Gestaltung des Objekts automatisch ändern, sobald ich das Element von außen über einen Graphen (hier Änderung der Hintergrundfarbe von einem dunklen Gelb auf normales Gelb (R255, G255, B0))anspreche.

In dem Projekt aus  FS#3668  kann das Softdesk ebenfalls nicht gespeichert werden - auch wenn man das nur lädt und einfach wieder auf speichern klickt, erhalte ich den folgenden Eintrag in den GUI-Logs:

2019-07-03 22:26:44,337 [4] ERROR Lumos.GUI.Windows.Softdesk.SoftdeskManager - Unable to save Softdesk Showdesk
System.Runtime.Serialization.SerializationException: Die Assembly "LumosGUI, Version=3.2.244.0, Culture=neutral, PublicKeyToken=null" kann nicht gefunden werden.

Server stack trace: 
   bei System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()
   bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
   bei System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
   bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   bei System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   bei System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
   bei System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

Exception rethrown at [0]: 
   bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   bei org.dmxc.lumos.Kernel.Resource.IResourceManager.saveResource(EResourceType type, LumosResource data)
   bei Lumos.GUI.Resource.ResourceManager.saveResourceInternal(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Resource\ResourceManager.cs:Zeile 537.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 606.
   bei Lumos.GUI.Windows.Softdesk.SoftdeskManager.SaveSoftdeskModelFile(SoftdeskModel model) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Softdesk\SoftdeskManager.cs:Zeile 338.

Die vollständigen Log-Files sind im Ticket  FS#3668  zu finden. Probleme beim Speichern des Softdesks im Projekt gab es zuletzt in dem im Ticket  FS#3433  beschriebenen Fehler.

Im Ticket  FS#3470  wurde der Fehler behoben, dass durch das Markieren von Softdesk-Elementen die Größe des Objekts falsch ausgegeben wurde.

Vermutlich durch die Behebung dieses Fehlers wachsen die Elemente nun mit jedem Speichern und Neuladen des Projekt an, und zwar um jeweils 5 Pixel in Breite und Höhe. Durch ein mehrfaches Speichern und Neuladen meines Projekts (im konkreten Fall 2 Mal) kam dann folgendes im Anhang dargestelltes Ergebnis zu Stande. Bild 1 ist das Original, Bild 2 nach dem zweimaligen Neuladen des Projekts. Der Bildausschnitt ist jeweils der gleiche.

Als kleine Unterstützung der Einsteiger wäre hier der Vorschlag, das Kontextmenü im Softdesk-Designer um den Eintrag “Open Input Assignment” oder ähnlich zu erweitern. Die Idee bzw. das Ziel dahinter ist, dass man einen weiteren Hinweis erhält, dass die Softdesk-Elemente erst im Input Assignment “mit Leben gefüllt” werden können.

Ich glaube, das Bild beschriebt den Fehler am besten. Zwei, wenn nicht sogar eine Nachkommastelle würde aus meiner Sicht als zurückgegebener Wert nach einen Button oder Label grundsätzlich ausreichen.

Der Fehler aus  FS#3700  liegt analog auch im Softdesk Designer vor, dass hier die Enft-Taste in den Eigenschaftsfeldern des Property Grids nicht akzeptiert wird.

Ich habe zwar die Möglichkeit, die Textgröße die Texte in Buttons festzulegen. Mein eingetragener Wert wird nach der Eingabe nicht übernommen und direkt auf 13 Pt. zurückgesetzt.

Öffne ich ein Softdesk im Designer, sollten beim Drücken der Tasten und Bewegen der Fader keinerlei Aktionen an das Input Assignment durchgereicht werden, sondern nur wenn ich den Test-Modus über den Play-Button oben rechts aktiviere. Dies funktioniert so leider nicht. Auch im Edit-Modus kommen die entsprechenden Aktionen im Input Assignment an.

Ich habe in meinem Softdesk drei Signallamps hinzugefügt. Alle drei haben für Minval (aus) -1, für Maxval (ein) 0, 1 bzw. 2. Auf diese Weise soll immer nur eine Signallamp an sein, ohne dass ich weitere Nodes zur Konvertierung vorschalten muss. An den Inputs aller Signallamps können die Werte -1, 0, 1 oder 2 anliegen.

Die gesetzten Werte werden jedoch von allen Signallamps ignoriert, sodass alle drei Signallamps bei den anliegenden Werten -1, 1 und 2 leuchten und bei 0 aus sind.

Ich würde mir für das Softdesk als neues Control einen Schiebeschalter mit zwei oder auf mehr möglichen Zuständen. Damit sollen direkte Umschaltungen zwischen zwei (oder mehr) Pfaden im Input Assignment möglich sein, wie sie sich zum Beispiel mit dem Input bzw. Output Selector realisieren lassen.

Ich würde mir eine Möglichkeit wünschen, um “nur” Bilder und Icons einem Softdesk als statisches Element hinzufügen zu können. Im Falle von Bildern mit transparenten Hintergründen sollte hier auch kein Rahmen zu sehen sein.

Das Ticket  FS#3878  dient ja mehr der dynamischen Anzeige von Bildern direkt in Buttons in Anlehnung an das Steam Deck.

Öffne ich ein Softdesk im Live Mode, bietet mir das Kontextmenü folgende Einträge:

• Fullscreen
• Normal
• Close

Insbesondere beim Verlassen des Fullscreen-Modus des Softdesks ist diese Aufteilung verwirrend, weil man den Eintrag Close im Fullscreen-Modus auch mit “beende Fullscreen” verstehen kann - bis man nach dem Klick hierauf feststellt, dass damit das Softdesk direkt geschlossen wird. Nebenbei “funkt” auch das aktuelle Kontextmenü bei der Touch-Bedienung dazwischen und man schließt versehentlich ein Softdesk, sofern die Funktion für das Aufrufen des Kontextmenüs über Touch (noch) aktiviert ist.

Mit persönlich fallen hierzu folgende Lösungsansätze ein, wobei dies nur ein Brainstorming ist und keineswegs alle Verschläge auch umgesetzt werden sollen:

• Das Kontextmenü wird mit anderen Begriffen kontextabhängig (also Fullscreen oder Normal / Window mode (Fenstermodus)) gestaltet, sodass die Einträge Open Fullscreen und Leave Fullscreen jeweils wechseln.
• Der Eintrag Close wird durch einen Gruppierungs- / Gliederungsstrich von den beiden Eintragen zur Anzeigeart getrennt.
• Im Fullscreen-Modus gibt es nur einen Eintrag zum Verlassen des Fullscreens. Das Schließen wird erst im normalen Fenstermodus möglich.
• Der Eintrag Normal wird in Window view umbenannt.

Ich würde mir gerne eine Möglichkeit wünschen, um eine Auswahl von Steuerelementen von einem Softdesk in ein zweites Softdesk zu übernehmen. Dies kann zum Beispiel eine Ausweitung der bestehenden Copy & Paste Funktion sein, aber ich bin auch für jeden anderen Weg offen.

Reduziere ich die Größe der Controls unter die initiale Größe des Controls (bei der Signallamp ist dies zum Beispiel 50; 50 Pixel), wird die Größe des Auswahlrahmens nicht angepasst. Das Ergebnis sieht dann wie im Screenshot dargestellt aus.

Durch das Redesign der Auswahlrahmen und Anfasser für die Softdesk Controls musst der Patch zu  FS#3470  nun wieder entfernt werden. Dieser sorgt dafür, dass alle Controls nach der Eingabe eines Werts für die Größe nun um 5 Pixel anwachsen.

Dupliziere ich ein Control durch Copy&Paste kann ich das neue Control nicht am Raster ausrichten, wenn in der X- und Y-Position ein Wert mit XXX,5 bzw. YYY,5 enthalten ist. Erst wenn ich das ,5 entferne, funktioniert die Ausrichtung am Raster.

Folglich sollte beim Copy&Paste vermieden werden, dass die Controls auf “halbe” Pixel eingefügt werden.