Bugtracker DMXControl 3

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

Das Problem lässt sich wie folgt reproduzieren:

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

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

Für den Sparkle Effekt wünsche ich mir noch folgenden Parameter:

• Min Delay (ms): Einstellung, wie viel Zeit zwischen dem Aufleuchten des nächsten Geräts vergehen soll, um auf Wunsch ein nahezu paralleles Aufleuchten von mehreren Geräten zu vermeiden. Standartwert wäre auch aus Kompatibilitätsgründen 0 ms.

Für den Position Master sollen folgende Buttons hinzugefügt werden:

• Zero Pan
• Zero Tilt

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.

Für einen Test baute ich kürzlich zusätzlich zum Main-PC noch einen zweiten Backup-PC auf, wovon nur einer der beiden PCs die DMX-Daten über Art-Net ausgeben sollte. Gerade bei Art-Net gibt es ja bekanntermaßen murks, wenn zwei PCs das gleiche Gerät ansprechen wollen.

Wenn alles geregelt läuft, kann ich vor einem Neustart zum Beispiel die Art-Net-Ausgabe deaktivieren. Liegt aber nun ein Fehler vor, wodurch ich das Deaktivieren nicht mehr entsprechend anstoßen kann, sind die DMX-Interfaces wie zuletzt gespeichert beim erneuten Starten des Kernels nur kurze Zeit wieder aktiviert und die Ausgabe wird auf 0 gesetzt - egal ob ein Projekt geladen wurde oder nicht. Dies war im konkreten Fall insofern problematisch, weil das Projekt beim Starten von DMXControl 3 als “Default Project” direkt mit geladen wird und ich während des Ladevorgangs keinen Zugriff auf die DMX-Ausgabe habe. Damit mir nun mein Main-PC nicht in die Suppe spuckt und nichts ausgegeben wird, blieb mir nichts anderes übrig, als im Interface-Rack die Art-Net-Interfaces händisch temporär direkt auf den Backup-PC umzuklemmen.

Um nun im Falle eines unvorhergesehen Neustarts (insbesondere mit einem Default Project, was effektiv gesehen das “Arbeitsprojekt” / “Showprojekt” ist) nicht Hand an der Verdrahtung der Hardware anlegen zu müssen, würde ich mir hier eine Möglichkeit wünschen, dass ich im Idealfall selbst den Zeitpunkt festlegen kann, wann die DMX-Ausgabe auf die Interfaces bzw. die Interfaces selbst aktiviert werden - und zwar unabhängig davon, was in den Einstellungen für die DMX-Ausgabe grundsätzlich gespeichert ist.

Aus meiner Sicht sollte die Zeit für das automatische Schließen der Abfrage “Load last window layout?” verlängert werden. Gerade wenn ich größere Projekte lade, ist DMXControl 3 noch lange mit sich selbst beschäftigt. In diesem Zustand geht die Abfrage ein Stück weit darin unter, weil im Hintergrund noch vielerlei Dinge passieren.

Im Zusammenhang mit dem Ticket  FS#3483  fiel auf, dass ich dem Speedmaster einen enorm hohen BPM-Wert von >10000 BPM mit auf den Weg geben muss, wenn ich den Speedmaster auf die möglichen Zeit-Parameter eines Effekts lege, die in Millisekunden anzugeben sind. Im Node im Input Assignment selbst wird aber die richtige Zeit von 600ms ausgegeben, wenn ich den Speedmaster auf einen Wert von 100 BPM tappe.

Getestet mit Build 1446

Ich habe eine neue Cuelist mit einem SpeedMaster angelegt sowie mehrere Verknüpfungen im Input Assignment erstellt. Daraufhin ließ sich das Projekt nicht mehr speichern.

2019-01-23 23:07:34,989 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore - Returning 26 resources of type  in Project.
2019-01-23 23:07:49,545 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Project.ProjectManager - Session SKI-DSK-M4A89GA is saving Project New Project to Temp\ea184066-c6e0-40bf-b75f-d5645fefbaa0.tmp.
2019-01-23 23:07:57,222 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - saveProject KernelInputManager.
2019-01-23 23:07:58,393 [37] ERROR org.dmxc.lumos.Kernel.Scene.Fanning.FannedValueManager - Unable to serialize IFannedValue with Types: String
2019-01-23 23:07:58,395 [37] ERROR org.dmxc.lumos.Kernel.Project.ProjectManager - Error at save Project, try to load a previous Version
org.dmxc.lumos.Kernel.Exceptions.WrongValueTypeException: There is no Converter for Type: String
   bei org.dmxc.lumos.Kernel.Scene.Fanning.FannedValueManager.serializeIFannedValue(IFannedValue value) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Scene\Fanning\FannedValueManager.cs:Zeile 457.
   bei org.dmxc.lumos.Kernel.Scene.Fanning.FannedValueManager.org.dmxc.lumos.Kernel.Resource.Serializer.IResourceSerializer.serialize(Object toSerialize) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Scene\Fanning\FannedValueManager.cs:Zeile 428.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(String name, Object value, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 329.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 267.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(String name, Object value, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 335.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 267.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 273.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 273.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 273.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 273.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 273.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 273.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 273.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 249.
   bei org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:Zeile 489.
   bei org.dmxc.lumos.Kernel.Resource.ResourceManager.saveResourceInternal(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Resource\ResourceManager.cs:Zeile 283.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 602.
   bei org.dmxc.lumos.Kernel.Project.Project.saveProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Project\Project.cs:Zeile 274.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.saveProject(String name, Stream outputStream, String sessionName) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 382.
2019-01-23 23:07:58,439 [Log-Thread] INFO  org.dmxc.lumos.Kernel.GUISession.Session - Failed to save Project to GUI SKI-DSK-M4A89GA, Path F:\Verein\DMXControl Projects\Software\DMXControl 3\Testprojekte\DMXC 3.2\Beta-Test V3.2 Alpha 2 (Testprojekt 1).zip

Problem siehe oben und lässt sich wie folgt reproduzieren:

1. Slider mit Parametermaster 1 verknüpfen.
2. Connectionset deaktivieren.
3. Im Parametermaster-Node einen anderen Parametermaster, zum Beispiel Parametermaster 2 auswählen.
4. Connectionset aktivieren.

Das Ergebnis ist, dass der Slider nach dem Reaktivieren des Connectionsets weiterhin den Parametermaster 1 anspricht, obwohl im Connectionset auf der Inputseite die ID des Parametermaster 2 vermerkt ist. Diese wurde intern nicht weiterverarbeitet. Gleiches lässt sich mit dem Cuelist-Node reproduzieren.

Die neue WPF-Message-Box kann aktuell noch in ihrer Größe angepasst. Dabei ist auch ein Maximieren möglich, wenn ich das Fenster an den Bildschirmrand ziehe. Dies sollte aber unterbunden werden und die WPF-Message-Box sollte eine ggf. global vorgegebene Größe erhalten.

Aktuell kann man aus der Stage View heraus bereits Geräte zu einer neuen (leeren) Device Group hinzufügen.

Hier könnte ich mir einen zusätzlichen Workflow als hilfreich vorstellen, mit dem man in der Stage View ein oder mehrere Geräte auch einer existierenden Device Group hinzufügen kann. Bis dato ist dies ja nur im Add Device möglich, aber nur für eine Gruppe.

Ich habe das Ticket mal auf Usuability Relevant gesetzt, um damit herauszufinden, ob dieser Mehrwert auch von jemand anderes gesehen wird.

Ich habe gestern mit meinem Live-Show-Projekt über einen längeren Zeitraum ein wechselndes Ambiente gebaut und zwischendurch immer mal wieder Licht live gedrückt. Beim Heraussuchen der Logdateien für einen anderen Fehler bin ich auf die mit rund 170 MB sehr große Logdatei des Kernels aufmerksam geworden.

Der folgende Eintrag wurde über den genannten Zeitraum über 1,2 Millionen Mal in die Logdatei geschrieben - sogar noch als vorletzter Eintrag bevor der Kernel final geschlossen wurde.

2023-01-06 19:31:14,781 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - Processing Queue of Graphs contains 11 elements
[...]
2023-01-06 22:50:18,081 [114] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - Processing Queue of Graphs contains 50 elements
2023-01-06 22:50:18,095 [Main] INFO  DMXControl 3 Kernel - Kernel closing!

Diese Logeinträge werden generiert, sobald ich das Projekt geladen habe, selbst wenn nach dem Laden noch nichts aktiv ausgegeben wird.

Das zugehörige Projekt umfasste zu dem Zeitpunkt 114 Connectionsets sowie 18 Bänke. Für das Debugging stelle ich das Projekt über die Cloud zur Verfügung, benannt entsprechend mit der Nummer dieses Tickets.

Über eine lange Laufzeit einer Sitzung haben sich im Log des Kernels zahlreiche Fehlermeldungen im Bereich des ArNetManagers aufgestaut, sodass dieses Log allein über 4,5 Millionen Zeilen enthält. Exemplarische Fehlermeldungen sind unten herausgezogen. In diesem Zusammenhang konnte die GUI keine Verbindung mehr aufbauen, weil der Kernel mit Log schreiben beschäftigt war.

Im Anhang sind die kompletten Logs der Sitzung. Bitte beim Öffnen u. U. Zeit einplanen…

2023-06-17 14:57:46,972 [60] ERROR org.dmxc.lumos.Kernel.DMX.ArtNetFactory - 
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtDmx(Byte[] packet) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 557
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 741

2023-06-17 15:25:54,776 [98] ERROR org.dmxc.lumos.Kernel.DMX.ArtNetFactory - 
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 602
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 741

2023-06-17 23:19:20,497 [140] ERROR org.dmxc.lumos.Kernel.DMX.ArtNetFactory - 
System.Net.Sockets.SocketException (10055): Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war.
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ReceiveFromAsync(Socket socket, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.ReceiveFromAsync(Memory`1 buffer, SocketFlags socketFlags, EndPoint remoteEndPoint, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.BeginReceiveFrom(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint& remoteEP, AsyncCallback callback, Object state)
   at System.Net.Sockets.UdpClient.BeginReceive(AsyncCallback requestCallback, Object state)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 739
  ...
   at System.Threading.Tasks.TaskToApm.TaskAsyncResult..ctor(Task task, Object state, AsyncCallback callback)
   at System.Net.Sockets.Socket.BeginReceiveFrom(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint& remoteEP, AsyncCallback callback, Object state)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 705
   at System.Threading.Tasks.TaskToApm.TaskAsyncResult.InvokeCallback()
   at System.Threading.Tasks.AwaitTaskContinuation.<>c.<.cctor>b__17_0(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.AwaitTaskContinuation.RunCallback(ContextCallback callback, Object state, Task& currentTask)
   at System.Threading.Tasks.AwaitTaskContinuation.Run(Task task, Boolean canInlineContinuationTask)
   at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.InvokeContinuation(Action`1 continuation, Object state, Boolean forceAsync, Boolean requiresExecutionContextFlow)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.OnCompleted(SocketAsyncEventArgs _)
   at System.Net.Sockets.SocketAsyncEventArgs.<>c.<.cctor>b__179_0(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at System.Threading.ThreadPoolBoundHandleOverlapped.CompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pNativeOverlapped)
--- End of stack trace from previous location ---
   at System.Threading.Tasks.TaskToApm.End[TResult](IAsyncResult asyncResult)
   at System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   at System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 741

Ich starte eine Timecode-Show über Play und halte die Show mittels Pause an. In dieser Situation kann ich den Wiedergabe-Marker (den roten) nicht neu positionieren.

Der Wiedergabe-Marker lässt sich daher nur unter einer ganz bestimmten Konstellation neu positionieren und zwar:

• Die Wiedergabe wurde nicht durch pausieren angehalten.
• Nach dem Pausieren wird der Track nochmals vom ursprünglichen Startpunkt wiedergegeben.
• Die Wiedergabe wird über Stop angehalten.

Wenn diese Punkte beachtet werden, kann man zwar damit arbeiten, jedoch ist es ein unerwartetes Verhalten, was den Workflow beeinträchtigt.

Versuche ich für den Plasma-Effekt die Frequenz beliebig zu ändern, hat dieser Wert keinen Einfluss auf den Effekt. Er läuft also aktuell trotz beliebiger Frequency mit der gleichen Geschwindigkeit weiter.

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

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

Besitzt ein Gerät verschiedene Strobe-Effekte wie zum Beispiel

<strobe dmxchannel="1">
  <step type="open" mindmx="0" maxdmx="5" />
  <range type="linear" mindmx="128" maxdmx="250" minval="0.1" maxval="20" />	    
  <range type="pulse" mindmx="11" maxdmx="33" minval="0.5" maxval="6" />	  
  <range type="ramp up" mindmx="34" maxdmx="56" minval="1" maxval="12" />
  <range type="ramp down" mindmx="57" maxdmx="79" minval="1" maxval="12" />
  <range type="random" mindmx="80" maxdmx="102" minval="1" maxval="12" />
  <range type="spikes" mindmx="103" maxdmx="127" minval="1" maxval="12" />
  <step type="open" mindmx="251" maxdmx="255" />	  
</strobe>

so wird im Device Control als Wertebereich für die Strobe-Frequenz immer nur der Bereich 0,1 bis 20 Hz ausgegeben - egal, welcher Strobe-Effekt ausgewählt wird.

Dies ist unschön, weil die HAL unter Umständen zwei unterschiedliche Geräte durch diese “falsche” Umrechnung auch unterschiedlich stroben lässt.

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

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

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

Aktuell erwarten Trigger-Inputs nur true oder false als Input. Um die Graphen zu vereinfachen, wäre es gut, wenn die Inputs parallel auch 0 und 1 als Wert zulassen würden.

Ich habe im beigefügten Projekt eine einfache Cuelist erstellt, die einem Cuelist-Track einer Timecode-Show zugeordnet ist.

Editiere ich eine beliebige Cue aus dieser Cuelist im Programmer und speichere die Änderungen zum Beispiel Replace oder Update zurück, wird der Wert für den Trigger immer auf 00:00:01.000 zurückgesetzt und die Cue an Position in der Cuelist eingefügt.

Die zugehörigen Logs beinhalten folgende Schritte:

1. Sitzung starten und Projekt laden
2. Cue 3 der Cuelist 1 in den Programmer laden
3. Änderungen vornehmen
4. Änderungen über Update in die Cue 3 zurückspeichern
5. Cue 3 an ursprüngliche Position zurückschieben und alten Wert manuell wieder eintragen
6. Projekt speichern und Projekt beenden

In den Einstellungen für die Executor-Seiten kann ich festlegen, wie viele Executoren ist pro Seite nutzen möchte. Dieser Wert wird jedoch ignoriert. Egal welchen Wert ich einstelle, es werden grundsätzlich acht Executoren pro Seite angelegt.

Füge ich eine Auswahl von mehreren Geräten nachträglich manuell über den Project Explorer einer Stage View hinzu, werden diese trotz vorhandenem Platz sehr weitläufig positioniert, wie im beigefügten Screenshot ist.

Der Fehler tritt auf, wenn ich ein beliebiges Icon (also Device, Device Group oder Matrix) in seiner Größe vergrößere. Reduziere ich die Größe des Icons wieder auf die Standardgröße von 32 x 32 Pixel, erfolgt die Positionierung der Icons wie gewohnt.

Dies ist ein Punkt, der von meiner Seite aus auch erst mit DMXControl 3.2.1 behoben werden kann.

Analog zu den zusätzlichen Befehlen zum Herunterfahren des Kernels (siehe Ticket  FS#4394 ) sollten diese aus Konsistenzgründen auch im Umbra hinterlegt werden. Aktuell wären diese zusätzlichen Befehle “quit” und “close”.

Füge ich eine zweite Audiodatei dem Audio-Track hinzu, so wird diese bei 0:00 positioniert. Dies hat dann zur Folge, dass ich die bereits im Audio-Track existierende Audiodatei nicht mehr verschieben kann.

Erst wenn eine bereits vorhandene Audiodatei so weit nach hinten geschoben habe, kann ich beide Audiodateien einzeln wieder verschieben. Aus diesem Grund sollten neue Audiodateien immer hinter die letzte Audiodatei eingefügt werden.

Beim Durchsehen der Logs der GUI fiel mir auf, dass die GUI vergeblich nach folgenden Dateien sucht:

• C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations\en\LC_MESSAGES\Lumos.mo
• C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations\en\LC_MESSAGES\DMXPlugins.mo

Auf meinem PC sind nur die äquivalenten Daten für de vorhanden. Fehlen hier im Installer entsprechende Dateien?

Der vollständige Auszug aus den Logfiles lautet:

2020-03-26 17:51:39,179 [Main GUI] DEBUG NGettext.Plural.DefaultPluralRuleGenerator - Creating a built-in plural rule for langcode "en" for locale "en".
2020-03-26 17:51:39,183 [Main GUI] WARN  NGettext.Loaders.MoLoader - Unable to load any translation file. All of these not found:
C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations\en\LC_MESSAGES\Lumos.mo
C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations\en\LC_MESSAGES\Lumos.mo
C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations\en\LC_MESSAGES\Lumos.mo
2020-03-26 17:51:39,183 [Main GUI] WARN  LumosLIB.Tools.I18n.T - Unable to find Lumos.mo translation File for Culture en: Can not find MO file name in locale directory "C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations".
2020-03-26 17:51:39,183 [Main GUI] WARN  NGettext.Loaders.MoLoader - Unable to load any translation file. All of these not found:
C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations\en\LC_MESSAGES\DMXPlugins.mo
C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations\en\LC_MESSAGES\DMXPlugins.mo
C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations\en\LC_MESSAGES\DMXPlugins.mo
2020-03-26 17:51:39,183 [Main GUI] WARN  LumosLIB.Tools.I18n.T - Unable to find DMXPlugins.mo translation File for Culture en: Can not find MO file name in locale directory "C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\GUI\Localizations".

Im GUI-Log ist mir folgende Warnung aufgefallen, auf Grund dessen das Softdesk nicht im Projekt gespeichert werden kann:

2019-03-20 22:15:13,618 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to save project in SoftdeskManager
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
   bei System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
   bei System.Windows.Forms.Control.Invoke(Delegate method)
   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 329.
   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 1195.
   bei Lumos.GUI.Windows.Softdesk.SoftdeskManager.saveProject(LumosGUIIOContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Softdesk\SoftdeskManager.cs:Zeile 300.
   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.

Mit der Veröffentlichung der Beta 6 kommt nun immer folgende Fehlermeldung im Kernel, wenn ein Projekt Executoren enthält, denen ein Element zugeordnet sind:

21:02:46 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Executor.ScenelistExecutorMemberConfiguration could not be loaded: Number, Name
21:02:46 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Executor.ExecutorMemberConfiguration could not be loaded: Number, Name

Trotz dieser Fehlermeldung stimmt die Zuordnung der Executoren aber und auch die individuelle Konfiguration der Buttons wird richtig geladen.

So war es auch im Zuge des Zusammenfügen der Logs für  FS#5035 . In den dort beigefügten Logfiles ist die genannte Fehlermeldung ebenfalls enthalten, als ich das Projekt aus FS#4772 öffnete. Dieses enthält drei Executoren, denen eine Szenenliste zugeordnet ist.

Der folgende Log-Eintrag taucht beim Starten des Kernels regelmäßig auf:

2019-04-09 22:11:39,807 [Main] WARN  org.dmxc.lumos.Kernel.Plugin.PluginManager - Timeout when fetching Interface List from DMX Interface Factory Enttec
System.TimeoutException: Timeout für den Vorgang wurde überschritten.
   bei DMXLIB.FactoryTimeoutDecorator.get_Interfaces() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\DMXLIB\FactoryTimeoutDecorator.cs:Zeile 105.
   bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.loadInterfaces(IDMXInterfaceFactory factory) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Plugin\AbstractPluginManager.cs:Zeile 1246.

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.

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.

Beim Durchschauen von Logfiles ist mir folgender Eintrag im GUI-Log aufgefallen. Zuvor habe ich ein paar unterschiedliche Projekte geladen und wieder geschlossen (durch das Laden eines weiteren Projekts).

2019-04-14 14:24:32,687 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to load project in MIDIManager
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Sink with that ID is already existing!
   bei org.dmxc.lumos.Kernel.Input.v2.AbstractInputManager.RegisterSink(IInputSink sink) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Input\v2\AbstractInputManager.cs:Zeile 100.
   bei Lumos.GUI.Input.v2.InputManager.RegisterSink(IInputSink sink) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Input\v2\InputManager.cs:Zeile 176.
   bei Lumos.GUI.MIDI.MidiInformation.onRuleAdded(Object sender, RuleEventArgs e) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\MIDI\MidiInformation.cs:Zeile 116.
   bei Lumos.GUI.MIDI.MidiInformation.OnRuleSetAdded(Object o, RuleSetEventArgs rs) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\MIDI\MidiInformation.cs:Zeile 90.
   bei Lumos.GUI.MIDI.MidiInformation.RuleSetCollection.OnAdded(RuleSet rs) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\MIDI\MidiInformation.cs:Zeile 20.
   bei Lumos.GUI.MIDI.MIDIManager.Load() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\MIDI\MIDIManager.cs:Zeile 153.
   bei Lumos.GUI.MIDI.MIDIManager.Lumos.GUI.Run.IGuiProjectManager.loadProject(LumosGUIIOContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\MIDI\MIDIManager.cs:Zeile 109.
   bei Lumos.GUI.Run.GuiRunManager.<>c__DisplayClass32_0.<loadProject>b__0(IGuiManager m) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Run\GuiRunManager.cs:Zeile 289.

Die vollständigen Logs sind im Anhang.

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()<---

Habe ich Geräte einer Powersource zugeordnet und lasse mir das zugehörige VU-Meter anzeigen, werden dessen Werte nicht kontinuierlich aktualisiert.

1. Devices mit gepflegten Leistungsdaten hinzufügen
2. Powersource anlegen
3. Electricity-Window öffnen
4. In der Stage View Geräte highlighten oder Lumos drücken

Das Ergebnis ist, dass das VU-Meter wird nicht aktualisiert wird. Ändere ich aber zum Beispiel den Namen, bekommt das VU-Meter die aktuellen Werte übermittelt. Die Nodes im Input Assignment sind davon nicht betroffen.

Auf einer Remote-GUI werden die Vorschau-Icons für die Effekte und Filter nicht anzeigt.

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

Ich habe ein Projekt geladen, in dem verschiedene Geräte deaktiviert sind. Aktiviere ich diese Geräte nun, kann ich diese nicht direkt sauber ansprechen. Dies äußert sich unter anderem darin, dass beim Leeren des Programemrs werden die Intialwerte nicht richtig gesetzt, wie z. B. Dimmer auf 0, Shutter geschlossen oder Standardfarbe weiß. Teilweise bleiben auch beim Beenden von Cuelists die Werte in einem undefinierten Zustand hängen.

Erst wenn ich das Projekt noch einmal neu lade, reagieren die wieder aktivierten Geräte so wie gewohnt.

In Bezug zum Ticket  FS#3400  fiel mir auf und ein, dass ein entsprechendes Dropdown-Menü in den Properties der jeweiligen Nodes hilfreich wäre, wo ich die jeweiligen Cuelists, Master etc. auswählen kann, ohne die Properties verlassen zu müssen.

Beispiel für das Group Master Node: im Feld GroupMaster zeigt mir das Dropdown-Menü alle verwendbaren Group Master im Klartext an. Ist der gewünschte Group Master ausgewählt, ersetzt das Input Assignment den Namen durch die individuelle ID des Group Masters. Ähnlich würde folglich auch mit den Cuelists gearbeitet werden. Hier laufe ich ja Gefahr, dass beim Ändern des Namens der Cuelist die zugehörige Verbindung nicht mehr funktioniert, sollte keine “Übersetzung” in die ID erfolgen.