Bugtracker DMXControl 3

Oftmals werden Weißtöne in Geräten nur als Farbpreset hinterlegt. Aus der WhatApp-Diskussion vom 17.10.2021 ging hervor, dass diese Fälle im DDF dann ebenfalls als virtuelles Farbrad angelegt werden sollten.

Um die Eingabe zu erleichtern und insgesamt einheitlich zu halten, sollte eine Möglichkeit geschaffen werden, dass man für den Farbwert auch einen Wert wie 3270K oder 4500K für Weißtöne eintragen kann. Die HAL verhält sich dann analog zur bereits existierenden Variante für LEE-, Chromagel oder Supergel-Farbfilter.

Ggf. wäre aber zu beachten, dass es Geräte gibt, die die Farbpresets für weiß trotzdem als linear einstellbaren Bereich abbilden.

Ich habe den Output “Child ID” des Device Group Nodes mit dem Input “List” des List Selector verbunden. Möchte ich nun durch diese Liste durchschalten, erscheint bei jeder Umschaltung der folgende Eintrag im Kernel. Als Wert für die Umschaltung übergebe ich ganzzahlige Werte (also int-Werte) mittels des Counter-Nodes im Bereich 0 bis 10.

13:16:20 ERROR AbstractNode -
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.ListSelectorNode.processInternal(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Logic\ListSelectorNode.cs:Zeile 93.
   bei org.dmxc.lumos.Kernel.Input.v2.AbstractNode.process(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Node\AbstractNode.cs:Zeile 230.

Der DMXCMixer-Node gibt am Strobe-Output keinen Double-Wert aus, sodass nachfolgende, numerisch arbeitende Nodes wie der Compare-Nodes mit den ausgegebenen Werten nicht direkt arbeiten können. Hierzu muss der Wert erst unnötigerweise mit einem Format-Node konvertiert werden. Dieses Verhalten ist insofern unschön als dass es zum einen nicht von außen ersichtlich und zum anderen sich im direkten Vergleich mit dem Intensity-Output nicht gleich verhält. Der Intensity-Output gibt direkt einen Double-Wert aus.

Der Blick in den Code zeigt, dass der DMXCMixer offensichtlich von vorn herein unterschiedliche Datentypen erhält. Denn abgesehen von den verschiedenen Parametern Dimmer (Intensity) bzw. Strobe gibt es keine Unterschiede.

Die direkte Verknüpfungen für GUI, Kernel und Umbra im Startmenü starten nur Launcher und holen diesen in Vordergrund, ohne jedoch die jeweils ausgewählte Anwendung auszuführen.

Die Verknüpfung für die GUI enthält folgende Angaben:

• Ziel:

  "C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Launcher\DMXCLauncher.exe" --gui

• Ausführen in:

  "C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\GUI"

Ist ein Gerät ein einer Gerätegruppe verknüpft und ich möchte dieses löschen, so klappt dies aktuell nicht. Ich lande gewissermaßen in einer Schleife, die ich jedoch manuell abbrechen kann, wenn ich im Reference error window auf “nein” klicke. In diesem Zusammenhang fällt auf, dass das Dropdownmenü nicht mit den richtigen Werten gefüllt wird.

Um Geräte aktuell aus dem Projekt zu entfernen, muss ich dieses erst aus der Gerätegruppe entfernen, bevor ich es löschen kann.

In den Einstellungen für die Executor-Seiten kann ich festlegen, wie viele Executoren ist pro Seite nutzen möchte. Dieser Wert wird jedoch ignoriert. Egal welchen Wert ich einstelle, es werden grundsätzlich acht Executoren pro Seite angelegt.

Auf das Ticket  FS#4647  aufbauend ist es bei einer bereits angelegten Executor-Seite nicht mehr möglich, die Anzahl der Executoren zu ändern. Die angebotene Option in den Einstellungen für die Seite wird nicht berücksichtigt.

Analog zu den zusätzlichen Befehlen zum Herunterfahren des Kernels (siehe Ticket  FS#4394 ) sollten diese aus Konsistenzgründen auch im Umbra hinterlegt werden. Aktuell wären diese zusätzlichen Befehle “quit” und “close”.

Man kann in den Einstellungen der Executoren festlegen, dass ein Fader und Buttons nicht belegt sind. In diesem Fall könnte aus meiner Sicht die Übersichtlichkeit erhöht werden, wenn diese bei der Einstellung “Empty” ausgegraut werden, also optisch in den Hintergrund treten. Gerade ein unbelegter Fader zeigt dies nicht offensichtlich genug.

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

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

Mit dieser Cuelist führe ich folgende Schritte aus:

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

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

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

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

Aktuell ist keine Ausgabe über das “neue” Art-Net-Ausgabeplugin möglich.

Beim Start des Kernels gibt es folgenden Eintrag:

23:29:31 WARN  AssemblyManager - Unable to remove Zone.Identifier from File C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Plugins\ArtisticLicenseArtNet.dll
System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Plugins\ArtisticLicenseArtNet.dll:Zone.Identifier:$DATA' was denied.
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.ThrowIOError(Int32 errorCode, String path)
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.ThrowLastIOError(String path)
   bei Trinet.Core.IO.Ntfs.SafeNativeMethods.SafeDeleteFile(String name)
   bei Trinet.Core.IO.Ntfs.AlternateDataStreamInfo.Delete()
   bei org.dmxc.lumos.Kernel.AssemblyScan.AbstractAssemblyManager.TryRemoveZoneIdentifierIfExisting(String file) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosLIB\src\Kernel\AssemblyScan\AbstractAssemblyManager.cs:Zeile 436.

Sobald ich das Plugin deaktiviere, erscheint der folgende Log-Eintrag:

23:31:52 ERROR ArtNetFactory -
System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.Sockets.Socket".
   bei System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   bei System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\mos_DMXPlugins_Pipeline_master_2\ArtisticLicenseArtNet\src\ArtNetManager.cs:Zeile 704.

Im Anhang befinden sich die Logs einer Sitzung sowie die Konfiguration des ausgeschalteten Plugings.

Legt man eine neue Color-, Gobo oder Positionlist an, erscheint hierzu immer der Auswahldialog “New Item List”, wo über das dort enthaltende Dropdown-Menü der Typ ausgewählt wird.

Tendenziell ist dieser Auswahldialog “New Item List” aber eigentlich überflüssig. Die dortigen Einträge können auch in das Kontextmenü des Project Explores überführt werden, so wie es bereits bei den Mastern der Fall ist.

Durch die neuen Master kamen weitere Icons in der sowieso extrem breiten Menüleiste des Project Explorers hinzu. Dadurch rutschen häufiger benötigte Icons noch weiter nach rechts.

Daher wäre der Wunsch unabhängig vom Ticket FS#3360, dass diese vier Icons für die vier Master in ein Dropdown-Menü zusammengefasst werden, dessen Obertitel “Add Master” ist.

In der Titelleiste des Umbras erscheint zwar die Version richtig, nämlich DMXControl V3.3.0.887, der weitere Zusatz ist aber bei “Alpha 7” stehen geblieben.

Im Kernel wird in einer der ersten Zeilen des Logs die genaue Versionsnummer vermerkt:

2022-01-06 16:40:37,100 [Main] INFO  org.dmxc.lumos.Kernel.Run.KernelRunManager - DMXControl V3.3.0.887 Alpha8 starting! (x86)

Ein solcher äquivalenter Eintrag fehlt im Log des Umbras. Hier kann man nur über

2022-01-06 16:51:20,132 [Main] INFO  Umbra.Run.UmbraRunManager - Umbra Build Time: 06.01.2022 13:32:25 UTC

darauf schließen, welcher Build der aktuellen Programmversion zu Grunde liegt.

Ist ein Button mit “Empty” belegt, sollten diese so gestaltet werden, dass diese farblich deutlich zurückhaltend gestaltet sind. Aktuell muss man sehr genau schauen, welche Button mit einer “richtigen” Aktion belegt sind.

Für den Position Master sollen folgende Buttons hinzugefügt werden:

• Zero Pan
• Zero Tilt

Beim Reproduzieren des Fehlers aus Ticket  FS#4709  habe ich ein einziges DDFs aus verschiedenen Verzeichnissen einem neuem Projekt hinzugefügt. Bedeutet:

1. DDF aus Verzeichnis A dem Projekt hinzugefügt
2. DDF in ein anderes Verzeichnis verschoben und leicht modifiziert
3. DDF aus Verzeichnis B dem Projekt hinzugefügt
4. …

Aus diesem Grund befand sich das DDF beim Speichern des Projekts nicht mehr im Verzeichnis A. Dies bemerkt der Kernel und trägt eine Fehlermeldung im Log ein:

23:43:06 WARN  FileBackendDatastore - Following Resources could not be saved in Project:
{ "type": "DDF", "name": "Icons\\Eurolite LED BAR-6 QCL RGBA (9 channel).xml" }
{ "type": "DDF", "name": "Images\\Eurolite LED BAR-6 QCL RGBA (9 channel).xml" }
23:43:07 INFO  Messages - Message from SKI-DSK-TCM900A: Saved Project to GUI SKI-DSK-TCM900A, Path 2022-01-22 - DDF Folders.dmz

In der GUI gibt es dazu keinerlei Hinweise, dass beim Speichern des Projekts nicht (mehr) alle benötigen Daten gefunden werden konnten. Gerade in Hinblick darauf, wenn zukünftig noch mehr Dateien für das Projekt benötigt werden, sollte bereits beim Speichern ein solcher Hinweis erscheinen.

Möglicherweise steht dieses Ticket ein Stück weit auch im Zusammenhang mit  FS#4651  oder kann im gleichen Aufwasch behoben werden.

Um etwas mit dem List Selector zu spielen, habe ich mir das im beigefügten Projekt enthaltene Connectionset gebaut. Über die Buttons “previous” und “next” kann ich die Geräte der zugeordneten Gerätegruppe durchschalten. Für einen schnellen Überblick einfach das letzte Fensterlayout laden.

Hierbei musste ich aber feststellen, dass die Liste, welche das Device Group Node generiert, nicht der Reihenfolge der Sortierung der Geräte innerhalb der Device Group entspricht. Die erwartete Sortierung entspricht dem, wie die Geräte in der Stage View von links nach rechts positioniert sind. Selbst eine einfache alphabetische Sortierung der Geräte entsprechend ihres Namnes oder auf Basis der Gerätenummer findet nicht statt. Somit ist es in der aktuellen Version etwas unintuitiv, das gewünschte Gerät aus der Liste herauszusuchen.

Ich nutze den Sparkle-Effekt, um damit die Farbe einer Gerätegruppe zu steuern. Trage ich unter Peak beim Sparkle-Effekt zum Beispiel einen ColorMaster ein, erscheint bei Bestätigung der Eingabe der folgende Fehler und der Effekt bleibt stehen.

20:33:53 WARN  SceneFadeTicker - Exception triggering Item: start or end value have wrong type!
System.ArgumentException: start or end value have wrong type!
   bei org.dmxc.lumos.Kernel.PropertyValue.Fade.AbstractFader`1.fade(Object startValue, Object endValue, Double percent) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Fade\AbstractFader.cs:Zeile 53.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.SparkleFilter.doFilter(IPropertyValue input, Int64 timeInMs, Int64 delta) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Filter\SparkleFilter.cs:Zeile 180.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.AbstractEffectFilter.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Filter\AbstractEffectFilter.cs:Zeile 58.
   bei org.dmxc.lumos.Kernel.PropertyValue.AbstractPropertyValue.getPropertyValue(Int64 timeInMsAbs) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:Zeile 402.
   bei org.dmxc.lumos.Kernel.PropertyValue.AbstractPropertyValue.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:Zeile 338.
   bei org.dmxc.lumos.Kernel.Scene.Fade.FadeDecorator.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\FadeDecorator.cs:Zeile 96.
   bei org.dmxc.lumos.Kernel.Scene.Delay.DelayDecorator.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Delay\DelayDecorator.cs:Zeile 38.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AutoFadeDecorator.triggerFade() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AutoFadeDecorator.cs:Zeile 33.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AbstractValueFadeDecorator.triggerFade(Boolean& deregister) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AbstractValueFadeDecorator.cs:Zeile 201.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AbstractFadeDecorator.trigger() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AbstractFadeDecorator.cs:Zeile 65.
   bei org.dmxc.lumos.Kernel.Scene.SceneFadeTicker.processBag(ProcessableTickerBag bag, Int64 now) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\SceneFadeTicker.cs:Zeile 218.

Gleiches gilt auch für andere Master.

Mache ich das Gleiche zum Beispiel mit dem Chaser-Effekt, kann ich den ColorMaster nutzen, um die Farbe zu steuern. Entsprechend Patricks Aussage müssen hier Code-Segmente explizit kopiert werden.

An aktuell zwei Stellen ist mir aufgefallen, dass das Anzeigeformat unter den folgenden Punkten noch fortlaufend ist und nicht wie angedacht im Format [Universum.Adresse].

• Konfiguration der DMX-Interfaces: nach dem Aktualisieren der Liste (siehe Bild 1)
• Add device dialog: im Projekt existieren bereits Geräte und man fügt zu einem späteren Zeitpunkt weitere hinzu (siehe Bild 2)

An weiteren Stellen, wie zum Beispiel in den Device Properties oder im Patching Dialog werden die DMX-Adressen im gewünschten Format [Universum.Adresse] angezeigt.

Ich habe zwei DMX-Interfaces hinzugefügt und diese dann deaktiviert (siehe Bild 1). Aktualisiere ich die Ansicht, werden zwar beide Interfaces durch die grau hinterlegten Zellen als deaktiviert gekennzeichnet (siehe Bild 2). Der Haken wird aber wieder gesetzt, was dann zu Verwirrung führt.

Dieser Fehler steht aber nicht im Zusammenhang mit Ticket  FS#3864  bzw. darf nicht als solcher verstanden werden.

Im Anhang die Log-Dateien der Sitzung.

Ich habe ein Softdesk mit mehreren Controls angelegt. Von diesen habe wiederum einige gelöscht und den Softdesk Designer geschlossen. Speichere und schließe ich das Projekt und lade ein neues, bleibt das gelöschte Softdesk Control noch im Input Assignment erhalten, wie im beigefügten Screenshot zu sehen.

Da ich das Problem nicht direkt im gleichen Kontext wie Ticket  FS#4577  sehe, habe ich dieses neue Ticket erstellt.

Im Anhang findet sich das Projekt sowie die Logs der Sitzung.

Verschiedene DMX-Interfaces, wie zum Beispiel das Nodle U1 oder das Nodle R4S werden nach dem Beenden des Kernels nicht automatisch abgeschaltet, wenn diese zuvor aktiv waren. Die Status-LEDs gehen nicht aus.

Aktuell gibt es in den Einstellungen für den Executor zu den Cuelists noch den Eintrag “Release at zero”. Dieser funktioniert nicht und wurde mittlerweile durch “Auto Stop” abgelöst.

Kann ein Projekt nicht erfolgreich abgespeichert werden, wird das Dirty Flag trotzdem auf “Projekt unverändert” zurückgesetzt. Aus meiner Sicht sollte das nicht so sein und erst den Status “Projekt gespeichert” annehmen, wenn im Kernel der Logeintrag

00:00:40 INFO  Messages - Message from ...: Saved Project to GUI Undefined, Path MyProject.dmz

erscheint. Ein typisches Beispiel ist, um das Problem schnell zu reproduzieren, das Projekt mittels 7zip oder ähnlich “anzusehen”, wodurch DMXC keine Schreibrechte mehr auf die Datei hat. Siehe hierzu auch mein Ticket  FS#4651 .

Ist das Projekt zum Ablauf des eingestellten Timers nicht “Diry”, das heißt, das Dirty Flag ist nicht gesetzt, wird das automatische Speichern zu diesem Zeitpunkt ausgesetzt. Der Timer wird aber neu gestartet.

Entscheidung aus QRM 22.1

Können durch diverse Filter (voreingestellte Filter oder durch manuelle Textfilter aus Suchmaske) keine passenden Ergebnisse gefunden werden, soll hierauf durch einen Text wie “No results found” hingewiesen werden. Im Fall der Gobo List ist es aktuell so, dass dann man nur ein leeres Fenster sieht.

Die neuen Executoren unterstützen aktuell noch keine Multi-Touch-Eingabe. Diese Funktion soll auch Basis der Implementierung im Softdesk übernommen werden.

Füge ich eine Special Cue ein, so wurde die in DMXControl 3.2.3 standardmäßig so benannt, welche Aktion beim hinzufügen dieser Special Cue eingestellt war. Zum Beispiel:

• Audio: Play: Jack Ü - to ü [vs. Skrillex & Diplo feat. AlunaGeorge].mp3
• Cuelist: Go: DMH EFF laufend 4-fach

In DMXControl 3.3.0 Alpha 9 werden aktuell stattdessen die Namen vergeben, welche in den Optionen der Cuelists voreingestellt sind.

Arbeitet man mit mehreren Seiten, wird der Button der aktuellen ausgewählten Seite immer mittig dargestellt. Dies ist auch der Fall, wenn das Executor-Fenster breit genug ist und alle Buttons dargestellt werden können. Daher sollte aus meiner Sicht das Schieben der Buttons erst aktiviert werden, wenn die Breite des Fensters nicht ausreicht, um alle Buttons darzustellen. Steht genügend Platz zur Verfügung, sollten die Buttons einfach nur statisch zentriert angezeigt werden.

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.

Werden gewisse Elemente wie zum Beispiel Nodes im Input Assignment durch Alternativen ersetzt, erhält das betreffende Node einen Hiidden-Flag. Dieses Flag sorgt dafür, dass diese Nodes für neue Projekte nicht mehr zur Verfügung stehen. Bestehende Projekte können aber noch geladen werden.

Der Nutzer wird im Form eines ToDos darauf hingewiesen, dass diese Element in der zukünftigen Version entfernt wird.

Mit ein bisschen gefummel habe ich aus dem Code herausgefunden, dass die Definition innerhalb der csv-Datei für den Custom Chaser wie folgt aussehen muss:

ChaserDefinitionFile
MyChaser:
1;0;1;0;0;1;0;1
0;1;0;1;1;0;1;0

Hier stellt sich mir die Frage, ob das so gewollt ist, oder ob es ein Tippfehler handelt. Denn gefühlt wäre das etwas ungewöhnlich, auch wenn ich es grundsätzlich dokumentieren kann. Die Frage wäre, ob es alternativ möglich wäre, den Namen in “” zusetzen.

Die Einstellung “Number of Executors” kann ich nicht erreichen, wenn ich die Einstellungen für die Executor Page im Project Explorer über das Kontextmenü zum Zweig “Executor Page” aufrufe (siehe Bild 1). Wähle ich stattdessen den Weg über die Settings, liegt die Einstellung vor und arbeitet auch wie erwartet (siehe Bild 2).

In den Optionen für die Cuelist Group ist der Eintrag “Intelligent settings” wieder sichtbar. Da diese Funktion nicht genutzt werden soll und auch nicht genutzt werden kann, müsste die einmal ausgeblendet werden.

Ich möchte mit einem einzigen Fader den Wert eines Position-Masters ändern. Dazu baue ich mir ein Positions-Objekt mittels des Format-Nodes zusammen und habe dies mit “{0:0.##}; {1:0.##}” parametriert. Erhält das Position Master Node diesen Wert, gibt der Kernel folgende Fehlermeldung aus:

19:11:23 WARN  EventTools - Exception in Delegate Invocation: Void <AddDefaultPorts>b__37_3(org.dmxc.lumos.Kernel.Input.v2.GraphNodePortID, System.Object) => org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.Void <AddDefaultPorts>b__37_3(org.dmxc.lumos.Kernel.Input.v2.GraphNodePortID, System.Object)
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.ArgumentOutOfRangeException: Input must be <= inMax [0]
Parametername: input
Der tatsächliche Wert war 0,5.
   bei LumosLIB.Tools.LumosTools.RuleOfThree(Double input, Double inMax, Double inMin, Double outMax, Double outMin, ERuleOfThreeBehavior behavior) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosLIB\src\Tools\LumosTools.cs:Zeile 544.
   bei org.dmxc.lumos.Kernel.Master.PositionMaster.set_Value(Position value) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Master\PositionMaster.cs:Zeile 170.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setInputaValue() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:Zeile 189.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.<AddDefaultPorts>b__37_3(GraphNodePortID sender, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:Zeile 236.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Delegate.DynamicInvokeImpl(Object[] args)
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0.<InvokeFailSafe>b__0(Delegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 136.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 180.

Das Position to Pan/Tilt Node versteht die so erstellten Werte dagegen und arbeitet erwartungsgemäß.

Das 3Dconnexion Plugin muss auf DMXControl 3.3 portiert und dann wieder dem Installer hinzugefügt werden.

Wie im beigefügten Bild zu sehen, entspricht die Höhe des Kontextmenüs zur Executor Page im Executor-Fenter nicht den allgemein üblichen Abmessungen. Dies gilt sowohl für das Standard Theme als auch das Dark Theme.

Wenn ich eine neue Gobo Affinity sowohl in einem neuen, leeren Projekt als auch in einem Projekt mit bereits gepatchten Geräten erstelle und hierzu das zu Grunde liegende Gobo auswählen möchte, so wird in dem Auswahlfenster kein Inhalt angezeigt - egal ob der Halen “Included in project” gesetzt ist oder nicht oder ob ich etwas in das Suchfeld eintrage.

Das zusammenstellen der Gobos für eine Goboliste funktioniert dagegen. Dort werden die verfügbaren Gobos angezeigt.

Im Anhang habe ich die Logfiles beigefügt, die den Punkt für ein leeres Projekt protokollieren.

Der neue Fadertyp “Limit” für die Executor-Variante der Cuelist ist in den Einstellungen des Executors noch nicht in der Auswahlliste für den Fader enthalten.

Ich möchte mir den aktuellen Farbwerrt eines Color Masters auf dem Buttons eines Macroboard Profiles anzeigen lassen und habe dazu den Ausgang “Value” des Color Masters direkt mit dem Eingang “Background Color” des Draw Bitmam Nodes verbunden.

Während der Color Master am Ausgang “Value” den Wert “1; 1; 1” als LumosColor-Objekt ausgibt, erwartet der Eingang “Background Color” des Draw Bitmap Nodes einen RGB-Wert. Folglich bleibt der Button effektiv gesehen dunkel, da ja “1; 1; 1” im RGB-Farbraum mit dem Wertebereich 0 bis 255 effektiv gesehen schwarz ist.

Im Hinblick darauf, dass wir im Input Assignment weitestgehend mit normierten Werten arbeiten wollen, sollte der Draw Bitmap Node als Folge dessen das LumosColor-Objekt an beiden Eingängen für die Farbe verstehen.

Ich möchte das aktuell gewählte Gobo eines Geräts auf dem Macro Board ausgeben und habe dazu den Ausgang “Gobo” des DMXC-Mixer-Nodes mit dem Node “Bitmap from Resource” verbunden. Dies soll eigentlich das Bild an den betreffenden Button übergeben. Stelle ich diese Verbindung her, erscheint im Kernel folgender Eintrag:

19:37:00 ERROR BitmapFromResource -
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.BitmapFromResource.processInternal(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Converter\Bitmap\BitmapFromResource.cs:Zeile 55.

Auf Grund dieser Fehlermeldung arbeiten die nachfolgenden Teile des Graphs nicht und ich sehe folglich auch kein Bild auf dem Button. Wähle ich stattdessen manuell eine Resource aus, arbeitet das Node “Bitmap from Resource” wie erwartet.

Füge ich am Gobo-Output des DMXCMixers das MacGyver-Node ein, wird im Übrigen der Name des Gobos nicht unter Image File im LumosGobo-Object geführt, sondern der Name des Gobos erscheint unter dem Ausgang “Min Value”. Schließe ich das Bitmap from Resource an diesen Ausgang an, werden mir die Gobos zumindest angezeigt, sofern ich ein Gobo des ersten von zwei Goborädern auswähle. Die Aktualisierung läuft aber nicht ganz so zuverlässig.

Sobald ich das Art-Net-Plugin selbst manuell abschalte oder der Kernel es beim Herunterfahren automatisch abschaltet, erscheint im Log immer der folgende Eintrag.

17:51:13 ERROR ArtNetFactory -
System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.Sockets.Socket".
   bei System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   bei System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\mos_DMXPlugins_Pipeline_master_2\ArtisticLicenseArtNet\src\ArtNetManager.cs:Zeile 704.

Aktiviere ich es danach wieder, arbeitet es soweit auch wie erwartet. Die Meldung erweckt jedoch gerade beim Überprüfen der Einstellungen den Eindruck, als ob etwas kaputt ist.

Das beigefügte Projekt kann insofern nicht vollständig geladen werden, als dass die entsprechend zugeordneten Executoren mit ihren Einstellungen nicht geladen werden. Die Bänke sind vorhanden, aber ohne gefüllte Executoren. In den Logfiles sind zahlreiche Einträge zu finden.

Das ursprüngliche Projekt habe ich dabei nur in DMXC 3.3 Beta 2 importiert und aufgerufen. Neu gespeichert wurde es mit der 3.3 nicht.

Das beigefügte Projekt habe ich unter DMXC 3.2.x erstellt und verschiedene Macroboard-Profile angelegt. Bedingt durch die Auslagerung in ein Plugin kann ich dieses nicht mehr laden. Es erscheint im Kernel der folgende Eintrag.

12:39:01 WARN  ProjectManager - Error when loading Project 2022-01-12 - Macroboard.dmz: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.Macroboard.MacroBoardManager.SelectProfile(String macroBoardID, String profileID, Boolean ignoreBoardNotExisting) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\MacroBoard\MacroBoardManager.cs:Zeile 338.
   bei org.dmxc.lumos.Kernel.Input.Macroboard.MacroBoardManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.loadProject(LumosIOContext context, ELoadTime time) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\MacroBoard\MacroBoardManager.cs:Zeile 441.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass29_1.<loadProject>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 337.
   bei System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.DoManagerTopDown(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 142.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.loadProject(String filename, Stream inputStream, Boolean loadId, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 333.

Ignoriere ich die zugehörige Fehlermeldung in der GUI, ist das Projekt gewissermaßen kaputt. Es fehlt nicht wie in anderen Fällen nur ein Element, in diesem Fall das Macroboard-Profil, sondern deutlich mehr.

Wenn ich aber die Datei MacroBoardProfiles.xml vor dem Laden aus dem Projekt entferne, kann gibt es keine Fehlermeldung. In diesem Fall kann ich aber dann das Macroboard-Profil neu anlegen und und die Buttons im Input Assignment neu zuordnen. Ist dies erledigt, lädt das auf diese Projekt nach dem Neustart der Sitzung wieder.

Das Projekt ist nur nach DMXC 3.3 importiert. Ansonsten gab es keine Veränderungen. Bei den Logfiles habe ich dieses Mal auch die des Installers beigefüpgt - nicht, dass eine Datei fehlt.

Im beigefügten Projekt habe ich die Buttons 1.7, 2.7 und 2.8 meines Streamdecks XL belegt. Schaue ich mir das Profil in der GUI selbst an, passt die Zuordnung. Auf dem Streamdeck passt die Zuordnung zwar auf der Eingangsseite. Auf der Ausgangsseite ist aber alles um einen Button nach links und einen Button nach oben verschoben. So erfolgt die eingestellte Ausgabe für den Button 2.8 auf dem Streamdeck tatsächlich auf dem Button 1.7.

Ergänze ich in dem Projekt ein zweites Macroboard-Profil und wechsle im Macroboard-Profile-Node manuell einmal zu diesem hin- und dann wieder zurück zum ersten, passt die Anzeige auf dem Streamdeck - bis ich anfange, die Tasten zu drücken. Dann sind wir wieder bei der Ausgangslage mit dem Offset.

Dieser Fehler ist höchstwahrscheinlich durch die Auslagerung der Macroboards in ein Plugin entstanden. In der Beta 1 hat noch alles wie gewünscht funktioniert.

Ich habe meiner DMX-Ausgabe weitere Art-Net-Interfaces hinzugefügt, sodass ich nun insgesamt 4 Instanzen habe. Diese wurden aber nun “frei Schnauze” in die Liste einsortiert, sodass meine Liste nun wie im beigefügten Screenshot aussieht. Hier sollte bitte nach Möglichkeit automatisch immer einer Sortierung der Einträge auf Basis des Herstellers, dann des Modells und dann der Serien-Nummer erfolgen, weil man sich sonst gerade im Fall der Art-Net-Konfiguration im Kreis dreht, wenn die später hinzugefügte Instanz mitten in der Liste eingefügt wird.

Das Ändern der Reihenfolge der Instanzen in der Config-Datei “DMXInterfaceMgmtConfig.xml” hat leider nicht ausgereicht, um die Darstellung in der GUI entsprechend zu beeinflussen.

Öffne und schließe ich den Image chooser mehrfach in einer Sitzung, um Gobos für eine Gobo list oder für die Gobo affinity auszuwählen, reagierte die GUI nach einigen Malen nicht mehr und im Log erscheint folgender Eintrag

2022-04-15 13:05:18,330 [Main GUI] ERROR Lumos.GUI.App - Exception in WPF
System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.

In diesen Fällen beendet sich die GUI selbst und muss manuell neu gestartet werden.

Die vollständigen Logs stelle ich zu einem späteren Zeitpunkt zur Verfügung, wenn ich das Problem nochmal gezielt reproduziere.

Nachdem ich nun das Position Master Node grundsätzlich extern ansteuern kann, ist mir aufgefallen, dass das Node am Value Input reale Positionswerte in Grad erwartet. Dies ist insbesondere im Zusammenspiel mit einer externen Ansteuerung über Fader etc. ungünstig, wie ich es bereits im Ticket  FS#4786  angeschnitten habe. Ändere ich den Aktionsbereich des zugeordneten Position Masters, muss ich auch in den Connectionsets verschiedene Anpassungen vornehmen.

Ich sehe hier folgende Ansätze, diesen Fehler (weil wir ja eigentlich immer nur mit normierten Werten von 0 bis 1 innerhalb der Connectionsets arbeiten wollen) zu beheben:

• Der Value Input wird so angepasst, sodass er nur eine normierte Position versteht.
• Der aktuelle Input wird erhalten und ein weiterer Input ergänzt, der dann die normierte Position versteht.
• Der aktuelle Input wird erhalten und analog zum Programmer-Node zwei getrennte Inputs für Pan und Tilt ergänzt.