Bugtracker DMXControl 3

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 Projekt eine große Device Group mit > 100 Geräten unterschiedlichen Typs (Spot-MHs, LED-PARs etc.). Die Auswahl dieser umfangreichen Device Group in der Stage View sorgt für eine sehr hohe Auslastung der GUI-Kernel-Verbindung, sodass sich Device Control und Control Panel nur sehr sehr langsam füllen. Häufiges An- und wieder Abwählen verstärkt das Problem zusätzlich.

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.

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

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

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

Die beigefügten Logs zeigen den Ablauf:

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

Ich habe die Version 0.0.251 des Projekts aus  FS#5147  geladen. Dabei werden folgende Meldungen nicht im Project Error Fenster anzeigt:

2023-09-10 19:40:44,135 [Log-Thread] WARN  org.dmxc.lumos.Kernel.HAL.Handler.DMXRangeWithValueRange - Min and Max Value in DDF are swapped (Max < Min). This leads to unexpected behaviour. Invert DMX Min / Max if required: Location: device-->functions-->colorwheel-->rainbow-->range

Diese Meldung ist eigentlich ein wichtiger Hinweis, dass (zwingend) Korrekturen am DDF vorgenommen werden müssen, welche beim Ignorieren später zu einem Nicht-Laden des Projekts führen können. Daher sollten auch schon solche Meldungen im Project Error Fenster auftauchen.

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.

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

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

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

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

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

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

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

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

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

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

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.

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.

Ich habe bei mir nun fünf Projekte neu importiert und diese teilweise auch gespeichert. Die Sortierung in der Liste mit den verfügbaren Projekten ist aber nicht nachvollziehbar und eher zufällig.

Für eine bessere Übersicht sollte aus meiner folgende Kriterien hinterlegt werden, um ein Projekt direkt aus der Liste auszuwählen und nicht die Suche nutzen zu müssen:

• 1. Kriterium: Angepinnte Projekte (Favoriten), dann alle anderen Projekte
• 2. Kriterium: Alphabetische Sortierung analog zum Windows Explorer (erst Ziffern aufsteigend, dann alphabetisch aufsteigend)

Im beigefügten Beispielprojekt habe ich vier verschiedene Inputs an das LTP-Node gehängt: Macro Board Profile, Tastatur (Umsch + 1), Push-Button aus Softdesk (Button 2) und MIDI. Lade ich das Projekt, kann ich über den Button 1 bereits die Signal Lamp einschalten, weil der LTP keinen definieren Wert übergibt, da er wiederum keinen definierten Wert von den Inputs erhält.

Dies hat bei anderen Projekten zur Folge, dass zum Beispiel ungewollt Cuelists ausgeführt werden. Zur Zeit lässt sich das nur dadurch beheben, dass ich nach dem Laden einmal alle Tasten betätigte und damit auch eine Neuberechnung des jeweiligen Connectionsset anstoße. Dabei muss ich beachten, dass beim manuellen Triggern alle Bänke aktiv sind, in denen ich die jeweiligen Input nutze. Sobald eine Bank nicht aktiv ist, behält der Input seinen undefinierten Zustand bei, wenn ich die Bank nachträglich aktiviere. Dies hat wiederum zur Folge, dass ich die dort in den Connectionset enthaltenen Inputs erneut manuell triggern muss.

Hierzu hatte sowohl ich das Ticket  FS#3958  sowie @steff das Ticket  FS#4432 . Vielleicht hat eines oder gar beide eine gewisse Relation zu diesem Ticket.

Bei diesem Punkt handelt es sich um ein Verhalten, was sowohl in DMXControl 3.2.3 als auch in DMXControl 3.3 Beta 2 gleichermaßen existiert. Um dies prüfen zu können, ist das Projekt in DMXControl 3.2.3 erstellt.

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

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

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

in der Cuelist gespeichert.

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

Aktuell kann ich die verschiedenen Executor-Seiten nicht in einer eigenen Reihenfolge anordnen. Die angebotene Option “UI Order Index” wird zur Zeit ignoriert.

Ich habe über die Startparameter –correlation=cpu und –correlation=gpu die Gobo-Korrelation jeweils manuell angestoßen. In beiden Fällen versucht der Kernel, die zugehörige Datei im Installationsverzeichnis zu speichern statt im Benutzerdatenverzeichnis. Aus diesem Grund erscheint die folgende Fehlermeldung.

14:16:02 WARN  ResourceManager - Unable to save Resource GoboCorrelations_CPU.csv of Type Application
System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Config\GoboCorrelations_CPU.csv' is denied.
   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream, String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
   at System.IO.File.Create(String path)
   at org.dmxc.lumos.Kernel.Resource.FileAccessUtil.SaveResourceToFileAsync(String relativePath, Stream data, Boolean useLocalPath, IProgress`1 progress, Boolean throwOnError) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\FileAccessUtil.cs:line 296
   at LumosToolsLIB.Tools.AsyncHelper.RunSync[TResult](Func`1 func) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\AsyncHelper.cs:line 0
   at org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResourceToStorage(String relativePath, Stream data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:line 498
   at org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResource(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:line 488
   at org.dmxc.lumos.Kernel.Resource.ResourceManager.SaveResourceInternalAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\ResourceManager.cs:line 230
   at org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.SaveResourceAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:line 768

Ich würde an dieser Stelle erwarten, dass die GoboCorrelations_CPU.csv und GoboCorrelations_GPU.csv im Butzerdatenverzeichnis abgelegt wird und dabei die dortigen Dateien aktualisiert. Normalerweise dürfen die Daten im Installationsverzeichnis ja nicht verändert werden.

Ich habe bewusst im Project Store herumgefummelt und dabei eine Projekt-Datei umbenannt. Möchte ich nun diese Version trotzdem laden, erscheint in der GUI nur die allgemeine Fehlermeldung “An error occurred while loading version ??? of …” und das Project Errors Fenster bleibt komplett leer. Der Kernel meldet aber korrekterweise, dass die Version nicht gefunden werden kann.

Von daher wäre es hilfreich, wenn die Info, die der Kernel hat, ebenfalls an die GUI weitergereicht wird - hier also “Unable to find Project ??? in Project Store”.

Führt man das Ticket FS#5348 gedanklich weiter, dann wäre im Zuge der Umsetzung der dort beschriebenen Funktion zu überlegen, ob das Fenster “Update DDFs in Project” von seiner Funktion her mit in das “Add device” Fenster übertragen wird.

Dies könnte ggf. bei der Neugestaltung des “Add device” Fensters im Rahmen des WPF-Umbaus erfolgen.

Wird ein DDF in einem Projekt bereits verwendet und man fügt weitere bzw. erneut Geräte ein, die dieses DDF verwenden, so wird dieses immer explizit aus dem Projekt herangezogen. Für ein bestehendes Projekt ist diese Regelung durchaus hilfreich, jedoch nicht, wenn man gerade ein neues DDF erstellt. Hier muss man dann immer erst die alte Version aus dem Projekt löschen, um dann die aktualisierte / korrigierte / ergänzte Version des DDFs ins Projekt einfügen zu können.

An dieser Stelle wäre es hilfreich, wenn man beim Hinzufügen explizit sagen könnte, dass die neuere Version aus dem Dateisystem verwendet werden soll. Dabei überschreibt diese Version dann die Version, die bis dato im Projekt existiert.

Jens-Peter und ich haben an einem DDF gearbeitet und dabei den folgenden Code eingefügt - so, wie er auch im Wiki dokumentiert ist.

<rawranges dmxchannel="0" name="Auto show" >
  <step type="Off" mindmx="0" maxdmx="31" />
  <range type="Show 1" mindmx="32" maxdmx="63" minval="0" maxval="100" />
  <range type="Show 2" mindmx="64" maxdmx="95" minval="0" maxval="100" />
</rawranges>

Bei dieser Implementierung ist es so, dass der step-Eintrag im Device Control nicht auswählbar ist. Damit lässt sich die Funktion in Form der verschiedenen Automatik-Shows nicht abschalten. Hierfür muss aktuell der folgende Workaround herhalten:

<rawranges dmxchannel="0" name="Auto show" >
  <range type="Off" mindmx="0" maxdmx="0" minval="0" maxval="100" />
  <range type="Show 1" mindmx="32" maxdmx="63" minval="0" maxval="100" />
  <range type="Show 2" mindmx="64" maxdmx="95" minval="0" maxval="100" />
</rawranges>

Es wäre wie gesagt hilfreich, wenn der beschriebene Workaround nicht erforderlich wäre und direkt step-Einträge bei der Funktion rawranges unterstützt werden.

Aufbauend auf das Ticket  FS#5305  muss der DMXC-Mixer Node ebenfalls ergänzt werden. Aktuell kann ich über den DMXC-Mixer Node nicht ermitteln, ob ein Generic Switch aktiv ist oder nicht. Folgende Wege wären denkbar:

• Der Status wird mit in den Output “Intensity” aufgenommen, dem entsprechend Off = 0 und On = 1
• Das Node erhält einen zusätzlichen Output

Installiert man DMXControl 3 auf einem weiteren PC komplett neu, erfolgt der erste Start mit allen Standardeinstellungen für die Anwendung selbst als auch bei den Vorgaben für ein neues Projekt. Auch sind keine DMX-Interfaces konfiguriert.

Grundsätzlich ist es möglich, die verschiedenen Konfigurationsdateien vom ersten PC auf den neuen PC zu kopieren. Einfacher wäre es, wenn DMXControl 3 hier mit einer Export- und Importfunktion unterstützt, wie es auch andere Programme machen. Über diese Funktion könnte man sich dann auch so zwischendurch ein Backup seiner Einstellungen machen.

In einem noch nicht näher bekannten Gesamtumfeld funktioniert die Merge-Funktion nicht zuverlässig, woraufhin die GUI sogar in Teilen abstürzt.

Genauere Details inklusive Log-Dateien kann Joseph (@nutzer99) liefern, da es bei ihm im Zuge der Programmierung seiner Show mehrfach aufgetreten ist. Ich möchte hiermit nur einmal das Problem grundlegend dokumentieren.

Ändere ich insbesondere die Konfiguration der DMX-Interfaces, muss ich danach beim weiteren Arbeiten darauf achten, dass Kernel und GUI ordnungsgemäß beendet werden. Denn diese Daten werden bekanntermaßen ausschließlich beim Beenden gesichert. Hängt sich der Kernel oder die GUI auf, kann die Änderung nicht mehr gespeichert werden. Folglich sind die getätigten Änderungen beim Neustart erneut vorzunehmen.

Um dies zu umgehen wäre mein Vorschlag, die Daten für die Programm- und insbesondere für die Interface-Konfiguration nach einer Änderung bei der nächsten manuellen Sicherung des Projekts ebenfalls zu speichern.

Aktuell muss ich den Wiedergabemarker an eine bestimmte Position setzen, um die exakte Zeit an dieser Stelle herauszufinden.

Ich persönlich fände es hilfreich, wenn mir fortlaufend auch die aktuelle Position der Maus selbst in der Zeitachse als Zeitwert angezeigt werden würde.

In meinem aktuellen Showprojekt kann ich die Timecodes-Show nicht mehr mitten im Song starten, wenn hier bereits eine gewisse Zeit vergangen und / oder eine gewisse Anzahl an Cues abzuwarbeiten waren. Konkret bedeutet das, dass beim Start im Song um die 40. Cue bei 1:31.000 die unten stehende Exception fliegt. Dies hat zur Folge, dass die betreffende (Haupt-) Cuelist der Show nicht mehr auf den vom Timecode-Player verschickten Timecode reagiert und damit nicht mehr ausgegeben wird. Hier muss ich das Projekt einmal komplett neu laden, damit die vollständige Wiedergabe inklusive dieser (Haupt-) Cuelist funktioniert. Andere Cuelists werden aber noch mit dem Timecode gefüttert.

16:02:23 ERROR ThreadManager - Thread TimecodeSceneTrigger exited ThreadStart-Method with Exception: Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.ApplyTimings(OutputValueItem item, Int64 timeOffset, Boolean fadeIn, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Int32 sourceIndex, Int32 destIndex, EGotoOptions options, Nullable`1 valueNew) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 519
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.FadeItem(OutputValueItem item, Int64 timeOffset, Boolean fadeIn, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Boolean clone, Int32 sourceIndex, Int32 destIndex, EGotoOptions options, Nullable`1 newValue) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 514
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.AdjustRunningTimings(FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Int64 timeOffset, IDictionary`2 toPlayValues, IDictionary`2 toFadeoutValues, Int32 sourceIndex, Int32 destIndex, EGotoOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 651
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.goToForward(Int32 destindex, Int32 sourceIndex, EGotoOptions options, Int64 timeOffset, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 224
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.goTo(Int32 index, EGotoOptions options, Int64 timeOffset, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 146
   at org.dmxc.lumos.Kernel.SceneList.SceneList.playSceneForward(IScene newScene, Int32 oldIndex, Int64 newSceneOffset, ETriggerReason reason, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, EGotoOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1601
   at org.dmxc.lumos.Kernel.SceneList.SceneList.playScene(Int32 newIndex, Int32 oldIndex, Int64 newSceneOffset, ETriggerReason reason) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1529
   at org.dmxc.lumos.Kernel.SceneList.SceneList.SceneTrigger_SceneTriggered(Object sender, TriggerEventArgs args) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1786
   at org.dmxc.lumos.Kernel.Scene.Trigger.AbstractSceneTrigger`1.triggerScene(SceneBag`1 bag, Boolean removeRunning, ETriggerReason reason) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\AbstractSceneTrigger.cs:line 284
   at org.dmxc.lumos.Kernel.Scene.Trigger.TimecodeSceneTrigger.triggerScenesByTimecode(Int64 actualTC, Int64 newTC) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\TimecodeSceneTrigger.cs:line 151
   at org.dmxc.lumos.Kernel.Scene.Trigger.TimecodeSceneTrigger.timecodeThreadRun(RunContext ctx) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\TimecodeSceneTrigger.cs:line 128
   at org.dmxc.lumos.Kernel.Run.ThreadWrapper.WrappedStart() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Run\Thread\ThreadWrapper.cs:line 213

Das Projekt stelle ich bei Bedarf intern zur Verfügung.

In meinem Showprojekt für das Jahrestreffen musste ich feststellen, dass bestimmte Cuelists mit Timecode-Trigger nach einiger Zeit unsauber wiedergegeben werden. Dies ließ sich sowohl in der StageView als auch in der DMX-Ausgabe real an den Geräten beobachten. Die gewünschten Effekte sehen damit mit zunehmender Wiedergabedauer der Timecodeshow deutlich merklich anderes aus als noch zu Beginn bei den ersten Aufrufen der entsprechenden Cuelists.

Die betreffenden Cuelists sind in dieser besagten Version mehrfach zwei verschiedenen Cuelist-Tracks zugeordnet.

Nachdem ich Cuelists auf die eigenständige Wiedergabe mittels Wait- / Follow-Trigger umgebaut und diese dann über entsprechende Special Cues aufrufe, laufen die Effekte über die komplette Wiedergabe-Dauer der Timecode-Show wie erwartet.

Anmerkung: Das in diesem Ticket beschriebene Phänomen zeige ich am besten live mit der realen Ausgabe und mache dann ggf. auch ein kurzes Video. Dem entsprechend werde ich Projekt und Logs später nachreichen. Die betreffende Version ist gesichert.

Hat man einer Cuelist eine Special Cue hinzugefügt, muss man diese löschen und neu einfügen, sobald man zum Beispiel im Falle der Cuelist einen anderen Befehl oder gar die ganze Cuelist ändern will. Hier wäre es gut, wenn man hierzu die Möglichkeit erhält, eine Special cue ebenfalls zu ändern.

Ich habe in einem Cuelist-Track bereits mehrere Cuelists an verschiedenen Stellen eingefügt. Hier würde ich mir wünschen, wenn man die Möglichkeit erhält, die aktuelle Cuelist an der aktuellen Position durch eine andere Cuelist zu ersetzen.

Über das Kontextmenü kann man vom Timecode-Player aktuell “nur” normale Cues der entsprechenden Cuelist hinzufügen. Dies funktioniert so bereits sehr gut.

An dieser Stelle würde ich mir wünschen, wenn hier die Möglichkeit zum Einfügen von Special cues ebenfalls ergänzt werden würde.

Arbeitet man mit mehreren Cuelist-Tracks, wäre es hilfreich, dass Cuelists vom Cuelist-Track A in den Cuelist-Track B oder C verschoben werden können. Dabei sollen die Cuelists ihren ursprünglichen Startpunkt beibehalten.

Aktuell muss man die betreffende Cuelist im Cuelist-Track B erst erneut manuell an der richtigen Stelle hinzufügen und diese dann im ursprünglichen Cuelist-Track löschen.

Ich lege einen 1D-Effekt auf die Farbe und trage dann einen ColorMaster als Wert für die Farbe ein. Schaue ich mir dies nun mit dem Effektvisualizer an, aktualisiert sich die grafische Darstellung des Wertebereichs nicht. Der Regenbogen bleibt konstant bei rot als Startpunkt, selbst wenn der Colormaster ein grün oder ein gelb ausgibt.

Hinterlege ich aber eine feste Farbe, wie zum Beispiel gelb, dann wird dies vom Effektvizualiser berücksichtigt.

Diese Problem betrifft aber nur den Effektvisualizer selbst - die Ausgabe in der Stageview passt.

Bilder und ggf. ein kleines Beispielprojekt können noch nachgereicht werden.

Ich habe auf einem PC bereits eine DMXC3.3-Instanz laufen. Dann starte ich auf einem zweiten PC eine weitere komplette Instanz von DMXC 3.3.0. Beide PCs befinden sich aber im gleichen Netzwerk. Hier beschwert sich der Kernel vom PC2, dass er sich nicht mit dem Umbra des PC1 verbinden kann - und in der Situation auch gar nicht soll. Die ersten Zeilen des Logs sehen wie folgt aus:

2024-04-04 23:08:38,105 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra DefaultUnknownServerName @ 192.168.21.31...
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 688

Dieser Fehler ist mir bewusst erst mit dem RC2 unter die Finger gekommen. Grundsätzlich stört es den Betrieb nicht, aber der füllt das Log-File des Kernels.

Ergänzend zum Benchmark entsprechend FS#5250 wäre es interessant, ein paar Zahlen, Daten, Fakten zu dem aktuellen Projekt aufrufen zu können - sprich Statistik. Dazu könnte unter anderem aufgeführt werden die Anzahl

• Devices
• Device Groups
• Cues
• Presets
• Cuelists
• Cuelist Groups
• Master (ggf. auch unterteilt nach den Typen)
• Executoren (ggf. belegt und unbelegt)
• Bänke im Input Assignment (ggf. aktiv und inaktiv)
• Graphen (ggf. aktiv und inaktiv)
• Timecodeshows
• …

Teilweise sind diese Zahlen ja bereits bekannt und können beim Laden des Projekts beobachtet werden. Allerdings laufen die wiederum zu schnell durch als dass man sie sich notieren könnte. Daher wäre ein entsprechendes Infofenster nett.

Über das Kontextmenü kann ich aus dem Cuelist-Track die Option “Add cue” aufrufen. Es wäre hilfreich, wenn diese Cue an der aktuellen Position des Wiedergabemarkers einfügen werden würde. Die Position, wo ich das Kontextmenü aufrufe, spielt dabei keine Rolle.

Befindet sich der Wiedergabemarker dabei außerhalb einer Bereichs einer Cuelist, wird die Cue in der Cuelist hinzugefügt, die sich in der Reihenfolge vor dem Wiedergabemarker befindet.

Ich habe gerade mit der aktuellen Version ein komplett neues Projekt erstellt. Dabei meckert der Kernel wie im beigefügten Log-Auszug an, dass das Default-Projekt hinsichtlich der Projekt-Version veraltet ist. Ggf. kann dieses ja mit dem Einspielen des neuen Standart-Layouts (siehe FS#5080) angegangen werden. Aus diesem Grund habe ich dieses Ticket auch “nur” als ToDo definiert.

16:17:54 WARN  LoadedProjectVersion - Project K67xxxxx#1.0.0 has an old File Version 4. Current: 12

Aktuell muss man, um den Wiedergabemarker auf 0 zu setzen, entweder erst zum Anfang scrollen und dann einen Doppelklick in die Zeitleiste machen oder diesen händisch auf 0 schieben. Gerade beim manuellen Doppelklick passiert es, dass man nicht direkt bei 0 landet.

Um dies zu vereinfachen, sollte der Wiedergabemarker über einen Doppelklick auf den Stop-Button automatisch auf 0 gesetzt werden.

Aktuell erfolgt das Zoomen (über das Scrollrad) immer vom Nullpunkt. Dadurch verschiebt sich die Position des Wiedergabemarker immer aus dem Anzeigebereich heraus.

Es wäre hilfreich, wenn der Wiedergabemarker selbst als Mittelpunkt für das Zoomen herangezogen würde.

Im beigefügten neuen Projekt habe ich 12 Nanoleaf-Devices hinzugefügt. Im Anschluss speicherte ich dieses Projekt und habe es in der laufenden Sitzung neu geladen. Dies ist aber nun nicht mehr möglich.

Das Problem muss sich mit der Beta 12 eingeschlichen haben. Ein anderes Projekt konnte ich mit der Beta 11 noch erfolgreich laden und speichern.

Neben dem Beispielprojekt sind auch die Log-Dateien beigefügt.

Lege ich ein neues Preset an, sollte innerhalb des Fensters immer automatisch zu diesem neuen Preset gesprungen werden, dass ich nicht durch die Liste scrollen muss. Im Idealfall wird es auch noch automatisch ausgewählt.

Ich ändere ein existierendes Preset über “Edit in Programmer”. Das Preset ist dabei in der Liste nicht ausgewählt. Um die gewünschten Änderungen nun wieder zurück zu speichern, muss ich das richtige Preset auswählen, um dann über “Add Preset” den entsprechenden Befehl hierfür auszuführen.

Den Schritt des “Auswählens” des Presets, welches sich gerade im Programmer befindet, würde ich mir gerne sparen, indem dieses automatisch ausgewählt wird, sobald ich “Edit in Programmer” aufrufe.

Nach der Behebung von  FS#5168  kann ich im Draw Bitmap Node zwar nun wieder Schriftart und -größe wählen und sie werden vom Node auch gespeichert, jedoch werden diese Änderung nicht mehr an das Macroboard weitergegeben - sowohl hardwareseitig auf dem Macroboard selbst als auch softwareseitig in der Anzeige der Macroboard Profilen. Auch ein Speichern und Neuladen des Projekts schafft keine Abhilfe.

Die Farbe des Textes und auch die Inhalte werden dagegen erwartungsgemäß aktualisiert.

In dem beigefügten Projekt habe ich ein einfaches Beispiel generiert. Eigentlich sollte hier der Button 1.1 des Macro Boards den Text in der Schriftart “Arial” in der Schriftgröße “20px” anzeigen.

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.

Ich musste gerade feststellen, dass es beim Umbra einen kontinuierlichen Anstieg der Auslastung des Arbeitsspeichers durch den Umbra gibt, obwohl kein Projekt (mehr) geladen ist. Innerhalb von ca. 10 Minuten lag dieser Wert laut Taskmanager bei rund 400MB.

Was habe ich gemacht?

• Umbra manuell auf PC2 gestartet
• Kernel ca. 30 Sekunden später manuell auf PC2 gestartet
• Weitere 30 Sekunden später GUI manuell auf PC1 gestartet
• Zwei unterschiedliche Projekte geladen und wieder geschlossen
• Komplettes Setup ca. 5 Minuten nach dem Start komplett im Leerlauf belassen und die Auslastung des Arbeitsspeichers durch den Umnbra beobachtet. Nach ca. 10 Minuten lag Wert bei ca. 400MB
• GUI auf PC1 geschlossen
• Weitere 10 Minuten die Auslastung des Arbeitsspeichers beobachtet bei weiterhin aktiver lokaler Verbindung zum Kernel auf PC. Nach Ablauf dieser Zeit lag der Wert vor dem Herunterfahren des Umbras bei 468MB (siehe auch kurz vorher erstellten, beigefügten Screenshot).

Dieses Verhalten kann ich mit der Beta 9 in zwei Konstellationen nachstellen:

• Kernel und Umbra auf PC2 (Windows 11), GUI auf PC1 (Windows 10)
• Alle drei Programme lokal auf PC1 (Windows 10)

Im Anhang die Logs aus der 1. Konstellation.

Aktuell kann das Compare Node nicht verwendet werden, um zu prüfen, ob der anliegende Wert zwischen >< bzw. außerhalb <> zwei Werten liegt. Grundsätzlich lässt sich dies mit einem Konstrukt aus zwei Compare-Nodes und einem Logic-Node bauen. Es wäre aber hilfreich, wenn der Compare-Node diese Möglichkeiten direkt anbieten würde.

Ich habe mich mit dem PC 1 in einer 1:1-Verbindung auf dem Umbra verbunden, der gemeinsam mit dem Kernel auf PC 2 läuft. Nun ändere ich währenddessen die IP-Adresse des PC 2. Nach einem kleinen Moment stürzt die GUI ab.

Die Verbindung zwischen Umbra und Kernel bleibt auf dem PC 2 bestehen und auch beide Programme laufen weiter. Nach einem Neustart der GUI war ein direktes Verbinden und weiterarbeiten mit dem ggf. aktuell geladenen Projekt möglich.

Das erwartete Verhalten wäre an dieser Stelle, dass die GUI es zumindest abfangen kann, wenn die ursprüngliche Verbindung unterbrochen wird - was ja auch in anderen Konstellationen vorkommen kann.

Die Logfiles sind für beide PCs (PC 1: GUI, PC 2: Umbra und Kernel) im Anhang beigefügt.

Mit dem neuen Operator “Average” berechnet das Math-Node den (einfachen) Durchschnittswert aus den Werten an allen Eingängen, die nicht leer sind.

Ich wechsele recht regelmäßig beim Programmieren zwischen verschiedenen PCs, welche dann auch allesamt noch unterschiedliche Bildschirmkonfigurationen haben - das heißt sowohl die Anzahl als auch die Anordnung.

Immer wenn ich das Projekt nach dem Wechsel erstmalig wieder auf einem anderen PC bzw. unter einer anderen Bildschirmkonfiguration öffne, um daran weiterzuarbeiten, passiert es, dass abgedockte Fenster komplett zusammengeschoben werden. Hierbei ist zu beachten, dass ich die Option “show taskbar icon for floating windows” aktiv habe. Exemplarisch habe ich einen Screenshot für das Input Assignment beigefügt, wo die Fenstergröße effektiv gesehen 0 ist.

Das Gemeine an diesem Problem ist in erster Linie, dass man die Fenster in dieser Größe schnell übersieht, wenn man nicht so wie ich um das Problem weiß. Die Funktion “Move floating windows to primary screen” hilft hierbei leider nicht weiter - sie positioniert auch nur die derart zusammengeschobenen auf dem ersten Bildschirm.

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