Bugtracker DMXControl 3

In Bezug zum Ticket  FS#3400  fiel mir auf und ein, dass ein entsprechendes Dropdown-Menü in den Properties der jeweiligen Nodes hilfreich wäre, wo ich die jeweiligen Cuelists, Master etc. auswählen kann, ohne die Properties verlassen zu müssen.

Beispiel für das Group Master Node: im Feld GroupMaster zeigt mir das Dropdown-Menü alle verwendbaren Group Master im Klartext an. Ist der gewünschte Group Master ausgewählt, ersetzt das Input Assignment den Namen durch die individuelle ID des Group Masters. Ähnlich würde folglich auch mit den Cuelists gearbeitet werden. Hier laufe ich ja Gefahr, dass beim Ändern des Namens der Cuelist die zugehörige Verbindung nicht mehr funktioniert, sollte keine “Übersetzung” in die ID erfolgen.

Da mit dieser Version weitere Master Einzug erhalten, wäre hier eine zentrale Verwaltung für alle Master im Project Explorer hilfreich. Insbesondere für die Speed- und Playback-Master fehlt eine Möglichkeit, diese aus dem Projekt zu löschen.

Daher schlage ich vor, im Projekt Explorer einen weiteren Eintrag mit dem Namen Master sowie mit den festen Unterordnern Group Master, Speed Master, Playback Master hinzuzufügen. In den Unterordnern sind dann folgende Optionen verfügbar / zulässig:

• Group Master: aktivieren und deaktivieren
• Speed Master / Playback Master: neu anlegen, löschen

Da man aktuell Gefahr läuft, sich sein Projekt bei Tippfehlern mit Speed Mastern und Playback Mastern unnötig zu fluten, habe ich diesem Wunsch für den Moment eine mittlere Priorität eingeräumt.

Ich habe an einem Projekt zuletzt viel im Input Assignment gearbeitet und wunderte mich dann, dass ein Button eines Softdesks nicht mehr funktionierte. Der Kernel sagte dann folgendes:

22:15:27 WARN  InputManager - Following Graphs are orphaned and will be removed:
S1-510-3121
S1-510-0901
S1-210-0901
S1-211-3121

Hierzu habe ich die Erwartungshalten, dass erstmal nicht grundsätzlich angenommen wird, dass verwaiste Graphen entfernt werden können. Vielmehr bedarf es hier einer Info, wie hiermit umgegangen werden soll.

Ob sich dieses Verhalten mit dem Projekt, an dem ich gerade arbeite, reproduzieren lässt, muss ich später klären und dann Logfiles und Projekt beifügen.

Ich habe in einem leeren Projekt das IA-Fenster geöffnet. Dann lege ich zwei Device Groups an und benenne diese zum Beispiel mit Group 1 und Group 2. Diese finalen Namen kommen nicht im IA-Fenster an, weil sich der Baum nicht aktualisiert.

Gleiches passiert (nicht), wenn ich die Group Master deaktiviere oder wieder aktiviere. Im Baum werden mir zum einen weiterhin beide Master angezeigt und zum anderen noch mit dem Standard-Namen “New Device Group Master”.

Dies ist der im Ticket  FS#4500  angekündigte weiterführende Fehlerbericht.

Da das kleine Tool durchaus öfters zum Einsatz kommt und ja sowohl für das DE- als auch für das Nodle-Interface funktioniert, dürfte es meiner Meinung nach hilfreich sein, wenn der Installer eine entsprechende Verknüpfung im Startmenü hinzufügt.

Ich habe das im Bild 1 dargestellte Connectionset (Graph 1) erstellt und die Nodes zwecks guter Übersicht manuell so platziert, dass es nur wenige Überschneidungen und vor allem keine “zurücklaufende” Verbindungen gibt. Führe ich nun den Autoposition-Befehl entsteht die im Bild 2 gezeigte Anordnung, wo zwar nur eine Verbindung zurück läuft, hierdurch die Übersichtlichkeit gefühlt zurückgeht.

Spannend wird es, wenn ich die Verbindung zwischen dem Rule of Three auf der linken Seite und dem Output Selector entferne. Beim anschließenden Ausführen des Autoposition-Befehl werden die Nodes wie in Bild 3 dargestellt angeordnet, was einer nochmals besseren Anordnung ist.

Im zweiten Beispiel (Bild 4 und 5) beinhalten beide Connectionsets die gleichen Nodes. Erstaunlicherweise ist die Anordnung mittels des Autoposition-Befehls nicht gleich. Das Connectionset in Bild 6 ist eine des Connectionset aus Bild 4 bzw. 5. Hier habe ich testweise einfach mal das Delay-Node hinzugefügt und dann den Autoposition-Befehl ausgeführt.

Folgende Punkte scheinen aus meiner Sicht die Anordnung der Nodes zu beeinflussen:

• Wann werden welche Inputs und Outputs hinzugefügt?
• In welcher Reihenfolge werden Verbindungen anlegt?
• Ist auf der linken Seite immer ein Input (Tastatur, Softdesk) vorhanden?

Als Folge dieser Faktoren wird das Connectionset teilweise sehr unübersichtlich und nicht nachvollziehbar sortiert.

Die Message-Box muss an folgenden Stellen von ihrem Verhalten her angepasst werden. Der in eckiger Klammer gesetzte Eintrag ist derjenige, der standardmäßig vorbelegt sein soll

• Ordner (im Project Explorer allgemein) löschen: Ja / [Nein] (statt nur OK)
• Gerät löschen: Ja / [Nein] (statt nur OK)
• Cuelist löschen: Ja / [Nein] (statt nur OK)
• Cuelist Group löschen: Ja / [Nein] (statt nur OK)
• Datei löschen: Ja / [Nein] (statt nur OK)
• Item List löschen: Ja / [Nein] (statt nur OK)
• Zuordnung zu Executor löschen: Ja / [Nein] (statt nur OK)
• Stage View löschen: Ja / [Nein] (statt nur OK)
• Connectionset löschen: Ja / [Nein] (statt nur OK)
• Bank im Input Assignment löschen: Ja / [Nein] (statt nur OK)

Wie zu erkennen, ist bei den meisten Abfragen, die ein Löschen initiieren, standardmäßig das Schema “OK oder Dialog schließen zum Abbrechen” hinterlegt statt dem besseren Verhalten (auch bezogen auf die Fragestellung) “Ja / Nein”.

Bei einigen Geräten unter anderem von Robe und Martin werden Goboshake, Goborotation und Goboindex in Abhängigkeit des zugeordneten Wertebereichs vom Gobokanal aktiviert. Dabei ist die Goboshake-Funktion meist immer als “Aufsatz” zur Goboindizierung oder Goborotation verfügbar. Diese Konstellation kann aktuell nicht vollständig und vor allem fehlerfrei abgebildet werden.

Um hier die DDFs an dieser Stelle zu vereinfachen, schlage ich folgenden Beispielcode vor (hier für den Robe Robin 600E Spot):

<step type="gobo" mindmx="4" maxdmx="7" val="Robe Robin 600e Spot Gobo 1 (Rad 1).png" caption="Gobo 1">
  <range handler="goboshake" mindmx="4" maxdmx="7" minval="0.0" maxval="0" />
  <step for="goboindex" mindmx="4" maxdmx="7">
    <range handler="goboshake" mindmx="60" maxdmx="69" minval="0.4" maxval="10" />
  </step>
  <step for="goborotation" mindmx="32" maxdmx="35">
    <range handler="goboshake" mindmx="130" maxdmx="141" minval="0.4" maxval="10" />
  </step>
</step>

Dabei wird innerhalb des step für goboindex bzw. goborotation entschieden, in welchem Wertebereich der Goboshake “aufgeschaltet” wird.

Alle anderen Definitionen sind von diesem Vorschlag erst einmal unberührt.

Lade ich ein vorhandenes Projekt, sind die Verbindungen im Input Assignment trotz aktiver Bank “On Hold” und warten quasi auf einen Initialisierungsimpuls. Aufgefallen ist mir dies in folgender Konstellation:

Ich habe zwei verschiedene Verbindungen. Die Schnittmenge beider Verbindung ist der Speedmaster 1. In der Verbindung 1 (Beat Tastatur) triggere ich den Speedmaster 1 über die Tastatur. In der Verbindung 2 (Beat Softdesk) triggere ich den gleichen Speedmaster über den Button des Softdesks und nutze diese Verbindung auch, um mir den aktuellen BPM-Wert im Softdesk anzuzeigen.

Triggere ich den Speedmaster 1 über die Tastatur, kommen die Werte nach dem Laden des Projekts zwar beim Speedmaster an. Das Feedback ans Softdesk über die Verbindung 2 erhalte ich erst, wenn ich dieser Verbindung einen einmaligen Impuls gebe, entweder

• über einen verfügbaren Input (in diesem Fall der Button, der auch den BPM-Wert anzeigt) oder
• durch Deaktivieren und Aktivieren der Verbindung 2 (Beat Softdesk) oder
• in diesem Fall durch Änderung der Einstellung des Speedmaster 1 in der Verbindung selbst.

Um den besagten Aktualisierungs- bzw. Initialisierungsimpuls zu generieren, reicht es nicht, die komplette Bank zu deaktivieren und wieder zu aktivieren. Dass dieser fehlt, kann man auch daran erkennen, dass an den Nodes kleine Statuswerte angezeigt werden.

Zum Nachstellen des Problems habe ich ein Beispielprojekt beigefügt. Die oben genannten Verbindungen sind in den ersten beiden Bänken im Input Assignment zu finden. Hierzu am besten das letzte Fensterlayout laden.

Möchte ich über die DDFLib ein DDF suchen und öffne hierzu das Fenster, erscheint die beigefügte Fehlermeldung und im GUI-Log der folgende Eintrag.

2020-03-25 18:18:25,124 [Log-Thread] INFO  Lumos.GUI.Windows.DDFLibSearchForm - Exception when accessing DDFLib Webservice: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
System.Net.WebException: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
   bei DDFAPIClient.DDFClient.CheckResponse(IRestResponse response, HttpStatusCode expectedHttpStatus)
   bei DDFAPIClient.DDFClient.GetDataList[T](Boolean fromCache, Dictionary`2 filters)
   bei Lumos.GUI.Windows.DDFLibSearchForm.<>c__DisplayClass4_0.<.ctor>b__0() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\NewDevice\DDFLib\DDFLibSearchForm.cs:Zeile 49.
   bei System.Threading.Tasks.Task`1.InnerInvoke()
   bei System.Threading.Tasks.Task.Execute()

Entsprechenden Aussagen im Forum zu Folge, scheint dieser Fehler nicht unbedingt ein Fehler in DMXControl 3.2.1 selbst zu sein, denn auch in DMXControl 3.2.0 tritt dieser Fehler mittlerweile auf.

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.

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

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

Ich möchte in einer Cuelist mit mehreren Cues eine der Cues einige Positionen nach oben oder nach unten verschieben. Dies ist aber mit den Up- / Down-Buttons nur bedingt möglich. Ich kann aktuell eine Cue immer nur eine Position nach oben oder nach unten verschieben. Mehrfaches betätigen der Buttons funktioniert an dieser Stelle nicht.

Der aktuelle Workaround besteht darin, dass ich gewissermaßen “invertiert” verschiebe. Konkret heißt das für den Fall, wo ich die Cue 1 zum Beispiel von Position 1 auf Position 5 verschieben möchte, dass ich die Cues 2 bis 5 markierte und eine Position nach oben verschiebe.

Zur Reproduktion kann ein beliebiges Projekt verwendet werden, das eine Cuelist mit mehreren Cues enthält.

Mir ist sehr wohl bewusst, dass ich mit diesem Ticket ein Fass aufmache.

Ich werfe aber trotzdem den Wunsch in den Raum, die Unterteilung zwischen Non-Detect und Auto-Detect-Interfaces (wieder) aufheben.

Es mag zwar sein, dass wir so den Stellenwert der “besseren” Intefaces pushen, allerdings würde ich auf Grund der doch regelmäßigen Nachfrage “ich finde das Interface … in der Liste nicht” die Idee dahinter als nicht (mehr) praktikabel ansehen. Sie führte doch immer wie der zu einer solchen Nachfrage, weil die Nutzer diesen Unterschied einfach nicht einordnen können. Daher sollte es aus Nutzersicht aus meiner Sicht egal sein, wie sich das Interface verhält - ob es eine Seriennummer übermittelt oder nicht.

Ich bitte daher darum, sofern nicht vorzeitig durch eine erneute Bewertung dieses Punkts eine Lösung gefunden wird, dass dieser Punkt spätestens beim nächsten QRM diskutiert wird.

In vielen Fällen liegen auf einem DMX-Kanal mehrere individuelle Funktionen mit ihren eigenen Regelbereichen, hier zum Beispiel beim GLP YPOC 575 PRO:

<raw dmxchannel="13" name="Special">
  <step caption="Open" mindmx="0" maxdmx="15" />
  <range type="Goboshake 10°" mindmx="16" maxdmx="31" minval="3.5" maxval="60" />
  <range type="Goboshake 20°" mindmx="32" maxdmx="47" minval="3.5" maxval="60" />
  <range type="Goboshake 30°" mindmx="48" maxdmx="63" minval="3.5" maxval="60" />
  <range type="Color Chaser 1" mindmx="64" maxdmx="79" minval="3.5" maxval="60" />
  <range type="Color Chaser 2" mindmx="80" maxdmx="95" minval="3.5" maxval="60" />
</raw>

Alle Funktionen sind Funktionen wie beispielsweise auch diverse Automatik-Programme bei LED-Scheinwerfern, die die HAL nicht direkt unterstützt und deswegen über raw-Funktionen abgebildet werden müssen. Hier wäre mein Vorschlag eine Möglichkeit für die raw-Funktion zu schaffen, die beispielsweise ähnlich zur Implementierung der unterschiedlichen Strobe-Mobi arbeitet: man erhält im Device Control ein Dropdown-Menü zum Auswählen der Gerätefunktion und dazu einen Regler zum Auswählen der Geschwindigkeit o. ä. Die Implementierung könnte vielleicht etwas abgewandelt zum oben aufgeführten Beispiel erfolgen.

Ich habe in einem Projekt drei meiner vier angelegten Executoren mit Cuelists verknüpft. Im Baum des Project Explorers wird aber nun ein anderes Icon verwendet, welches den Status “Cuelist verknüpft” darstellt als in der Tabellenübersicht. Im Anhang befindet sich ein entsprechender Screenshot.

Folgender Fehler ist mir in den angehängten Logfiles unter die Finger gekommen.

2018-12-28 21:19:47,525 [Main-Process-Chain] ERROR org.dmxc.lumos.Kernel.Devices.DeviceBeam - Unknown Exception when invoking the HAL: Value is not between Min / Max Value [5,0,1]: 5
org.dmxc.lumos.Kernel.Exceptions.ValueOutOfRangeException: Value is not between Min / Max Value [5,0,1]: 5
   bei org.dmxc.lumos.Kernel.HAL.Handler.DMXRangeWithValueRange.getRAWDMXValue(Object ovalue) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Values\DMXRangeWithValueRange.cs:Zeile 199.
   bei org.dmxc.lumos.Kernel.HAL.Handler.DMXRangeWithValueRange.getValue(Object value, EValueOptions options) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Values\DMXRangeWithValueRange.cs:Zeile 187.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractValue.getValue(Object value, IList`1 nestedHandlerNames, EValueOptions options) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Values\AbstractValue.cs:Zeile 288.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractRangesHandlerNode.handlePropValue(Double newVal, HALHandleContext ctx, String[] types) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractRangesHandlerNode.cs:Zeile 542.
   bei org.dmxc.lumos.Kernel.HAL.Handler.RawDMXHandlerNode.handleRawValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Generic\RawDMXHandlerNode.cs:Zeile 57.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractHandlerNode.handleValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractHandlerNode.cs:Zeile 454.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.handlePropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 336.
   bei org.dmxc.lumos.Kernel.Devices.DeviceBeam.pushPropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Devices\DeviceBeam.cs:Zeile 222.

Beim durchsehen der Logs ist mit folgender Fehler aufgefallen:

2018-06-08 21:25:42,859 [47] ERROR org.dmxc.lumos.Kernel.Devices.DeviceBeam - Unknown Exception when invoking the HAL: h (Hue) has to be between 0 and 360
Parametername: h
Der tatsächliche Wert war -1.
System.ArgumentOutOfRangeException: h (Hue) has to be between 0 and 360
Parametername: h
Der tatsächliche Wert war -1.
   bei org.dmxc.lumos.Kernel.HAL.Handler.Color.CustomColorLogic.calculate(Double h, Double s, Double v) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Color\CustomColorLogic.cs:Zeile 190.
   bei org.dmxc.lumos.Kernel.HAL.Handler.Matrix.ColorBridgeHandlerNode.handleColorAndDimmerValue(LumosColor lc, Double dimmer, HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Color\ColorBridgeHandlerNode.cs:Zeile 285.
   bei org.dmxc.lumos.Kernel.HAL.Handler.Matrix.ColorBridgeHandlerNode.handleColorValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Color\ColorBridgeHandlerNode.cs:Zeile 222.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractHandlerNode.handleValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractHandlerNode.cs:Zeile 441.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.handlePropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 336.
   bei org.dmxc.lumos.Kernel.Devices.DeviceBeam.pushPropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Devices\DeviceBeam.cs:Zeile 219.

Nach dem Starten von DMXControl 3 Beta 3 und dem Hinzufügen von einer größeren Anzahl von Geräten zu einem neuen, leeren Projekt, ist die GUI mit folgendem Vermerk im Log abgestürzt.

2018-06-14 17:25:18,885 [ConnectionManager-MessageDispatcher] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Die Auflistung wurde geändert. Der Enumerationsvorgang kann möglicherweise nicht ausgeführt werden.
System.InvalidOperationException: Die Auflistung wurde geändert. Der Enumerationsvorgang kann möglicherweise nicht ausgeführt werden.
   bei System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
   bei System.Collections.Generic.Dictionary`2.Enumerator.MoveNext()
   bei System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   bei System.Linq.Enumerable.<SelectManyIterator>d__16`2.MoveNext()
   bei System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
   bei Lumos.GUI.ChannelOverview.PatchMatrixControl.CreateOverlayRectangles(Nullable`1 previewIndex, Int32 cellWidth, Int32 cellHeight, Rectangle clientInnerRectangle, MatrixItemOverlay overlay) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\PatchMatrixControl.cs:Zeile 635.
   bei Lumos.GUI.ChannelOverview.PatchMatrixControl.CalculateItemOverlayRectangles() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\PatchMatrixControl.cs:Zeile 553.
   bei Lumos.GUI.ChannelOverview.PatchMatrixControl.OnOverlayPropertyChanged(Object sender, PropertyChangedEventArgs e) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\PatchMatrixControl.cs:Zeile 693.
   bei Lumos.GUI.ChannelOverview.MatrixItemList`1.OnCellPropertyChanged(Object cell, PropertyChangedEventArgs e) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\MatrixItemList.cs:Zeile 213.
   bei Lumos.GUI.ChannelOverview.MatrixItemList`1.OnMatrixItemPropertyChanged(Object sender, PropertyChangedEventArgs e) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\MatrixItemList.cs:Zeile 225.
   bei Lumos.GUI.ChannelOverview.Lib.PropertyNotificationObject.OnPropertyChanged(String propertyName) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\Lib\PropertyNotificationObject.cs:Zeile 118.
   bei Lumos.GUI.ChannelOverview.Lib.PropertyNotificationObject.OnPropertyChanged[T](Expression`1 propertyExpression) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\Lib\PropertyNotificationObject.cs:Zeile 108.
   bei Lumos.GUI.ChannelOverview.Lib.PropertyNotificationObject.ChangeProperty[TValue](Expression`1 property, TValue& originValue, TValue newValue, Action propertyChanged, Action propertyChanging) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\Lib\PropertyNotificationObject.cs:Zeile 97.
   bei Lumos.GUI.ChannelOverview.DMX.DmxDeviceItemOverlay.set_DeviceName(String value) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\DMX\DmxDeviceItemOverlay.cs:Zeile 47.
   bei Lumos.GUI.Windows.DmxOutputPatching.<>c__DisplayClass55_0.<device_NameChanged>b__0(DmxDeviceItemOverlay c) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Windows\dmxOutput\DmxOutputPatching.cs:Zeile 865.
   bei LumosLIB.Tools.LumosTools.ForEach[T](IEnumerable`1 source, Action`1 action) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Tools\LumosTools.cs:Zeile 1017.
   bei Lumos.GUI.Windows.DmxOutputPatching.device_NameChanged(Object sender, String newValue) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Windows\dmxOutput\DmxOutputPatching.cs:Zeile 865.
   bei Lumos.GUI.Facade.FacadeChangedEvent`1.Invoke(Object sender, T newValue)
   bei Lumos.GUI.Facade.Devices.DeviceFacade.OnNameChanged(String name) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Facade\Devices\DeviceFacade.cs:Zeile 745.
   bei Lumos.GUI.Facade.Devices.DeviceFacade.OnPropertyChangedMessage(PropertyChangedMessage m) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Facade\Devices\DeviceFacade.cs:Zeile 705.
   bei Lumos.GUI.Facade.AbstractFacade`1.onMessage(IMessage message) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Facade\AbstractFacade.cs:Zeile 94.
   bei Lumos.GUI.Connection.ConnectionManager.onMessage(IMessage message) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Connection\ConnectionManager.cs:Zeile 815.
   bei Lumos.GUI.Connection.ConnectionManager.messageDispatcherRun() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Connection\ConnectionManager.cs:Zeile 878.
   bei System.Threading.ThreadHelper.ThreadStart_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.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   bei System.Threading.ThreadHelper.ThreadStart()

Die Logs von Kernel und GUI befinden sich im Anhang.

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.

Übersteigt das Input Assignment eine bistimmte Anzahl von Verknüpfungen, lässt sich dieses in Folge der oben genannten Fehlermeldung in der GUI nicht mehr bearbeiten. Erst wenn die Anzahl durch Löschen von verknüpften Buttons oder von gesteuerten Cuelists unter die “Grenze” reduziert wurde, ist wieder eine Bearbeitung möglich. Die zugehörigen Logs sind im Anhang beigefügt.

Werden die Angaben im Informations-Teil des DDFs wie folgt formatiert, zerschießen diese das Add Device Dialog entsprechend des beigefügten Screenshot.

<information>
  <ddf-library-id>
    
    </ddf-library-id>
  <model>
        Super Winner HID
    </model>
  <vendor>
         JB Systems
    </vendor>
  <author>
       cooltour
    </author>
  <mode>
       5CH
    </mode>
  <electrical>
    <static>250</static>
  </electrical>
  <comment>
    </comment>
</information>

Da wie zu sehen das DDF auch nicht unter der Gerätebezeichnung oder dem Hersteller erscheinen, sollte über eine der beiden folgenden Szenarien zum Abfangen dieses Problems nachgedacht werden:

• Im Informations-Teil der DDFs dürfen die Tag für model, vendor etc. nur in einer Zeile liegen. Falls nicht, wird das DDF als ungültig gekennzeichnet.
• Im Fenster selbst wird eine entsprechende Robustheit eingebaut, dass solche Dinge zu keinem Problem bei der Anzeige mehr führen.

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.

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.

In dem Graphen mit dem Namen “Input Selctor” des beigefügten Projekts möchte ich verschiedene Geräte einer Gerätegruppe über die Tastatur auswählen können.

• 1: Auswahl QWO Group
• 2: Auswahl AX5 Group
• + (Nummernblock): vor
• - (Nummernblock): zurück
• S: Gerät auswählen

Am Ende des Math-Nodes übergebe ich eigentlich die Werte 1 oder 2, damit ich im Input Selector zwischen den über die Counter-Nodes erzeugen Device-IDs umschalten kann. Leider schlägt das Umschalten fehl und ich erhalte am Ausgang des Input Selectors immer nur den Wert des Eingang 1. Oder gibt es hier eine Wert-Überschneidung, weil im Input Selector parallel auch ein true oder false bzw. das Äquivalent 0 oder 1 übertragen wird.

In Vorbereitung zum Livestream habe ich den Build 645 der 3.3 installiert. Danach ließ sich der Umbra (mal wieder) nicht starten.

Der Installer hat fand dabei nicht gewünschte Version der .net Desktop Runtime und führte das Setup erneut aus. Nachfolgend der betreffende Auszug aus dem Log des Installers:

Checking if .NET 4.8 is installed...
.NET 4.8 found!
Checking if ASP.NET Core 6 (32bit) is installed...
ASP.NET Core 6 (x32) found!
Checking if ASP.NET Core 6 (64bit) is installed...
ASP.NET Core 6 (x64) found!
Checking if .NET 6 Desktop Runtime (x32) is installed...
Checking if .NET 6 Desktop Runtime (x64) is installed...
.NET 6 Desktop Runtime (x64) found!
Checking if Visual C++ 2015 Redistributable is installed...
Visual C++ 2015 Redistributable found!
Checking if XNA 4.0 is installed...
XNA 4.0 found!
Checking if Windows Installer 3.1 is installed...
Windows Installer 3.1 found!
Verzeichnis wird erstellt: C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0
Lade .NET Desktop (x86)...
Installiere .NET Desktop (x86)...
Datei wird gelöscht: C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\dotnetdesktop-current-windows-runtime-bundle-installer.exe
Lade .NET Desktop (x64)...
Installiere .NET Desktop (x64)...
Datei wird gelöscht: C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\dotnetdesktop-current-windows-runtime-bundle-installer.exe

Der Start des Umbras schlug aber dann entsprechend fehl. Die Ereignisanzeige von Windows gab dabei folgende Fehlermeldung:

Description: A .NET application failed.
Application: Umbra.exe
Path: C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Umbra\Umbra.exe
Message: You must install or update .NET to run this application.

App: C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Umbra\Umbra.exe
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '6.0.23' (x64)
.NET location: C:\Program Files\dotnet\

The following frameworks were found:
  6.0.22 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=6.0.23&arch=x64&rid=win10-x64

Zum Zeitpunkt dieser Fehlermeldung war auf dem PC die Version 6.0.22 installiert. Über das Windows-Update war die Version 6.0.23 in der Pipeline. Erst nachdem dieses Update eingespielt wurde, ließ sich der Umbra wieder starten.

Irgendwie sollte versucht werden, das Problem dahingehend abzufangen, dass mal als Nutzer einen Hinweis erhält - und sei es eben nur Hinweis, der sich eben nicht nur in der Ereignisanzeige versteckt.

Fehlermeldung bei fehlenden Schreibrechte auf das Projekt-Zip-Archiv:

• Bild 1, englische Oberfläche: englischer und deutscher Text vermischt
• Bild 2, deutsche Oberfläche: richtige, ausschließlich deutsche Texte

Die verschiedenen Optionen für die Einstellungen der Stage View sind noch nicht übersetzt.

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

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

Ich habe eine Colorlist angelegt, mit der ich ursprünglich die “Breite” des Color Scroll-Effekts beeinflussen wollte. Hier ist mir aufgefallen, dass hier aber ein Parameter im Effekt fehlt bzw. hilfreich wäre - das zugehörige Ticket läuft unter der Nummer FS#3861.

Wähle ich in der Colorlist eine der gleich in diesem Fall drei Rots (siehe Bild 1) aus und möchte es verschieben, wählt die Colorlist stattdessen alle drei an und nach mehreren Klicks auf Up erhalte ich das im Bild 2 gezeigte Ergebnis - obwohl ich die beiden anderen Rots gar nicht angefasst habe.

In den Logfiles gibt es zu dieser Aktion keinerlei Einträge, weswegen ist keine beifügt habe.

Ich habe mir eine Cuelist mit fünf Cues gebaut, wobei das Tracking standardmäßig aktiv ist:

1. Cue 1 - blue > red
2. Cue 2 - static white
3. Cue 3 - green > blue
4. Cue 4 - static red
5. Cue 5 - static violett

Mit dieser Cuelist führe ich folgende Schritte aus:

• Ich lasse die manuell via Go getriggert per Executor bis zur 5. Cue durchlaufen.
• Ich drücke mehrfach den Pause- / Back-Button. Die Anzeige unter “Current cue” springt ab dem zweiten Klick mit jedem weiteren Klick Cue für Cue zurück - und zwar in der Reihenfolge, wie die Cues in der zugeordneten Cuelist angeordnet sind. Den Button drücke ich so lange, bis unter “Current cue” die “Cue 2” aufgeführt wird. Die Zeile ist grau hinterlegt.
• Ich klicken auf Go. Der blaue Balken beginnt, sich von links aus aufzubauen. Das gleiche Verhalten zeigt die Cuelist selbst auch.

Mit dem Klick auf Go führt die Cuelist aber nicht wie vom Executor suggeriert die “Cue 2” aus, sondern die der “Cue 5” vorhergehende “Cue 4”. Erst wenn ich das Tracking deaktiviere wird auch die “Cue 2” tatsächlich ausgegeben.

An dieser Stelle sollte ich aus meiner Sicht die Cuelist nicht anders verhalten, als wenn ich die “Cue 2” in der Cuelist selbst manuell per “Load” vorauswähle und dann mit dem Klick auf Go (egal ob Cuelist oder per Executor) aufrufe. Sprich: in beiden Fällen (egal ob Tracking aktiv oder nicht) sollte die “Cue 2” ausgeführt werden, so wie es mir auch in der Anzeige im Executor oder in den Progress-Balken der Cuelist suggeriert wird.

Um das unterschiedliche Verhalten darzustellen, enthält das beigefügte Projekt die Cuelist zwei Mal - einmal mit aktiven und einmal mit deaktiviertem Tracking. Beide Cuuelists sind direkt per Executor aufrufbar, wenn das letzte Fensterlayout geladen wird.

Ich habe die Tooltips in den Einstellungen deaktiviert. Gebe ich nun im Device Control einen nicht zulässigen Wert ein, werde ich hier weiterhin nicht darauf hingewiesen. Die GUI reagiert dabei so lange nicht, bis ich die Eingabe über Esc abbreche.

Der Tooltip für den Button “Mitte der Punkte für Schieberegler” fällt größer aus als die anderen Tooltip im Position Control.

Im Masterfenster werden die Titel / Displays nur noch in Mindestbreite angezeigt und füllen nicht mehr die Breite für einen Master aus.

Ich habe ein Projekt gespeichert, wo der Timecode-Player geöffnet ist. Lade ich das Projekt und bestätige, dass das letzte Fensterlayout geladen werden soll, bleibt der Inhalt des Timecode-Players leer.

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.

Ich habe das Projekt aus  FS#5180  weitergebaut und in eine Timecode Show überführt.

Führe ich die Timecode Show erstmalig nach dem Laden des Projekts aus, läuft diese bis zum Ende der Release Time wie erwartet ab. In dem Moment, wo der Marker wieder auf 0 springt (weil die sich Cuelist beendet hat), wird der Inhalt der Cue 2 wiedergegeben. Führe ich dann die Timecode Show erneut aus, wird die Cue 1 vollständig ignoriert und nur der Release der Cuelist ausgeführt.

Die Erwartungshaltung ist, dass nach dem automatischen Beenden der Cuelist (Release when last cue ends) und dem Zurücksetzen des Markers die Cuelist wie nach dem Laden des Projekts (oder dem manuellen Stoppen) aus ist und ich die Timecode Show vollständig wiedergeben kann.

Hätte ich als Release Mode “manual only” gewählt, dann wäre das aktuelle Verhalten in Ordnung.

Der Eintrag “GO” im gezeigten Menü besitzt nicht die Standard-Textgröße wie die anderen Einträge in diesem Menü wo “Go Back” oder “Go Next”.

Im Installations-Assistent wird beim ersten Schritt der Text der Überschrift verdeckt, da nun auch die Build-Nummer mit in die Versionsnummer aufgenommen wurde.

Hier wäre die Frage, welchen Mehrwert die Buildnummer zumindest in den Texten darstellt.

Fehlerbeschreibung siehe oben

Bei den Properties der Intelligent Cuelist Group Settings werden verschiedene Texte verdeckt, sodass diese entweder abgeschnitten oder auf zwei Zeilen umgebrochen werden und in beiden Fällen trotz verfügbarer Fensterbreite nicht komplett zu lesen sind.

Momentan taucht ja immer die Meldung “Device” not set in properties, wenn eben bei einem entsprechenden Interface zum Beispiel der COM-Port noch nicht gewählt ist. Möglicherweise fehlt aber in dieser Meldung eine Aufforderung, eben genau dies zu tun, sodass die Meldung eher nur als Infomeldung abgetan wird.

Um eben der Meldung mit auf den Weg zu geben, dass eine User-Interaktion erwartet wird, wäre hier ein alternativer Vorschlag zum Beispiel “Please select the “device” in advanced interface settings.”

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.

Nach dem Anlegen eines neuen Projekts erscheint die Abfrage, ob das neu angelegte Projekt auch direkt geladen werden soll. Allerdings fehlt in diesem Fenster der entsprechende Text, wie im beigefügten Screenshot zu sehen. Das Problem besteht sowohl in der englischen als auch in der deutschen GUI.