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.

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.

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 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 eine Cuelist mehreren Cuelist Groups zugeordnet. Beide Cuelist groups stehen auf “Single list running”. Wechsele ich zwischen den Cuelists hin- und her, wird in der Regel die Release time der zu beendenden Cuelist ignoriert. Folglich wird die alte Cuelist hart ausgeblendet und nur die neue faded ein. Der Kernel protokolliert in diesem Moment folgendes, wobei klar ersichtlich ist, dass der Release der Cuelists mehrfach getriggert wird:

2025-03-26 20:30:15,492 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,553 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Stopping Cuelist Cuelist 2 due to Group Group 1 config.
2025-03-26 20:30:15,553 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Stopping Cuelist Cuelist 2 due to Group Group 2 config.
2025-03-26 20:30:15,553 [Log-Thread] WARN  org.dmxc.lumos.Kernel.SceneList.SceneList - Unable to stop Cuelist Cuelist 2, because other Invocation is currently in process
2025-03-26 20:30:15,554 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,554 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Skip Stopping Cuelist Cuelist 1 due to Group Group 1 config as List is releasing.
2025-03-26 20:30:15,608 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,608 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,642 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,642 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,710 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Skip Stopping Cuelist Cuelist 1 due to Group Group 2 config as List is releasing.
2025-03-26 20:30:16,221 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:16,221 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:16,255 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:16,255 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack

Schalte ich das Single list running bei einer der beiden Cuelist groups aus, erfolgt der Übergang wie erwartet mit der eingestellten Release time sowie mit der Fade time der neuen Cuelist.

An dieser Stelle wäre meine Erwartungshaltung, dass die Zuordnung von Cuelists zu mehreren Cuelist groups mit der Einstellung “Single list running” nicht darauf Einfluss hat, ob der Release einer Cuelist vollständig ausgeführt wird oder nicht. Soll eine Cuelist keine Release time haben, lege ich dies in den Einstellungen der Cuelist fest.

Um das Problem ggf. besser zu verstehen, habe ich das beigefügte Beispielprojekt gebaut. Hierzu einfach zwischen den drei Cuelists hin- und herschalten, die den Executoren zugeordnet sind.

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 ein Projekt mit der Version 2.0.4 geöffnet und dann über eine gewisse Zeit mehrmals gespeichert. In den Logs des Kernels wird die Revisionsnummer allerdings nicht hochgezählt, wie im beigefügten Auszug zu sehen ist. Eigentlich müsste mit dem letzten Eintrag die Revisionsnummer bei 7 stehen. Die Projektdatei selbst wird richtig abgelegt.

18:20:06 INFO  Project_gService - Start saving Project.
18:20:06 INFO  ProjectManager - Saving Project Ehrung der Besten
18:20:08 INFO  ProjectManager - Version { "guid": "K4SS0GF8", "major": 2, "revision": 4 } of Project Ehrung der Besten successfully saved.
20:00:01 INFO  Project_gService - Start saving Project.
20:00:01 INFO  ProjectManager - Saving Project Ehrung der Besten
20:00:03 INFO  ProjectManager - Version { "guid": "K4SS0GF8", "major": 2, "revision": 4 } of Project Ehrung der Besten successfully saved.
20:26:00 INFO  Project_gService - Start saving Project.
20:26:00 INFO  ProjectManager - Saving Project Ehrung der Besten
20:26:03 INFO  ProjectManager - Version { "guid": "K4SS0GF8", "major": 2, "revision": 4 } of Project Ehrung der Besten successfully saved.

Führt man die Installation auf einem Gerät ohne vorhandene Internetverbindung aus, wird erst zu spät festgestellt, dass diese nicht vorliegt. So werden verschiedene .net-Frameworks nicht installiert bevor man einen Hinweis erhält. Dadurch entsteht der Eindruck, dass bis dahin alles ordnungsgemäß abgelaufen ist.

Im Idealfall prüft der Installer ganz zu Anfang, ob eine Internetverbindung besteht und gibt einen Hinweis, falls diese nicht existiert.

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.

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.

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.

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

Aktuell ist der zulässige Höchstwert für die Phase bei 1080° festgesetzt. Dieser ist mittlerweile zu gering und sollte hochgesetzt werden.

In diesem Zusammenhang wäre dieser Wert als zentrale Konstante zu definieren, statt ihn einzeln in den Effekten zu hinterlegen.

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.

Aktuell umfasst das Standard-Layout von DMXC 3.2.3 unten rechts nur das Preset-Fenster. Hier sollte aus folgenden Gründen eine Anpassung des Standard-Layouts vorgenommen werden:

• Die Presets sind sinnvoll, sollten aber nicht direkt als erstes genutzt werden.
• Das Effects und Filters wird mehrheitlich immer mit als Fenster geöffnet und dann über das Preset-Fenster gelegt.

Daher sollte das Standard-Layout wie im Screenshot gezeigt um das Effects und Filters Fenster ergänzt werden, was sich das Panel gemeinsam mit dem Preset-Fenster teilt.

Ich würde mich über eine Möglichkeit freuen, den Wiedergabe-Marker schnell wieder wieder auf den Anfang zu setzen. Folgende Varianten wären einzeln oder auch in Kombination denkbar:

• In der Menüleiste wird ein zusätzlicher Button eingefügt.
• Der Wiedergabe-Marker wird bei einem Doppelklick auf den Startpunkt gesetzt, während ein einfacher Klick ihn auf den Punkt springen lässt, von wo die Wiedergabe zuletzt gestartet wurde.