Bugtracker DMXControl 3

Ändere ich die Werte für Fade Factor und Speed Factor entweder extern über das Cuelist-Node im Input Assignment oder auch direkt im Cuelist Editor, werden diese Werte beim Starten der Cuelist immer auf den Standardwert von 100% zurückgesetzt. Der gewählte Wert für die Intensität wird aber beibehalten.

Ist die Cuelist dann aktiv, kann ich die Werte für Fade Factor und Speed Factor ändern, wo sie dann auch das erwartete Verhalten zeigen.

Im Anhang findet sich ein kleines Projekt mit einer Cuelist, wo ich die Fadezeiten länger gewählt habe, um auch während des Fades Zeit zu haben, die Werte für Fade Factor und Speed Factor zu ändern.

Launcher wird gestartet ⇒ Hide Kernel / Umbra ist (offenbar) aktiv ⇒ DMXC wird zusammen gestartet ⇒ Hide funktioniert nicht. Kernel und Umbra erscheinen.

Hide muss also bei jedem Neustart deaktiviert und dann wieder aktiviert werden, damit Kernel und Umbra im Hintergrund verschwinden.

Wenn die Project Administration geöffnet wird, sollte der Fokus des Cursors direkt im Suchfeld sein, damit ich direkt einen Suchbegriff eingeben kann. Dadurch dass sich die Maus mit dem letzten Klick eher abseits von der Project Administration befindet, ist das Setzen des Cursors in das Suchfeld etwas umständlich.

Ich habe die 3.3 Alpha 9 installiert und mein Projekt aus der 3.2.3 neu rübergeholt.
Dabei ist mir aufgefallen das die Silder farblich nicht mehr richtig angezeigt werden.
Bilder vom Softdesk aus der 3.3 Alpha 8 und Alpha 9 sowie das Projekt habe ich angehängt.

Gruss Steff

In gewissen Situationen habe ich gleich mehrere Cuelists, die ich gemeinsam live manipulieren möchte, wie unter anderem Timing (Fade Factor), Effect speed, Limit, Temp. Aktuell muss ich hierzu entsprechend viele Executoren anlegen, kann aber dann die Werte immer noch nicht für mehrere Cuelists gemeinsam setzen.

Um dies zu ermöglichen kamen mir hier zwei mögliche Ansätze in den Sinn:

• Es wird ein neuer Executor-Typ “Cuelist Group” eingeführt. Für alle in dieser Cuelist Group enthaltenen Cuelists kann man dann gemeinsam alle verfügbaren Werte gemeinsam ansprechen. Zusätzlich erhält man Zugriff auf die Funktionen wie “Alle starten” oder “Alle stoppen”, die das Cuelist Group Node bereits anbietet. Dieser Ansatz würde dann auch zu dem Ticket FS#4325 passen, die genannten Funktionen auch im Node direkt hinzuzufügen.
• Man kann einem Executor mehrere Elemente zuordnen. An dieser Stelle würde es dann ggf. keine Differenzierung geben, dass es bei den Cuelists erlaubt ist, bei den verschiedenen Mastern aber nicht.

Beim noch einmal über FS#3974, FS#4870 nachdenken (im Rahmen von https://forum.dmxcontrol-projects.org/index.php?thread/16934-cuelist-freigabezeit-verz%C3%B6gerung-dimmer-farbwert ), kam mir folgende zusammenfassende Überlegung: Ideal wäre es, wenn man die Freigabe einer Cuelist generell als weitere Cue ansehen kann (mit allen daraus resultierenden Vor- und Nachteilen). Mit dieser Release-Cue hätte man einerseits die Möglichkeit FS#4870 umzusetzen. Da jede Cue eine Fade Time und eine Delay Time hat, wäre das hier einfach eingebbar. Man müsste noch überlegen, ob man hier auch ein Fanning zulässt wie das bei den Zeiten für andere Cues auch möglich ist. Aber tatsächlich hätte ich damit eigentlich kein Problem, denn dadurch verschiebt man eben nur den Zeitpunkt für einzelne Geräteeigenschaften, wann sie freigegeben werden. So würde dann auch der Cue Timing Editor funktionieren. Mehr noch kann man den Zeitpunkt der Freigabe der Cuelist dann noch feiner einstellen als bisher, denn dann gäbe es nämlich nicht nur “manual only”, “with go” und “when last cue ends”. Stattdessen kann man dann die ganz normalen Cue-Trigger für das Freigeben verwenden. Das einzige, was man überlegen müsste wäre, wie man “manual only” richtig abdeckt. Aber da dürfte eigentlich ein “No Trigger” Eintrag für diese Art von speziellen Cues reichen. So kann ich nie die Release-Cue triggern und die Cuelist nur beenden, wenn ich auf Stop klicke. Dann wir natürlich trotzdem die “Release-Cue” ausgeführt.

Habe ein Projekt (s. Anhang) in importiert, dieses wird in der PA aber nicht angezeigt. Ich habe es noch ein weiteres Mal importiert, dabei kam die Abfrag, ob ich eine Kopie speichern möchte da es schon vorhanden sei, es wurde also prinzipiell irgendwo hinterlegt aber erscheint nicht. Nachdem ich die PA geschlossen und erneut geöffnet habe erscheint das Projekt wieder. Im Kernel keine Meldung, in der Umbra ein paar Fehlermeldungen die ich nicht verstehe, Logs im Anhang.

Ich habe ein Projekt von Stephan (s. Anhang) importiert und geladen, ohnme Probleme. Nach einem Neustart von DMXC wird mit in der Projekt Administration angezeigt: “Mindestens eine version dieses Projekts hat Ladeprobleme!”. Ich habe das Projekt nochmal importiert und geladen, ohne Probleme. Ich kann das beschädigte Projekt leider nicht exportieren und Anhängen, da der Export dieses Projektes nicht funktioniert. Logs im Anhang.

DMXC tut bei mir gerade sehr merkwürdige Dinge, prinzipiell ist die GUI nicht tot, der der Kernel auch nicht, und gewisse Teile funktionieren noch (der Fader der Intensität springt bspw. auf 100 wenn ich Lumos drücke) andere Teile funktionieren aber gar nicht, es wird z.B. trotz lauender Cuelist kein Output ausgegeben und die Stage View aktualisiert sich etwa alle 5 minuten. Außerdem kann ich die Fader eines Masters zwar noch bewegen, sie haben aber keinen Einfluss mehr und die Anzeige über dem Fader im Master aktualisiert sich nicht. Vor dem Absturz habe ich lediglich eine Cuelist erstellt, diese auf einen Executor mit LimitFader gezogen und die Funktion des Faders anschießend auf Intensity umgestellt. Logs sind im Anhang.

Wenn man die Properties des Timer-Nodes öffnet, wirft der Kernel den folgenden Fehler. Offenbar wurden die Icons für die verschiedenen Modi verschoben, sodass diese nicht mehr zu finden sind. Im Dropdown vor den Modi sind die Icons zumindest leer.

19:45:46 FATAL DMXControl 3 Kernel - Unhandled Exception: Could not find the resource "org.dmxc.lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.resources" among the resources "Lumos.Properties.Resources.resources", "Lumos.Properties.Shaders.resources", "Lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.resources" embedded in the assembly "Lumos", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.
System.Resources.MissingManifestResourceException: Could not find the resource "org.dmxc.lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.resources" among the resources "Lumos.Properties.Resources.resources", "Lumos.Properties.Shaders.resources", "Lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.resources" embedded in the assembly "Lumos", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.
   at System.Resources.ManifestBasedResourceGroveler.HandleResourceStreamMissing(String fileName)
   at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists)
   at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
   at System.Resources.ResourceManager.GetObject(String name, CultureInfo culture, Boolean wrapUnmanagedMemStream)
   at System.Resources.ResourceManager.GetObject(String name, CultureInfo culture)
   at org.dmxc.lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.get_TIMER_png() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Converter\TimerNodeImages.Designer.cs:line 118
   at org.dmxc.lumos.Kernel.Input.v2.Worker.Effect.TimerNodeResourceProvider.loadResource(EResourceDataType type, String name) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Converter\TimerNode.cs:line 403
   at org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.<>c__DisplayClass71_0.<TryLoadResourceCore>b__1(IResourceProvider c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:line 564
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Func`2 predicate, Boolean& found)
   at org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.TryLoadResourceCore(EResourceDataType type, String name, EResourceSource source, EIOFlags flags, Boolean sync) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:line 562
   at org.dmxc.lumos.Kernel.Net.gService.Resource_gService._loadResource_RequestReceived(Object sender, RequestEventArgs`1 args) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\gService\Resource_gService.cs:line 180
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state)
   at System.Threading.QueueUserWorkItemCallback.<>c.<.cctor>b__6_0(QueueUserWorkItemCallback quwi)
   at System.Threading.ExecutionContext.RunForThreadPoolUnsafe[TState](ExecutionContext executionContext, Action`1 callback, TState& state)
   at System.Threading.QueueUserWorkItemCallback.Execute()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
   at System.Threading.Thread.StartCallback()
An unhandeled Exception has occoured. DMXControl 3 Kernel has to be terminated. Press Enter to exit.

Ich habe den Schweregrad im Übrigen deswegen hoch gesetzt, da sich der Kernel potentiell beenden kann (zumindest gemäß des Wortlauts der letzten Zeile).

Möchte ich diverse Master in verschiedenen Gerätefunktionen nutzen, so ist dies bei folgenden nicht mehr möglich:

• ParameterMaster: alle Varianten von Index (Index allgemein, Goboindex, Prismindex)
• SpeedMaster: Strobe, alle Varianten von Rotation (Rotation allgemein, Goborotation, Prismrotation)

In DMXControl 3.2.3 können die Master auf die genannten Funktionen angewendet werden, wie es auch im Wiki im Master beschrieben ist.

Getestet habe ich dies mit dem Clay Paky QWO 800 sowie dem Futurelight DMH-160. Logs kann ich nicht zur Verfügung stellen, da keine kontextbezogenen Ereignisse protokolliert wurden. Es erscheint einzig und allein der Tooltip “Value not valid”.

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

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

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

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

Möchte ich im Add Device Dialog die DMX-Adresse für ein neu zu patchendes Gerät korrigieren und lösche mittels der Backspace-Taste oder der Entf-Taste meine Eingabe, so werden immer zwei Zeichen entfernt. Im Eingabefeld für Device Name tritt dieses Phänomen nicht auf.

Da dieses Problem ein reines GUI-Problem ist, kann ich hierzu keine Logs zur Verfügung stellen. Dies muss daher direkt in der Software nachvollzogen werden.

Im beigefügten Projekt habe ich in der Cue 1 der Cuelist 1 einen Chaser auf die Gerätegruppe (Device Group) gelegt. Ändere ich nun die Sortierung der Geräte in dieser Gerätegruppe über das Kontextmenü und sortiere sie zum Beispiel zufällig, wird der Chaser trotz Play Mode “Normal” beim erneuten Starten der Cuelist nicht aktualisiert. Aktuell kann ich die Sortierung nur per Drag ‘n’ Drop oder über die Buttons Up und Down ändern. Über letzte habe ich die zur Zeit aktive Reihenfolge realisiert: 1 - 4, 13 - 16, 5 - 12.

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.

Wenn ich bei einem Executor die Auto Start / Stop Funktion verwende, funktioniert das automatische starten immer mal wieder nicht. Sobald ich den Fader auf null und direkt danach wieder hoch ziehe, startet die Cuelist nicht.

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 habe eine einfache Cuelist mit zwei Cues gebaut, die in Schleife wiedergegeben wird:

1. Cue 1: Dimmer [100%], Farbe [ColorMaster 1]
2. Cue 2: Dimmer [100%], Farbe [ColorMaster 2]

Beide Color Master habe ich mir in den verschiedenen Modi RGB, CMY und HSV in eine Executor Page geliegt.

Jenachdem, welchen Color Master Typ ich nutze, um die Farbe einzustellen, ändert sich der Farbübergang zwischen den beiden Cues. Entweder direkt oder entlang des Farbkreises. Dass die Kombination des Farbtypes / Farbmodells den Fade beeinflusst, ist grundsätzlich bekannt (siehe Ticket FS#4279).

An dieser Stelle kann es zu Verwunderungen führen, wenn eben dieses Verhalten nicht bewusst ist. Die Verwunderung kann noch größer sein, wenn man einmal die Farbe per Fader festlegt (der als HSV konfiguriert ist) und dann die Farbe per Button setzt - innerhalb eines Executorzugs. Auch dies beeinflusst den Farbübergang.

Grundsätzlich kann man diesen Punkt dokumentieren, bis er sich bei der Umsetzung des Tickets FS#4279 “erledigt”. Die Frage ist aber, ob dies ein praktikabler Weg ist und ob es nicht besser wäre, dem ColorMaster eine Einstellung mitzugeben, dass er die Farbe nur intern in einem bestimmten Farbmodell vorhält.

Ich lade ein etwas größeres Projekt, wo DMXC auch ein bisschen mit zu tun hat (große Anzahl an Geräten und Cuelists, einige Connectionssets im Input Assignment). Dabei passiert es regelmäßig, dass die Project Administration im Hintergrund verschwindet und ich das Fenster erst explizit über die Taskleiste in den Vorgrund holen muss, um weiterarbeiten zu können.

Es macht keinen Unterschied, ob ich das zuletzt gespeicherte Fensterlayout aufrufe oder nicht. Ebenfalls hat die Einstellung “Show taskbar icon for each window” ebenfalls keinen Einfluss, ob das Fenster nach dem Laden des Projekts im Hintergrund liegt oder nicht.

Ich habe in einem Projekt zwei Bänke mit unterschiedlichen Macro Board Profilen. Die nicht benötigte Bank ist dabei im Input Assignment deaktiviert. In jeder Bank gibt es ein Connectionset, wo ich die direkte Zuordnung zu meinem Stream Deck vornehme. So kann ich gedanklich nur durch das Deaktivieren der einen Bank und Aktivieren der anderen Bank direkt die Umschaltung der Zuordnung vornehmen und muss kein Conenctionset ändern. Dies habe ich in dem beigefügten Projekt so einmal nachgebaut. Lade ich das Projekt, erscheint im Kernel immer die folgende Fehlermeldung:

20:09:00 WARN  DuplexStreamHandler - Exception in Delegate Invocation: Void _getMacroBoardProfiles_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.GetMultipleRequest]) => org.dmxc.lumos.Kernel.Net.gService.MacroBoard_gService.Void _getMacroBoardProfiles_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.GetMultipleRequest])
System.InvalidOperationException: Object is currently in use elsewhere.
   at System.Drawing.Image.Save(Stream stream, ImageCodecInfo encoder, EncoderParameters encoderParams)
   at System.Drawing.Image.Save(Stream stream, ImageFormat format)
   at LumosLIB.GUI.Windows.PropertyGrid.SerializableBitmap.getArrayFromBitmap() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\GUI\Windows\PropertyGrid\SerializableBitmap.cs:line 112
   at LumosLIB.GUI.Windows.PropertyGrid.SerializableBitmap.get_SerializedBitmap() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\GUI\Windows\PropertyGrid\SerializableBitmap.cs:line 42
   at org.dmxc.lumos.Kernel.Devices.Descriptor.DescriptorTools.FromProfile(IMacroBoardProfile profile, IEnumerable`1 imagesToInclude, Boolean includeAllImages) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Devices\Descriptor\DescriptorTools.cs:line 0
   at org.dmxc.lumos.Kernel.Net.gService.MacroBoard_gService.<>c.<_getMacroBoardProfiles_RequestReceived>b__14_1(IMacroBoardProfile c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\MacroBoard_gService.cs:line 174
   at System.Linq.Enumerable.SelectIListIterator`2.MoveNext()
   at Google.Protobuf.Collections.RepeatedField`1.AddRange(IEnumerable`1 values)
   at org.dmxc.lumos.Kernel.Net.gService.MacroBoard_gService._getMacroBoardProfiles_RequestReceived(Object sender, RequestEventArgs`1 args) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\MacroBoard_gService.cs:line 174
   at LumosToolsLIB.Tools.EventTools.<>c__DisplayClass4_0`1.<InvokeFailSafe>b__0(EventHandler`1 a) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\EventTools.cs:line 67
   at LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate](TDelegate delegate, Action`1 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\EventTools.cs:line 154

Neben dem Projekt sind anbei die Logs eines Zyklus DMXC starten, Projekt laden und wieder herunterfahren beigefügt.

Fehlerbeschreibung

Manchmal funktioniert die Selektion in der StageView nicht mehr…. DeviceControl und Selected DeviceNode arbeiten dann nicht

~~~~~~~~~~~~~~~~~~~

Das Selected Device Node ist dazu gedacht, die aktuelle Auswahl von Devices bzw. Device Groups im Input Assignment zur Verfügung zu stellen. Dies funktioniert so mit der Beta 5 nicht mehr. In der Beta 3 hat das Node noch erwartungsgemäß gearbeitet.

Um den Fehler nachzustellen, habe ich das beigefügte Beispielprojekt erstellt. Im zugehörigen Connectionset ist zu sehen, dass es keinerlei Aktualisierungen im Node gibt und deswegen die aktuelle Auswahl auch nicht in dem hierzu vorbereiteten Softdesk angezeigt wird. Ich muss aber nachfolgend einschränkend feststellen, dass es sich um ein eher sporadisch auftretendes Projekt handelt. Nachdem ich nun zwischenzeitlich ein bisschen hin- und hergeklickt sowie andere Projekte geladen habe, funktioniert das Node aktuell wieder. Die beigefügten Logs zeigen aber die Situation, in der es nicht erwartungsgemäß arbeitete.

Beim erfolgreichen Laden eines Projekts erscheint irgendwann eine Abfrage, ob das letzte Layout geladen werden soll. Zukünftig sollte diese Abfrage ein Dropdown umfassen, in dem alle im Projekt enthaltenen Layouts aufgeführt sind. Hier sollte das zuletzt geladene Layout vorausgewählt sein. Es sollte auch eine Möglichkeit geben, das Laden des Layouts abzubrechen. In Hinblick auf FS#4954 (was im Zuge dieser Integration auch umgesetzt werden kann) wäre gut, wenn es drei Optionen gäbe:

• Jedes Mal nachfragen (Ask) (Standardmäßig eingestellt)
• Immer das letzte Layout laden (Load always last Layout)
• Immer “Layout xyz” laden (Load always “Layout xyz”)
• Kein Layout laden (No Default Layout)

Die Abfrage kommt nur im ersten Fall hoch.

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.

Bisher können schon verschiedene Layouts in einem Projekt gespeichert werden. Allerdings ist es noch nicht möglich, eines der Layouts als Startup-Layout für ein Projekt zu definieren. Es sollte eine Einstellungsmöglichkeit geben, in der man auswählen kann, ob ein spezifisches Layout geladen werden soll oder das zuletzt verwendete. Für ersteres muss dann auch noch ein Handling für nicht mehr existierende Layouts implementiert werden. Siehe dazu auch: https://youtu.be/aXtpf6tv3Cw?t=8542

Wir hatten das Problem bereits in der 3.2.2. Jetzt tritt das Problem wieder auf.

1. Cuelist Group mit Cuelists im IA mit Softdesk Cuelist Monitor verbinden
2. Projekt speichern
3. Projekt laden

–> Cuelist Monitor ist leer…

Wird ein Projekt erfolgreich geladen, erscheint die Abfrage, ob das vorherige Layout geladen werden soll. Diese Abfrage erscheint jedoch nur in der GUI, in der das Laden des Projekts ausgelöst wurde. Die Abfrage sollte jedoch in allen GUIs erscheinen. Hierfür bräuchte es einen gRPC-Call, der an alle GUIs geht. Dieser sollte dann die AskLoadProjectLayout Funktion im Window Manager ausführen. Die Project Administration soll dann entweder eine neue “AskLoadProjectLayoutInAllGUIs” Funktion oder direkt den gRPC-Call aufrufen.

2023-01-08 23:18:51,715 [68] ERROR org.dmxc.lumos.Kernel.Plugin.PluginManager - Error when disabling Plugin: Nanoleaf-Plugin
System.PlatformNotSupportedException: Thread abort is not supported on this platform.
   at System.Threading.Thread.Abort()
   at Nanoleaf_Plugin.API.Communication.StopEventListener() in D:\Jenkins\workspace\noleaf_Lumos_Plugin_Pipeline_3.3\Nanoleaf-Plugin\API\Communication.cs:line 807
   at Nanoleaf_Plugin.NanoleafPlugin.shutdownPlugin() in D:\Jenkins\workspace\noleaf_Lumos_Plugin_Pipeline_3.3\Nanoleaf-Plugin\Plugin\NanoleafPlugin.cs:line 231
   at org.dmxc.lumos.Kernel.Plugin.KernelPluginBase.stopPlugin() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Plugin\KernelPluginBase.cs:line 70
   at org.dmxc.lumos.Kernel.Plugin.PluginManager.DisablePlugin(String pluginId) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Plugin\PluginManager.cs:line 180

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.

Wenn keine GUI mehr mit Kernel oder Umbra verbunden ist und die Fenster versteckt sind, sollen die Fenster in den Vordergrund geholt werden.

Hintergrund ist, dass man man nicht immer mitbekommt, wenn z.b. der Kernel nicht sauber herunter gefahren sind. (Folgeticket aus  FS#4729 )

Seit DMXControl 3.3.0 Beta 2 werden RGB-Werte für Farben vom Input Selector wieder in ein Lumos-Color-Objekt konvertiert.

Dieses Problem hatten wir bereits im Rahmen des Beta-Tests von DMXControl 3.2.2. Seiner Zeit hatte ich es im Ticket  FS#4273  berichtet. Die dort vorhandenen Screenshots sind 1.1 übertragbar, weswegen ich keine neuen Screenshots erstellt habe.

Nachdem sich nun Projekt mit “großen” Input Selctoren laden lassen, musste ich feststellen, dass die eingestellten Werte für die Inputs nicht vollständig geladen werden. DMXControl 3 liest immer nur die ersten vier Werte für die Input Selectoren aus, obwohl alle Werte in der Graphs.xml abgespeichert werden.

Im Anhang einmal der Screenshot, so wie es sein soll und das zugehörige Testprojekt.

In dem beigefügten Projekt habe ich eine Reihe unterschiedlicher Master angelegt und zwar in folgender Reihenfolge:

• Group Master (beim Patching)
  • MIS Group
  • DMH Group
  • AX5 Master
• Parameter Master (über Device Control)
  • Parameter Master 1 (Default)
  • Parameter Master 13
  • Parameter Master 8
• Speed Master (über Device Control)
  • Speed Master 1 (Default)
  • Speed Master 6
  • Speed Master 4
  • Speed Master 7
  • Speed Master 3
• Color Master (über Device Control)
  • Color Master 1 (Default)
  • Color Master 21
  • Color Master 14
  • Color Master 3
  • Color Master 31

Meine Erwartungshaltung wäre an dieser Stelle, dass die Master eines jeden Typs (insbesondere die Parameter Master, Speed Master, Position Master und Color Master) nicht pauschal in der Reihenfolge sortiert werden, wie ich sie erzeugt habe, sondern

• Alphabetisch (bevorzugt)
• Anhand der Nummer des Masters

Das aktuelle Ergebnis des nicht wirklich sortieren Zustands (auch nach dem Speichern und Laden des Projekts) ist im beifügten Screenshot zu sehen.

Ich habe mir ein Projekt erstellt, um die verschiedenen Executor-Typen zu testen und zu dokumentieren. Die Belegung der verschiedenen Seiten ist in den beigefügten Screenshots zu sehen. Die verschiedenen Executoren enthalten dabei auf allen Seiten mehrfach die gleichen Elemente, damit ich insbesondere auch die zahlreichen Buttons prüfen kann. Soweit ich das überblicke, werden diese Informationen auch richtig in die Datei “ExecutorMemberWrappers.xml” geschrieben.

Beim erneuten Laden des Projekts direkt aus der laufenden Sitzung heraus oder auch beim Laden des Projekts nach einem Neustart von DMXC werden die Belegung der Executor-Pages augenscheinlich unvollständig bzw. gar nicht geladen - insbesondere bei den “hinteren” Executor-Pages (im aktuellen Beispiel Group Master, Parameter Master etc.). Beim Betätigen des Faders des Executor 2.1 (Executor Page Group Master) kann man aber erkennen, dass eine Verknüpfung im Hintergrund noch existiert. Die Fader der Executoren 2.2 und 2.3 bewegen sich mit. Gleiches fällt auf, wenn man die Belegung der Executoren ändern möchte. Es wird erst beim zweiten Ablegen eines Elements auf den Executor wirklich das neue Element angezeigt.

Im Anhang findet sich neben den Screenshots des Sollzustands das zugehörige Projekt sowie die Logfiles, die nach dem Neustart und Laden des Projekts generiert wurden.

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.

Mit der Beta 5 habe ich häufig insbesondere beim Speichern des aktuellen Projekts das Problem, dass die GUI abstürzt. Folgender Eintrag im Log der GUI zu finden.

2022-12-23 16:24:17,453 [Log-Thread] DEBUG Lumos.GUI.Run.GuiRunManager - InformSaveProject [before=True] took 105 ms
2022-12-23 16:24:17,531 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.User_gClient - UserContext of current User changed
2022-12-23 16:24:17,540 [92] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.
System.InvalidOperationException: Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.
   bei Lumos.GUI.Facade.User.UserContextFacade.ProcessDeviceChangedMessage(UserContextChangedMessage message) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\User\UserContextFacade.cs:Zeile 43.
   bei Lumos.GUI.Facade.GUISession.UserContextFacadeUpdater.<ProcessChange>d__3.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\GUISession\FacadeUpdaters.cs:Zeile 38.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Facade.GUISession.FacadeContainer`2.<ProcessChangeMessage>d__21.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\GUISession\FacadeContainer.cs:Zeile 142.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   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.User.UserManager.<OnUserContextChanged>d__65.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\User\UserManager.cs:Zeile 282.
--- 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()

Der Kernel führt zu dem Zeitpunkt des Absturz folgende Aktionen aus:

2022-12-23 16:24:17,475 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Saving Project FS#4944 - Master window
2022-12-23 16:24:17,484 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - saveProject KernelInputManager.
2022-12-23 16:24:17,796 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Resource.FileAccessUtil - Deleted D:\Arbeit\MSK event GbR\Software\DMXControl 3.3.0\Kernel\Temp\b42fdf64-174b-4edc-97eb-b4cb45012ba3.tmp
2022-12-23 16:24:17,796 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Project FS#4944 - Master window successfully saved.

Im Softdek kann man einen eingefügten SLider nicht sehen(außer drei Strichen). Ändert man den Style, dann kann man ihn richtig sehen.
Alpha 8

Ich habe mehr oder minder unbeabsichtigt ein Msuikstück mit einer Länge von 76 Minuten einem leeren Projekt hinzugefügt. Im Kernel erscheinen daraufhin die folgenden Einträge:

21:07:37 ERROR LumosTools - Can't get Tags of Resource [[SOUNDFILE]]
System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.
   bei System.IO.MemoryStream.set_Capacity(Int32 value)
   bei System.IO.MemoryStream.EnsureCapacity(Int32 value)
   bei System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   bei LumosLIB.Tools.CommonTools.<CopyStreamCore>d__95.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1396.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosLIB.Tools.CommonTools.CopyStream(Stream source, Stream destination, Int32 blockSize, IProgress`1 progressCallback, Boolean disposeSource) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1372.
   bei LumosLIB.Tools.CommonTools.<ToMSCore>d__81.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1218.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosLIB.Tools.CommonTools.ToMS(Stream stream) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1205.
   bei LumosLIB.Tools.LumosTools.SimpleFileAbstraction..ctor(Stream stream, String name, Boolean disposeStream) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\LumosTools.cs:Zeile 573.
   bei LumosLIB.Tools.LumosTools.<GetDetails>d__42.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\LumosTools.cs:Zeile 615.
21:10:45 ERROR AudioManager - Unable to process FFT / Wave for [[SOUNDFILE]] after several tries....

Auf Grund dieses Fehlers bleiben die Background-Tasks unerledigt beim Status “Waiting” stehen, weil hier die FFT nicht generiert werden konnte. In solchen Fällen sollte der entsprechende Tasks mit einem Fehler abgebrochen werden, als weiterhin den Status “Waiting” beizubehalten.

Als Folgeticket aus  FS#4552 

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.

Wenn ich im folgenden Setup auf PC 1 in einem leeren Projekt Geräte und Gerätegruppen in einer Stage View hinzufüge, so wird die auf PC 2 nicht aktualisiert. Gleiches gilt umgekehrt.

• PC 1: Umbra, Kernel, GUI
• PC 2: GUI

Auch wenn die Icons der Geräte und Gerätegruppen nicht simultan anzeigt werden, so aktualisieren sich zumindest beide GUIs, wenn die Geräte auswähle.

Der Fehlerdialog ist schlecht designed!

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.

Ich habe ein Projekt erstellt, in dem insgesamt 672 Geräte und 28 Gerätegruppen gepatcht und in zahlreichen Ordnern abgelegt.

Das Laden des Projekt schlägt jedoch mit einer Fehlermeldung fehl. Ignoriere ich diese, fallen gibt es folgende Fehler:

• die Zuordnung der Geräte und den Gerätegruppen zu den Ordnern schlägt ca. zu 80% fehl
• in den beiden Stage Views fehlen Icons von Geräten und Gerätegruppen

Spannenderweise liegen die Positionsinformationen der Icons in den Stage Views grundsätzlich noch vor. Ziehe ich die fehlenden Icons wieder in die Stage View, werden diese an der richtigen Position eingefügt.

Lade ich das gleiche Projekt mit der 3.3 Alpha 4, so funktioniert das Projekt ohne Probleme.

Im Anhang findet sich das betreffende Projekt sowie die Logs eines Durchlaufs einer Sitzung.

s.o.

Es ist suboptimal, das die FFT-Analyse die CPU auslastet wärend eines File-Imports, dadurch stockt der Resource-Stream extrem, oder der Kernel wird zwischendurch disconnected…..

- Input - Knopf drücken
- Output - bmp und ist gedrückt

Das Dirty Flag berücksichtigt aktuell keinerlei Änderungen etc., die in einem Softdesk vorgenommen werden. Dies umfasst unter anderem:

• Hinzufügen neuer Controls, selbst obwohl diese im Input bzw. Output-Baum des Input Assignments auftauchen
• Anpassung des Display Names
• Festlegen von Position und Größe
• Auswahl des Styles
• Änderung des Layouts wie Farbe oder auch des Textes

An dieser Stelle müssen wir aber aufpassen, dass ja über das Input Assignment Teile der Softdesk Controls zur Laufzeit geändert werden können. Hier müssen wir festlegen, ob:

• durch eine Änderung über das Input Assignment initiierte Änderung von Text und / oder Farbe grundsätzlich das Dirty Flag triggert, weil es per Definition eine Änderung am Control ist (analog zu den Werten für Master und Executoren).
• per se Anpassungen an Farbe und Text ignoriert werden, das heißt auch, wenn keine Ansteuerung über das IA erfolgt und man diese manuell im Softdesk Editor vornimmt.
• das Dirty Flag nur getriggert wird, wenn Änderungen im Edit-Modus des Softdesks erfolgen (dabei ist dann egal ob per IA oder manuell). Erfolgen Änderungen an Farbe etc. im Anzeige-Modus, werden diese ignoriert.

Um hier mal ein bisschen zu spielen, kann das kleine Projekt aus Ticket FS#4739 verwendet werden.

Im Gobo Affinity Window soll man auf das Bild des Gobos klicken können, um ein anderes Gobo auszuwählen, was entsprechend der Gobo List ersetzt wird. Dies ist aktuell nicht mölglich.

Der Launcher kann aktuell nur eine Version erkennen, anzeigen und starten (im selben Ordner bzw. anhand des Registry-Eintrags). Sobald es mit DMXControl 3.3.1 auch offiziell möglich ist, mehrere Versionen parallel zu installieren (Installer packt dann Registry-Einträge von DMXC 3.3.1 in einen separaten Registry-Eintrag zur 3.3.0). Der Launcher muss einerseits diese neue Struktur unterstützen und andererseits so erweitert werden, dass er dann im Zweifelsfall mehrere DMXC-Versionen anzeigen kann.

Regelmäßig unregelmäßig kam es in bei mir im York vor, dass ein Tastendruck im Softdesk teilweise mit mehreren Sekunden Verzögerung umgesetzt werden. Dieses Problem kommt und geht über den Abend, ohne dass nicht explizit Änderungen am ausgeführten Projekt durchgeführt werden.

@patme hat in der heutigen Beta-Testerrunde berichtet, dass ihm dieses Problem bei einem seiner letzten Langzeit-Testläufe mit DMXControl 3.3.0 Beta 2 ebenfalls unter die Finger gekommen ist.

Mehr durch Zufall musste ich feststellen, dass die GUI direkt beim Start mit dem folgenden Logeintrag abstürzt, wenn statt des 3.3er-Kernels der 3.2.3er-Kernel läuft. Auch wenn die Konstellation eher ungewöhnlich ist, sollte diese trotzdem keinen Absturz hervorrufen.

2023-01-07 20:22:54,057 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig
System.Net.Sockets.SocketException (0x80004005): Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig
   bei System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   bei System.Net.Sockets.Socket.Bind(EndPoint localEP)
   bei LumosProtobuf.Udp.UdpListener.StartListen() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UdpListener.cs:Zeile 41.
   bei LumosProtobuf.Udp.UmbraDiscoveryClient.StartDiscovery(IReadOnlyCollection`1 listenAdresses) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraDiscoveryClient.cs:Zeile 66.
   bei org.dmxc.lumos.Kernel.Net.AbstractGrpcManager.NetTools_NetworkChanged(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\AbstractGrpcManager.cs:Zeile 175.
   bei org.dmxc.lumos.Kernel.Net.AbstractGrpcManager.StartupFinished() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\AbstractGrpcManager.cs:Zeile 167.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.InformManagerStartupFinished(TManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 372.
   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.Run.AbstractRunManager`2.startManager() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 340.
   bei Lumos.GUI.Run.GuiRunManager.startupGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Run\GuiRunManager.cs:Zeile 62.
   bei Lumos.GUI.Program.runGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Program.cs:Zeile 194.
   bei Lumos.GUI.Program.Main(String[] param) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Program.cs:Zeile 160.

Reproduzieren lässt sich dies, in dem ich den 3.2.3er Kernel manuell starte und dann Umbra und GUI über den Launcher aufrufe.