Bugtracker DMXControl 3

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Zahlreiche MIDI-Controller bieten Tasten, deren Farbe ich über bestimmte MIDI-Werte festlegen kann. Diese Werte sind für eine Reihe von Tasten oftmals gleich. Möchte ich nun für ein Feedback verschiedene Farben einer Taste nutzen, muss ich aktuell den Button (oder ein anderes Element) im RuleSet mehrfach anlegen, damit mit im Input Assignment die Outputs des Buttons mit den verfügbaren Farben ausgeführt werden.

Ich würde mir hier eine Möglichkeit wünschen, zum einen die Definition im Rule Set zu vereinfachen, zum anderen im gleichen Atemzug die Übersichtlichkeit im Output-Baum des Input Assignments zu erhöhen.

Am 05.04.2019 habe ich die Beta 1 ein weiteres Mal in der gleichen Location mit dem gleichen, nur erweiterten Projekt aus Ticket  FS#3499  im Live-Einsatz getestet. Die Logs sind zwecks Analyse beigefügt.

In der Cloud liegt unter Entwicklung / DMXControl 3 / Test ein Procdump-Abbild der Anwendung kurz nach dem Start sowie kurz vor Ende Session.

Am Samstag, 23.03.2019 hatte ich die Beta 1 bei einem größeren Setup laufen lassen. Die zugehörigen Logs sind zwecks Analyse beigefügt. Hier waren mir beim Überfliegen insbesondere in der ersten Sitzung ein paar Dinge in den Logs aufgefallen.

Eine Fehlermeldung aus den GUI-Logfiles. Die Fehlermeldung trat in der gleichen Session wie die aus dem Ticket  FS#3543  auf. Dort sind auch die vollständigen Logfiles zu finden.

2019-04-14 14:24:32,834 [Log-Thread] WARN  Lumos.GUI.Facade.GUISession.CommandWrapper - Exception when executing Command loadProject: Mindestens ein Fehler ist aufgetreten.
System.AggregateException: Mindestens ein Fehler ist aufgetreten. ---> org.dmxc.lumos.Kernel.Exceptions.ProjectLoadException: Warnings in Project

Server stack trace: 
   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 139.
   bei System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   bei System.Runtime.Remoting.Messaging.StackBuilderSink.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.Command.ICommand.execute(Object[] parameters)
   bei Lumos.GUI.Facade.GUISession.CommandWrapper.<>c__DisplayClass25_0.<execute>b__1() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\GUISession\CommandWrapper.cs:Zeile 171.
   bei System.Threading.Tasks.Task`1.InnerInvoke()
   bei System.Threading.Tasks.Task.Execute()
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   bei System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   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 173.
---> (Interne Ausnahme #0) org.dmxc.lumos.Kernel.Exceptions.ProjectLoadException: Warnings in Project

Server stack trace: 
   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 139.
   bei System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   bei System.Runtime.Remoting.Messaging.StackBuilderSink.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.Command.ICommand.execute(Object[] parameters)
   bei Lumos.GUI.Facade.GUISession.CommandWrapper.<>c__DisplayClass25_0.<execute>b__1() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\GUISession\CommandWrapper.cs:Zeile 171.
   bei System.Threading.Tasks.Task`1.InnerInvoke()
   bei System.Threading.Tasks.Task.Execute()<---

Im Project Explorer kann ich aktuell kein Softdesk ausschneiden bzw. kopieren und dann wieder einfügen. Beim Markieren eines Softdesks wird mir zwar im Kontextmenü angeboten, das Softdesk zumindest auszuschneiden, aber das Einfügen steht dann nicht mehr zur Auswahl.

Am Freitag, 15.03. und Samstag, 16.03. erfolgte ein Test unter Live-Bedingungen. Die zugehörigen Logs sind zwecks Analyse beigefügt.

In DMXControl 3.1.3 erhielten deaktivierte Geräte wie im beigefügten Screenshot zu sehen ein kleines Verbots-Icon. Dieses fehlt aktuell bei DMXControl 3.2 in der Beta 1.

In einem meiner Projekte habe ich ein paar Gruppen zu viel angelegt, die aber am Ende die gleichen Geräte ansprechen. Um nun nicht alle Cuelist ändern zu müssen, schlage ich vor, eine Merge-Funktion für Device Groups anzubieten.

Diese Funktion könnte ebenfalls im Fenster “Reference Error” untergebracht werden, wo man dann die Device Group auswählen kann, mit der alle Cuelists der gerade zum Löschen ausgewählten Device Group verknüpft werden sollen.

Das DMXC-Mixer-Node hat auf der Output-Seite aktuell nur den Output “Device”, in dem die Device-ID angezeigt wird. Hier sollten aus Konsistenzgründen noch die Outputs “Name” und “Number” hinzugefügt werden, so wie es bei vielen anderen Wrapper-Nodes der Fall ist.

Dem entsprechend würden die ersten drei Outputs wie folgt lauten:

• (Device-) Name
• (Device-) ID
• (Device-) Number

Ich füge in einem neuen leeren Projekt das Draw Bitmap Node ein und ändere die Schriftart von “Courier New” auf “Arial”. Diese Änderung wird vom Node zwar angenommen, aber nicht umgesetzt. Auch ein Speichern und Neuladen des Projekts hilft hier nicht.

Klappe ich den Eintrag “Font” in den Einstellungen des Nodes auf, steht dort in jeder Zeile die folgende Fehlermeldung:

Der Typ "System.Drawing.FontConverter" in der Assembly "System.Drawing.Common, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" konnte nicht geladen werden.

Dieser Eintrag taucht in keinem der Logs auf, daher nur der Screenshot.

Ändere ich den Namen für die Elemente eines Makros oder aus dem Softdesk, so wird der Name nur im Input-Baum und Output-Baum direkt aktualisiert. Die Inputs und Outputs in den Graphen selbst behalten den Namen bei.

In der Beta 7 kann das Position Master Node nicht geladen werden, sobald es in einem Graphen verwendet wird.

Das unten beigefügte Projekt ist neu erstellt. Dort habe ich den Position Master 1 nur im Position Master Node einem sonst leeren Graphen hinzugefügt. Beim erneuten Laden des Projekts generiert der Kernel die nachfolgende Fehlermeldung und im Graphen wird der Node entfernt.

09:58:09 WARN  InputManager - Unable to add Node to Graph: Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setInputaValue() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:line 192
   at org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setParameterInternal(GenericParameter parameter, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:line 389
   at org.dmxc.lumos.Kernel.Input.v2.AbstractNode.setParameter(GenericParameter parameter, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\AbstractNode.cs:line 371
   at LumosLIB.Tools.ParameterTools.LoadParameters[TParameter](IParameterable`1 parameterable, ManagedTreeItem tree, Func`2 convertName, Func`3 convertStringValueToID, Func`3 convertObjectValueToID) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\ParameterTools.cs:line 341
   at LumosLIB.Tools.ParameterTools.LoadParameters[TParameter](IParameterable`1 parameterable, ManagedTreeItem tree) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\ParameterTools.cs:line 228
   at org.dmxc.lumos.Kernel.Input.v2.InputManager.CreateSavedNode(ManagedTreeItem n, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\InputManager.cs:line 0

Ich habe in einem Projekt ein Connectionset erstellt und dieses Projekt dann gespeichert. Danach öffne ich dieses Projekt wieder und klone den Graphen.

Ersetze ich nun innerhalb dieses Graphens per Drag & Drop die In- bzw. Output, werden mir die neuen In- bzw. Outputs sowohl im Graphen als auch in der Tabelle nicht angezeigt. Auch bei einem erneuten Ladend des Projekts erfolgt keine Aktualisierung des Namens. Die gewünschte, nach dem Klonen geänderte Zuordnung funktioniert aber.

Beispielprojekt kann bei Bedarf nachgereicht werden,

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

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

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

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

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

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

Die standardmäßig verfügbaren Master “Color Master 1”, “Speed Master 1” und “Parameter Master 1” lassen sich nicht per Drag & Drop einem Graphen hinzufügen, wenn ich dies aus dem Input-Baum heraus mache. Aus dem Output-Baum heraus lassen sich diese genannten Master jedoch ohne weiteres per Drag & Drop dem aktuellen Graphen hinzufügen.

Dies lässt sich direkt mit einem leeren Projekt reproduzieren. Logeinträge sind hierzu nicht vorhanden.

Ich habe in dem beigefügten Projekt ein Connectionset für ein Softdesk gebaut, bei dem die Input und Output Selectoren mit mehr als 4 Eingängen konfiguriert sind. Beim Input Selecotor sind es 5 (1..5) und beim Output Selector 6 (1..6). Speichere ich das Projekt und lade es erneut, wird es auf Grund des folgenden Fehlers nicht geladen:

13:48:02 WARN  Graph - Unable to add Edge to Graph: Missing port.
Parametername: e
System.ArgumentException: Missing port.
Parametername: e
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdges(IEnumerable`1 edges, Boolean processGraph, Boolean reassignLevel) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 337.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 310.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.org.dmxc.lumos.Kernel.Resource.ILumosSaveable.loadFromManagedTree(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 802.

Da der Fehler eindeutig zuzuordnen ist, füge ich nur das Beispielprojekt bei.

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

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

In DMXControl 3.3.0 Beta 2 kann ich im Input Selector Node keine eigenen Eingaben mehr hinterlegen. Sobald ich in ein anderes Feld klicke, werden diese wieder entfernt. Dieser Fehler existierte bis zur Beta 1 noch nicht.

Log-Dateien kann ich keine zur Verfügung stellen, weil diese Änderungen im Node nicht protokolliert werden.

Nachdem ich nun das Position Master Node grundsätzlich extern ansteuern kann, ist mir aufgefallen, dass das Node am Value Input reale Positionswerte in Grad erwartet. Dies ist insbesondere im Zusammenspiel mit einer externen Ansteuerung über Fader etc. ungünstig, wie ich es bereits im Ticket  FS#4786  angeschnitten habe. Ändere ich den Aktionsbereich des zugeordneten Position Masters, muss ich auch in den Connectionsets verschiedene Anpassungen vornehmen.

Ich sehe hier folgende Ansätze, diesen Fehler (weil wir ja eigentlich immer nur mit normierten Werten von 0 bis 1 innerhalb der Connectionsets arbeiten wollen) zu beheben:

• Der Value Input wird so angepasst, sodass er nur eine normierte Position versteht.
• Der aktuelle Input wird erhalten und ein weiterer Input ergänzt, der dann die normierte Position versteht.
• Der aktuelle Input wird erhalten und analog zum Programmer-Node zwei getrennte Inputs für Pan und Tilt ergänzt.

Ich möchte das aktuell gewählte Gobo eines Geräts auf dem Macro Board ausgeben und habe dazu den Ausgang “Gobo” des DMXC-Mixer-Nodes mit dem Node “Bitmap from Resource” verbunden. Dies soll eigentlich das Bild an den betreffenden Button übergeben. Stelle ich diese Verbindung her, erscheint im Kernel folgender Eintrag:

19:37:00 ERROR BitmapFromResource -
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.BitmapFromResource.processInternal(NodeProcessContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Converter\Bitmap\BitmapFromResource.cs:Zeile 55.

Auf Grund dieser Fehlermeldung arbeiten die nachfolgenden Teile des Graphs nicht und ich sehe folglich auch kein Bild auf dem Button. Wähle ich stattdessen manuell eine Resource aus, arbeitet das Node “Bitmap from Resource” wie erwartet.

Füge ich am Gobo-Output des DMXCMixers das MacGyver-Node ein, wird im Übrigen der Name des Gobos nicht unter Image File im LumosGobo-Object geführt, sondern der Name des Gobos erscheint unter dem Ausgang “Min Value”. Schließe ich das Bitmap from Resource an diesen Ausgang an, werden mir die Gobos zumindest angezeigt, sofern ich ein Gobo des ersten von zwei Goborädern auswähle. Die Aktualisierung läuft aber nicht ganz so zuverlässig.

Ich möchte mir den aktuellen Farbwerrt eines Color Masters auf dem Buttons eines Macroboard Profiles anzeigen lassen und habe dazu den Ausgang “Value” des Color Masters direkt mit dem Eingang “Background Color” des Draw Bitmam Nodes verbunden.

Während der Color Master am Ausgang “Value” den Wert “1; 1; 1” als LumosColor-Objekt ausgibt, erwartet der Eingang “Background Color” des Draw Bitmap Nodes einen RGB-Wert. Folglich bleibt der Button effektiv gesehen dunkel, da ja “1; 1; 1” im RGB-Farbraum mit dem Wertebereich 0 bis 255 effektiv gesehen schwarz ist.

Im Hinblick darauf, dass wir im Input Assignment weitestgehend mit normierten Werten arbeiten wollen, sollte der Draw Bitmap Node als Folge dessen das LumosColor-Objekt an beiden Eingängen für die Farbe verstehen.

Ich möchte mit einem einzigen Fader den Wert eines Position-Masters ändern. Dazu baue ich mir ein Positions-Objekt mittels des Format-Nodes zusammen und habe dies mit “{0:0.##}; {1:0.##}” parametriert. Erhält das Position Master Node diesen Wert, gibt der Kernel folgende Fehlermeldung aus:

19:11:23 WARN  EventTools - Exception in Delegate Invocation: Void <AddDefaultPorts>b__37_3(org.dmxc.lumos.Kernel.Input.v2.GraphNodePortID, System.Object) => org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.Void <AddDefaultPorts>b__37_3(org.dmxc.lumos.Kernel.Input.v2.GraphNodePortID, System.Object)
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.ArgumentOutOfRangeException: Input must be <= inMax [0]
Parametername: input
Der tatsächliche Wert war 0,5.
   bei LumosLIB.Tools.LumosTools.RuleOfThree(Double input, Double inMax, Double inMin, Double outMax, Double outMin, ERuleOfThreeBehavior behavior) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosLIB\src\Tools\LumosTools.cs:Zeile 544.
   bei org.dmxc.lumos.Kernel.Master.PositionMaster.set_Value(Position value) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Master\PositionMaster.cs:Zeile 170.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setInputaValue() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:Zeile 189.
   bei org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.<AddDefaultPorts>b__37_3(GraphNodePortID sender, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:Zeile 236.
   --- 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.Delegate.DynamicInvokeImpl(Object[] args)
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0.<InvokeFailSafe>b__0(Delegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 136.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 180.

Das Position to Pan/Tilt Node versteht die so erstellten Werte dagegen und arbeitet erwartungsgemäß.

Um etwas mit dem List Selector zu spielen, habe ich mir das im beigefügten Projekt enthaltene Connectionset gebaut. Über die Buttons “previous” und “next” kann ich die Geräte der zugeordneten Gerätegruppe durchschalten. Für einen schnellen Überblick einfach das letzte Fensterlayout laden.

Hierbei musste ich aber feststellen, dass die Liste, welche das Device Group Node generiert, nicht der Reihenfolge der Sortierung der Geräte innerhalb der Device Group entspricht. Die erwartete Sortierung entspricht dem, wie die Geräte in der Stage View von links nach rechts positioniert sind. Selbst eine einfache alphabetische Sortierung der Geräte entsprechend ihres Namnes oder auf Basis der Gerätenummer findet nicht statt. Somit ist es in der aktuellen Version etwas unintuitiv, das gewünschte Gerät aus der Liste herauszusuchen.