Bugtracker DMXControl 3

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.

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.

Ich habe in einer Cuelist als eine der ersten Szenen eine Audiodatei eingefügt, welche “innerhalb” der Cuelist wiedergegeben werden soll. Alle nachfolgenden Cues mit dem Trigger “Timecode” werden aber nicht ausgeführt weil entweder der Timecode der Audiodatei nicht übergeben wird oder der Trigger selbst einen internen Fehler aufweist.

Reproduzieren lässt sich dies mit dem beigefügten Projekt. Logeinträge mit eventuellen Fehlermeldungen sind in allen drei Komponenten nicht vorhanden. Der Kernel protokolliert nur erwartungsgemäß, wenn die Audiodatei gestartet bzw. gestoppt wurde.

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

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.

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

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 .

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.

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.

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.

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.

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

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.

Ändere ich bei einem bereits einmal gespeicherten und wieder geöffneten Projekt zum Beispiel bei einer Auswahl von Devices in der Stage View die Einstellung “Enabled”, so friet die GUI ein. Um weiterarbeiten zu können, muss ich den Prozess “hart” über den Task Manager beenden.

Dieses Ticket beschreibt den eigentlich beobachteten Fehler aus Ticket FS#4683. Im Nachhinein betrachtet war es dort die gleiche Vorgehensweise, nur eben mit dem Eintrag “Mirror horizontal”. Hier war das Projekt zum Zeitpunkt des Auftreten des Fehlers zuvor ebenfalls innerhalb der Sitzung nochmal neu geladen worden.

Im Anhang befindet sich das Projekt sowie die Logfiles, wobei die der GUI nur bis zu dem Zeitpunkt erfasst sind, bis diese über den Taskamanager beendet wurde.

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.

Durch einen dummen Zufall ist mir aufgefallen, dass DDFs, welche sowohl im Verzeichnis “Icons” und / oder “Images” liegen, ebenfalls einem Projekt hinzufügt werden können. In diesem Fall übernimmt DMXControl 3 beim Speichern sogar diese zusätzlichen Pfade, wie in dem beigefügten Projekt zu sehen ist.

Um den Fehler gezielt zu reproduzieren, habe ich bewusst den DMX-Mode bei den Devices 2 und 3 angepasst, damit ich die Software entsprechend zum erneuten Laden der verfügbaren DDFs bewegen konnte.

Aus meiner Sicht sollte dies unterbunden werden. DDFs haben ausschließlich direkt im Verzeichnis “UserDevices” zu liegen, nicht in den Unterordnern “Icons” oder “Images”. Eigene Ordner werden im Übrigen bereits ignoriert.

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

• Zero Pan
• Zero Tilt

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.

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.

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.

Ich habe ein Gerät mit einer 1×6 Matrix (6 Pixel horizontal in einer Zeile). Ändere ich hier die Ausrichtung der Matrix oder möchte diese auf einer Ebene spiegeln, friert die GUI ein. Nach dem Abschießen der GUI lässt sich der Kernel daraufhin auch nicht mehr per Kommandozeile vollständig herunter fahren.

In Vorbereitung auf den heutigen Stream habe ich mir den Temp-Fader nochmal angeschaut, nachdem die Info kam, die Funktion sei nun vollständig implementiert. Im Zuge dieses Tests sind gleich zwei Dinge aufgefallen, die sich am besten mit dem beigefügten Projekt reproduzieren lassen.

1. Die Steuerung der Intensity der Cuelists ist kaputt gegangen. Die Executoren 1.1 und 1.3 übergeben die Werte zwar an die Cuelists. Eine Umsetzung findet aber nicht mehr statt.
2. Temp-Fader wird nur aktualisiert, wenn die Cuelist auf Executor 1.3 eingefadet, zwischen den Cues übergefadet oder ausgeblendet wird. Ist die Cue zu 100% eingeblendet, wirkt sich der Temp-Fader nur noch als zusätzlicher Intensity-Regler für Helligkeit, aber nicht für den Grad der Einmischung der Werte.

Zum zweiten Punkt wäre folgende Erwartungshaltung. Ist die Cuelist auf Executor 1.1 aktiv, soll der Temp-Fader zu jedem Zeitpunkt bestimmen

• den Wert, wie weit die Farbe eingemischt wird zwischen 0% und 100% grün / blau alternierend.
• den Winkel, wie “hoch” die Geräte schwenken zwischen 0° und 95° (dies ist besser live zu sehen).

Hinzu kommt, dass beim Überblenden der Cuelist auf Executor 1.3 nicht von Cue 1 nach Cue 2 übergeblendet wird. Stattdessen Blitzen die im Hintergrund gesetzten Werte (Defaultwerte oder die Cuelist auf Executor 1.1) auf und faden mit der gesetzten Fadezeit der Cue 1 bzw. Cue 2 aus. Für dieses Verhalten ist der Wert des Temp-Faders irrelevant.

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.

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.

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.

Zur Überprüfung des im Ticket  FS#4415  wollte ich dieses nach dem Import entsprechend in DMXControl 3.3 Alpha 7 laden. Dies ist aber auf Grund der folgenden Meldung im Kernel nicht möglich:

2021-12-02 19:14:23,620 [12] ERROR org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter - Error in Reading KeyValue Pair: Attribute

   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateManagedTree(XmlElement node, Double version, EIOFlags flags, List`1 errors) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 146.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateManagedTree(XmlElement node, Double version, EIOFlags flags, List`1 errors) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 127.

In den beigefügten Logs ist die vollständige Fehlermeldung enthalten. Das entsprechende Projekt liegt ebenfalls bei.

Grob zusammenfasst beinhaltet das Projekt folgendes:

• 20 Geräte, zugeordnet zu 4 verschiedenen Gerätegruppen
• 1 Cuelist
• 2 Makroboard-Profile, wobei nur das erste eine entsprechend einfache Zuweisung im Input Assignment besitzt

Öffne ich das Projekt aus  FS#4656  und starte dann einmal nur die GUI neu, ist das Executor-Fenster komplett leer. Es werden sowohl keine Executor Pages als auch die Executoren selbst nicht angezeigt.

Klicke ich aber auf “Add Page”, merkt das Fenster, dass bereits Executor Pages im geladenen Projekt existieren und beginnt entsprechend nach dem “höchsten” Executor zu zählen. Auch die Seitenzahl beginnt nicht bei 1.

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.

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.

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.

Das beigefügte Projekt enthält drei Softdesks mit zahlreichen Steuerelementen. Beim ersten Laden klappt in der Regel alles noch einwandfrei, wenn die letzte Fensteranordnung aufgerufen wird, die alle drei Softdesks anzeigt. Wenn ich aber die nachfolgend genannten Schritte ausführe, findet die GUI zwei der drei Softdesks nicht, obwohl diese zuvor noch geöffnet werden konnten. Die zugehörigen Fenster bleiben leer.

1. Projekt über “Close Project” schließen.
2. Ein neues, leeres Projekt erstellen lassen.
3. Beigefügtes Projekt erneut öffnen und letzte Fensteranordnung aufrufen.

Ursprung dieses Tickets war, dass bei meinen Projekten aus DMXC 3.2.2 die noch deutlich umfangreicheren Softdesks bereits beim ersten Laden des Projekts nach dem Start der Sitzung nicht aufgerufen werden konnten, was zur Folge hat, dass das gesamte Projekt nicht mehr funktioniert. Hinterlege ich im Projekt die Softdesks einzeln in einem separaten Projekt ohne weitere Inhalte, indem ich die über die Datei “SoftdeskMaster.xml” auskommentiere, konnten alle Softdesks für sich einzeln geladen werden. Sobald aber alle “aktiv” sind, klappt dies nicht. Spannenderweise wechselst dies auch durch, wenn ich die Reihenfolge der Einträge in der Datei “SoftdeskMaster.xml” ändere.

Im Anhang findet sich das vereinfachte Testprojekt mit den speziell für dieses Ticket angelegten Softdesk sowie die Log-Dateien für einen kompletten Durchlauf, wie er oben beschrieben ist.

Kann der Kernel ein Projekt nicht speichern, weil es durch andere Anwendungen schreibgeschützt ist oder nicht gefunden werden kann, erhält der Nutzer keine Info mehr darüber. Hier sollte unbedingt eine Fehlermeldung in der GUI erscheinen, wie es auch aktuell in DMXC 3.2.x der Fall ist.

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

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.

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.

Ich habe mit der Alpha 7 ein neues Projekt erstellt. Wenn ich dieses speichere, schließe und sowohl innerhalb der laufenden Sitzung als auch nach einem kompletten Neustart von DMXC, kann ich im Anschluss die Namen der Geräte und Gerätegruppen nicht mehr ändern. Der Zweig im Projekt Explorer aktualisiert sich nicht. Aktualisiere ich den Baum durch öffnen eines anderen Ordners oder mittels des Refresh-Buttons, ist der alte Name wieder da. Ändere ich den Namen über die Properties, hängt sich die GUI auf, sodass ich sie hart beenden muss.

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.

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"