Bugtracker DMXControl 3

Ich setze ich über eine Matrix (in meinem Fall 3 Zeilen und 8 Spalten) eine beliebige Farbe und verringere danach die Größe der Matrix zum Beispiel auf 3 x 3. Danach lässt sich die gesetzte Farbe der nicht mehr einfach über Clear Programmer löschen. Um die Geräte zur “resetten” muss einmal eine beliebige Farbe manuell gesetzt werden, sodass der Programmer “frische” Werte erhält, die dann über Clear Programmer gelöscht werden können.

Hier sollte vor dem aktiv werden der neuen Matrixgröße einmal automatisch der Programmer gelöscht werden.

Hat eine Matrix weniger als 3 Zeilen, funktioniert der Farbverlauf Top nicht. Hier wird die Matrix stattdessen immer mit der Farbe 2 vollständig ausgefüllt.

Das Problem lässt sich aktuell umgehen, wenn man den Farbverlauf Bottom auswählt und die Farben entsprechend umkehrt.

Aktuell lassen sich Cuelists, Devices, etc. im Project Explorer aktuell nur sortieren, indem man einen Rechtsklick macht und dort aus dem Kontextmenü Sort einen entsprechenden Eintrag zum Sortieren wählt.

Vorteilhafter wäre es, wenn man durch das Klicken auf die jeweilige Überschrift die Einträge entsprechend sortieren kann - ähnlich wie im Windows Explorer.

Führt man einen Doppelklick im Property-Grid aus, so wird bei Feldern mit durch Semikolon getrennte Werte immer noch das Semikolon und das dahinter folgende Leerzeichen mit ausgewählt. Dies macht das schnelle Ändern gerade bei Color und Position unnötig aufwendig, da hier folglich auch immer das Semikolon mit neu gesetzt werden muss.

Ich setze im Softdesk einen Color Picker ein, um die Farben meiner LED-PARs individuell zu steuern. Wähle ich direkt eine Farbe aus (alte Farbe violett, neue Farbe grün), wird diese Farbe aktuell sofort aktiv gesetzt. Im Live-Betrieb sieht das meiner Meinung nach nicht schön aus. Deswegen der Wunsch, dass die Color Picker eine einstellbare (ggf. globale) Fadezeit erhalten, da ja auch an den meisten anderen Stellen in DMXControl 3 gefadet wird.

Die Fadezeit wird im übrigen dann nicht berücksichtigt, während der Auswahlpunkt mit der Maus gehalten wird. Liegt der Startpunkt allerdings nicht am Punkt der aktuellen Farbe, wird hier selbstverständlich gefaded.

Soll eine Cuelist mit der Option “release at last cue ends” automatisch beendet werden, funktioniert dies nicht, wenn der letzte Cue ein Special Cue ist. Aktuell hilft es nur, wenn danach noch eine leere Cue eingefügt wird.

Dieser Eintrag bezieht sich auf den Thread https://forum.dmxcontrol-projects.org/index.php?thread/12068-zwischen-cuelisten-hin-und-her-springen/.

Aktuell fehlt die Möglichkeit, MovingHeads oder Scanner einfache Linien im Raum fahren zu lassen. Mit dem Kreis-Effekt kann man zwar horizontale und vertikale Linien fahren, jedoch keine diagonalen Linien, welche so auch zum Beispiel in einem Punkt starten / enden und dann fächerartig nach außen fahren.
Folgende Parameter sollen einstellbar sein:

• Länge der Linie (Amplitude)
• Drehung in Bezug zum einstellten Mittelpunkt
• Position des Mittelpunkts als prozentuale Angabe in Bezug auf die Länge
• Frequenz (Geschwindigkeit)
• Phase (Offset)
• Pausenzeit an den Endpunkten
• Unterschiedliche Geschwindigkeitsprofile

Der Geschwindigkeitsprofile können wie folgt aussehen:

• konstante Geschwindigkeit über die gesamte Länge
• Sinus-Verteilung
• Cosinus-Verteilung
• Rampe (Beschleunigung / Bremsen innerhalb der ersten / letzten 10%, sonst konstante Geschwindigkeit)

Möchte ich das folgende alternierende Fanning erstellen, ist der zugehörige Syntax verhältnismäßig aufwendig und unter Umständen schwer auf Fehler zu untersuchen:

• Ausgabe: R R R B W W
• Syntax: 255; 0; 0 # 255; 0; 0 # 255; 0; 0 # 0; 0; 255 # 255; 255; 255 # 255; 255; 255

Um dies zu vereinfachen und die Eingabe zu beschleunigen, schlage ich die Implementierung des folgenden oder eines äquivalenten Syntax vor, um Eigenschaften wie zum Beispiel die Farbe auf nachfolgende Geräte zu übertragen:

3X 255; 0; 0 # 0; 0; 255 # 2X 255; 255; 255

Sollte die zugehörige Gruppe kleiner werden, weil zu viele Geräte deaktiviert wurden, wird einfach von Beginn an ausgegeben. Die Ausgabe sähe dann so aus:

• 3 aktive Geräte: R R R

Ergänze ich den Syntax zusätzlich um das M zum Spiegeln (siehe hierzu FS #2679), sieht die Ausgabe wie folgt aus:

• 4 aktive Geräte: R R (Spiegelachse) R R
• 8 aktive Geräte: B R R R (Spiegelachse) R R R B
• 28 aktive Geräte: R R W W B R R R W W B R R R (Spiegelachse) R R R B W W R R R B W W R R

Werden GUI und Kernel auf einem PC gemeinsam gestartet und hat sich dann auch keine weitere GUI mit dem Kernel verbunden, so kann meiner Meinung nach der Punkt “Informing connected sessions” komplett entfallen bzw. übersprungen werden. Hierdurch würde das Laden des Projekts nochmal beschleunigt werden. Hierzu brauch die GUI nur kurz beim Kernel abfahren, wie viele Verbindungen bestehen. Der Kernel selbst kennt die Anzahl ja bereits.

Es fehlt im Fenster “Master” die Möglichkeit, horizontal zu scrollen.

Aktuell werden die Group-Master in einer mir nicht ersichtlichen Reihenfolge sortiert. Hier wäre eine alphabetische Sortierung vorteilhafter bzw. noch besser, eine Sortierung analog zur Sortierung der Device Groups im Project Explorer.

Analog zum White Automix Mode sollte auch für Amber, UV und jede weitere “Sonderfarbe” abseits von RGB die Möglichkeit hinzugefügt werden, wie die Farben einzumischen sind.

Auf Basis der Diskussion im Forum https://forum.dmxcontrol-projects.org/index.php?thread/12498-wertebereich-für-color-im-device-control/ sollen folgende, vom User einstellbare Wertebereiche im Device Control geschaffen werden:

• Internal: 0.0 bis 1.0 (direkte Anzeige des Kernel-internen Werts)
• Byte: 0.0 bis 255.0 (als Double implementiert)
• Percent: 0.0 bis 100.0 (Wertebereich in %)

Gültig sollen diese Einstellungen / benutzerdefinierten Wertebereiche für folgende Funktionen sein:

• Dimmer
• Color
• PT-Speed
• Iris
• Focus
• Frost
• ggf. RAWs

Für folgende “physikalischen” Werte soll ähnlich verfahren werden:

• Frequency
• Angle
• Time

Zugehörige Funktionen wären:

• Pan / Tilt
• Strobe
• Effect-Speed
• ggf. weitere

Die Eigenschaften müssen nach Typ gruppiert werden und abhängig vom Typ gibt es entsprechende Darstellungen. So hätte der Typ “Geschwindigkeit” eher die Auswahl “BPM, Hz, ms, s” wohingegen der Typ “Intensity” die oben genannten Auswahlmöglichkeiten hat.

Um den Patch einer Matrix zu ändern muss entweder der gesamte Patch gelöscht werden oder ich muss den Dialog zur Auswahl der Geräte öffnen, dort zum verlinkten Gerät scrollen und den Haken entfernen.

Hier wäre hilfreich, wenn man direkt nach der Anwahl des betreffenden Pixels die Verknüpfung mit der Entf-Taste oder einen zusätzlichen Eintrag im Kontextmenü löschen könnte.

Sobald in einem Projekt eine Generic Matrix verwendet wird, werden in der Channel Overview die Adressbereiche der Geräte (mit den blauen Balken) nicht mehr gekennzeichnet. Löscht man die Generic Matrix wieder, werden auch die Adressbereiche wieder angezeigt.

Verändere ich den Dimmer von Geräten, die auf eine Matrix gepatcht sind, kann ich die Helligkeit der gesamten Matrix über den neuen Dimmer nicht mehr regeln. Alle Geräte, die ich manuell bzw. direkt in ihrer Helligkeit angepasst habe, gehen aus. Bei Werteänderungen flackert die Matrix bzw. die Geräte, bei denen ich die Helligkeit manuell über den Dimmer angepasst habe.

Benenne ich ein Subdevice um, wird der Name nach dem Betätigen der Enter-Taste nicht direkt aktualisiert. Aktuell muss die Ansicht einmal gewechselt werden, zum Beispiel zu einem anderen Device und dann wieder zurück.

Um die Erstellung von DDFs zu vereinfachen, sollten für eine Auswahl von LED-Farben, wie amber, ultaviolett, lime
“Standard-Arbeitsbereiche” im Kernel fest hinterlegt werden.

Die Angaben von

hueLeftBottom="0"  hueLeftTop="60" hueRightTop="60" hueRightBottom="120"

wäre dann optional und kann von Usern im DDF hinzugefügt werden, der mit der Standard-Definition nicht einverstanden ist. Die DDF-spezifischen Angaben überschreiben dann die Standard-Definition.

Ändere ich in der Tabellen-Ansicht des Patch-Fensters verschiedene DMX-Adressen stürzt die Matrix-Ansicht ab. Um die Matrix-Ansicht zu sehen, muss das Patch-Fenster einmal geschlossen und wieder neu aufgerufen werden.

Möchte man Geräte aus einer vorhandenen Stage View in eine neue, zusätzliche Stage View umsetzen, weil die erste zu voll wird oder aus anderen Gründen, muss man sich aktuell die betreffenden Geräte aus dem Device-Ordner im Project Explorer heraussuchen, der Stage View zuordnen und dann die Geräte aus der ersten Stage View löschen.

An dieser Stelle würde ich vorschlagen einen Befehl einzuführen, der eine bestimmte Auswahl von Geräten und Gruppen von einer Stage View an die gleiche Stelle in einer anderen Stage View verschiebt.

Aktuell gibt es keine Möglichkeit, die einer Stage View zugeordneten Geräte beim entsprechenden Eintrag im Project Explorer wie in den anderen Einträgen wie Device, Device Groups etc. zu sortieren.

Diese Funktion wird dann benötigt, möchte man einzelne Geräte aus einer Stage View entfernen, man hat aber bereits eine große Anzahl von Geräten der Stage View zugeordnet.

Die Fenstergröße des Programmer-Filters ist nicht optimal. Die wichtigste Spalte mit dem Geräte- und / oder Gruppen-Namen wird zu schmal dargestellt. Optimal ist eigentlich die Darstellung, wie sie im DMXC3-Tutorial, Lektion 8 zu sehen ist.

Manchmal könnte es hilfreich sein (insbesondere für Einsteiger), wenn über die Stage View ersichtlich ist, für welche Devices oder Device Groups Werte im Programmer werden. Und gerade, wenn man eine vorhandene Cue oder Preset ändert über den Befehl “Edit in Programmer”, wäre es gut zu sehen, welche Devices oder Device Groups man auswählen muss, damit man den Cue genau richtig ändert.

Dieses Highlighting könnte einfach so aussehen, dass die Icons grün hinterlegt werden.

Das Feature mit der Kommentarzeile für die DMX-Interfaces ist gut, aber gerade bei ArtNet-Interfaces wäre es hilfreich, wenn man für jedes Universum einen separaten Kommentar angeben kann.

Fehlerbeschreibung siehe oben

Im Patching Dialog wird die DMX-Adresse von Subdevices nicht wie sonst üblich im Format Universum.Adresse, sondern nur als “voller Dezimalwert” ausgegeben, das heiß zum Beispiel 513 statt 2.1.

Wird beim Manuel Beat der Faktor 1/2 gewählt und dann über Tap der Beat angepasst, wird zwar der richtige BPM-Wert anzeigt (zum Beispiel 62 BPM), die Ausgabe erfolgt mit 250 BPM (4-mal schneller als der eingegebene Takt). Umgekehrt verhält es sich, wenn der Faktor auf 2 steht und man dann den Beat anpasst. Die Anzeige gibt 250 BPM an, ausgegeben wird aber nur 62 BPM (1/4 des eigentlich eingegebenen Takts).

Beim Durchsehen der Logs von der VA vom 30.09.2017 ist mir beim Schließen des Kernels folgender Fehler unter die Finger gekommen:

2017-10-01 03:44:38,024 [40] ERROR org.dmxc.lumos.Kernel.Run.KernelRunManager - Exception when stopping Manager PluginManager: 'DMXLIB.ValueTypes.PathValue' kann nicht serialisiert werden, weil dafür kein parameterloser Konstruktor verfügbar ist.
System.InvalidOperationException: 'DMXLIB.ValueTypes.PathValue' kann nicht serialisiert werden, weil dafür kein parameterloser Konstruktor verfügbar ist.
   bei System.Xml.Serialization.TypeDesc.CheckSupported()
   bei System.Xml.Serialization.TypeScope.GetTypeDesc(Type type, MemberInfo source, Boolean directReference, Boolean throwOnError)
   bei System.Xml.Serialization.ModelScope.GetTypeModel(Type type, Boolean directReference)
   bei System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping(Type type, XmlRootAttribute root, String defaultNamespace)
   bei System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(String name, Object value, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 329.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 250.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 256.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 256.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 232.
   bei org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:Zeile 367.
   bei org.dmxc.lumos.Kernel.Resource.ResourceManager.saveResourceInternal(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Resource\ResourceManager.cs:Zeile 271.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 544.
   bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.shutdownManager() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Plugin\AbstractPluginManager.cs:Zeile 1290.
   bei org.dmxc.lumos.Kernel.Plugin.PluginManager.org.dmxc.lumos.Kernel.Run.IManager.shutdown() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Plugin\PluginManager.cs:Zeile 217.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.ManagerShutdownAction(TManager m) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 516.

Der Fehler tritt im Übrigen auch bei anderen Sitzungen auf. Einschränkungen konnte ich nicht feststellen, ich möchte ihn an dieser Stelle nur nochmal dokumentieren. Die kompletten Logs sind angehängt.

Entsprechend des beigefügten Screenshots ist zu erkennen, dass die Icons für die Buttons im Cuelist-Menü deutlich unschärfer wirken als beispielsweise die Icons im linken Bereich.

Bislang gibt es in DMXControl 3 aktuell rechteckige Matrizen. Diese lassen sich aber nur bedingt für Moving-Heads verwenden, die einen runden Kopf besitzen und die Anordnung der Pixel rund bzw. wabenförmig ist. Um diesen Fall besser zu unterstützen, schlage ich vor, ein solche radiale Matrix - oder kurz “radix” - in DMXControl 3 zu implementieren.

Möchte ich Geräte in einen eigenen Ordner verschieben, denen ein Subdevice zugeordnet ist, so lässt DMXControl dieses nicht zu.

Um einen besseren Überblick über den Beat zu haben, schlage ich in Anlehnung an DMXControl 2 folgende Anpassungen vor:

• Bereits beim ersten Klick auf den Tap-Button wird ein Beat-Signal generiert. Im Rahmen der DevCon 2018 gefixt
• Ist der Haken aktiv gesetzt, sollte über den Sync-Button auch ein manuelles Beat-Signal (ein einzelner Schritt) generiert werden.
• Der “aktive” Schritt für die Ermittlung des Beat-Wertes wird in roter Schrift angezeigt.

Ändere ich für ein Device die Default Color, so wird die neue Farbe zwar direkt richtig im Device Control und im Color Picker wiedergegeben, jedoch nicht in der Stage View. hier bleibt die Farbe weiterhin weiß.

Durch die Integration der DDFs aus der DDFLib tauchen im Dialog Add Device alle DDFs doppelt auf, auf Grund eines teilweise anderen Dateinamens der DDFs aus der DDFLib vom Installer nicht aktualisiert wurden. Hier wäre eine eindeutige Unterscheidungsmöglichkeit hilfreich.

Wird eine Cuelist Group direkt im Projekt Explorer umbenannt, so wird dieser neue Name nicht in den Dialog Cuelist Group Properties übernommen. Um der Cuelist Group einen anderen Namen zu vergeben, muss aktuell der Properties Dialog geöffnet werden.

In verschiedenen Verzeichnissen des Projekts Explorers können die Einträge nicht alphabetisch sortiert oder anderweitig in der Reihenfolge verschoben / neu geordnet werden, unter anderem in den Verzeichnissen:

• Executor
• Presets
• Files
• Item lists
• Layouts

Nach dem Beenden von DMXControl 3 waren folgende Fehlermeldungen im Log zu finden:

2018-06-03 23:02:52,774 [55] ERROR org.dmxc.lumos.Kernel.Run.KernelRunManager - Exception when stopping Manager PluginManager: Beim Generieren des XML-Dokuments ist ein Fehler aufgetreten.
System.InvalidOperationException: Beim Generieren des XML-Dokuments ist ein Fehler aufgetreten. ---> System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei DMXLIB.ValueTypes.PathValue.GetHashCode() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\DMXLIB\ValueTypes\PathValue.cs:Zeile 29.
   bei System.Collections.Hashtable.GetHash(Object key)
   bei System.Collections.Hashtable.InitHash(Object key, Int32 hashsize, UInt32& seed, UInt32& incr)
   bei System.Collections.Hashtable.ContainsKey(Object key)
   bei System.Xml.Serialization.XmlSerializationWriter.WriteStartElement(String name, String ns, Object o, Boolean writePrefixed, XmlSerializerNamespaces xmlns)
   bei Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterPathValue.Write2_PathValue(String n, String ns, PathValue o, Boolean isNullable, Boolean needType)
   bei Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterPathValue.Write3_PathValue(Object o)
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Xml.Serialization.XmlSerializer.Serialize(XmlWriter xmlWriter, Object o, XmlSerializerNamespaces namespaces, String encodingStyle, String id)
   bei System.Xml.Serialization.XmlSerializer.Serialize(Stream stream, Object o, XmlSerializerNamespaces namespaces)
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(String name, Object value, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 337.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 255.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 261.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 261.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 237.
   bei org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:Zeile 367.
   bei org.dmxc.lumos.Kernel.Resource.ResourceManager.saveResourceInternal(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Resource\ResourceManager.cs:Zeile 271.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 549.
   bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.shutdownManager() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Plugin\AbstractPluginManager.cs:Zeile 1288.
   bei org.dmxc.lumos.Kernel.Plugin.PluginManager.org.dmxc.lumos.Kernel.Run.IManager.shutdown() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Plugin\PluginManager.cs:Zeile 217.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.ManagerShutdownAction(TManager m) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 516.

Beim durchsehen der Logs ist mit folgender Fehler aufgefallen:

2018-06-08 21:25:42,859 [47] ERROR org.dmxc.lumos.Kernel.Devices.DeviceBeam - Unknown Exception when invoking the HAL: h (Hue) has to be between 0 and 360
Parametername: h
Der tatsächliche Wert war -1.
System.ArgumentOutOfRangeException: h (Hue) has to be between 0 and 360
Parametername: h
Der tatsächliche Wert war -1.
   bei org.dmxc.lumos.Kernel.HAL.Handler.Color.CustomColorLogic.calculate(Double h, Double s, Double v) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Color\CustomColorLogic.cs:Zeile 190.
   bei org.dmxc.lumos.Kernel.HAL.Handler.Matrix.ColorBridgeHandlerNode.handleColorAndDimmerValue(LumosColor lc, Double dimmer, HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Color\ColorBridgeHandlerNode.cs:Zeile 285.
   bei org.dmxc.lumos.Kernel.HAL.Handler.Matrix.ColorBridgeHandlerNode.handleColorValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\Color\ColorBridgeHandlerNode.cs:Zeile 222.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractHandlerNode.handleValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractHandlerNode.cs:Zeile 441.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.handlePropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 336.
   bei org.dmxc.lumos.Kernel.Devices.DeviceBeam.pushPropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Devices\DeviceBeam.cs:Zeile 219.

In vielen Fällen liegen auf einem DMX-Kanal mehrere individuelle Funktionen mit ihren eigenen Regelbereichen, hier zum Beispiel beim GLP YPOC 575 PRO:

<raw dmxchannel="13" name="Special">
  <step caption="Open" mindmx="0" maxdmx="15" />
  <range type="Goboshake 10°" mindmx="16" maxdmx="31" minval="3.5" maxval="60" />
  <range type="Goboshake 20°" mindmx="32" maxdmx="47" minval="3.5" maxval="60" />
  <range type="Goboshake 30°" mindmx="48" maxdmx="63" minval="3.5" maxval="60" />
  <range type="Color Chaser 1" mindmx="64" maxdmx="79" minval="3.5" maxval="60" />
  <range type="Color Chaser 2" mindmx="80" maxdmx="95" minval="3.5" maxval="60" />
</raw>

Alle Funktionen sind Funktionen wie beispielsweise auch diverse Automatik-Programme bei LED-Scheinwerfern, die die HAL nicht direkt unterstützt und deswegen über raw-Funktionen abgebildet werden müssen. Hier wäre mein Vorschlag eine Möglichkeit für die raw-Funktion zu schaffen, die beispielsweise ähnlich zur Implementierung der unterschiedlichen Strobe-Mobi arbeitet: man erhält im Device Control ein Dropdown-Menü zum Auswählen der Gerätefunktion und dazu einen Regler zum Auswählen der Geschwindigkeit o. ä. Die Implementierung könnte vielleicht etwas abgewandelt zum oben aufgeführten Beispiel erfolgen.

Weil ich auf die lustige Idee kam, im DDF für den Martin MAC 600 ein zweites Prisma definieren, habe ich im Kernel folgende Fehlermeldung produziert:

2018-06-12 22:51:23,407 [20] ERROR org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory - TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht.
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.InvalidOperationException: There are two Handlers for the same Property: Prism
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.BuildRegistry() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 196.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.parseXmlFile(DDFParseContext context) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 65.
   bei org.dmxc.lumos.Kernel.Devices.DeviceBeam..ctor(IDevice parentDevice, UInt32 beamNumber, DDFParseContext context) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Devices\DeviceBeam.cs:Zeile 82.
   bei org.dmxc.lumos.Kernel.Devices.DMXDevice.parseDDF(XmlDocument ddf, String filename) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Devices\DMXDevice.cs:Zeile 336.
   bei org.dmxc.lumos.Kernel.Devices.DMXDevice.set_DDFSourceFile(String value) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Devices\DMXDevice.cs:Zeile 118.
   bei org.dmxc.lumos.Kernel.Devices.Factory.DMXDeviceFactory.createNewInstance(DeviceMetadata m, IDevice parent) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Devices\Factory\DMXDeviceFactory.cs:Zeile 40.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.createNewDevice(DeviceMetadata data, IDevice parentDevice) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 431.
   bei org.dmxc.lumos.Kernel.Project.DeviceManager.createNewDevice(DeviceMetadata data) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Project\DeviceManager.cs:Zeile 418.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.createDevice(DeviceMetadata m) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 1049.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 59.

Das DDF mit dem auskommentierten zweiten Prisma und die kompletten Logs der Sitzung sind beigefügt.

Ich habe in einem Projekt drei meiner vier angelegten Executoren mit Cuelists verknüpft. Im Baum des Project Explorers wird aber nun ein anderes Icon verwendet, welches den Status “Cuelist verknüpft” darstellt als in der Tabellenübersicht. Im Anhang befindet sich ein entsprechender Screenshot.

Für Live-Anwendungen wäre es hilfreich, wenn das Beat Tool über externe Steuerelemente wie MIDI oder Tastatur ansteuerbar wäre.

Für Live-Anwendungen wäre es hilfreich, wenn die Befehle Blackout, Freeze etc. über externe Steuerelemente wie MIDI oder Tastatur ansteuerbar wären.

Trägt man ein Fanning in die Go-To-Time, Go-Back-Time und Release-Time ein, so wird dies zwar akzeptiert und auch gespeichert. Der Kernel verwendet aber nur die erste Zahl des Fannings als entsprechende “Arbeitszeit” und ignoriert das Fanning komplett.

Hier sollte entweder eine Fehlermeldung aufkommen, dass eine solche Eintragung nicht zulässig ist oder dieses Feature unterstützt werden.

Mir ist ein Gerät unter die Finger gekommen, wo über einen Modus-Kanal ähnlich beim Futurelight DMH-160 Funktionen ausgewählt werden müssen. Bei dieser LED-Bar wird zwischen der Dimmer und Strobe-Funktion umgeschaltet. Wenn ich dies aber nun über den Support-Handler realisiere, ignoriert der Kernel die zweite Defintion (in diesem Fall die der Strobe-Funktion). Es wird entsprechend des folgenden DDFs immer nur die Dimmer-Funktion aktiviert. Ziehe ich den Regler für Strobe hoch, wechselt der Support-Handler die Auswahl nicht.

<?xml version="1.0" encoding="utf-8" ?>
<device image="Showlite LED Stage Bar 216x10mm.png" type="DMXDevice" dmxcversion="3.1.2" ddfversion="1.0">
  <information>
    <model>LED Stage Bar 216 x 10</model>
    <vendor>Showlite</vendor>
    <author>Stefan Kistner</author>
  </information>
  <functions>
    <rgb>
      <red dmxchannel="2" />
      <green dmxchannel="3" />
      <blue dmxchannel="4" />
    </rgb>
    <dimmer dmxchannel="1">
      <support dmxchannel="0" name="dimmer" />
      <range type="linear" mindmx="0" maxdmx="255" minval="0" maxval="100" >
        <step handler="support-dimmer" mindmx="0" maxdmx="7" />
      </range>
    </dimmer>
    <strobe dmxchannel="1">
      <support dmxchannel="0" name="strobe" />
      <range type="linear" mindmx="0" maxdmx="255" minval="0" maxval="20" >
        <step handler="support-strobe" mindmx="8" maxdmx="15" />
      </range>
    </strobe>
  </functions>
</device>

Werden im Cue Timing Editor von der eigentlich Fade und Delay-Zeit abweichende Werte vergeben, erhält der User hierüber keine Information, dass in der betreffenden Cue der Cue Timing Editor aktiv ist. Hier sollte eine entsprechende Kennzeichnung bzw. Hervorhebung der Cue eingefügt werden.

Werden im Cue Timing Editor zu einer Cue die Delay und Fade-Zeiten für einzelne Geräte einer Gruppe geändert, die gesamte Gruppe aber keine Werte enthält, gibt es hierüber kein visuelles Feedback. Folgende Lösungsvorschläge könnte ich mir hier vorstellen:

• Die Zellen in der oberen Zeile für die Gruppe werden ausgegraut (oder anderweitig farblich hervorgehoben), sollte in der betreffenden Spalte ein Wert für ein einzelnes Gerät einer Gruppe geändert worden sein.
• Sobald ein Wert für ein einzelnes Gerät geändert wurde, klappt der Cue Timing Editor die zugehörige Gruppe automatisch auf.

Im Rahmen einer Rückfrage im Forum erinnere ich mich gerade an eine tolle Sache, die DMXControl 2 beim Beenden der Software besser oder anders macht, als DMXControl 3. Gibt DMXControl 2 nämlich DMX-Werte aus, so bleiben diese im Interface auch noch nach dem Beenden von DMXControl 2 im Interface gesetzt. DMXControl 3 arbeitet hier anders und überschreibt beim Beenden des Kernels alle zuvor gesetzten DMX-Werte mit 0.

In meinen Club-Projekten kann ich dank der Arbeitsweise von DMXControl 2 zum einen den PC nach Feierabend schon vorzeitig herunterfahren, während ein Teil der Scheinwerfer noch als “Putzlicht” eingeschaltet bleibt. Ein zweiter Vorteil ist, dass im Falle eines Neustarts des PCs während der Veranstaltung das Effektlicht während des Neustarts des PCs im letzten Zustand verharrt und die Tanzfläche erst mit dem erneuten Starten von DMXControl 2 kurzzeitig dunkel wird.

Dieses Feature soll mit Hilfe der Freeze-Funktion realisiert werden. Ist diese aktiviert und DMXControl 3 wird beendet, bleiben die eingefrorenen DMX-Werte erhalten, auch wenn der Kernel geschlossen ist. Somit kann universell und leicht zugänglich die Einstellung situationsabhängig gesetzt werden. Für Anwender, die diese Funktion dauerhaft benötigten, wird in den Applications Settings der Eintrag “Freete on exit” für den Kernel mit den Einstellmöglichkeiten “true” oder “false” hinzugefügt.

Der Colorbridge fehlen noch zwei Parameter, mit denen ich den “aktiven” Hue Bereich der gepatchten Geräte festlegen kann. Diese Parameter werden benötigt, um folgendes Szenario besser abbilden zu können:

In einem Projekt werden zwei Generic Dimmer mit der Farbe rot und blau belegt und auf eine ColorBridge gepatcht. Wählt man über die ColorBridge die Farbe violett aus, bleiben die beiden Generic Dimmer dunkel.

Da die GUI aktuell viel mit der Maus bedient werden muss, schlage ich vor, dass die Werte in möglichst allen Eingabefeldern (Device control, Device properties, Cuelist properties etc.) auch über das Mausrad gesetzt und insbesondere verändert werden können. Aus meiner Sicht ist dies nochmal einfacher und schneller, als wenn man im Device Control zum Beispiel zum Einstellen des Focus noch die Klicks ausführt, um an den Schieberegler zu gelangen. Gerade bei beengten Platzverhältnissen und schlechten Untergründen (für eine Maus) sollte man hier bessere Ergebnisse erzielen.