Bugtracker DMXControl 3

Im Project Explorer wird im Kontextmenü zum Ordner Devices der Eintrag Add Device nicht angezeigt. Dies betrifft sowohl den Menübaum links als auch die Tabelle rechts, wenn ich das Kontextmenü dort aufrufe. In der Menüleiste des Projects Explorers sowie im Kontextmenü der Stage View ist der Eintrag aber noch enthalten.

Gelegentlich passiert es, dass der Programmer die richtige Anordnung der Einträge in der Menü-Leiste verliert. Beispiele sind im Anhang beigefügt. Eine mögliche Ursache scheint zu sein, dass die einzelnen Menüelemente nicht fixiert sind, was anhand der sechs senkrechten Punkte zu Beginn jedes Menüelements zu sehen ist.

Meiner Meinung nach sollte überlegt werden, wie sich vor allem das Group Handling schneller erreichen lässt. Ich finde es ein richtig starkes Feature, was aber aktuell ein wenig zu sehr versteckt ist und deswegen beim produktiven Arbeiten über das Dropdown-Menü etwas umständlich zu erreichen ist. Überlegungen wären hier:

• Das Group Handling erhält einen eigenen Reiter innerhalb des Device Controls (neben den Reitern Properties und Effects).
• Für das Group Handling wird ein komplett separetes Fenster losgelöst vom Device Control geschaffen, sodass (genügend Bildschirmfläche vorausgesetzt) Group Handling und Device Control neben- oder untereinander angezeigt werden können.

Das Plugin übernimmt nicht die Werte aus dem Programmer, hat man als erstes eine Auswahl von Geräten positioniert, verändert die Position eines einzelnes Geräts dieser Auswahl und wählt dann wieder die ursprünglichen Geräte wieder erneut aus. Der Programmer wird bei der Position auf den Wert 0 zurückgesetzt.

Für genaue Fehlerbeschreibung siehe Thread Pan/Tilt Ausgangsposition verändern im Forum.

Nutze ich in einem DDF für das rgb-Tag als untergeordnete Elemente die cw-Tags und ww-Tags, werden die Werte im Device Control bei Color nicht gemäß der Einstellungen in der GUI skaliert / umgerechnet. Hier ist weiterhin die Wertebereich von 0 bis 1 aktiv.

Füge ich Geräte einer vorhandenen Gruppe hinzu, werden die Icons der Devices zwar an der richtigen Stelle in der Stage View platziert. Das Icon einer vorhandenen Gruppe, die dann auch vorher in der Stage View positioniert war, wird hierbei das Icon an die neue Position verschoben. Hierbei macht es keinen Unterschied, ob die Icons in der Stage View gelockt sind oder nicht.

Möchte ich in einer Cue zum Beispiel den Namen der Cue ändern und drücke die Tasten Pos1 und Entf hintereinander, lösche ich mir ganz schnell mehrere Cues.

Eigentlich erwarte ich nämlich, dass der Cursor in der Zelle mit dem Namen beim Drücken von Pos1 vor das erste Zeichen springt und ich dann mit der Taste Entf Zeichen des Namens löschen kann. Stattdessen wird mit dem Drücken der Taste Pos1 die gesamte Zeile ausgewählt und dadurch mit dem Drücken der Taste Entf die gesamte Cue gelöscht. Ist man dann zu stürmisch, löscht man sich auf diesem Wege unter Umständen die gesamte Cuelist.

Ich habe gerade festgestellt, dass folgender Code im DDF anstandslos funktioniert.

<fog dmxchannel="0">
  <step type="off" mindmx="0" maxdmx="31" />
  <range type="fog" mindmx="32" maxdmx="255" minval="50" maxval="100" />
</fog>

Allerdings wird der im DDF hinterlegte Wertebereich nicht ins Device Control übernommen. Hier wird weiterhin ein Wertebereich von 0% bis 100% angezeigt und im Programmer abgelegt.

Mir ist in einem DDF folgende Implementierung unter die Finger gekommen:

<dimmer dmxchannel="5" mindmx="8" maxdmx="134" minval="0" maxval="100" />

Dieser Syntax funktioniert in DMXControl 3 so nicht. Eigentlich müsste es richtig lauten:

<dimmer dmxchannel="5">
  <range type="linear" mindmx="8" maxdmx="134" minval="0" maxval="100" />
</dimmer>

Um hier Unstimmigkeiten zu vermeiden schlage ich vor, dass solche Implementierungen wie oben vom Kernel grundsätzlich als fehlerhaft gekenntzeichnet werden, um keinen “Wildwuchs” im DDF-Syntax zu erhalten.

Fügt man ein neues Interface hinzu, werden diese automatisch fortlaufend auf die DMX-Universen gepatcht. Dies wird gerne von Einsteigern übersehen, gerade wenn man erst das Art-Net-Plugin und dann im Nachgang noch ein USB-Interface hinzufügt. Genau genommen ist dies für den Moment ein unerwünschtes Verhalten.

Daher schlage ich vor, dass neu hinzugefügte Interfaces immer auf das 1. DMX-Universum gesetzt werden. Interfaces, die mehrere Universen unterstützen, wie zum Beispiel das Art-Net-Plugin, werden auf die möglichen DMX-Universen verteilt - sprich DMX-Universum 1 bis 4 für das aktuelle Art-Net-Plugin. Möchte ein User mit mehreren DMX-Universen über mehrere USB-Interfaces arbeiten, so soll der das bewusst umstellen. Gleiches soll auch für den Patch des DMX-In gelten.

Ich habe mittlerweile zwei Geräte, bei denen ich Farb-Presets wählen kann, die Weißlicht mit verschiedenen Farbtemperaturen ausgeben. Parallel kann ich aber für beide Geräte über RGB auch individuelle Farben generieren. Um die Implementierung im DDF möglichst einfach zu halten, wäre mein erster Vorschlag, im Tag colortemp analog zum virtuellen Farbrad, über das Attribut enableRGB die Farbauswahl über den Colorpicker zu aktivieren. Die Geräte lassen nämlich analog zum virtuellen Farbrad nur entweder die Farbauswahl über den Colorpicker oder die Auswahl der Weißlicht-Presets zu.

<colortemp dmxchannel="0">
  <step type="enableRGB" mindmx="0" maxdmx="9"/>
  <range mindmx="10" maxdmx="255" minval="2700" maxval="8000" />
</colortemp>

Vorteile dieser Lösung wären:

• Die HAL kann beim Arbeiten mit weiteren Geräten bei der Farbe weiß ihre Vorteile ausspielen und die Geräte auf die gleiche Farbtemperatur setzen, während das virtuelle Farbrad hier nur bedingt weiterhelfen kann.
• Die Lösung ist für den User deutlich schneller und einfacher eingebaut.
• Es wird vorhandener Code wiederverwendet und keine weitere Sonderlösung generiert, da die HAL bereits beim virtuellen Farbrad den passenden DMX-Wert setzt, sobald wieder eine Farbe über dne Colorpicker ausgewählt wird.
• Schöneres GUI-Element zum Auswählen des gewünschten Farbmakros.

Eine Alternativ-Implementierung könnte über den Support-Handler laufen, allerdings lässt DMXControl im red-, green-, blue-Tag etc. keine step-Elemente zu. Somit kann die folgende Variante dem Projekt nicht hinzugefügt werden.

<rgb>
  <support dmxchannel="4" name="color" />
  <red dmxchannel="0" >
    <step handler="support-color" mindmx="0" maxdmx="9" />
  </red>
  <green dmxchannel="1">
     <step handler="support-color" mindmx="0" maxdmx="9" />
  </green>
  <blue dmxchannel="2">
     <step handler="support-color" mindmx="0" maxdmx="9" />
  </blue>
  <amber dmxchannel="3">
     <step handler="support-color" mindmx="0" maxdmx="9" />
  </amber>
</rgb>
<colortemp dmxchannel="4">
  <range mindmx="10" maxdmx="255" minval="2700" maxval="8000" defaultval="0" />
</colortemp>

Da das kleine Tool durchaus öfters zum Einsatz kommt und ja sowohl für das DE- als auch für das Nodle-Interface funktioniert, dürfte es meiner Meinung nach hilfreich sein, wenn der Installer eine entsprechende Verknüpfung im Startmenü hinzufügt.

In der Stage View können die Icons für die Geräte nicht auf eine Größe unterhalb von 32 x 32 Pixel, zum Beispiel 24 x 24 oder 16 x 16 veringert werden. Die Stage View ignoriert diese Werte in den Device Properties.

Es kommen ja mit DMXControl 3.2 weitere Master hinzu. Öffne ich nun das zugehörige Master-Fenster, werden mir alle Gruppen entsprechend untereinander angezeigt und jeder Master innerhalb der Gruppe in horizontaler Richtung. Dies führt bei größeren Projekten dazu, dass innerhalb des Fensters viel hin und hergescrollt werden muss, wenn entsprechend viele Master angelegt sind.

Für eine ständige Benutzung im Live-Betriebt wird in der Tat das Softdesk oder ein entsprechender Controller der bessere Ort bzw. Weg sein, die Master anzusteuern. Möchte man aber “mal eben” etwas korrigieren, was weder auf dem Softdesk, noch auf einem anderen Controller liegt, wird dies aktuell in diesem Fenster eher unübersichtlich.

Daher möchte ich anregen:

• Variante 1: Die Masterfenster werden grundsätzlich aufgeteilt und jeder Master erhält sein eigenes Fenster, was sich dann auch beliebig und platzsparender auf dem Bildschirm positioniert werden kann.
• Variante 2: Es wird nur die Aufteilung innerhalb des einigen Masterfensters optimiert und auf zwei Zeilen mit der Aufteilung Special Master und Group Master in Zeile 1 und Speed Master und Playback Master in Zeile 2 reduziert. Da bei DMXControl 3.2 festgelegt werden kann, ob ein Group Master angelegt werden soll und Speed und Playback Master generell Master sind, die vom User manuell erzeugt werden, wird der Platz in dem einen Fenster deutlich besser genutzt und man kommt als User bei kleinen Projekten möglicherweise ohne zu Scrollen an alle erforderlichen Master.

Im Log von DMXControl 3.2 Build 1042 ist mit folgender Fehler aufgefallen. Vollständige Logs finden sich im Anhang.

2018-09-06 19:28:14,863 [Log-Thread] ERROR org.dmxc.lumos.Kernel.HAL.Handler.AbstractRangesHandlerNode - Unable to process invalid Value 0:    bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractRangesHandlerNode.handleNumericValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractRangesHandlerNode.cs:Zeile 382.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractHandlerNode.handleValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractHandlerNode.cs:Zeile 447.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.handlePropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 329.
   bei org.dmxc.lumos.Kernel.Devices.DeviceBeam.pushPropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Devices\DeviceBeam.cs:Zeile 221.
   bei org.dmxc.lumos.Kernel.DeviceProperties.AbstractDeviceProperty`1.afterPropertyValueSet(HALHandleContext ctx, Boolean invokeHal) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\DeviceProperties\AbstractDeviceProperty.cs:Zeile 212.
   bei org.dmxc.lumos.Kernel.DeviceProperties.AbstractDeviceProperty`1.setCurrentValue(HALHandleContext ctx, Boolean invokeHal) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\DeviceProperties\AbstractDeviceProperty.cs:Zeile 201.
   bei org.dmxc.lumos.Kernel.DeviceProperties.AbstractDeviceProperty`1.setCurrentValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\DeviceProperties\AbstractDeviceProperty.cs:Zeile 185.
   bei org.dmxc.lumos.Kernel.Mixer.DMXCMixer.setPropertyValueInternal(IPropertyValue value, IMixable source) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Mixer\DMXCMixer.cs:Zeile 692.
   bei org.dmxc.lumos.Kernel.Mixer.DMXCMixer.setPropertyValue(IPropertyValue value, IMixable source) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Mixer\DMXCMixer.cs:Zeile 580.
   bei org.dmxc.lumos.Kernel.Mixer.DMXCMixer.processRegisterValues(RunContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Mixer\DMXCMixer.cs:Zeile 438.
   bei org.dmxc.lumos.Kernel.Run.MainProcessRunable.ActionBag.Invoke(RunContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Run\Thread\MainProcessRunable.cs:Zeile 51.
   bei org.dmxc.lumos.Kernel.Run.MainProcessRunable.processActions(RunContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Run\Thread\MainProcessRunable.cs:Zeile 297.
   bei org.dmxc.lumos.Kernel.Run.ThreadWrapper.WrappedStart() in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Run\Thread\ThreadWrapper.cs:Zeile 204.
   bei System.Threading.ThreadHelper.ThreadStart_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.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   bei System.Threading.ThreadHelper.ThreadStart()

Verändere ich auf meinem Test-Notebook die Größe der Stage View, indem ich das Device Control auf der rechten Seite oder die Control Windows an der Unterseite in ihrer Größe ändere, stürzt die Stage View reproduzierbar ab.

Die betreffenden Logfiles habe ich beigefügt.

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.

Aktuell fragt DMXControl 3 über drei verschiedene Fenster ab, ob die Software beendet werden soll. Um dieses zu vereinfachen, sollen die Fenster zusammengefasst und die gewünschten Einstellungen in einem Fenster aufgelistet werden.

Möchte ich den Patch einer ColorBridge nachträglich ändern, muss ich aktuell nochmal alle Geräte neu auswählen. Die Auswahl wird bei jedem Öffnen des Patching-Fensters für die ColorBridge zurückgesetzt.

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.

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.

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.

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.

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>

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.

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

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

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.

Wird im einem Projekt ein Scheinwerfer in eine andere DMX-Adresse (sowohl innerhalb eines Universums als auch beim Wechsel in ein neues Universum) verschoben, werden die DMX-Werte für folgende Eigenschaften an der Zieladresse bzw. im Zieluniversum nicht aktualisiert:

• Position
• Strobetype
• Support-Handler
• Color
• Gobo
• Prism

In der Beta 3 von DMXControl 3.1.2 liegt möglicherweise ein Bug vor, weswegen über Art-Net nur ein DMX-Universum ausgegeben werden kann. Getestet und reproduziert werden kann das Problem mit zwei verschiedenen PCs mit unterschiedlichen Betriebssystemen (Windows 7 und Windows 10) sowie zwei verschiedenen Art-Net-Nodes. Die Konfiguration ist im beigefügten Screenshot dokumentiert.

Nach dem Starten von DMXControl 3 Beta 3 und dem Hinzufügen von einer größeren Anzahl von Geräten zu einem neuen, leeren Projekt, ist die GUI mit folgendem Vermerk im Log abgestürzt.

2018-06-14 17:25:18,885 [ConnectionManager-MessageDispatcher] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Die Auflistung wurde geändert. Der Enumerationsvorgang kann möglicherweise nicht ausgeführt werden.
System.InvalidOperationException: Die Auflistung wurde geändert. Der Enumerationsvorgang kann möglicherweise nicht ausgeführt werden.
   bei System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
   bei System.Collections.Generic.Dictionary`2.Enumerator.MoveNext()
   bei System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   bei System.Linq.Enumerable.<SelectManyIterator>d__16`2.MoveNext()
   bei System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
   bei Lumos.GUI.ChannelOverview.PatchMatrixControl.CreateOverlayRectangles(Nullable`1 previewIndex, Int32 cellWidth, Int32 cellHeight, Rectangle clientInnerRectangle, MatrixItemOverlay overlay) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\PatchMatrixControl.cs:Zeile 635.
   bei Lumos.GUI.ChannelOverview.PatchMatrixControl.CalculateItemOverlayRectangles() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\PatchMatrixControl.cs:Zeile 553.
   bei Lumos.GUI.ChannelOverview.PatchMatrixControl.OnOverlayPropertyChanged(Object sender, PropertyChangedEventArgs e) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\PatchMatrixControl.cs:Zeile 693.
   bei Lumos.GUI.ChannelOverview.MatrixItemList`1.OnCellPropertyChanged(Object cell, PropertyChangedEventArgs e) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\MatrixItemList.cs:Zeile 213.
   bei Lumos.GUI.ChannelOverview.MatrixItemList`1.OnMatrixItemPropertyChanged(Object sender, PropertyChangedEventArgs e) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\MatrixItemList.cs:Zeile 225.
   bei Lumos.GUI.ChannelOverview.Lib.PropertyNotificationObject.OnPropertyChanged(String propertyName) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\Lib\PropertyNotificationObject.cs:Zeile 118.
   bei Lumos.GUI.ChannelOverview.Lib.PropertyNotificationObject.OnPropertyChanged[T](Expression`1 propertyExpression) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\Lib\PropertyNotificationObject.cs:Zeile 108.
   bei Lumos.GUI.ChannelOverview.Lib.PropertyNotificationObject.ChangeProperty[TValue](Expression`1 property, TValue& originValue, TValue newValue, Action propertyChanged, Action propertyChanging) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\Lib\PropertyNotificationObject.cs:Zeile 97.
   bei Lumos.GUI.ChannelOverview.DMX.DmxDeviceItemOverlay.set_DeviceName(String value) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosControls\PatchMatrixControl\DMX\DmxDeviceItemOverlay.cs:Zeile 47.
   bei Lumos.GUI.Windows.DmxOutputPatching.<>c__DisplayClass55_0.<device_NameChanged>b__0(DmxDeviceItemOverlay c) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Windows\dmxOutput\DmxOutputPatching.cs:Zeile 865.
   bei LumosLIB.Tools.LumosTools.ForEach[T](IEnumerable`1 source, Action`1 action) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosLIB\src\Tools\LumosTools.cs:Zeile 1017.
   bei Lumos.GUI.Windows.DmxOutputPatching.device_NameChanged(Object sender, String newValue) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Windows\dmxOutput\DmxOutputPatching.cs:Zeile 865.
   bei Lumos.GUI.Facade.FacadeChangedEvent`1.Invoke(Object sender, T newValue)
   bei Lumos.GUI.Facade.Devices.DeviceFacade.OnNameChanged(String name) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Facade\Devices\DeviceFacade.cs:Zeile 745.
   bei Lumos.GUI.Facade.Devices.DeviceFacade.OnPropertyChangedMessage(PropertyChangedMessage m) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Facade\Devices\DeviceFacade.cs:Zeile 705.
   bei Lumos.GUI.Facade.AbstractFacade`1.onMessage(IMessage message) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Facade\AbstractFacade.cs:Zeile 94.
   bei Lumos.GUI.Connection.ConnectionManager.onMessage(IMessage message) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Connection\ConnectionManager.cs:Zeile 815.
   bei Lumos.GUI.Connection.ConnectionManager.messageDispatcherRun() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\LumosGUI\src\Connection\ConnectionManager.cs:Zeile 878.
   bei System.Threading.ThreadHelper.ThreadStart_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.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   bei System.Threading.ThreadHelper.ThreadStart()

Die Logs von Kernel und GUI befinden sich im Anhang.

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.

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.

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.

Im Normalfall springt der Colorpicker zurück auf weiß, sobald man einen Doppelklick ausführt. Ist zu dem Zeitpunkt aber die Color Bridge ausgewählt, wird die DMX-Ausgabe und die Stage View eingefroren. Alleinig die Werte für Color im Device Control springen auf weiß zurück.

Füge ich einem leeren Projekt neue Geräte hinzu und speichere das Projekt ab, kommt im Log des Kernels ein Warnhinweis, der vermuten lässt, dass die DDFs inkl. Bild und Icons nicht im Projekt-zip abgespeichert wurden. Tatsächlich wurden die Daten ordnungsgemäß gespeichert. Dies könnte zu unnötigen Irritationen führen.

2018-06-07 20:44:36,479 [53] DEBUG org.dmxc.lumos.Kernel.Project.ProjectManager - Session SKI-DSK-M4A89GA is saving Project New Project to Temp\9c9e8daa-102f-4e8a-b851-ca4436702e41.tmp.
2018-06-07 20:44:46,208 [53] WARN  org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore - Following Resources could not be saved in Project: LibDevices\Images\Futurelight DMH-160.png
LibIcons\Futurelight DMH-160 Gobo 1 (Rad 1).png
...
LibIcons\Futurelight DMH-160 Gobo 7 (Rad 1).png
LibIcons\Futurelight DMH-160 Gobo 1 (Rad 2).png
...
LibIcons\Futurelight DMH-160 Gobo 7 (Rad 2).png
LibDevices\Futurelight DMH-160 (Extended-Mode).xml
LibDevices\Images\Futurelight DMB-160.png
LibIcons\Futurelight DMB-160 Gobo 1.png
LibIcons\Futurelight DMB-160 Gobo 2.png
...
LibIcons\Futurelight DMB-160 Gobo 17.png
LibDevices\Futurelight DMB-160 (Extended-Mode).xml
Devices\Images\IMG-000253.png
Icons\ICON-000574.png
Icons\ICON-000590.png
...
Icons\ICON-000588.png
Devices\Clay Paky Alpha Spot QWO 800 (Standard).xml
2018-06-07 20:44:46,603 [53] DEBUG org.dmxc.lumos.Kernel.Resource.FileAccessUtil - Deleted C:\Users\Stefan\AppData\Roaming\DMXControl Projects e.V.\DMXControl\Kernel\Temp\92f55e50-3983-438a-9e2c-2ac11217f065.tmp
2018-06-07 20:44:46,922 [47] INFO  org.dmxc.lumos.Kernel.GUISession.Session - Saved Project to GUI SKI-DSK-M4A89GA, Path F:\Verein\DMXControl Projects\Software\DMXControl 3\Testprojekte\Beta-Test V3.1.2 Beta 3 (Testprojekt 3) (SKI-DSK-M4A89GA).zip

Der Auszug aus den Log ist aus Gründen der Übersichtlichkeit im Bereich der aufgelisteten Icons gekürzt.

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.

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

Wird das DDF aus dem Eintrag  FS#3064  einem neuen Projekt hinzugefügt, Shutter und Dimmer geöffnet und ein beliebiges Gobo vom rotierenden Goborad gewählt, geht die Stage View davon aus, dass die Goborotation aktiviert ist. Der DMX-Wert 7 auf DMX-Kanal 14 und 128 auf DMX-Kanal 15 stehen aber gemäß Handbuch und gemäß tatsächlicher Ausgabe für ein indiziertes Gobo mit einer Position von 180°.

Bei der Verwendung des Support-Handlers gibt es aktuell noch einen Konflikt, wenn folgendes Szenario eintritt:

• Angefügtes DDF einem leeren Projekt hinzufügen
• Ein beliebiges Gobo auf dem ersten Goborad auswählen
• Goboshake aktivieren
• Im Nachgang die Goborotation oder die Goboindizierung einschalten

Sind die oben genannten Schritte abgearbeitet, läuft der Goboshake nicht mehr. Erst wenn der Wert für den Goboshake verändert wird, läuft zum Beispiel die Kombination aus Goborotation und Goboshake.

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.

Sowohl bei leeren Cuelist Groups als auch bei gefüllten Cuelist Groups stehen nicht alle Cuelists zur Auswahl als Master-Start bzw. Master-Stopp-Cuelist zur Verfügung, die im Projekt anlegt bzw. der Cuelist Group zugeordnet wurden.

Sofern die Liste abhängig von den der Cuelist Group hinterlegten Cuelists ist, so wird diese Liste in den Dropdown-Menüs nicht aktualisiert.

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.

Werden mit Hilfe der Copy&Paste-Funktion vorhandene Cues in neue Cuelists kopiert, werden Werte und Einstellungen nicht vollständig aus dem Programmer entfernt und tauchen beim Erstellen neuer Cues wieder im Programmer auf.

Das Problem lässt sich wie folgt reproduzieren:

• Neues Projekt mit zwei Gerätegruppen und darin zugeordneten Geräten anlegen
• Eine beliebige Cue erstellen und in der ersten Cuelist abspeichern
• Ersten Cue mittels Edit in Programmer wieder ändern
• Werte über Copy&Paste auf die zweite Gerätegruppe übertragen und Cue in der zweiten Cuelist oder als neuen Cue abspeichern

Von nun an tauchen Einträge im Programmer auf, die gar nicht angelegt wurden. Diese lassen sich temporär auch nur aus dem Programmer entfernen, wenn kein Gerät oder keine Gruppe ausgewählt ist. Sobald man einen neuen Cue vorbereitet und Werte im Programmer ankommen, tauchen die fehlerhaften Einträge wieder auf.

Wählt man nur eine Zelle innerhalb einer Cuelist aus, kann der betreffende Cue über das Kontextmenü zwar ausgeschnitten, kopiert und wieder eingefügt werden. Die Funktion Cue löschen funktioniert an dieser Stelle nicht. Hierzu muss aktuell die gesamte Zeile der Cue ausgewählt werden.

Übersteigt das Input Assignment eine bistimmte Anzahl von Verknüpfungen, lässt sich dieses in Folge der oben genannten Fehlermeldung in der GUI nicht mehr bearbeiten. Erst wenn die Anzahl durch Löschen von verknüpften Buttons oder von gesteuerten Cuelists unter die “Grenze” reduziert wurde, ist wieder eine Bearbeitung möglich. Die zugehörigen Logs sind im Anhang beigefügt.

Auf Grund einer System.OutOfMemoryException kam es zu einem Absturz der GUI. Logeintrag bei Systemzeit 2018-04-19 20:51:43,531. Log für Kernel und GUI im Anhang beigefügt.

Bei einigen Geräten unter anderem von Robe und Martin werden Goboshake, Goborotation und Goboindex in Abhängigkeit des zugeordneten Wertebereichs vom Gobokanal aktiviert. Dabei ist die Goboshake-Funktion meist immer als “Aufsatz” zur Goboindizierung oder Goborotation verfügbar. Diese Konstellation kann aktuell nicht vollständig und vor allem fehlerfrei abgebildet werden.

Um hier die DDFs an dieser Stelle zu vereinfachen, schlage ich folgenden Beispielcode vor (hier für den Robe Robin 600E Spot):

<step type="gobo" mindmx="4" maxdmx="7" val="Robe Robin 600e Spot Gobo 1 (Rad 1).png" caption="Gobo 1">
  <range handler="goboshake" mindmx="4" maxdmx="7" minval="0.0" maxval="0" />
  <step for="goboindex" mindmx="4" maxdmx="7">
    <range handler="goboshake" mindmx="60" maxdmx="69" minval="0.4" maxval="10" />
  </step>
  <step for="goborotation" mindmx="32" maxdmx="35">
    <range handler="goboshake" mindmx="130" maxdmx="141" minval="0.4" maxval="10" />
  </step>
</step>

Dabei wird innerhalb des step für goboindex bzw. goborotation entschieden, in welchem Wertebereich der Goboshake “aufgeschaltet” wird.

Alle anderen Definitionen sind von diesem Vorschlag erst einmal unberührt.

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

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.