Bugtracker DMXControl 3

Aktuell bietet das Node Position to Pan / Tilt nur die Ausgänge für Pan und Tilt als DMX-Wert, jeweils für 8 bit und für 16 bit. Benötige ich aber in einem Connectionset den Wert für Pan und / oder Tilt im Wertebereich 0 bis 1, muss ich mir erst das beigefügte Connectionset bauen und verkompliziere den Graphen dadurch unnötig.

Hier wünsche ich mir eine Möglichkeit, dass ich die Werte direkt im Wertebereich 0 bis 1 erhalte.

Beim DMX-Interface-Node werden die Ausgänge Available, Heartbeat und Heartbeat restarts nicht aktualisiert, was insbesondere am Heartbeat zu sehen ist.

Ziehe ich mein aktives Nodle R4S am PC ab, wäre zudem zu erwarten, dass sich der Wert für Available von true auf false ändert - spätestens, wenn im Kernel entsprechende Logeinträge aufgeführt werden.

Aktuell werden Sound-Dateien in der Projekt-Datei ebenfalls im Ordner Config gespeichert. Hier kam mir die Frage, ob es nicht sinniger wäre, die Dateien analog zu den DDFs in einem komplett eigenen Verzeichnis zu speichern.

Habe ich Geräte einer Powersource zugeordnet und lasse mir das zugehörige VU-Meter anzeigen, werden dessen Werte nicht kontinuierlich aktualisiert.

1. Devices mit gepflegten Leistungsdaten hinzufügen
2. Powersource anlegen
3. Electricity-Window öffnen
4. In der Stage View Geräte highlighten oder Lumos drücken

Das Ergebnis ist, dass das VU-Meter wird nicht aktualisiert wird. Ändere ich aber zum Beispiel den Namen, bekommt das VU-Meter die aktuellen Werte übermittelt. Die Nodes im Input Assignment sind davon nicht betroffen.

Das Powersource-Node wird nicht aktualisiert, wenn die Geräte einer Device Group oder die aktuelle Auswahl in der Stage View mehreren Powersources zugeordnet sind.

1. 8 Geräte mit gepflegten Leistungsdaten anlegen.
2. 2 oder mehr Powersources anlegen.
3. Geräte 1 bis 4 der Powersource A, Geräte 5 bis 8 der Powersource B zuordnen.
4. Neues, leeres Connectionset anlegen, Powersource-Node einfügen und Powersource A wählen.

In den beiden folgenden Fällen werden die Inhalte des Nodes nicht aktualisiert:

1. Man wählt in der Stage View die Device Group aus und highlightet diese.
2. Man wählt manuell die Geräte 1 bis 5 aus.

Wählt man dagegen nur die Geräte 1 bis 4 aus, aktualisiert das Powersource-Node die Werte auf der Output-Seite, auch ohne dass hieran weitere Nodes etc. angeschlossen sind.

Bei der UAC-Abfrage lautet der Titel nun “DMXControl3 Installer“. Zum ein fehlt das Leerzeichen zwischen DMXControl und der 3, zum anderen wurde im Installer der 3.2.1 auch explizit die Version 3.2.1 genannt.

Ob das Wort “Installer” durch “Setup” ersetzt wird, ist mir dagegen gleich.

Versuche ich für den Plasma-Effekt die Frequenz beliebig zu ändern, hat dieser Wert keinen Einfluss auf den Effekt. Er läuft also aktuell trotz beliebiger Frequency mit der gleichen Geschwindigkeit weiter.

Der Triggerwert für den RTC-Trigger steht auf 23:15 Uhr bei einer aktuellen Systemzeit von 23:20 Uhr. Die Cuelist wird ausgeführt. Ich stelle fest, dass die Uhrzeit falsch ist, stoppe die Cuelist und ändere den Wert auf 23:30 Uhr. Dann starte ich die Cuelist wieder. Daraufhin wird die Cue mit dem RTC-Trigger nicht mehr ausgeführt.

Für die neutrale Produktion von Videotutorials wäre es hilfreich, diese neutraler zu gestalten. Dazu würde ich mich wünschen, dass ich die Anzeige der Projektbeschriebung und der Verzeichnispfad bei Bedarf abschalten kann.

Ich patche ein Gerät mit mehr als einem DMX-Kanal auf die letzten Adressen eines DMX-Universums, zum Beispiel einen Hazer mit zwei DMX-Kanälen auf die DMX-Adresse 511 oder einen einfachen RGB-Scheinwerfer mit drei DMX-Kanälen auf die DMX-Adresse 510. Bestätige ich dies im Add Device Dialog, so setzt DMXControl beide Geräte auf die DMX-Adresse 1 des nächsten DMX-Universums, also 2.1. Folglich muss ich bei diesen Geräten die DMX-Adresse manuell korrigieren.

Ein Gerät mit nur einem DMX-Kanal (Dimmer, Nebelmaschine) kann ich dagegen auf die DMX-Adresse 512 setzen. Dies wird beim Bestätigen wie gewünscht umgesetzt, alasi auf die DMX-Adresse 1.512.

Ich steuere über das Softdesk immer bei zahlreichen Cuelists gemeinsam die Intensität, den Fade Factor und Speed Factor oder Slider an. Die zugehörigen Cuelists liegen meist auch in einer Cuelist Group. Bis dato muss ich aber diesen Slider immer pro Cuelist verdrahten, sodass ich ihn beispielsweise bei 10 Connectionsets für 10 verschiedene Cuelists einbinden muss.

Hier würde ich mir eine Möglichkeit wünschen, dass ich diese drei Werte über eine zentrale Stelle an die Cuelists übergeben kann, natürlich vorzugsweise über bereits vorhandene Nodes.

Ich habe ein Softdesk neu gebaut, wo mehrere Cuelist Monitore im Einsatz sind. Diese sollen mir die Cuelists aus verschiedenen Cuelist Groups anzeigen. Im Input Assignment erstelle ich das hierfür benötigte Connectionset (Cuelist Group Node → Cuelist Monitor) für die erste Cuelist Group. Nach dem Hinzufügen der Verbindung, sehe ich im Softdesk wie erwartet die der Cuelist Group zugeordneten Cuelist.

Wenn ich dieses Connectionset nun vervielfältige, um nach und nach die restlichen Cuelist Monitor zu füllen und ich nicht aufpasse, verliert der Cuelist Monitor des vorherigen Connectionsets die Inhalte. Bedeutet: ich habe sechs Cuelist Monitore in meinem Softdesk. Nach dem sechsten Duplizieren und Anpassen des Connectionsets zeigt nur noch der letzte Cuelist Monitor die zugehörigen Cuelists “seiner” zugeordneten Cuelist Group an.

Mögliche Workarounds sind zwar

• ich deaktiviere das Connectionset, von dem ich das Duplikat anlege
• ich füge den entsprechenden Cuelist Groups temporär eine andere Cuelist hinzu, nachdem ich im Input Assignment fertig bin
• ich speichere das Projekt und lade es neu

Diese sind aber allesamt unbefriedigend, weil sie zusätzliche Handlungen und Hintergrundwissen erfordern.

Von daher wäre es gut, wenn dieses Verhalten entweder grundlegend abgestellt werden kann oder ich die Möglichkeit erhalte, die Aktualisierung aller Connectionsets (oder die der aktiven Bank) manuell anstoßen zu können, so wie es ja auch beim Laden des Projekts bereits der Fall ist.

Beim Starten des Kernels taucht immer die folgende Fehlermeldung auf, die im Zusammenhang mit dem Nanoleaf-Plugin steht.

2021-01-03 17:38:36,053 [Main] WARN  LumosLIB.Tools.I18n.T - Call to GetString before catalog is initialized Show in InputAssignment,    bei LumosLIB.Tools.I18n.T._(String text, Object[] args) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Tools\I18n\T.cs:Zeile 119.
   bei Nanoleaf_Plugin.NanoleafPlugin.initializePlugin() in D:\Jenkins\workspace\noleaf_Lumos_Plugin_Pipeline_3.2\Plugin\NanoleafPlugin.cs:Zeile 109.
   bei org.dmxc.lumos.Kernel.Plugin.KernelPluginBase.initializePlugin(IKernelPluginContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Plugin\KernelPluginBase.cs:Zeile 80.
   bei org.dmxc.lumos.Kernel.Plugin.PluginManager.initializePlugin(Type t) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Plugin\PluginManager.cs:Zeile 499.
   bei org.dmxc.lumos.Kernel.Plugin.PluginManager.org.dmxc.lumos.Kernel.AssemblyScan.IAssemblyListener.scanNewType(Type t, EAssemblyType type) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Plugin\PluginManager.cs:Zeile 462.
   bei org.dmxc.lumos.Kernel.AssemblyScan.AbstractAssemblyManager.informAssemblyListener(Assembly a, EAssemblyType type, IAssemblyListener l, Boolean add, Type[] types) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\AssemblyScan\AbstractAssemblyManager.cs:Zeile 90.
   bei org.dmxc.lumos.Kernel.AssemblyScan.AbstractAssemblyManager.registerAssemblyListener(IAssemblyListener listener) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\AssemblyScan\AbstractAssemblyManager.cs:Zeile 69.
   bei org.dmxc.lumos.Kernel.Plugin.PluginManager.org.dmxc.lumos.Kernel.Run.IService.startService() in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Plugin\PluginManager.cs:Zeile 556.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.ServiceInitAction(TService s) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 678.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoTopDownAction(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 22.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoTopDownAction(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 24.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoTopDownAction(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 24.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoTopDownAction(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 24.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoTopDownAction(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 24.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoTopDownAction(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 24.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoTopDownAction(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 24.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoTopDownAction(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 24.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.DoServiceTopDown(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 144.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.startManager() in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 298.
   bei org.dmxc.lumos.Kernel.Run.KernelRunManager.startupKernel() in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Run\KernelRunManager.cs:Zeile 180.
   bei org.dmxc.lumos.Program.runKernel(String projectFile, ILumosLog log) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Program.cs:Zeile 152.
   bei org.dmxc.lumos.Program.Main(String[] param) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Program.cs:Zeile 128.

Das komplette Logfile des Kernels ist im Anhang beigefügt. Die GUI hatte ich in dieser Session nicht gestartet.

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

Ich lege in einem leeren Projekt ein Generic RGBW an und setze den Wert für Dimmer Wattage auf 120W. Schaue ich mir hier die Anzeige und die Werte im Powersource-Node an, erhalte ich folgende Werte für die Leistungsaufnahme:

• rot 100%: 30W –> ok
• gelb 100%: 60W –> ok
• weiß 100% bei RGB+ “only white”: 120W –> Fehler, richtig wäre 30W
• weiß 100% bei RGB+ “none”: 120W –> Fehler, richtig wäre 90W
• weiß 100% bei RGB+ “add”: 120W –> ok

Wie an den Werten zu erkennen ist, wird bei der Berechnung der Leistungsaufnahme die Einstellung für RGB+ nicht berücksichtigt. Dies gilt sowohl für das Generic RGBW als auch für Geräte mit einer RGBW-Matrix wie zum Beispiel das Ayrton Magic Panel R. Bei Matrixgeräten gilt dies, wenn ich die Farbe über den Colorpicker festlege. Für den Fall, dass auch die einzelnen Pixel in die Berechnung einfließen, gibt es ja bereits den Featurerequest im Ticket FS#4044.

Aktuell befinden sich die beiden Einträge zum Anlegen einer neuen Bank und eines neuen Connectionset als Unterpunkte in den Menüs zu den beiden Buttons “Bank” und “Connectionset”. Da aber insbesondere beim manuellen Anlegen neuer Connectionsets dieser Eintrag recht häufig benötigt wird, war in der letzten Betatester-Runde der Wunsch, diese Einträge nach “vorne” zu holen. Damit ist gemeint, dass das Anlegen einer neuen Bank und eines neuen Connectionsets im Idealfall mit einem Mausklick erfolgen kann.

Ich habe dieses Ticket daher mal auf Usabiltiy Relevant gesetzt, da es sicher einige Varianten gibt, dieses zu realisieren.

Damit Nutzer nach der Installation nicht aus allen Wolken fallen, wenn DMXControl 3 nicht richtig läuft, würde ich vorschlagen, den Installer mit einem Hardware-Check auszustatten. Dies könnte in Hinblick auf die nächste Major-Release von größerem Interesse sein.

Wie unter anderem beim Logic- oder beim Math-Node wäre es hilfreich, wenn man bei Bedarf die Anzahl an Ein- / Ausgängen beim Input bzw. Output Selector erhöhen könnte. Eventuell wäre hier auch zu überlegen, die obere Grenze nicht auf 10 Ein- / Ausgänge zu begrenzen, sogar hier bis zu 25 zuzulassen.

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

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

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

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

Um mittels Buttons bestimmte Szenen einer Szenenliste direkt aufzurufen, muss man aktuell zum Beispiel die Ausgangswerte der Buttons entsprechend anpassen, dass der Button 1 die Werte -1 und 0 und der Button 5 die Werte -1 und 4 übergibt. Dies führt zu aufwendigen Konfigurationen.

Hier sollte ein Node hilfreich sein, welches immer die ID des zuletzt geänderten Inputs n ausgibt. Die ID ist dabei der Zahlenwert des Inputs. Zusätzlich kann ich in den Einstellungen festlegen, ab welchem Wert die ID der verfügbaren Inputs hochgezählt werden soll. Die Anzahl der verfügbaren Inputs kann ich analog zum Beispiel des LTP-Nodes festlegen.

Die Software kann nachverfolgen, ob Änderungen am Projekt vorgenommen wurden. Dies soll in der GUI visualisiert werden. Beim QRM-Meeting vom 16.03.2021 wurde abgestimmt, dass

• Hinter dem Dateiname wird ein Sternchen eingefügt (*), zum Beispiel bei MyProject.zip*
• Das Speichern-Symbol (nicht das Speichern unter Symbol) erhält ein rotes Flag, wenn das Projekt geändert ist

Auf einer Remote-GUI werden die Vorschau-Icons für die Effekte und Filter nicht anzeigt.

Sowohl die Menüleiste des Input Assignment selbst als auch das Kontextmenü der Graphenansicht (hier erste Ebene) entspricht nicht der sonst üblichen Größe. Dadurch sind die Icons in beiden Fällen unscharf, was auch beim direkten Vergleich mit der Menüleiste des Project Explorers gut zu erkennen ist.

Im ähnlichen Kontext steht auch das Ticket  FS#4448 .

Aus dem "Live-Coding mit Arne #2" ging der Wunsch hervor, dass der Textzusatz beim Kopieren von Elementen von “Copy of Cuelist” in “Cuelist - Copy” geändert werden soll. Dies gewährleistet, dass bei einer alphanumerischen Sortierung der Elemente weiterhin der wichtige Teil des Namens vorne bleibt.

• Alt: Copy of Cuelist E, Copy (2) of Cuelist E, Cuelist B, Cuelist C, Cuelist D
• Neu: Cuelist B, Cuelist C, Cuelist D, Cuelist E - Copy, Cuelist E - Copy 2

Aus Gründen von Konsistenz und Pflege soll der “Textbaustein” in eine eigene Funktion ausgelagert und die Namensänderung darüber zentralisiert werden.

Wähle ich im Project Explorer den Ordner “Specail Master” aus und füge dort über das Kontextmenü einen Speed- oder Parametermaster hinzu, wird dieser am Anfang noch im Ordner “Special Master” angezeigt. Erst wenn ich weitere Master hinzufüge, wird der Ordner aktualisiert und die Master werden in ihren richtigen Ordnern anzeigt. Schlug diese unregelmäßige Aktualisierung fehl, muss ich den Project Explorer manuell aktualisieren.

In manchen Situationen kommt es vor, dass die Aktualisierung des Input- und Output-Baumes von außen nicht automatisch angestoßen wird, wenn das Input Assignment Fenster geöffnet ist. Ein Beispiel ist hier das Deaktivieren des Group Masters, wie in meinem Live-Tutorial "Clubshow mit DMXC3" bei 23:36 zu sehen. Diese Verschwinden erst, wenn ich das Fenster schließe und neu öffne. Ein weiteres Beispiel ist, dass die finalen Namen von neu angelegten Cuelists etc. nicht durchgereicht werden, sodass im Baum noch “New Cuelist” steht.

Unabhängig von der Tatsache, dass die beiden zuvor beschriebenen Punkte als Fehler zu werten sind und hierzu noch entsprechende Tickets folgen, wäre hier dennoch ein entsprechender Button hilfreich, um die Aktualisierung beider Bäume analog zum Refresh-Button im Project Explorer auch manuell anstoßen zu können.

Aktuell werden Connectionsets nur neu berechnet, wenn eine Werteänderung im logischen Verlauf des Graphen erfolgt. Ein gutes Beispiel ist hier das “Füllen” des Cuelist Monitors. Je nachdem wie das zugehörige Connectionset vervielfältigt wird, kommt es vor, dass der Inhalt des Cuelist Monitors gelöscht wird - nämlich bis ich entweder

1. das Projekt nach dem Speichern neu lade
2. kurzzeitig eine weitere Cuelist der entsprechenden Cuelist Group zuordne.

Dieser Fall ist auch in meinem Live-Tutorial "Clubshow mit DMXC3" ab 42:08 zu sehen. Ursprung für alle nachfolgenden Connectionsets (CS) war das Connectionset “MHS LCH”. Dieses CS ist nach dem Aktivieren aller CS das einzige, wo die Cuelists der gleichnamigen Cuelist Group nicht angezeigt werden. Hierzu wähle ich weiteren Verlauf die 2. Option, um auch die Cuelists in diesem Cuelist Monitor zu sehen.

Um das ganze Prozedere zu vereinfachen, wünsche ich mit eine Möglichkeit, die Aktualisierung bzw. Neuberechnung eines CS sowohl in der Graphenansicht für den aktuellen Graphen oder in der Tabellenansicht für eine oder eine Auswahl von CS manuell anstoßen zu können.

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

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

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

Ich habe das folgend beigefügte Projekt gebaut, in dem ich über das Input Assignment den Manual Beat Node mit der Taste Q (keine Tastenkombination) triggern möchte. An den Outputs werden nur die Anzahl der Beat Signale hochgezählt. Die Berechnung oder gar Aktualisierung der Outputs für Hz, BPM, s etc. findet nicht statt. Dabei macht es keinen Unterschied, ob ich das Beat-Tool sowohl über die Taste 1 über das Input Assignment oder per Mausklick in der GUI aktiviere oder deaktiviere.

Eventuell steht auch folgender Log-Eintrag der GUI mit in diesem Zusammenhang:

2021-04-26 19:59:43,762 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.Beat_gClient - LearnManualBeat
Grpc.Core.RpcException: Status(StatusCode=DeadlineExceeded, Detail="Server didn't respond.")
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   bei Lumos.GUI.Net.gClient.Beat_gClient.<LearnManualBeat>d__6.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Net\gClient\Beat_gClient.cs:Zeile 69.

Dieses Verhalten bzw. Problem besteht auch in DMXControl 3.2.2, ist also in dem Sinne nicht zwingend ein neues Problem.

Beim Sichten der GUI-Logs zum Ticket  FS#4506  ist mit folgender Eintrag aufgefallen:

2021-04-26 19:57:29,477 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_closed of type Picture and source Default could not be loaded!
2021-04-26 19:57:29,478 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_closed of type DeviceImage and source Default could not be loaded!
2021-04-26 19:57:29,480 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_closed of type Icon and source Default could not be loaded!
2021-04-26 19:57:29,481 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_closed of type Symbol and source Default could not be loaded!
2021-04-26 19:57:29,484 [Log-Thread] DEBUG org.dmxc.lumos.XNAViews.TextureManager - Added Texture: lock_closed
2021-04-26 19:57:29,485 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_open of type Picture and source Default could not be loaded!
2021-04-26 19:57:29,486 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_open of type DeviceImage and source Default could not be loaded!
2021-04-26 19:57:29,487 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_open of type Icon and source Default could not be loaded!
2021-04-26 19:57:29,489 [Log-Thread] DEBUG Lumos.GUI.Resource.ResourceManager - Resource lock_open of type Symbol and source Default could not be loaded!
2021-04-26 19:57:29,491 [Log-Thread] DEBUG org.dmxc.lumos.XNAViews.TextureManager - Added Texture: lock_open

Beim Sichten der GUI-Logs zum Ticket  FS#4506  ist mit folgender Eintrag beim Shutdown-Prozess aufgefallen:

2021-04-26 20:02:06,996 [Main GUI] ERROR 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.Themes.ThemeManager.checkCorrectFontUnit(Control parent) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 212.
   bei Lumos.GUI.Themes.ThemeManager.SetThemeInAllControlsTools(Control parent, AbstractGUITheme theme) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 316.
   bei Lumos.GUI.Themes.ThemeManager.Parent_ContextMenuStripChanged(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 435.
   bei System.Windows.Forms.Control.OnContextMenuStripChanged(EventArgs e)
   bei System.Windows.Forms.Control.set_ContextMenuStrip(ContextMenuStrip value)
   bei System.Windows.Forms.Control.DetachContextMenuStrip(Object sender, EventArgs e)
   bei System.ComponentModel.Component.Dispose(Boolean disposing)
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.ToolStrip.Dispose(Boolean disposing)
   bei System.Windows.Forms.ContextMenuStrip.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.ComponentModel.Container.Dispose(Boolean disposing)
   bei System.ComponentModel.Container.Dispose()
   bei Lumos.GUI.Windows.InputLayer.v2.InputLayerForm.Dispose(Boolean disposing) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\InputLayer\v2\InputLayerForm.Designer.cs:Zeile 24.
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei WeifenLuo.WinFormsUI.Docking.DockPane.Dispose(Boolean disposing)
   bei WeifenLuo.WinFormsUI.Docking.DockPane.Close()
   bei WeifenLuo.WinFormsUI.Docking.DockPaneCollection.Dispose()
   bei WeifenLuo.WinFormsUI.Docking.DockPanel.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.ContainerControl.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.Form.Dispose(Boolean disposing)
   bei Lumos.GUI.Windows.MainForm.Dispose(Boolean disposing) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\MainForm.Designer.cs:Zeile 22.
   bei System.Windows.Forms.Form.WmClose(Message& m)
   bei System.Windows.Forms.Form.WndProc(Message& m)
   bei Lumos.GUI.Windows.MainForm.WndProc(Message& m) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\MainForm.cs:Zeile 531.
   bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Um eine schnelle Startmöglichkeit in verschiedenen Netzwerk-Konstellationen zum Beispiel für die GUI zu erhalten, soll wie in der Entwicklersitzung am 28.04.2021 besprochen ein Startparameter implementiert werden, um eine Network ID zu übergeben.

Durch die Einführung von neuen Fanning-Operatoren wird die Liste der möglichen Fannings im Tooltip “Value not valid” immer länger. Wir sind aktuell bei 14 Fannings angelangt. Hier sollte die Anzahl auf ein paar gebräuchliche Fannings reduziert werden, zum Beispiel auf

• -8 # 8
• -8 > 8

Alternativ greift der Tooltip nur den Fanningoperator auf, den der Nutzer aktuell verwenden möchte. Damit lässt sich der Tooltip auf 4 Zeilen reduzieren.

Füge ich einem Projekt Geräte hinzu, während in der Stage View die Option “Show Device / Group Number” oder “DMX-Adress” aktiviert und diese sichtbar ist, wird die folgende Fehlermeldung im Log der GUI ausgegeben.

2021-05-10 19:12:45,308 [Main GUI] ERROR org.dmxc.lumos.XNAViews.StageView.StageView - Der Wert darf nicht NULL sein.
Parametername: text
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: text
   bei Microsoft.Xna.Framework.Graphics.SpriteFont.MeasureString(String text)
   bei org.dmxc.lumos.XNAViews.StageView.StageView.DrawIconStrings(RectangleF bounds, Single bottom, Single right, Single& bottomOut, Single& rightOut) in D:\Jenkins\workspace\Lumos_Pipeline_master\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1391.
   bei org.dmxc.lumos.XNAViews.StageView.StageView.Draw(Rectangle clipingRectangle) in D:\Jenkins\workspace\Lumos_Pipeline_master\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1139.

Das Hinzufügen der Geräte selbst erfolgt dabei wie erwartet, weswegen ich keine (weiteren) Logfiles beifüge.

Über das Tray-Menü des Launchers kann ich mit den Kernel und den Umbra nicht in den Vordergrund holen. Hierzu muss ich das Hauptfenster des Launchers direkt öffnen und die Einträge direkt umschalten.

Lege ich den Positionlist-Effekt auf eine Gruppe von Moving Heads, kann ich den Mittelpunkt des Effekts nicht über Pan und Tilt verschieben. Der Effekt durchgängig zentriert und müsse aktuell durch eine Änderung der Positionlist erfolgen.

Hierzu habe ich im beigefügten Projekt eine Cuelist hinterlegt, die das Problem zeigt.

Lege ich zuerst eine Itemlist an und füge dann erstmalig den zugehörigen Effekt hinzu, dann wird trotzdem die entsprechende Default List angelegt. Beispiel:

1. Neue Colorlist anlegen
2. Color Chaser auf Geräte anwenden
3. Default Colorlist wurde trotzdem angelegt und dem Effekt zugeordnet

Die Frage ist an dieser Stelle: ist dieses Verhalten so in Ordnung? Oder soll geprüft werden, ob eine entsprechende Itemlist existiert und hier dann die erste genutzt werden?

Im Positionlist-Fenster werden die Positionen aktuell mit bis zu acht Nachkommastellen angegeben und auch immer beim Anpassen auf die Anzahl angehoben. Hier stellt sich die Frage, ob eine solch hohe Genauigkeit erforderlich ist, weil diese auch die Übersichtlichkeit und Werteingabe / -änderung darunter leidet.

Damit man beim Color Chaser auch eine Hintergrundfarbe setzen kann, soll der Color Chaser als zusätzlichen Parameter die Blend Modes erhalten, wie man sie auch schon aus den Matrix-Effekten kennt.

Um das Standardverhalten des Color Chasers nicht zu verändern, wird als Default Blend Mode “Multiply” gesetzt.

Zum besseren Verständnis der Arbeitsweise der Color (List) Chaser, Gobo (List) Chaser, dem Position (List) Chaser und ggf. weiteren List Chasern sollen die in einer eigenen Kategorie anzeigt werden.

In dem Zusammenhang wurde auch diskutiert, die List Chaser um “List” zu erweitern. Ob dies am Ende sinnvoll ist, muss technisch entschieden werden.

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

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

Ich lade exemplarisch das beigefügte Projekt. Wenn ich dann die GUI “hart” neustarte, das heißt die Anwendung über den Taskmanager schließe und die GUI neu starte, werden die Icons der Devic Groups in der Stage View nicht an ihrem ursprünglichen Platz anzeigt. Stattdessen befinden sich beide Icons der Device Groups übereinander gestapelt im Null-Punkt oben links in der Stage View. Die Icons der Geräte selbst befinden sich dagegen an ihrem ursprünglichen Platz.

Im Anhang finden sich die Logs der Sitzung sowohl vor als auch nach dem Neustart der GUI. Kernel und Umbra liefen die ganze Zeit durch.

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

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

Um festzulegen, ob der Launcher nach dem normalen Schließen von DMXControl 3 noch weiter ausgeführt werden soll, soll der Schließen-Dialog entsprechend der Absprache im QRM vom 15.05.2021 einen weiteren Eintrag erhalten. Mit diesem Eintrag in Form eines Hakens kann man festlegen, ob der Launcher geschlossen werden soll oder nicht.

Da die bereits vorhandenen Einträge auch in den allgemeinen Einstellungen der GUI hinterlegt sind, sollte die Option für den Launcher ebenfalls dort enthalten sein.

Durch diese Option kann der Launcher auf die Exit-Codes reagieren und zum Beispiel visualisieren, wenn die GUI abgestürzt ist.

Der Project Explorer bietet in DMXControl 3.2.2 aktuell noch folgende Shortcuts. Diese sind in DMXControl 3.3 nicht mehr vorhanden:

• Strg+X, Strg+C, Strg+V
• Entf

Im Anhang befindet sich das Logfile der Alpha 4, wo ich exemplarisch in einem leeren Projekt das Kopieren und Einfügen über die Tastatur mit einer Szenenliste probiere.

Ich habe in meinem Club22-Projekt mehrfach einen Count-Down ins Softdesk eingebaut, um die Zeit in Minuten und Sekunden bis zum Auslösen einer Aktion ausgeben zu können. Das Umbauen eines entsprechen Werts benötigt hier aber das im Anhang beigefügte Connectionset. Ausgangspunkt ist der Fade-Output des Cue-Nodes. Im Rule of Three-Node geschieht die Umrechnung des Prozentwerts in Sekunden. Die nachfolgenden vier Nodes übernehmen die Aufteilung in Minuten und Sekunden. Der größte Nachteil an diesem Aufbau ist, dass ich beim Ändern der Fadezeit der Cues das Rule of Three manuell anpassen muss und auch nicht mit wechselnden Fadezeiten arbeiten kann.

Um dies zu vereinfachen und universeller zu gestalten, schlage ich die Implementierung eines Count-Down-Nodes vor. Der Name Count-Down ist aber aktuell nur ein Arbeitstitel - vielleicht gibt es hier noch einen besseren.

Dieses Node ist wie folgt aufgebaut:

• Eingänge
  • Fadewert in % als dynamisch verändernder Wert wie er zum Beispiel aus dem Cue-Node kommt
  • Zeitbezugswert als fester Wert in Sekunden, welcher entweder manuell gesetzt oder aus einem anderen Node übergeben wird
  • Zeitwert als dynamischer Wert in Sekunden oder Millisekunden, wenn die Quelle diesen bereits zur Verfügung stellt
• Ausgänge
  • Zeitangabe in HH:MM:SS als String, abhängig von der eingestellten Vorlage
• Einstellungen
  • Angabe des Zeitformats aus einer Auswahl von fest vorgegeben Vorlagen wie SS, MM:SS, HH:MM:SS, etc.
  • Angabe der Einheit auf der Eingangseite für die Zeit in Sekunden oder Millisekunden, sofern sich das nicht aus dem ankommenden Wert “herauslesen” lässt
  • Zählrichtung, also absteigend (klassischer Count-Down) oder zunehmend (Stopp-Uhr)
  • Ggf. ein benutzerdefiniertes Prefix oder Suffix

Im beigefügten Projekt ist das Expression-Node mit drei Variablen x, y und z konfiguriert. Da scheinbar beim Laden des Projekts die Variable z mit dem zugehörigen Input nicht rechtzeitig geladen wird, wird die Verbindung zu diesem Input gelöscht. Der Kernel zeigt an dieser Stelle den folgenden Eintrag.

2021-08-27 10:08:46,945 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Input.v2.InputManager - Unable to add Edge to Graph: Missing port.
Parametername: e
System.ArgumentException: Missing port.
Parametername: e
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdges(IEnumerable`1 edges, Boolean processGraph, Boolean reassignLevel) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 335.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 308.
   bei org.dmxc.lumos.Kernel.Input.v2.InputManager.org.dmxc.lumos.Kernel.Project.IProjectResourceUser<org.dmxc.lumos.Kernel.Input.v2.IGraph>.LoadItem(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\Lumos\src\Kernel\Input\v2\InputManager.cs:Zeile 1623.

Im Anhang findet sich das Projekt sowie die vollständigen Logfiles.

Ich habe den folgenden, angepassten DDF-Code vom DDF “BriTeQ - BT-Strobe 1500” aus der DDFLib.

<functions>
  <strobe dmxchannel="0">
    <range type="linear" mindmx="0" maxdmx="5" minval="0" maxval="0"/>
    <range type="linear" mindmx="38" maxdmx="255" minval="1" maxval="12"/>
  </strobe>
</functions>

Wie zu sehen ist, wird der Wertebereich 6 bis 37 komplett ausgeklammert. In diesem Wertebereich liegen Funktionen, die nicht verwendet werden sollen. Dem entsprechend wäre meine Erwartungshaltung die folgende:

• Frequenz 0 → DMX-Wert 2 bzw. 3
• Frequenz 1 → DMX-Wert 1 linear ansteigend bis
• Frequenz 12 → DMX-Wert 12

Füge ich den DDF-Code nun aber in DMXControl ein, lautet der DMX-Wert aber stattdessen 15 und damit voll in dem Bereich, den ich nicht ansprechen möchte. Auch alternative Implementierungen wie

<step type="open" mindmx="0" maxdmx="5"/>

führen zu dem gleichen, nicht erwarteten Ergebnis, dass der DMX-Wert bei 15 liegt.

Das Aktivieren und Deaktivieren von Bänken über den Menüpunkt “Bank > Aktive” ist aktuell nicht möglich. Der Befehl wird nicht durchgereicht, sodass sich auch der farbige Balken nicht ändert.