Bugtracker DMXControl 3

Füge ich verschiedene Radix-Geräte einem Projekt hinzu, zum Beispiel das DDF aus  FS#3573  oder die Vorlage-DDFs aus dem internen Testprojekt und wende Highlight auf diese Geräte an, bleiben die Geräte dunkel. Es wird zwar Dimmer und Shutter geöffnet, die Hightlight-Funktion setzt aber keine Werte auf den Farbkanälen, wie sie es bei Matrix-Geräten macht.

Für eine der Bedienungsanleitung entsprechende Anordnung von Pixeln in einem Radix-Gerät habe ich folgenden Code im DDF eingebaut:

<radix dmxchannel="21" whiteoffset="3" shape="honeycomb">
  <ring>
  <segment nr="0" />
  </ring>
    <ring angleoffset="240">
    <segment nr="6" />
    <segment nr="5" />
    <segment nr="4" />
    <segment nr="3" />
    <segment nr="2" />
    <segment nr="1" />
  </ring>
</radix>

Die Pixel sind nämlich im Uhrzeigersinn angeordnet. In den Beispiel-DDFs gabe es leider keinen Hinweis auf ein Attribut, die “Drehrichtung” umzukehren. Wähle ich nun zwei Gruppen gemeinsam aus, wo sich die Reihenfolge der Pixel im Radix unterscheidet, kommt folgende Fehlermeldung:

2019-05-01 13:03:26,886 [80] ERROR org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory - TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht.
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.ArgumentException: Rings Size musst be in increasing order
   bei org.dmxc.lumos.Kernel.PropertyType.Radix..ctor(Color[][] radix) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\PropertyType\Radix.cs:Zeile 34.
   bei org.dmxc.lumos.Kernel.PropertyType.Radix.ToNewRingSegments(Int32[] ringSegments) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\PropertyType\Radix.cs:Zeile 277.
   bei org.dmxc.lumos.Kernel.PropertyType.RadixType.mergeTypes(IPropertyType propType, Boolean sameDevice) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\PropertyType\RadixType.cs:Zeile 148.
   bei org.dmxc.lumos.Kernel.DeviceProperties.GroupPropertyWrapper.org.dmxc.lumos.Kernel.DeviceProperties.IGUIDeviceProperty.get_MergedGUIPropertyType() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\DeviceGroupProperties\GroupPropertyWrapper.cs:Zeile 194.
   bei LumosLIB.Kernel.Devices.Descriptor.DescriptorTools.FromDeviceProperty(IGUIDeviceProperty property, Boolean relative) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Devices\Descriptor\DescriptorTools.cs:Zeile 32.
   bei LumosLIB.Kernel.Devices.Descriptor.DescriptorTools.FromGroup(IGUIDeviceGroup group, Boolean relative) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Devices\Descriptor\DescriptorTools.cs:Zeile 20.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.getGroupDescriptor(String groupID, Boolean relative) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 596.
   --- 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_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 60.
2019-05-01 13:03:26,899 [80] ERROR org.dmxc.lumos.Kernel.Command.Command - Error while invoking Command: getGroupDescriptor, Paras: 
System.ArgumentException: Rings Size musst be in increasing order
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 68.
   bei org.dmxc.lumos.Kernel.Command.Command.execute(Object[] paras) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\Command.cs:Zeile 120.

Ich habe in meinem Projekt mehrere Speedmaster angelegt (aktuell 3) und verteile diese als Beat Source auf unterschiedliche Cuelists. Speichere ich das Projekt, starte DMXControl 3 neu und lade das Projekt, sind alle Einstellungen wieder auf den Default zurückgesetzt (also SpeedMaster 1), wobei selbst dann nicht funktioniert. Ich muss nach dem Neustart der Sitzung alle Einstellungen neu setzen.

In einem Projekt, welches zuletzt unter DMXControl 3.1.2 gespeichert wurde und ich nun mit DMXControl 3.2 weiter bearbeiten möchte, kann ich den Cue Timing Editor (CTE) bei entsprechenden Cues nicht öffnen. Die Log-Files der GUI zeigen beim Ausführen der Aktion folgenden Eintrag:

2019-06-13 20:13:30,883 [Main GUI] ERROR Lumos.GUI.Windows.SceneList.SceneListView2 - Unable to Show SceneEditView for SceneIndex 1
System.InvalidOperationException: Die Sequenz enthält mehrere übereinstimmende Elemente.
   bei System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   bei Lumos.GUI.Windows.SceneList.SceneEditView.SetDeviceValues(TreeGridNode n, GroupState g) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\SceneList\SceneEditView.cs:Zeile 186.
   bei Lumos.GUI.Windows.SceneList.SceneEditView.SetGroupValue(TreeGridNode n, Boolean expand) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\SceneList\SceneEditView.cs:Zeile 174.
   bei Lumos.GUI.Windows.SceneList.SceneEditView.RefreshContent(Boolean expand) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\SceneList\SceneEditView.cs:Zeile 139.
   bei Lumos.GUI.Windows.SceneList.SceneEditView..ctor(ISceneFacade facade) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\SceneList\SceneEditView.cs:Zeile 107.
   bei Lumos.GUI.Windows.SceneList.SceneListView2.showFadeEditor(Int32 index) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\SceneList\SceneListView2.cs:Zeile 687.

Bei Cues, won entsprechende Werte im CTE noch nicht gesetzt waren und ich diese somit neu einfüge, lässt sich der CTE im Nachgang normal öffnen.

Die Logfiles und das aus das Wesentliche reduzierte Projekt sind im Anhang beigefügt.

Eines meiner älteren Projekte, was ich zuletzt mit der Beta 2 fleißig bearbeitet und genutzt habe, kann ich mit der Beta 4 nun nicht mehr Speichern. Auch ein einfaches Laden des Projekts und speichern ohne weitere Änderungen schlägt fehl. Im Kernel taucht vor dem Abschluss des Speichervorgangs folgender unscheinbarer Log-Eintrag auf:

2019-07-03 22:26:55,232 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to save project in PEManager

Das GUI-Log zeigt dazu noch folgende Informationen:

2019-07-03 22:26:44,398 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to save project in PEManager
System.Runtime.Remoting.RemotingException: Fehler beim Verarbeiten der Anforderung auf dem Server: System.Runtime.Remoting.RemotingException: TCP-Channelprotokollverletzung: Präambel wird erwartet.
   bei System.Runtime.Remoting.Channels.Tcp.TcpSocketHandler.ReadAndMatchPreamble()
   bei System.Runtime.Remoting.Channels.Tcp.TcpSocketHandler.ReadVersionAndOperation(UInt16& operation)
   bei System.Runtime.Remoting.Channels.Ipc.IpcServerHandler.ReadHeaders()
   bei System.Runtime.Remoting.Channels.Ipc.IpcServerTransportSink.ServiceRequest(Object state)
   bei System.Runtime.Remoting.Channels.SocketHandler.ProcessRequestNow()

Server stack trace: 
   bei System.Runtime.Remoting.Channels.Ipc.IpcServerHandler.ReadToEndOfHeaders(BaseTransportHeaders headers)
   bei System.Runtime.Remoting.Channels.Ipc.IpcClientHandler.ReadHeaders()
   bei System.Runtime.Remoting.Channels.Ipc.IpcClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
   bei System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]: 
   bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   bei org.dmxc.lumos.Kernel.HAL.Lists.IGUIItemList.get_ID()
   bei Lumos.GUI.Windows.ItemList.PE.ItemListNode.get_ID() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ItemList\PE\ItemListNode.cs:Zeile 37.
   bei LumosLIB.GUI.Windows.ProjectExplorer.AbstractExplorerNode.saveToManagedTree(ManagedTreeItem item) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\GUI\Windows\ProjectExplorer\AbstractExplorerNode.cs:Zeile 285.
   bei LumosLIB.GUI.Windows.ProjectExplorer.AbstractExplorerBranch.saveToManagedTree(ManagedTreeItem item) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\GUI\Windows\ProjectExplorer\AbstractExplorerBranch.cs:Zeile 93.
   bei Lumos.GUI.Windows.PEManager.Lumos.GUI.Run.IGuiProjectManager.saveProject(LumosGUIIOContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\PEManager.cs:Zeile 335.
   bei Lumos.GUI.Run.GuiRunManager.<>c__DisplayClass34_0.<saveProject>b__0(IGuiManager m) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Run\GuiRunManager.cs:Zeile 337.

Die vollständigen Logfiles sind beigefügt. Das Projekt stelle ich intern zur Verfügung.

Für eine zurückliegende Veranstaltung wollte ich mit zwei Slidern im Softdesk über zwei ParameterMaster die Funktionen Fan und Fog meines Hazers ansteuern. Hierzu erstellte ich eine Cue mit {ParameterMaster 1} für Fog und {ParamterMaster 2} für Fan. Nach dem Neustart von DMXControl 3 funktioniert die Zuordnung nicht mehr, da sich scheinbar die internen Referenzen der Parametermaster ändern. Dies ist auch daran zu erkennen, dass im Master Window die ParameterMaster 1 und 2 jeweils doppelt auftauchen.

Auf Wunsch stelle ich ein kleines Beispielprojekt zur Verfügung.

Bei den Speedmastern wird der BPM-Wert nur über zwei (Tastatur-) Anschläge ermittelt. Dies ist im direkten Vergleich zum “alten” Beat Tool deutlich ungenauer, weil sich der BPM-Wert dort aus 5 (Tastatur-) Anschlägen berechnet.

Das ungenaue Arbeiten der Speedmaster kommt besonders dann zum Vorschein, wenn ich zum Synchronisieren des BPM-Werts ein paar mehr (Tastatur-) Anschläge (also vier bis sechs) benötige. Durch die fehlende Mittlung der Werte erhalte ich sehr starke Varianzen im BPM-Wert von teilweise +/- 20 BPM zum eigentlichen BPM-Wert des laufenden Songs etc., was dann bei einem bereits laufenden Effekt unschön rüber kommt.

Zusammengefasst wäre es schön, wenn sich die Speedmaster in Bezug auf die Beat-Synchronisation ähnlich wie das Beat Tool verhalten würden: beim ersten Tappen Ausgabe des ersten Beat-Signals, über das weitere Tappen dann Angleichen der Geschwindigkeit durch Mittlung von mehreren (mindestens 4) (Tastatur-) Anschlägen.

In der aktuellen Sitzung ist mir folgender Fehler nach dem Schließen der GUI unter die Finger gekommen (Kernel und GUI wurden zu Beginn getrennt gestartet):

2019-08-10 19:22:46,317 [42] FATAL DMXControl 3 Kernel - Unhandled Exception: Mindestens ein Fehler ist aufgetreten.
System.AggregateException: Mindestens ein Fehler ist aufgetreten. ---> System.Threading.SynchronizationLockException: Die Objektsynchronisationsmethode wurde von einem nicht synchronisierten Codeblock aufgerufen.
   bei LumosLIB.Tools.SynchronizedEnumerator`1.MoveNext() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Tools\Collections\SynchronizedReadOnlyCollection.cs:Zeile 188.
   bei System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed)
   bei System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed)
   bei System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize)
   bei System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext()
   bei System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1()
   bei System.Threading.Tasks.Task.InnerInvoke()
   bei System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
   bei System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   bei System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   bei System.Threading.Tasks.Task.Wait()
   bei System.Threading.Tasks.Parallel.PartitionerForEachWorker[TSource,TLocal](Partitioner`1 source, ParallelOptions parallelOptions, Action`1 simpleBody, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally)
   bei System.Threading.Tasks.Parallel.ForEachWorker[TSource,TLocal](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally)
   bei System.Threading.Tasks.Parallel.ForEach[TSource](IEnumerable`1 source, Action`1 body)
   bei LumosLIB.Tools.LumosTools.ForEach[T](IEnumerable`1 source, Action`1 action, Boolean parallel) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Tools\LumosTools.cs:Zeile 1210.
   bei org.dmxc.lumos.Kernel.Project.SceneListManager.StopAllCuelists(Boolean immediate) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\SceneListManager.cs:Zeile 438.
   bei org.dmxc.lumos.Kernel.Run.KernelRunManager.beforeServiceShutdownHook() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Run\KernelRunManager.cs:Zeile 218.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.stopManager() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 360.
   bei org.dmxc.lumos.Kernel.Run.KernelRunManager.shutdownKernel(Boolean hard) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Run\KernelRunManager.cs:Zeile 206.
   bei org.dmxc.lumos.Kernel.GUISession.SessionManager.<>c.<RemoteShutdown>b__17_0(Object o) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\GUISession\SessionManager.cs:Zeile 69.
   bei System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
---> (Interne Ausnahme #0) System.Threading.SynchronizationLockException: Die Objektsynchronisationsmethode wurde von einem nicht synchronisierten Codeblock aufgerufen.
   bei LumosLIB.Tools.SynchronizedEnumerator`1.MoveNext() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Tools\Collections\SynchronizedReadOnlyCollection.cs:Zeile 188.
   bei System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed)
   bei System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed)
   bei System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize)
   bei System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext()
   bei System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1()
   bei System.Threading.Tasks.Task.InnerInvoke()
   bei System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
   bei System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )<---

Nach dem Erscheinen der Fehlermeldung und dem Versuch, den Kernel über den Befehl shutdown zu beenden, kam eine Fehlermeldung von Windows, dass ein Problem festgestellt wurde und das Programm geschlossen werden muss. Die vollständigen Logfiles sind im Anhang zu finden.

Ich habe ein Projekt mit mehreren Speedmastern gebaut. Lade ich das gleiche Projekt noch einmal neu, kann ich die Werte im Masterfenster zwar ändern oder über das Input Assignment triggern, in den Cuelists kommt nichts mehr an. Hier laufen die Cuelists dann mit der beim Starten der Sitzung (nach dem initialen Laden des Projekts) weiter.

Möchte ich eine Cuelist mit einem neuen, eigenen Speedmaster in der Beat Source ausstatten, kann ich diesen erst auswählen, wenn ich das Projekt neu geladen habe. Im Masterfenster ist der neue Speedmaster aber direkt schon aufgeführt, wie im Screenshot zu sehen ist.

Zusätzlich habe ich die Log-Dateien aus der Sitzung beigefügt.

Ich habe für meine neuen Futurelight Color Mega Wave.i das DDF gebaut und dabei folgendes festgestellt. Nutze ich im DDF sowohl eine Matrix zur Ansteuerung der in diesem Fall 6 Pixel sowie das Colorwheel zum Abrufen von Farbmakros für die gesamte Bar, kann ich die LEDs nicht mehr über die Matrix ansprechen. Die Funktion RGB, um alle 6 LEDs gleichzeitig auf eine Farbe zu setzen, gibt es bei diesem Gerät nicht.

Die betreffenden Teile des DDFs lauten:

<colorwheel dmxchannel="12">
  <support dmxchannel="11" name="colorwheel">
    <step mindmx="64" maxdmx="79" />
  </support>
  <step type="enableRGB" mindmx="0" maxdmx="3"/>
  <step type="color" val="#ff0000" mindmx="244" maxdmx="245" caption="red" />
  <step type="color" val="#00ff00" mindmx="246" maxdmx="247" caption="green" />
  <step type="color" val="#0000ff" mindmx="248" maxdmx="249" caption="blue" />
  <step type="color" val="#ffffff" mindmx="250" maxdmx="251" caption="white" />
  <rainbow>
    <support dmxchannel="11" name="rainbow" />
    <range type="cw" mindmx="1" maxdmx="255" minval="0.1" maxval="8" >
      <step handler="support-rainbow" mindmx="32" maxdmx="47" />
    </range>
    <range type="ccw" mindmx="1" maxdmx="255" minval="0.1" maxval="8" >
      <step handler="support-rainbow" mindmx="48" maxdmx="63" />
    </range>
  </rainbow>
</colorwheel>
<matrix dmxchannel="14" rows="1" columns="6" whiteoffset="3">
  <support dmxchannel="11" name="matrix">
    <step mindmx="0" maxdmx="15" />
  </support>
</matrix>

Mit dem Support-Handler in der Matrix-Funktion möchte ich erreichen, dass der Funktionskanal zum Umschalten zwischen normaler Farbmischung, den Farbmakros und des Rainbow-Effekts auf den Wert gesetzt wird, damit ich die Farbe wieder für jedes Pixel einzeln setzen kann. Möglicherweise kann dieser auch entfallen, wenn die Umschaltung mit Hilfe von enableRGB funktioniert.

Im Anhang findet sich das komplette DDF sowie die Bedienungsanleitung mit der Kanalbelegung.

Füge ich einen Radix-Effekt einer Cuelist hinzu, so wird dieser nicht dauerhaft in der Cuelist hinterlegt und geht mit dem Neuladen des Projekts verloren.

Projekt und Logs sind beigefügt.

Nutze ich das im Anhang beigefügte DDF, hängt sich die GUI komplett auf, sobald ich den Dialog Add Device schließe. Ersetze ich den vom Kernel bemängelten Code

<ptspeed dmxchannel="8">
  <step type="linear" mindmx="255" maxdmx="0" minval="0" maxval="255" />
</ptspeed>

durch den folgenden, korrigierten Code

<ptspeed dmxchannel="8">
  <range type="linear" mindmx="0" maxdmx="255" minval="100" maxval="0" />
</ptspeed>

lässt sich das DDF ganz regulär hinzufügen und auch die GUI arbeitet ohne Probleme weiter.

Die Logs bis zum Zeitpunkt des Aufhängens der GUI sind ebenfalls beigefügt.

Es wäre gut, wenn eine laufende Audio Cue beim Stoppen der zugehörigen Cuelist ebenfalls gestoppt wird.

Sobald eine Cuelist einem Executor zugeordnet ist, lässt sich dieser im Project Explorer nicht mehr in einem Unterordner verschieben.

Umgekehrt lassen sich Executoren, die leer bereits in Unterordnern verteilt waren, nicht mehr auf die obere Ebene verschieben, wenn ihnen nachträglich eine Cuelist zugeordnet wurde. Lade ich das Projekt darüber hinaus erneut, tauchen alle Executoren auf der oberen Ordnerebene auf.

Reproduzieren lässt dich dies wie folgt:

1. Eine Cuelist erzeugen
2. Im Project Explorer im Verzeichnis Executor einen neuen Unterordner anlegen
3. Einen neuen Executor generieren und die Cuelist mit diesem verknüpfen
4. Versuchen, den Executor in den angelegten Unterordner zu verschieben

In dem Projekt zu  FS#3958  ist zu beobachten, dass das Anlegen und Löschen von Cuelists jeweils eine Zeit von > 30 Sekunden in Anspruch nimmt, wo dann auch insbesondere die GUI nicht ansprechbar ist und Windows den Status “keine Rückmeldung” erhält.

Ich habe in einem Projekt drei Device Groups mit jeweils unterschiedlicher Anzahl von Geräten. Füge ich einen beliebigen Effekt auf die alle gemeinsam ausgewählten Device Groups und wähle als Group Handling “Parallel Groups”, werden Änderungen am Effekt fortan immer nur auf einer der drei Device Groups wiedergegeben. Die verbleibenden zwei Deivce Groups geben des Effekt mit den ursprünglichen Parametern wieder.

Um die Änderung auf allen ausgewählten Device Groups sehen zu können, muss ich entweder:

• die Einstellung für das Group Handling ändern
• den Effekt in einer Cue abspeichern und diese dann neu in den Programmer laden

In beiden Fällen tritt aber der oben beschriebe Fehler direkt wieder auf, sobald ich einen Parameter des Effekts ändere.

Zur Darstellung des Fehlers ist im Anhang ein entsprechendes Beispielprojekt mit einer vorbereiteten Cuelist zu finden. Zur Reproduktion einfach die Cue in den Programmer laden und die Parameter des Triangle-Effekts ändern.

Definiere ich in einem DDF eine Matrix mit nur einer Zeile (Icon links), wird das erste Pixel der Matrix nicht farblich hervorgehoben. Dies geschieht nur, wenn ich die Matrix mit nur einer Spalte definiere (Icon Mitte).

Getestet mit DMXControl 3.2.1, Build 600

Lege einen beliebigen Effekt im Device Control auf eine beliebige Funktion eines Geräts, werden jegliche Änderungen an den Parametern des Effekts in der Stage View und der DMX-Ausgabe nicht umgesetzt. Einzig der Effektvisualiser generiert die richtige Vorschau auf Basis der gesetzten Parameter.

Speichere ich den Effekt in einer Cue ab, so wird dieser entsprechend der im Blindflug eingestellten Parameter beim Abspielen der Cue richtig wiedergegeben und auch beim Editieren der Cue zeigt die Stage View den Effekt richtig an. Alle folgenden Änderungen registriert die Stage View und die DMX-Ausgabe jedoch nicht.

Logs der Sitzung siehe Anhang. Auffällig sind hier die beiden folgenden Einträge, welche nach dem Aufruf eines leeren Projekts erschienen:

2020-01-15 20:21:02,619 [305] ERROR org.dmxc.lumos.Kernel.Command.Command - Error while invoking Command: getEffectVectorsFromProgrammer, Paras: 
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 70.
   bei org.dmxc.lumos.Kernel.Command.Command.execute(Object[] paras) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\Command.cs:Zeile 121.
2020-01-15 20:21:02,647 [305] ERROR org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory - TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht.
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.getEffectVectorsFromProgrammer(String sessionName, String groupID, String propID, String effectID) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 2262.
   --- 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 System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 60.

Findet der Kernel beim Starten fehlerhafte Einstellungen für das Nodle U1 bzw. R4S, wird nun automatisch der USB Engery Fixer ausgeführt - eine sehr schicke Lösung.

Allerdings sollte nach dem erfolgreichen Fix die Meldung des Kernels nicht mehr ausgegeben werden, dass inkorrekte Einstellungen gefunden wurden. Denn aktuell ist es so:

Fehlerhafte USB-Einstellungen? Ja → USB Energy Fixer ausführen, bestätigt durch UAC-Abfrage → Einstellung korrigiert → Rückmeldung an User, USB-Interface neu zu verbinden → Warnmeldung, dass fehlerhafte USB-Einstellungen gefunden wurden mit der Bitte, den USB Energy Fixer auszuführen.

Alternativ könnt mal die “alte” Fehlermeldung dahingehend abändern, dass hieraus eine Abfrage wird, ob man den USB Energy Fixer ausführen möchte.

Ich wollte kürzlich ein einzelnes Gerät (ein RGBW-LED-Stripe) gezielt in seiner Helligkeit begrenzen. Hier musste ich aber feststellen, dass die Einträge Limit und in den Properties nur verfügbar sind, wenn das Gerät über einen Dimmer im DDF verfügt. So musste ich einen gesparten Groupmaster anlegen, um die Helligkeit für diesen LED-Stripe separat begrenzen zu können.

Ich habe mehrere Cues für statische Positionen von Moving Lights. Zur Zeit erfolgt das Überblenden nur linear. Ich stelle mir den Effekt aber auch sehr elegant vor, wenn dieser Fade nicht nur linear, sondern in verschiedenen Kurven wie zum Beispiel S-Kurve o. ä. erfolgen könnte.

Möchte ich über die DDFLib ein DDF suchen und öffne hierzu das Fenster, erscheint die beigefügte Fehlermeldung und im GUI-Log der folgende Eintrag.

2020-03-25 18:18:25,124 [Log-Thread] INFO  Lumos.GUI.Windows.DDFLibSearchForm - Exception when accessing DDFLib Webservice: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
System.Net.WebException: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
   bei DDFAPIClient.DDFClient.CheckResponse(IRestResponse response, HttpStatusCode expectedHttpStatus)
   bei DDFAPIClient.DDFClient.GetDataList[T](Boolean fromCache, Dictionary`2 filters)
   bei Lumos.GUI.Windows.DDFLibSearchForm.<>c__DisplayClass4_0.<.ctor>b__0() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\NewDevice\DDFLib\DDFLibSearchForm.cs:Zeile 49.
   bei System.Threading.Tasks.Task`1.InnerInvoke()
   bei System.Threading.Tasks.Task.Execute()

Entsprechenden Aussagen im Forum zu Folge, scheint dieser Fehler nicht unbedingt ein Fehler in DMXControl 3.2.1 selbst zu sein, denn auch in DMXControl 3.2.0 tritt dieser Fehler mittlerweile auf.

Das beigefügte Projekt kann wegen eines Timeout-Fehlers beim ersten Versuch nicht geladen werden. Es erscheint die Fehlermeldung “Project could not be loaded. Either the file ist corrupt or not a valid project file”. Hierzu gibt der GUI folgenden Hinweis in den Logs:

2020-03-30 21:02:52,252 [Log-Thread] WARN  Lumos.GUI.Facade.GUISession.CommandWrapper - Exception when executing Command loadProject: The Command "loadProject" has timeouted after 198000ms
System.TimeoutException: The Command "loadProject" has timeouted after 198000ms
   bei Lumos.GUI.Facade.GUISession.CommandWrapper.execute(Object[] parameters) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\GUISession\CommandWrapper.cs:Zeile 189.

Schließe ich die GUI und starte sie neu, wird das Projekt nur zum Teil geladen, jedoch wirft der Kernel dabei weitere Fehlermeldungen, unter anderem:

2020-03-30 21:25:06,237 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Project.DeviceManager - Created saved Device MH-X60 14CH in 204357 us
2020-03-30 21:25:06,250 [65] ERROR org.dmxc.lumos.Kernel.HAL.Handler.DMXRangeWithDiscreteValue - Illegal use of Attributes "minval,maxval" in XmlNode device-->functions-->prism-->step. This DDF might not be loaded in a future Version!

Diesen Fehler kann ich zwar korrigieren (siehe Projekt DDFs korrigiert), jedoch lässt sich das bearbeitete Projekt ebenfalls nicht vollständig laden, weil laut Jens-Peter ein Fehler im Input Assignment vorliegt (hier hängt der Ladeprozess am längsten fest).

In den Settings fehlen die New project default settings und die Current project settings. Letztere sind auch nicht über das Kontextmenü zu den Cuelist Groups im Project Explorer zu erreichen.

Speichere ich ein Preset ab, werden zuvor gehighlightete Geräte dunkel geschaltet. Das Problem lässt sich wie folgt reproduzieren:

1. RGB-Devices anlegen und auswählen.
2. Highlight aktivieren.
3. Eine beliebige Farbe im Device Control einstellen.
4. Ein neues Preset anlegen.

Das Ergebnis ist, dass die gewählten Geräte nicht mit gehighlightet sind, obwohl die Funktion aktiv ist. Dies ist deswegen verwunderlich, weil sich dieses Verhalten beim Anlegen einer regulären Cue nicht zeigt. Das Highlight für die gewählten Geräte bleibt weiter aktiv.

Im Zuge der Umsetzung des Main switch features (unter anderem für die Realisierung von  FS#4015 ) kam von Arne der Gedanke, in DMXControl 3 eine Möglichkeit zu schaffen, um die Application settings auf die Standardwerte zurückzusetzen. Hier gibt es zwei, vielleicht aber auch noch mehr Varianten, über die ein solcher Reset erfolgen könnte:

• Man erhält direkt in DMXControl 3 einen Menüeintrag.
• Im Startmenü wird eine zusätzliche Verknüpfung angelegt, über die DMXControl 3 direkt mit den Standardwerten gestartet wird.

Ein großes, umfangreiches Projekt kann in der laufenden Sitzung nicht ein zweites Mal geladen werden. Dabei ist es egal, ob man zwischendurch ein anderes bzw. leeres Projekt geöffnet hat oder das gleiche Projekt direkt ein zweites Mal lädt.

Die beigefügten Logfiles zeigen den ersten Fall (Projekt laden, neues Projekt laden, ursprüngliches Projekt laden). Ein Projekt zum Testen steht bereits intern zur Verfügung.

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

Ich habe eine Cuelist mit einer einzigen Cue erstellt, in der relativ ein Circle-Effekt auf einer Gruppe von Moving-Heads läuft. Beim Starten der Cuelist wird die Bewegung wie erwartet eingefaded.

Stoppe ich die Cuelist aber, gibt diese die Bewegung trotz laufender Release Time im vollen Maß aus. Ist die Zeit abgelaufen und Cuelist ist deaktiviert, springen die Geräte zur Ursprungsposition zurück.

Dupliziere ich die Cue und ändere diese von REL zu ABS ab, verhält sich die Cuelist während der laufenden Release Time wie erwartet, das heißt die Geräte fahren langsam zur Ursprungsposition zurück. Gleiches gilt analog auch für den Dimmer oder die Goborotation.

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

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

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

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

Spreche ich in einer Cuelist unterschiedliche Geräte oder Gerätegruppen sowohl absolut als auch relativ an, bleiben die relativen Werte im Hintergrund irgendwie im weiteren Ablauf erhalten. Dies hat zur Folge, dass wenn ich zwischenzeitlich Cues mit absoluten Werten für alle Geräte in die Cuelist einbaue, dass diese Cues die Geräte nicht auf eine gemeinsame Position bringen.

Für das bessere Verständnis am Besten das Video anschauen und es mit dem beigefügten Projekt selbst nachvollziehen.

Für DMXControl 3.3 soll ein Start Manager entwickelt werden, über den unter anderem folgende Funktionen abgedeckt werden:

• Gleichzeitiges Starten von Umbra, Kernel und GUI
• Herstellung der Verbindung aller Komponenten untereinander bei lokaler Ausführung
• Festlegung eines Standard- bzw. Autostartprojekts
• …

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

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

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

Ich kann auf einem zweiten PC keine zweite, komplett eigenständig laufende Instanz von DMXC3 ausführen, wenn sich beide PCs im gleichen Netzwerk befinden. Dabei macht es keinen Unterschied, ob ich die Komponenten gemeinsam starte oder manuell Komponente für Komponente. Im Network Explorer werden mir beide Instanzen angezeigt. Ich kann auf dem PC 2 aber keine Verbindung zum lokal ausgeführten Kernel herstellen. Ziehe ich die Verbindungslinie von der GUI zum Umbra und vom Umbra zum Kernel, so blinkt diese kontinuierlich. Bei der Instanz auf dem zweiten PC vermeldet der Kernel hierbei immerzu folgenden Eintrag im Log, selbst wenn ich über die GUI versuche, diesen “einzufangen” und ihn dazu bewegen möchte, sich mit dem Umbra auf PC 2 zu verbinden.

2021-04-25 01:32:14,390 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.GrpcManager - Connecting to Umbra Server on Host 192.168.21.22:17475
2021-04-25 01:32:14,393 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Login Call: 1ms
2021-04-25 01:32:14,393 [42] ERROR org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to Login to Umbra Server: Client limit reached. Only 1 Clients of Type Kernel allowed.

Eine solche Konstellation sollte aber möglich sein. Anwendungsfälle gibt es hier genügend. Aktuell kann ich einen parallelen Test auf meinem zweiten PC nur ausführen, wenn ich zum Beispiel den Netzwerkadapter deaktiviere.

Im Anhang sind die Logfiles aus der Konstellation, bei der alle Komponenten manuell gestartet wurden.

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

Möchte ich ein Gerät aus dem Projekt löschen, welches in einer Device Group eingebunden ist, kann ich dies nicht direkt im Device-Ordner machen. Das Reference Error Window erhält nicht die notwendigen Parameter bzw. gibt diese zurück, sodass das Gerät nach der Auswahl einer Aktion gelöscht wird. Auf Grund dieses Problems kommt das Fenster erneut hoch und das Gerät ist weiterhin im Projekt enthalten.

Im Anhang findet sich ein Projekt mit 10 Geräten, wo ich probeweise wie auf dem Screenshot zu sehen versucht habe, die Geräte AX5 (9) und (10) zu löschen.

In dem Projekt aus  FS#4522  habe in der Stage View zwei neue Device Groups aus einer Auswahl erzeugt. Einmal über den Button in der Menüleiste und einmal über das Kontextmenü. Bei beiden Wegen wird die neue Device Group angelegt, jedoch nicht automatisch wie bisher auch der aktuellen Stage View hinzugefügt.

Das Ergebnis ist im beigefügten Projekt zu sehen.

Der Dateiname des Zip-Archiv mit dem Log-Dateien wird eigentlich nach dem Schema

DMXControl3Logs_YYYYMMDD_hhmmss.zip

generiert - bzw. sollte so generiert werden. Aktuell ist es so, dass “füllende” Nullen nicht berücksichtigt werden. Die führt dazu, dass folgende Dateinamen herauskommen, die sich am Ende nicht chronologisch nach dem Dateinamen sortieren lassen:

DMXControl3Logs_202148_831.zip    -->  DMXControl3Logs_20210408_080301.zip
DMXControl3Logs_2021430_1247.zip  -->  DMXControl3Logs_20210430_120407.zip
DMXControl3Logs_202151_23199.zip  -->  DMXControl3Logs_20210501_231909.zip

Folglich muss hier einmal das Format überprüft werden, welches für die Ausgabe des Datums und der Uhrzeit herangezogen wird.

Beim Testen des Chaser 2 sind mir mehrere Punkte aufgefallen. Diese habe ich allesamt mit der Cuelist des beigefügten Projekts nachgestellt. Die hier genannten Punkte sind gleichermaßen im Projekt zu finden.

1. Doppelschritt im Playmode In Out
Wähle ich den Playmode In Out, bleibt der Chaser 2 am inneren und äußeren Punkt jeweils zwei Takte stehen. Beim Bounce ist dies nicht der Fall.

2. Speedmaster ohne Funktion
Der Speedmaster hat keine Auswirkungen auf die Wiedergabegeschwindigkeit des Chaser Effekts.

3. Zeitsprung Playmode Normal
Im Playmode Normal und Reverse findet der Wechsel bzw. die Umschaltung zwischen dem ersten und zweiten Gerät in der Device Group nicht nahtlos statt. Hier gibt es einen kurzen Augenblick, bei dem das Gerät 1 bereits aus aber das Gerät 2 noch nicht an ist und so ein Blitz entsteht. Dieser Punkt ist allerdings erst gut mit realen Geräten zu sehen, wie zum Beispiel mit meinen Moving-Bars.

4. Fanning-Operator ? auf Duration
Hier wäre die Erwartungshaltung, dass die Duration eines jeden Steps entsprechend der Angabe variiert wird. In dieser Cue habe ich exemplarisch den Fanning-Operator ? genutzt, es betrifft hier aber im Endeffekt jeden Fanning-Operator

5. Fanning-Operator > auf Fade
Analog zum Parameter Duration sollte auch hier der Fanning-Operator eine Auswirkung zeigen, nämlich hier mit einem zunehmenden Fade zu jedem Step: beim 1. Gerät kein Fade, beim letzten Gerät 500ms.

6. Absturz bei Duration 0
Trage ich bei Duration als Wert 0ms ein, stürzt der Chaser mit folgendem Logeintrag ab und gibt keine Werte mehr aus. Hier sollte der mögliche / zulässige Wertebereich angepasst werden. Dieser Fehler kann reproduziert werden, wenn die entsprechende Cue in den Programmer geladen wird.

2021-05-02 00:06:13,928 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.DuplexStreamHandler - Exception in Delegate Invocation: Void _deleteProgrammerAttachable_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.DeleteProgrammerAttachableRequest]) => org.dmxc.lumos.Kernel.Net.gService.Programmer_gService.Void _deleteProgrammerAttachable_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.DeleteProgrammerAttachableRequest])
System.DivideByZeroException: Es wurde versucht, durch 0 (null) zu teilen.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.Chaser.AbstractChaserPattern.doUpdateChaser(Int64 timeInMs, Int64 delta, Int32 duration, Int32 fadetime, Int32 deviceCount, Int32 length, Int32 stepSize, Int32 breakSteps, Int32 breakTime) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\Filter\Chaser\Pattern\AbstractChaserPattern.cs:Zeile 43.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.ChaserFilter2.doFilter(IPropertyValue input, Int64 timeInMs, Int64 delta) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\Filter\Chaser\ChaserFilter2.cs:Zeile 219.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.AbstractEffectFilter.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\Filter\AbstractEffectFilter.cs:Zeile 58.
   bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1.getPropertyValue(Int64 timeInMsAbs) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 409.
   bei org.dmxc.lumos.Kernel.PropertyValue.PropertyValue`1.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\PropertyValue\PropertyValue.cs:Zeile 352.
   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\Lumos\src\Kernel\Scene\Fade\FadeDecorator.cs:Zeile 95.
   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\Lumos\src\Kernel\Scene\Delay\DelayDecorator.cs:Zeile 37.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AutoFadeDecorator.triggerFade() in D:\Jenkins\workspace\Lumos_Pipeline_master\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\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\Lumos\src\Kernel\Scene\Fade\AbstractFadeDecorator.cs:Zeile 65.
   bei org.dmxc.lumos.Kernel.Scene.SceneFadeTicker.register(IProcessable value) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Scene\SceneFadeTicker.cs:Zeile 71.
   bei org.dmxc.lumos.Kernel.Mixer.Register.MixerRegister.registerFadeable(IProcessable value) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Mixer\Register\MixerRegister.cs:Zeile 147.
   bei org.dmxc.lumos.Kernel.Mixer.Register.MixerRegister.pushProcessableValue(IProcessable value) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Mixer\Register\MixerRegister.cs:Zeile 215.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.playSceneEntry(ISceneEntry[] entrys, HALTimestamp ts) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 1265.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.playSceneEntry(ISceneEntry[] entrys) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 1213.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.deletePropertyAttachable(String attachableID) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 562.
   bei org.dmxc.lumos.Kernel.Net.gService.Programmer_gService._deleteProgrammerAttachable_RequestReceived(Object sender, RequestEventArgs`1 e) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Net\gService\Programmer_gService.cs:Zeile 334.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass3_0`1.<InvokeFailSafe>b__0(EventHandler`1 a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 28.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0`1.<InvokeFailSaveGeneric>b__0(TDelegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 62.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 82.

Füge ich einem leeren Projekt Executoren zu und ordne die Executor Pages zu und möchte dieses speichern, so ist dieses mit dem folgenden Logeintrag nicht möglich.

2021-05-14 23:48:59,565 [40] ERROR org.dmxc.lumos.Kernel.Project.ProjectManager - Can't save content of ExecutorManager
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Project.ExecutorManager.Save(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Project\ExecutorManager.cs:Zeile 745.
   bei org.dmxc.lumos.Kernel.Project.ExecutorManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.saveProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Project\ExecutorManager.cs:Zeile 948.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass30_1.<saveProject>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 476.

Ändere ich die Faderposition aller Master (-typen) im Masterfenster oder klicke auf die zugehörigen Buttons, so werden die angezeigten Werte und die Fader bei den Klicks auf die Buttons nicht aktualisiert.

Die Funktionen werden aber wie erwartet ausgeführt.

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

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

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

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

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

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

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

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

Aktuell ist ein lineares Fanning mit dem Positionmaster und einem festen Wert nicht möglich. Bei der Eingabe von zum Beispiel {Positionmaster 1} > 0;0 erscheint folgende Fehlermeldung.

2021-05-15 19:25:01,506 [51] ERROR LumosLIB.Tools.gRPC.GrpcTools - Unable to Serialize Element of Type: org.dmxc.lumos.Kernel.Scene.Fanning.LinearFannedValue
2021-05-15 19:25:01,516 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.DuplexStreamHandler - Exception in Delegate Invocation: Void _setProgrammerValue_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.SetProgrammerValueRequest]) => org.dmxc.lumos.Kernel.Net.gService.Programmer_gService.Void _setProgrammerValue_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.SetProgrammerValueRequest])
System.Runtime.Serialization.SerializationException: Unable to Serialize Element of Type: org.dmxc.lumos.Kernel.Scene.Fanning.LinearFannedValue
   bei LumosLIB.Tools.gRPC.GrpcTools.ToObjectData(Object obj, EFallbackEnforcement fallbackEnforcement) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Tools\GRPC\GrpcTools.cs:Zeile 307.
   bei LumosLIB.Tools.gRPC.GrpcTools.ToPropertyValue(Object value) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Tools\GRPC\GrpcTools.cs:Zeile 149.
   bei org.dmxc.lumos.Kernel.Net.gService.Programmer_gService.ReadPropertyValueData(IUserContext uc, String groupId, String propertyId) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Net\gService\Programmer_gService.cs:Zeile 217.
   bei org.dmxc.lumos.Kernel.Net.gService.Programmer_gService._setProgrammerValue_RequestReceived(Object sender, RequestEventArgs`1 e) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Net\gService\Programmer_gService.cs:Zeile 268.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass3_0`1.<InvokeFailSafe>b__0(EventHandler`1 a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 28.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0`1.<InvokeFailSaveGeneric>b__0(TDelegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 62.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 82.

Hierbei friet die GUI ein und ist nicht mehr bedienbar. Ich muss die GUI hierzu abschießen und dann nach dem Neustart den Programmer leeren, um weiterarbeiten zu können. Ein Fanning über zwei Positionmaster entsprechend {Positionmaster 1} > {Positionmaster 2} ist dagegen möglich. Im Bereich des Colormasters tritt ein vergleichbarer Fehler ebenfalls nicht auf.

Im Anhang die Logfiles der Sitzung, bis die GUI einfriert und über den Taskmanager geschlossen werden muss.

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

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

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

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

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