Bugtracker DMXControl 3

Ändere ich den Inhalt einer Zelle, zum Beispiel im Cuelist Editor, im Cue Timing Editor oder in Übersicht der DMX-Interfaces und möchte diese Änderung bestätigen, muss ich mit der Maus an eine beliebige andere Stelle klicken. Zuletzt klappte dies noch durch Drücken der Enter-Taste, um die Eingabe zu bestätigen, oder über die Escape-Taste zum Verwerfen der Änderung.

Die folgende Fehlermeldung erscheint in den Logs, wenn ich in einem Graphen den Output Selector nutze:

2019-08-11 19:07:34,142 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Input.v2.InputManager - Graph M51302 created Exception in Process: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   bei org.dmxc.lumos.Kernel.Input.v2.InputManager.ProcessGraphs(RunContext ctx) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Input\v2\InputManager.cs:Zeile 1110.

Die Logs sind im Anhang beigefügt. Ich habe von Arne die Freigabe erhalten, mit dem Build 320 zu testen.

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.

Öffne ich ein Softdesk im Designer, sollten beim Drücken der Tasten und Bewegen der Fader keinerlei Aktionen an das Input Assignment durchgereicht werden, sondern nur wenn ich den Test-Modus über den Play-Button oben rechts aktiviere. Dies funktioniert so leider nicht. Auch im Edit-Modus kommen die entsprechenden Aktionen im Input Assignment an.

Ich baue einen Graphen, um eine Umschaltung mittels eines Counter Nodes zu realisieren. Der Counter Node wird über eine Taste getriggert und ist am Ausgang mit einem Executor verbunden. Der Counter Node besitzt die Grenzen von 1 bis 5, das Inkrement liegt bei 1. Overflow ist zugelassen. Durch das Drücken meiner Inkrementierungstaste liegt am Counter nun ein Wert an.

Ändere ich nun die Grenzen des Counters auf 21 bis 25, muss ich im konkreten Fall die Taste nun bis zu 20 mal drücken, bis der Counter wieder in seinen neuen Wertebereich gelangt. Ein einfaches Drücken reicht hier nicht aus, was hier durchaus meine Erwartungshaltung wäre.

Ich ordne mehrere Geräte einer PowerSoruce im Electricity Management zu. Diese entsprechend zugeordneten Geräte lassen sich innerhalb der PowerSource nicht sortieren. Das Kontextmenü ist ausgegraut. Einzig die Buttons zum manuellen Einstellen der Reihenfolge werden aktiv, sobald ich ein Gerät auswähle.

Ich habe zwar die Möglichkeit, die Textgröße die Texte in Buttons festzulegen. Mein eingetragener Wert wird nach der Eingabe nicht übernommen und direkt auf 13 Pt. zurückgesetzt.

Öffne ich ein Softdesk testweise im Build 296, so werden die visuellen Stile nicht angezeigt und ich erhalte eine Schwarz-Weiß-Version meines eigentlich bunt eingefärbten Softdesks. Dies betrifft in erster Linie die Buttons. Slider werden weiterhin in der gewünschten Farbe angezeigt.

Dass die Informationen noch vorhanden sind, zeigt sich daran, dass beim Betätigen die richtige (Füll-) Farbe aufleuchtet und das Softdesk beim Öffnen des Softdesks mit der Beta 4 wie gewohnt angezeigt wird.

Die Log-Files und ein Screenshot sind im Anhang beigefügt.

Füge ich das Art-Net-Ausgabeplugin neu hinzu, werden die Send- und Recieve-Universen aus meiner Sicht ungünstig adressiert. Im konkreten sieht das wie folgt aus:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 4 - 7

Device 2

• Send U5 - U7: Universes 8 - 11
• Revice U5 - U7: Universes 12 - 15

Möchte ich nun ein 8-Port Art-Net-Node ansprechen, muss ich hier im Device 2 mindestens die Universen für Send neu sortieren. Ich könnte zwar mein Art-Net-Node auch irgendwie umkonfigurieren, aber persönlich finde ich diese Stückelung innerhalb eines Subnet nicht geschickt. Mein erster Vorschlag wäre folgende Standard-Konfiguration:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 8 - 11

Device 2

• Send U5 - U7: Universes 4 - 7
• Revice U5 - U7: Universes 12 - 15

Ich habe dieses Ticket quasi auf Bitten von Arne angelegt, damit wir hier die optimalen Wertebereiche für den Programmer Node diskutieren können. Aktuell akzeptieren die Eingänge des Programmer Nodes folgende Werte:

• Device oder Group ID: unter anderem Device-Nummer oder Gruppennummer, auch über ein Format-Node als “Aufzählung” / Liste zum direkten Auswählen von mehreren unterschiedlichen Geräten gleichzeitig
• Dimmer: 0 - 100
• Shutter, Lumos / Nox: 0 oder 1 bzw. true oder false
• Strobe: 0 - 1
• Position: Pan und Tilt jeweils 0 - 1
• Color: Farbwerte als RGB
• Colortemp: 0 - 1
• Gobo, Prisma: aktuell 0 - 100
• Goboindex, Prismindex, Fokus, Zoom: 0 - 1
• Goborotation, Prismrotation: 0 - 0,5 für Rotation CW und 0,5 - 1 für Rotation CCW

Ziel der Diskussion sollte sein, dass (aus meiner Sicht) die Wertebereiche zum einen so gewählt sind, dass

1. sie universell verwendbar sind
2. beim Anlegen des Graphen auch einfach und nachvollziehbar händelbar sind

Ich möchte mit dem Position-Element im Softdesk das Programmer Node steuern. Da dieses für Pan und Tilt getrennte Eingänge besitzt, fügte ich ein Position to Pan/Tilt Converter hinzu. Dieses Conventer-Node gibt für Pan und Tilt allerdings DMX-Werte aus, die das Programmer Node aktuell nicht akzeptiert. Auch das Zwischenschalten von Rule of Three Bausteinen, um den DMX-Wert wieder auf einen Winkel umzusetzen, brachte nicht den gewünschten Erfolg.

Ich wollte mit Hilfe der ColorBar den Eingang Color des Programmer Nodes steuern, um die Farbe eines selektierten Geräts auszuwählen.

Allerdings gibt die ColorBar nur Farben in der vollen Sättigung als RGB-Wert aus (Auswahlpunkt im ColorPicker am äußeren Rand), sodass Farben mit einer geringeren Sättigung wie ein helles Gelb nicht dargestellt werden können. Eine Überlegung war daher, die ColorBar an den HSV-to-Color-Converter anzuschließen, allerdings gibt die ColorBar nur RGB-Werte weiter und nicht beispielsweise parallel die Werte von 0 bis 1, sodass den Converter-Node nicht nutzen kann.

Der Fehler aus  FS#3700  liegt analog auch im Softdesk Designer vor, dass hier die Enft-Taste in den Eigenschaftsfeldern des Property Grids nicht akzeptiert wird.

Ich füge einem neuen leeren Projekt zum Beispiel vier Clay Paky Alpha Spot QWO 800 hinzu und stelle eine beliebige Strobe-Frequenz bei geöffnetem Shutter und voller Helligkeit ein. Ist der Programmer hierbei geschlossen, kann ich Änderungen in der gesamten GUI soweit wie gewohnt vornehmen.

Sind Stage View und Programmer parallel geöffnet, reagiert die GUI deutlich verzögert, insbesondere die Control Windows und das Device Control, wo ich Werte über Regler einstellen kann. Im ungünstigsten Fall wird der Inhalt des Device Controls nicht aktualisiert bzw. nicht aufgebaut. Dies ist mir insofern zum Verhängnis geworden, dass ich eine Cue über “Edit in Programmer Blind” live nicht anpassen konnte.

Aktuell bietet der Selector-Node nur die Möglichkeit, aus verschiedenen Eingängen den jeweils aktiven zu wählen und durchzuschalten.

Ich hätte aktuell einen Anwendungsfall, wo kurz gesprochen ein Selector-Node zum Wählen des aktiven Ausgangs hilfreich wäre. Hintergrund ist, dass ich mit einem Button verschiedene Cuelists aktivieren möchte. Die Auswahl der Cuelist, die aktiviert werden soll, würde dabei über einen zweiten Taster erfolgen.

Lade ich ein vorhandenes Projekt, sind die Verbindungen im Input Assignment trotz aktiver Bank “On Hold” und warten quasi auf einen Initialisierungsimpuls. Aufgefallen ist mir dies in folgender Konstellation:

Ich habe zwei verschiedene Verbindungen. Die Schnittmenge beider Verbindung ist der Speedmaster 1. In der Verbindung 1 (Beat Tastatur) triggere ich den Speedmaster 1 über die Tastatur. In der Verbindung 2 (Beat Softdesk) triggere ich den gleichen Speedmaster über den Button des Softdesks und nutze diese Verbindung auch, um mir den aktuellen BPM-Wert im Softdesk anzuzeigen.

Triggere ich den Speedmaster 1 über die Tastatur, kommen die Werte nach dem Laden des Projekts zwar beim Speedmaster an. Das Feedback ans Softdesk über die Verbindung 2 erhalte ich erst, wenn ich dieser Verbindung einen einmaligen Impuls gebe, entweder

• über einen verfügbaren Input (in diesem Fall der Button, der auch den BPM-Wert anzeigt) oder
• durch Deaktivieren und Aktivieren der Verbindung 2 (Beat Softdesk) oder
• in diesem Fall durch Änderung der Einstellung des Speedmaster 1 in der Verbindung selbst.

Um den besagten Aktualisierungs- bzw. Initialisierungsimpuls zu generieren, reicht es nicht, die komplette Bank zu deaktivieren und wieder zu aktivieren. Dass dieser fehlt, kann man auch daran erkennen, dass an den Nodes kleine Statuswerte angezeigt werden.

Zum Nachstellen des Problems habe ich ein Beispielprojekt beigefügt. Die oben genannten Verbindungen sind in den ersten beiden Bänken im Input Assignment zu finden. Hierzu am besten das letzte Fensterlayout laden.

Ich glaube, das Bild beschriebt den Fehler am besten. Zwei, wenn nicht sogar eine Nachkommastelle würde aus meiner Sicht als zurückgegebener Wert nach einen Button oder Label grundsätzlich ausreichen.

In meiner Live-Session mit Maik kam die Frage auf, ob man das Zuordnen von Cuelists zu einer bestimmten Cuelist Group zu einem gewissen Grad teil-automatisiert gestalten kann, sobald man eine neue Cuelist erzeugt.

Aufhänger für diese Frage war die Funktion im Add-Device-Dialog, bei der man neue Geräte beim Anlegen direkt einer neuen oder einer vorhandenen Device Group zuordnen kann.

Als kleine Unterstützung der Einsteiger wäre hier der Vorschlag, das Kontextmenü im Softdesk-Designer um den Eintrag “Open Input Assignment” oder ähnlich zu erweitern. Die Idee bzw. das Ziel dahinter ist, dass man einen weiteren Hinweis erhält, dass die Softdesk-Elemente erst im Input Assignment “mit Leben gefüllt” werden können.

Ändere ich den Wert eine Zelle im Cuelist Editor oder den Namen einer Verbindung im Input Assignment und möchte mit den Tasten Pos1 bzw. Ende an den Anfang bzw. Ende des Textes in der Zelle springen, wird stattdessen der Edit-Modus der Zelle verlassen und die erste bzw. letzte Zelle in der Zeile ausgewählt.

Wenn ich im Fenster Input Assignment den Namen einer Verbindung ändere und dabei die Entf-Taste nutze, werden die Textzeichen rechts vom Cursor nicht wie erwartet entfernt.

Im Cuelist Editor beispielsweise arbeitet die Enft-Taste wie gewohnt, wenn ich den Namen der Cue ändern möchte.

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.

Im Ticket  FS#3470  wurde der Fehler behoben, dass durch das Markieren von Softdesk-Elementen die Größe des Objekts falsch ausgegeben wurde.

Vermutlich durch die Behebung dieses Fehlers wachsen die Elemente nun mit jedem Speichern und Neuladen des Projekt an, und zwar um jeweils 5 Pixel in Breite und Höhe. Durch ein mehrfaches Speichern und Neuladen meines Projekts (im konkreten Fall 2 Mal) kam dann folgendes im Anhang dargestelltes Ergebnis zu Stande. Bild 1 ist das Original, Bild 2 nach dem zweimaligen Neuladen des Projekts. Der Bildausschnitt ist jeweils der gleiche.

In dem Projekt aus  FS#3668  kann das Softdesk ebenfalls nicht gespeichert werden - auch wenn man das nur lädt und einfach wieder auf speichern klickt, erhalte ich den folgenden Eintrag in den GUI-Logs:

2019-07-03 22:26:44,337 [4] ERROR Lumos.GUI.Windows.Softdesk.SoftdeskManager - Unable to save Softdesk Showdesk
System.Runtime.Serialization.SerializationException: Die Assembly "LumosGUI, Version=3.2.244.0, Culture=neutral, PublicKeyToken=null" kann nicht gefunden werden.

Server stack trace: 
   bei System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()
   bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
   bei System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
   bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   bei System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   bei System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
   bei System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

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.Resource.IResourceManager.saveResource(EResourceType type, LumosResource data)
   bei Lumos.GUI.Resource.ResourceManager.saveResourceInternal(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Resource\ResourceManager.cs:Zeile 537.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 606.
   bei Lumos.GUI.Windows.Softdesk.SoftdeskManager.SaveSoftdeskModelFile(SoftdeskModel model) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Softdesk\SoftdeskManager.cs:Zeile 338.

Die vollständigen Log-Files sind im Ticket  FS#3668  zu finden. Probleme beim Speichern des Softdesks im Projekt gab es zuletzt in dem im Ticket  FS#3433  beschriebenen Fehler.

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.

Ich habe dem Softdesk einen Button hinzugefügt. Ändere ich die Hintergrundfarbe des Buttons auf gelb, wechselt die Textfarbe automatisch von weiß auf schwarz. Als Eingabehilfe wäre dies zwar ok, jedoch wechselt die Textfarbe auch nachträglich, wenn ich die Hintergrundfarbe des Buttons über einen Graphen wie [Cuelist State] > [Rule of Three] > [HSV to Color] > [Button] anspreche.

Die Erwartungshaltung ist hier, dass ich selbst dauerhaft die Textfarbe des Elements (hier weißer Text bei einem gelben Button) festlege und es keine Automatismen gibt, welche die Gestaltung des Objekts automatisch ändern, sobald ich das Element von außen über einen Graphen (hier Änderung der Hintergrundfarbe von einem dunklen Gelb auf normales Gelb (R255, G255, B0))anspreche.

Je nach Anordnung der Nodes in einem Grpahen variiert die Breite der neuen Verbindungslinien. Es ist daher möglich ist, dass sie gänzlich verschwinden, sobald die Verbindungspunkte zweier Nodes (also Ausgang und Eingang) wie im beigefügten Beispiel vertikal untereinander anordnet.

Der Eintrag “GO” im gezeigten Menü besitzt nicht die Standard-Textgröße wie die anderen Einträge in diesem Menü wo “Go Back” oder “Go Next”.

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.

Der folgende Fehler trat im Zuge des Schließen des Projekts auf:

2019-06-04 15:07:54,897 [73] 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.Scene.Entry.AbstractSceneEntry.get_DeviceProperty() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Entry\AbstractSceneEntry.cs:Zeile 164.
   bei org.dmxc.lumos.Kernel.Scene.AbstractScene.get_SceneEntrys() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\AbstractScene.cs:Zeile 427.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.clear(Boolean writeUndo, Boolean throwEvent) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 1652.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.clear() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 1619.
   bei org.dmxc.lumos.Kernel.GUISession.Session.closeProject() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\GUISession\Session.cs:Zeile 974.
   bei org.dmxc.lumos.Kernel.GUISession.SessionManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.closeProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\GUISession\SessionManager.cs:Zeile 507.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass30_0.<closeProject>b__0(ILumosManager m) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 161.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoButtomUpAction(Func`2 action) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 36.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoButtomUpAction(Func`2 action) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 33.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoButtomUpAction(Func`2 action) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 33.
     [...]
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoButtomUpAction(Func`2 action) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 33.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoButtomUpAction(Func`2 action) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 33.
   bei org.dmxc.lumos.Kernel.Run.DependencyNode`1.DoButtomUpAction(Func`2 action) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Run\DependencyNode.cs:Zeile 33.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.DoManagerButtomUp(Func`2 action) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 162.
   bei org.dmxc.lumos.Kernel.Run.KernelRunManager.org.dmxc.lumos.Kernel.Run.IKernelRunManager.DoManagerButtomUp(Func`2 managerAction)
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.closeProject(String sessionName, Boolean ask) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 157.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.closeProject(String sessionName) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 144.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.closeProject(String sessionName) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 1418.
   --- 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.

Die vollständigen Logs sind in Ticket  FS#3636  zu finden.

Eine andere Variante des Fehlers aus Ticket  FS#3637 :

2019-06-04 15:07:53,554 [78] ERROR org.dmxc.lumos.Kernel.Command.Command - Error while invoking Command: getAttachableState, 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 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.

Die vollständigen Logs sind im Ticket  FS#3636  zu finden.

Im Zuge des Schließens der Sitzung, in der u. a. der Fehler aus  FS#3636  auftrat, erschien folgender Eintrag in den Logs der Sitzung:

2019-06-04 15:07:53,549 [78] 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.Scene.Entry.AbstractSceneEntry.get_DeviceProperty() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Entry\AbstractSceneEntry.cs:Zeile 164.
   bei org.dmxc.lumos.Kernel.Scene.AbstractScene.get_SceneEntrys() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\AbstractScene.cs:Zeile 427.
   bei org.dmxc.lumos.Kernel.GUISession.Programmer.getAttachableState(String[] includeDeviceIds) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\GUISession\Programmer.cs:Zeile 1164.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.getAttachableState(String sessionName, String[] incDevIds) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 778.
   --- 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.

Die vollständigen Logs sind im oben genannten Ticket zu finden.

Im Zusammenhang mit  FS#3636  ist zusätzlich folgender Fehler aufgetreten:

2019-06-04 15:04:19,362 [71] ERROR org.dmxc.lumos.Kernel.Command.Command - Error while invoking Command: canAttachPresetToGroup, 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 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.

Die vollständigen Logs sind im oben genannten Ticket zu finden.

Beim Basteln mit der Beta 2 ist mir folgender Fehler unter die Finger gekommen:

2019-06-04 15:04:19,356 [71] 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.Scene.Entry.AbstractSceneEntry.get_DeviceProperty() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\Entry\AbstractSceneEntry.cs:Zeile 164.
   bei org.dmxc.lumos.Kernel.Scene.EntryContainerTools.<ContainsPropertyIterator>d__12.MoveNext() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Scene\EntryContainerTools.cs:Zeile 238.
   bei System.Linq.Enumerable.<IntersectIterator>d__70`1.MoveNext()
   bei System.Linq.Enumerable.Any[TSource](IEnumerable`1 source)
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.canAttachTo(IPreset p, IDeviceGroup g, IDeviceProperty prop, EPresetType type) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 974.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.<>c__DisplayClass66_1.<canAttachPresetToGroup>b__0(IDeviceProperty prop) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 951.
   bei System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   bei System.Collections.Generic.HashSet`1.UnionWith(IEnumerable`1 other)
   bei System.Collections.Generic.HashSet`1..ctor(IEnumerable`1 collection, IEqualityComparer`1 comparer)
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.canAttachPresetToGroup(String presetId, String groupID, EPresetType type) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 949.
   --- 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.

Die vollständigen Log befinden sich im Anhang.

Das 3DConnexion-Plugin lässt sich zwar fehlerfrei starten und konfigurieren, die “Anbindung” an die Stage View fehlt bis dato. Das soll heißen, ein in der Stage View ausgewähltes Gerät kann über die 3D-Maus nicht gesteuert werden.

Starte und stoppe ich mit Hilfe der Option “Single List Running” Cuelists innerhalb einer Cuelist Group, fällt beim Umschalten auf, dass durch Fade-In von Cuelist B und Fade-Out von Cuelist A erst einmal Richtung 0-Position (Dimmer 0%, Positon 0,0) bewegen. Dies ist besonders bei Positionswechsel von Moving Heads über mehrere Cuelist unschön, da ich keine direkte Fahrt von Position 1 auf Position 2 erhalte.

Kurzfristig lässt sich dies zwar wie mit Arne besprochen für mich selbst über eine längere Release-Time in den Cuelists etwas anfangen. Langfristig haben wir an dieser Stelle über eine Delay Time für das Stoppen von Cuelists innerhalb der Cuelist Group nachgedacht. Hierüber wird die zu stoppende Cuelist mit einer frei festzulegenden Verzögerung gestoppt.

Über das neue Input Assignment können Cuelists nun auch über eine Cuelist-Nummer angesprochen werden. Diese Cuelist-Nummer ist aktuell aber nicht für den User zugänglich, sodass diese nicht geändert werden können.

Diese Änderungsmöglichkeit der Cuelist Nummer sollte daher sowohl mit in die Cuelist Properties aber auch in den Project Explorer als zusätzliche Spalte aufgenommen werden. Letzters würde die Übersichtlichkeit erhöhen, aber (das wäre meine persönliche Hoffnung) dass ich sie dort auch direkt ändern kann.

Die neue Auswahlmöglichkeit der Cuelists, Executuren, Group Master etc.) direkt im Node ist richtig super. Jedoch ist der Workflow in der aktuellen Fassung noch dahingehend suboptimal, dass die Einträge in dem Dropdown-Menü nicht nach Namen sortiert werden, wie im beigefügten Screenshot anhand des Cuelist-Nodes zu sehen. Dies ist gerade bei einer größeren Anzahl von Cuelists hinderlich und bringt eigentlich vermeidbare Verzögerungen im Programmieren mit sich, weil sich die Sortierung anhand der Cuelist-, Device Group-Nummer etc. ableitet und somit die Erstellungshistorie der Objekte darstellt.

Daher wäre an dieser Stelle der Wunsch, die Einträge alphabetisch zu sortieren.

Mit folgendem Log-Eintrag ist mir die GUI der Beta 2 abgestürzt.

2019-05-28 12:41:42,390 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Windows.Softdesk.Softdesk.UserControl_MouseDown(Object sender, MouseButtonEventArgs e) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Softdesk\Softdesk.xaml.cs:Zeile 252.
   bei System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
   bei System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   bei System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   bei System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   bei System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   bei System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
   bei System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean trusted)
   bei System.Windows.Input.InputManager.ProcessStagingArea()
   bei System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
   bei System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
   bei System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
   bei System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   bei System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   bei MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   bei System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   bei System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.Run(Form mainForm)
   bei Lumos.GUI.Program.runGui() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Program.cs:Zeile 192.
   bei Lumos.GUI.Program.Main(String[] param) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Program.cs:Zeile 149.

Die Hintergrundfarbe des Softdesks kann nicht festgelegt werden. Im hellen Theme ist dieser standardmäßig in einem hellen Grau.

Unter DMXControl 3.1 habe ich das im Anhang befindliche DDF erstellt und live am Gerät erfolgreich geprüft. Das DDF war fehlerfrei.

Mit DMXControl 3.2 kann ich mit dem gleichen DDF jedoch keine Gobos mehr auswählen. Die Auswahl wird vom Control Windows für Gobo angenommen und auch vom Device Control übernommen, in der Stage View und vor allem am Gerät selbst kommt die Auswahl nicht an. Die Gobos sind wie folgt implementiert:

<step type="gobo" mindmx="65" maxdmx="69" val="Robe Robin 600E Spot Gobo 1 (Rad 2).png" caption="Gobo 1">
  <range handler="goboshake" mindmx="65" maxdmx="69" minval="0" maxval="0" />
  <range handler="goboshake" mindmx="110" maxdmx="119" minval="0.4" maxval="10" />
</step>

<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" 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="139" minval="0.4" maxval="10" />
  </step>
 </step>

Selbst beim Kopieren von nur drei Gobos eines Goborads ohne Zusätze wie Goborotation, Goboshake, Goboindizierung etc. in ein Test-DDF, wo neben dem Goborad zusätzlich nur ein Dimmer enthalten ist, funktioniert die Auswahl der Gobos nicht. Es wird jeweils nur das letzte Gobo aktiviert.

Reduziere ich den Dateinamen für das Icon um nur ein Zeichen auf 34 Zeichen zzgl. Dateiendung - also auf Robe Robin 600 Spot Gobo 1 (Rad 1).png (ohne das E) - arbeitet das DDF wieder fehlerfrei.

Zum Nachstellen des Problem habe ich im Anhang beide Varianten hochgeladen. Die alte Variante ist die Ursprungsvariante für DMXControl 3.1, die neue Variante ist die entsprechend korrigierte Variante mit dem verkürzten Dateinamen für DMXControl 3.2.

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.

Füge ich ein Radix-Gerät meinem Projekt hinzu und möchte über den Colorpicker die Gesamtfarbe festlegen, gibt die Stage View die eingestellte Farbe nicht wieder. Die DMX-Ausgabe arbeitet aber wie gewünscht. Es wäre gut, wenn Radix-Geräte am Ende genauso arbeiten, wie klassische Matrix-Geräte - hier funktioniert das Festlegen und Visualisieren einer festen Farbe vom Colorpicker in der Stage View

Das verwendete DDF des Radix-Geräts ist im Anhang beigefügt.

In den Logs ist mir folgender Fehler aufgefallen, nachdem ich ein Projekt geladen habe.

2019-05-01 10:30:59,469 [1] ERROR Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der angegebene Schlüssel war nicht im Wörterbuch angegeben.
System.Collections.Generic.KeyNotFoundException: Der angegebene Schlüssel war nicht im Wörterbuch angegeben.
   bei System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   bei Lumos.GUI.ChannelOverview.PatchMatrixControl.PaintCell(Graphics graphics, Int32 cellIndex) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosControls\PatchMatrixControl\PatchMatrixControl.cs:Zeile 738.
   bei Lumos.GUI.ChannelOverview.PatchMatrixControl.OnPaint(PaintEventArgs e) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosControls\PatchMatrixControl\PatchMatrixControl.cs:Zeile 501.
   bei System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
   bei System.Windows.Forms.Control.WmPaint(Message& m)
   bei System.Windows.Forms.Control.WndProc(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
2019-05-01 10:33:04,937 [Log-Thread] INFO  AudioAnalyser.AudioAnalyserPlugin - Saving Data AudioAnalyser Start. 3
2019-05-01 10:33:04,938 [Log-Thread] INFO  AudioAnalyser.AudioAnalyserPlugin - Saving Data AudioAnalyser End. 5

In der gleichen Session wie in Ticket  FS#3567  ist mir folgender Eintrag im GUI-Log aufgefallen. Ich könnte mir denken, dass dieser Eintrag im Zusammenhang mit den Blades steht.

2019-04-26 14:15:45,941 [1] ERROR TreeGridMode - Die Methode oder der Vorgang ist nicht implementiert.
System.NotImplementedException: Die Methode oder der Vorgang ist nicht implementiert.
   bei Lumos.GUI.Windows.Programmer.ProgrammerModelValue.<>c.<GetCellValueWrapper>b__24_23(Object v) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Programmer\ProgrammerModel.cs:Zeile 767.
   bei org.dmxc.lumos.XNAViews.ListView.Mode.DataGrid.CellValueWrapper.Update(Boolean force) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\ListView\Mode\DataGrid\Member\Cell\CellWrapper\CellValueWrapper.cs:Zeile 93.
2019-04-26 14:15:46,168 [1] ERROR TreeGridMode - Die Methode oder der Vorgang ist nicht implementiert.

Füge ich in ein DDF ein Blade-Modul ein, werden diese in der Stage View grundsätzlich als geschlossen visualisiert. Das bedeutet, bei einem Klick auf Lumos öffnet sich zwar der Shutter, der Lichtkegel bleibt aber weiterhin schwarz. Der Dimmer arbeitet im Hintergrund regulär, was ich anhand der DMX-Ausgabe und durch das Einblenden der Intensity sehen kann. Kommentiere ich das Blade-Modus aus, funktioniert das DDF wie gewohnt.

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.