Bugtracker DMXControl 3

Ich habe folgende Definition erstellt:

<cmy>
  <cyan dmxchannel="3"/>
  <magenta dmxchannel="4"/>
  <yellow dmxchannel="5"/>
</cmy>
<colorwheel dmxchannel="7">
  <step type="enableRGB" mindmx="0" maxdmx="0"/>
  <step type="color" val="L007" mindmx="1" maxdmx="1"/>
  <step type="color" val="L103" mindmx="2" maxdmx="2"/>
  ...
  <wheelrotation>
    <range type="cw" mindmx="201" maxdmx="180" minval="0.1" maxval="8"/>
    <step type="stop" mindmx="202" maxdmx="207"/>
    <range type="ccw" mindmx="208" maxdmx="229" minval="0.1" maxval="8"/>
  </wheelrotation>
  <random>
    <step type="fast" mindmx="235" maxdmx="239"/>
    <step type="medium" mindmx="240" maxdmx="244"/>
    <step type="slow" mindmx="245" maxdmx="249"/>
  </random>
</colorwheel>

Die Umschaltung vom virtuellen Farbrad zurück zu CMY funktioniert aber so nicht, weil der Wert “enableRGB” die CMY-Mischung nicht berücksichtigt. Daher wäre meine Erwartungshaltung:

• entweder wird hier eine entsprechende Unterstützung für virtuelle Farbräder in Kombination mit CMY und HSV ergänzt
• für die anderen Farbmischungen werden eigene Werte ergänzt

Geräte, die als Matrix definiert sind, können über den Blackout nicht dunkel geschaltet werden. Dabei ist es egal, ob ein Matrix-Effekt angewendet wurde oder ob Dimmer und Farbe für die gesamte Matrix gesetzt wurden.

Wenn ich mit dem Compare-Node Werte vergleiche, muss ich Nachgang noch weitere Nodes einfügen, wenn mit dem zu prüfenden Wert weiterarbeiten möchte. Üblicherweise ist das ein Input Selector.

Um die Connectionsets zu vereinfachen, schlage ich vor, den Compare-Node um einen zusätzlichen Eingang mit dem Namen “Val” zu erweitern. An diesen Eingang schließe ich einen beliebigen Wert an, mit ich im Anschluss weiterarbeiten möchte. Dieser muss aber nicht zwingend der Wert sein, auf den ich die Prüfung laufen lasse und kann daher auch ein String sein. Deswegen sehe ich aktuell keinen Sinn darin, ein vergleichbares Verhalten über eine Einstellung festzulegen.

Nutze ich den Val-Eingang, wird am Ausgang statt True / False bei Erfüllung der Prüfbedingung der am Val-Eingang anliegende Wert ausgegeben. Ggf. ist zu überlegen, ob das Node eine Einstellung erhält, bei der festlegt wird, welcher Wert bei Nichterfüllung der Prüfbedingung anliegen soll.

Ich füge ein Gerät mit einer Auflösung für die Farbmischung mit 16 bit einem leeren Projekt hinzu wie zum Beispiel dem Robe LEDBeam 150 im Mode 1.

Bewege ich den Punkt mit der Maus und schaue mir die Werte in der Kanalübersicht an, sehe ich, dass die DMX-Werte sowohl für 8 bit als auch 16 bit parallel ein- und ausfaden - der DMX-Kanal für 16 bit verhält sich wie der DMX-Kanal für 8 bit. Gleiches passiert auch, wenn ich im Device Control die Regler für RGB, CMY oder HSV direkt im Dropdown unter Color nutze.

Benutze ich die Regler für die einzelnen Farben, verhält sich die DMX-Ausgabe so wie ich es für 16 bit erwarte. Gleiches gilt auch für das Position Control oder den Regler für Dimmer im Intensity Panel. Daher wäre es gut, wenn der Color Picker im Color Panel sich gleichermaßen verhalten und am Ende die DMX-Werte für die Fine-Channel nach dem bekannten Muster ausgegeben werden.

Mit dem beigefügten Projekt habe ich eine einfache Ansteuerung der Position von in der Stage View ausgewählten Geräten über meinen MIDI-Controller (Traktor F1) realisiert. Bei schnellen, ruckartigen Werteänderungen stockt GUI bis hin zum Einfrieren. Das Stocken betrifft im konkreten Fall unter anderem das Position Control und das Device Control. Hier liegt bei mir die Vermutung nahe, dass bei einer meiner letzten Nutzung im größeren Umfeld deswegen die GUI auch komplett abgestürzt ist. Der gezeigte Auszug aus den beigefügten Logs entstammt der ersten GUI-Session.

2023-09-15 18:44:42,258 [74] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Facade.DeviceProperties.DevicePropertyFacade.<OnProgrammerValueChanged>d__71.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\DeviceProperties\DevicePropertyFacade.cs:Zeile 516.
--- 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()

Nutze ich im gleichen Connectionset statt die Fader / Encoder meines MIDI-Controllers die beiden Slider des ebenfalls enthaltenen Softdesks, werden alle Werteänderungen sauber umgesetzt. Sowohl langsame als auch schlagartige Werteänderungen kommen nahezu verzögerungsfrei im Position Control und im Device Control an.

Zur besseren Übersichtlichkeit und möglicherweise auch schnelleren Änderungsmöglichkeit sollten folgende Objekt-Nummern im Project Explorer als zusätzliche Spalte anzeigt werden:

• Cuelist Group Number
• Executor Number
• Executor Page Number

Bei mir fehlen in den General Settings die folgenden Einstellungen für das Project Autosave / Project Administration:

• Keep files per project
• Maximum MB per project
• Warning MB in project store

Ich kann aktuell nicht nachvollziehen, seit wann diese Einstellungen nicht mehr verfügbar sind. Um die Bezeichnungen der verschiedenen Optionen musste ich im Livestream zu gRPC nachschauen, weil wir dort die Einstellungen gezeigt haben.

In der Konfigurations-Datei für den Kernel sind aber noch alle Optionen vorhanden:

<TreeItem Name="PROJECT.AUTO_SAVE_ENABLED">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="False" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_INTERVAL">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="10" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_SUSPEND_ON_ACTIVITY">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="False" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_KEEP_FILES">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="50" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_MAX_MB">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="250" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_TOTAL_MAX_MB">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="1000" />
    </TreeItem>

Im Anhang habe ich die Logs sowie einen Screenshot beigefügt, der zeigt, dass die Einstellungen fehlen.

Ich habe verschiedene Einstellungen für den AudioAnalzyer gesetzt und das Projekt gespeichert. Der Fokus liegt dabei auf den Einstellungen, die über die Dropdown-Menüs ausgewählt werden. Diese werden beim erneuten Laden nicht übernommen, sondern nur die Standartwerte gesetzt. Dazu zählen:

• Number of Bands für Spectrum
• Algorithm für Beat Detection
• Audio Device

In dem beigefügten Projekt sind die oben genannten Einträge entsprechend verändert.

Können sich zwei PCs im Netzwerk auf Grund unterschiedlicher IP-Adressen nicht erreichen, laufen in GUI und im Kernel stetig die folgenden Log-Einträge auf:

GUI

2025-08-17 00:46:48,187 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:48,188 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:46:51,607 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:46:51,608 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384411.606000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384411.606000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:46:53,640 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:53,641 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:46:55,818 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="Unavailable", Detail="failed to connect to all addresses", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384415.816000000","description":"Failed to pick subchannel","file":"..\..\..\src\core\ext\filters\client_channel\client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1755384415.816000000","description":"failed to connect to all addresses","file":"..\..\..\src\core\lib\transport\error_utils.cc","file_line":165,"grpc_status":14}]}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384415.816000000","description":"Failed to pick subchannel","file":"..\..\..\src\core\ext\filters\client_channel\client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1755384415.816000000","description":"failed to connect to all addresses","file":"..\..\..\src\core\lib\transport\error_utils.cc","file_line":165,"grpc_status":14}]}
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:46:57,043 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:46:59,091 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:59,092 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:47:02,485 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:47:02,487 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384422.486000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384422.486000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:47:04,531 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:47:04,532 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:47:06,912 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 192.168.21.32
2025-08-17 00:47:07,940 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384427.939000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384427.939000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.

Kernel

2025-08-17 16:51:24,632 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:line 694
2025-08-17 16:51:26,652 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 16:51:26,653 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 16:51:29,857 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:line 694
2025-08-17 16:51:31,895 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 16:51:31,896 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 16:51:35,299 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:line 694

Die Fehlermeldung lässt sich in folgender Konstellation reproduzieren, wenn beide an einem unmanaged Switch hängen und bei beiden Laptops zwei vollständige Sessions mit DMXControl 3.3.1 laufen:

• LICHT-LAPTOP-1: IP-Adresse 169.254.1.19 durch Windows vergeben, da Netzwerkprofil (noch) auf DHCP
• LICHT-LAPTOP-2: IP-Adresse 192.168.21.32, statisch vergeben

Ich habe an dieser Stelle die Erwartungshaltung, dass der Aufbau einer Verbindung in einem solchen Fall nach einer bestimmten Anzahl von Versuchen abgebrochen und ich als Nutzer darüber informiert werde - auch wenn der Versuch des Verbindungsaufbaus “nur” alle 5 Sekunden erfolgt. Der Mehrwert einer solchen Information liegt auch darin, dass mir aufgefallen wäre, dass die IP-Adresse des LICHT-LAPTOP-1 nicht passt und ich daraufhin nicht selbst vergeblich versuche, die GUI am LICHT-LAPTOP-2 anzumelden.

Ich habe in dem beigefügten Projekt eine einfache Cuelist gebaut, in der ich zwei Color Master in Kombination mit verschiedenen Fanning-Operatoren nutze.

Wechsle ich nur innerhalb des Fannig-Operators die Reihenfolge der Color Master, so wird die Farbe immer direkt übergefadet. Ändert sich aber mit der nachfolgenden Cue der Fanning-Operator, springt die Farbe des entsprechenden Geräts jedoch grundsätzlich hart auf weiß, um dann in die Zielfarbe einzufaden. Die Reihenfolge der Color Master ist dabei unerheblich.

Dies ist sowohl in der Stage View als auch in der Channel Overview zu sehen.

Ich habe nach der Beschaffung von Geräten mit einem RGBL-Chip (rot, grün, blau und lime) festgestellt, dass das Konzept für die Ansteuerung von RGB+LEDs unvollständig ist - und zwar wenn es um das Mischen von Weiß geht.

Bei dem mir vorliegenden Gerät wird zum Beispiel ein “gutes” Weiß statt über RGB eben unter Zuhilfenahme der Lime-LED gemischt wird. Rot grün und blau sind dabei nicht auf Maximum. Nur durch eine solche Mischung kann ich softwareseitig den angegebenen Farbwiedergabeindex erreichen.

Die Optimalwerte können für ein “gutes” Weiß aber von Gerät zu Gerät abweichen. Daher ist es über die HAL zur Zeit in DMXControl 3 nicht möglich, für unterschiedliche Geräte nahezu die gleiche Farbe zu generieren.

Aus diesem Grund sollte die HAL und ggf. auch die DDFs eine Möglichkeit erhalten, die Farbausgabe dahingehend zu kalibrieren, dass man für die Farben optimale Werte erreicht.

Im Photo- und Videobereich wird dies zum Beispiel über so genannte Farbkarten realisiert, auf der eine gewisse Anzahl an definierten Farben enthalten sind. Der Videosoftware sind dabei die Farben bekannt. So kann das Photo-Videomaterial softwareseitig korrigiert und angeglichen werden. In dem folgenden Video wird dieser Punkt auch nochmal kurz vorgestellt: https://www.youtube.com/watch?v=M934d_P89pQ

Ich habe an einem Projekt Änderungen vorgenommen, die auch vom DirtyFlag registriert wurden. Schließe ich dieses geänderte Projekt nun, ohne die Änderungen manuell gespeichert zu haben, sind meine Änderungen weg.

Daher sollte (wie bei anderen Programmen auch) die Abfrage erscheinen, ob getätigte Änderungen vor dem Schließen des Projekts noch gespeichert werden sollen.

Aus der Diskussion zwischen Arne und Jens-Peter geht hervor, dass die Abfrage muss an insgesamt vier Stellen erfolgen muss:

• Projekt schließen direkt in der Menüleiste
• Projekt schließen in der PA beim aktiven Projekt
• Beim Laden eines neuen Projekts
• Beim Laden eines neuen Projekts im Kernel über Komandozeilenabfrage

Im Falle der GUI steuert diese den Prozess selbst und fragt den Status des DirtyFlag ab.

Wählt man im Affinity window das Gobo aus, welches zu ersetzen ist, erhält man den Filter “Included in project”.

Dieser Filter sollte auch in allen anderen Image Selector Windows angeboten werden, um auf Wunsch das Auswählen von Gerätebildern oder Icons zu vereinfachen und zu beschleunigen. Dieser Filter ist aber Gegensatz zur Auswahl bei der Gobo Affinity standardmäßig deaktiviert.

Projekte, die ich angepinnt und damit als Favorit markiert habe, sollten in der Liste der Projekte farblich hervorgehoben oder anderweitig von den nicht angepinnten Projekten separiert werden. Der Stern finde ich als Hinweis drauf ein bisschen zu wenig.

Dieses Ticket steht in gewissen Teilen auch im Zusammenhang mit Ticket  FS#4927 , da ich von meiner Seite davon ausgehe, dass die angepinnten Projekte immer oben in der Liste angezeigt werden.

Tests mit dem Bitmap from Resource Node haben unter anderem auch im Ticket  FS#4802  gezeigt und bestätigt, dass dieser Weg nicht der richtige für den folgenden Anwendungsfall ist:

Ich möchte mir das aktuell gewählte Gobo auf einem Button eines Macro Boards anzeigen lassen. Im Idealfall kann ich dazu ein entsprechendes Converter-Node am Gobo-Ausgang des DMXC-Mixers bzw. des Programmers anschließen und mit diesem dann wiederum den gewünschten Button verknüpfen.

Erstelle ich ein Fanning mit den Fanning-Operatoren ?, ?? oder ?# in Kombination mit einem Master, so werden die Werte kontinuierlich neu berechnet, obwohl ich den zugehörigen Master gar nicht anfasse. Das Problem ist mir unter anderem bei folgenden Eingaben aufgefallen:

• Dimmer: 0 ? {ParameterMaster 1}
• Color: 255; 255; 255 ?# {ColorMaster 1}

Die Erwartungshaltung ist an dieser Stelle eigentlich, dass die Werte nur neu berechnet werden, wenn

• die entsprechende Cue erneut aufgerufen wird
• man den Wert des zugehörigen Masters ändert

Zur Zeit werden die Konfigurationsdaten im Standard-Verzeichnis unter

C:\Users\[User]\AppData\Roaming\DMXControl Projects e.V\

grundsätzlich ohne jeden Bezug zu einer Programm-Version abgelegt, welches (seit je her)

DMXControl

heißt - möglicherweise, weil es zu Zeiten von DMXControl 2 ähnlich war. Dies birgt aber den Nachteil, dass man nach dem Starten einer neueren Version nicht mehr ohne weiteres auf ältere Version zurückgehen kann. Einige Konfigurationsdaten werden verändert und sind dann nur noch für die neue Version verständlich. Zwar kann man hier mit Hilfe der Umgebungsvariablen aushelfen, jedoch ist fraglich, wie häufig von dieser Gelegenheit gebraucht gemacht wird.

Aus diesem Grund schlage ich vor, eine Unterscheidung nach Minor-Versionen von DMXControl 3 zu implementieren und die Konfigurationsdaten in den Verzeichnissen wie folgt aufzuteilen:

• DMXControl (alle Versionen bis einschließlich 3.2.x)
• DMXControl 3.3
• DMXControl 3.4
• …

Bei der Installation einer jeweils neueren Version fragt der Installer ab, ob die bestehenden Konfigurationsdaten übernommen werden sollen. Das Verzeichnis der UserDevices wird grundsätzlich kopiert, sollte das Verzeichnis noch nicht existieren.

Zum Color Grid hätte ich folgende Featurewünsche:

1. Anzahl der Buttons einstellbar machen.
2. Angabe der Anzahl der Buttons pro Zeile (die Anzahl benötigten Zeilen ergibt sich aus der Gesamtzahl der Buttons und wäre keine notwendige Einstelloption).
3. Nutzung eigener Farblisten als Preset für das Color Grid.

Bei Punkt 3 wäre hier der Gedankengang, die bereits existierende Colorlist aufzugreifen. Wenn man dann noch weiterspinnt, könnte ich mir sogar eine Weiterentwicklung des Color Grids dahingehend vorstellen, ähnlich auch mit einer Gobolist verfahren zu können.

Analog zu den Cuelists sollte auch bei Softdesks durch Copy & Paste eine Kopie des zuvor ausgewählten Softdesks angelegt werden.

Getestet mit Build 1402

Der Installer legt aktuell noch nicht die Verknüpfung im Startmenü zu den eigenen DDFs an.