Bugtracker DMXControl 3

Ich habe Probleme beim Laden von gespeicherten Textbüchern.

Es werden die Styles nicht geladen
Und es kommt vor, dass bei größeren Änderungen Sachen nicht gespeichert werden. Was genau konnte ich noch nicht reproduzieren.

Ich habe aber im Log eine Meldung gefunden, dass nicht richtig gespeichert werden konnte.

Mir ist folgender Fehler in der aktuellen Release 3.3.2 aufgefallen.

Das FFT-Diagramm wird nur noch schwarz/weiß/grau dargestellt, es wird auch nicht mehr aktualisiert wenn z.B. das Weighting geändert wird.
Der Fehler tritt auf sobald eine Timecode Show geöffnet wird.
Es ist egal ob eine Show:
- aus einem bestehenden Projekt geöffnet
- eine neue Timecode Show in einem bestehenden Projekt eingefügt wird
- oder ein Timecode Show in einem komplett neuen Projekt erstellt wird

Ich habe das auf zwei unterschiedlichen PC´s getestet, auf beiden tritt das Problem auf.

Bin mir nicht sicher ob ich nur eine Einstellung übersehen habe.

Im Anhang ist ein Screenshot von dem Fehler und ein Export der LogFiles. Der Export ist von einem neuen Projekt nur mit einer Timecode Show als Test
es sind noch keine DDF in Projekt vorhanden.

Steffen

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

Erwartetes Verhalten

Ich habe folgende Definition erstellt:

<cmy>
  <cyan dmxchannel="3"/>
  <magenta dmxchannel="4"/>
  <yellow dmxchannel="5"/>
</cmy>
<colorwheel dmxchannel="7">
  <step type="enableRGB" mindmx="0" maxdmx="0"/>
  <step type="color" val="L007" mindmx="1" maxdmx="1"/>
  <step type="color" val="L103" mindmx="2" maxdmx="2"/>
  ...
  <wheelrotation>
    <range type="cw" mindmx="201" maxdmx="180" minval="0.1" maxval="8"/>
    <step type="stop" mindmx="202" maxdmx="207"/>
    <range type="ccw" mindmx="208" maxdmx="229" minval="0.1" maxval="8"/>
  </wheelrotation>
  <random>
    <step type="fast" mindmx="235" maxdmx="239"/>
    <step type="medium" mindmx="240" maxdmx="244"/>
    <step type="slow" mindmx="245" maxdmx="249"/>
  </random>
</colorwheel>

Die Umschaltung vom virtuellen Farbrad zurück zu CMY funktioniert aber so nicht, weil der Wert “enableRGB” die CMY-Mischung nicht berücksichtigt. Daher wäre meine Erwartungshaltung:

• entweder wird hier eine entsprechende Unterstützung für virtuelle Farbräder in Kombination mit CMY und HSV ergänzt
• für die anderen Farbmischungen werden eigene Werte ergänzt

Geräte, die als Matrix definiert sind, können über den Blackout nicht dunkel geschaltet werden. Dabei ist es egal, ob ein Matrix-Effekt angewendet wurde oder ob Dimmer und Farbe für die gesamte Matrix gesetzt wurden.

Fehlerbeschreibung

Erwartetes Verhalten

Ich füge ein Gerät mit einer Auflösung für die Farbmischung mit 16 bit einem leeren Projekt hinzu wie zum Beispiel dem Robe LEDBeam 150 im Mode 1.

Bewege ich den Punkt mit der Maus und schaue mir die Werte in der Kanalübersicht an, sehe ich, dass die DMX-Werte sowohl für 8 bit als auch 16 bit parallel ein- und ausfaden - der DMX-Kanal für 16 bit verhält sich wie der DMX-Kanal für 8 bit. Gleiches passiert auch, wenn ich im Device Control die Regler für RGB, CMY oder HSV direkt im Dropdown unter Color nutze.

Benutze ich die Regler für die einzelnen Farben, verhält sich die DMX-Ausgabe so wie ich es für 16 bit erwarte. Gleiches gilt auch für das Position Control oder den Regler für Dimmer im Intensity Panel. Daher wäre es gut, wenn der Color Picker im Color Panel sich gleichermaßen verhalten und am Ende die DMX-Werte für die Fine-Channel nach dem bekannten Muster ausgegeben werden.

Fehlerbeschreibung

Erwartetes Verhalten

DMXControl 3 besitzt im Projekt Explorer die Funktion, dass Einträge auch auf die ExecutorPage gezogen werden können. Dann werden mehrere Executoren mit den passenden Inhalten angelegt. Dies funktioniert auch, wenn der Executor beim Laden des Projekts leer war. Wenn er jedoch bereits einen Member enthalten hatte, wird der Inhalt der Buttons und des Faders nicht korrekt aktualisiert. Dann werden die Standard-Elemente des MemberWrappers eingefügt und nicht die spezifischen Elemente, die durch das Hinzufügen auf die ExecutorPage vorgegeben werden.

I’ve noticed a cuelist behaviour that seems incorrect

I have a cuelist (we’ll call this the master cuelist), and within that cuelist, I am triggering some other cuelists (we’ll call these sub-cuelists) using the ‘Go’ and ‘Stop’ special cues.

If I use the ‘Go to’ function to jump to a later point in the master cuelist after I have triggered a ‘go’ and then a ‘stop’ on a sub-cuelist, that sub-cuelist remains playing when I believe it should be stopped.

So in the attached example screenshot, if I “Go To” cue 17, I would expect the ‘Petro Alts’ and ‘Petro Zips’ cuelists to be stopped, but instead they are running.

If I play the cuelist from the start, they behave as expected.

Verwende ich beim TCP die Executoren, dann werden alle Knopfdrücker etc. einmal ausgeführt, die vor dem Marker gesetzt sind. Das Sorgt dafür, wenn man 20x nen Trigger gesetzt hat, wird auch 20x dieser ausgelöst. Was zum einen den GUI in die Knie zwingt, als auch unschön bei der DMX Ausgabe ist

Meiner Meinung nach müsste man die Executoren nicht triggern, sondern erst ab dem Zeitpunkt wo man den TCP startet

Folgendes Vorgehen:
Einen Colormaster anlegen, im Input-Assigment über Item-List (Colorlist) und List-Selector die Farbe an den Colormaster geben. Wähle ich nun GoTo auf diese Cue aus wird die Farbe des Colormaster hart gesetzt. Im normalen Ablauf der Cuelist wird gefadet.
Nehme ich die Color aus dem List-Selector, wandle sie nach RGB und wieder zurück nach Color und gebe das an den Colormaster wird er auch bei GoTo korrekt gefadet.
Anbei ein Beispiel-Projekt. Colormaster 1 wird direkt über den ListSelector gesetzt, Colormaster 2 über die Wandlung. CM 1 fadet bei GoTo nicht, CM 2 fadet….

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

20:56:12 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:56:13 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Timeslot for ID 12b9c255-1f9f-4a2a-84f5-b9822edec50a-TS already registered
   at org.dmxc.lumos.Kernel.Time.TimeManager.registerFixedTimeSlot(String targetId, ITimeSlot timeSlot) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Time\TimeManager.cs:line 89
   at org.dmxc.lumos.Kernel.Timecode.Timecode.Play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 919
20:56:13 INFO  Timecode - Run:     [1, New TimecodeShow]
20:56:13 INFO  Timecode - Start:   [1, New TimecodeShow] Frame:     0
20:56:15 WARN  Timecode - Performing the Frame: 39 takes too much time, it exceeds the max. frame duration 191.4261ms >= 40ms
20:56:19 WARN  Timecode - Performing the Frame: 139 takes too much time, it exceeds the max. frame duration 169.6493ms >= 40ms
20:56:24 WARN  Timecode - Performing the Frame: 263 takes too much time, it exceeds the max. frame duration 155.5815ms >= 40ms
20:56:26 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   319 Time: 00:00:12.7770985
20:56:41 INFO  Timecode - Stop:    [1, New TimecodeShow] Frame:   319 Time: 00:00:13.5876047
20:56:41 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:56:43 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Timeslot for ID 12b9c255-1f9f-4a2a-84f5-b9822edec50a-TS already registered
   at org.dmxc.lumos.Kernel.Time.TimeManager.registerFixedTimeSlot(String targetId, ITimeSlot timeSlot) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Time\TimeManager.cs:line 89
   at org.dmxc.lumos.Kernel.Timecode.Timecode.Play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 919
20:56:43 INFO  Timecode - Run:     [1, New TimecodeShow]
20:56:43 INFO  Timecode - Start:   [1, New TimecodeShow] Frame:     0
20:56:44 WARN  Timecode - Performing the Frame: 39 takes too much time, it exceeds the max. frame duration 202.5471ms >= 40ms
20:56:48 WARN  Timecode - Performing the Frame: 139 takes too much time, it exceeds the max. frame duration 183.8875ms >= 40ms
20:56:49 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   182 Time: 00:00:07.2996301
20:56:50 INFO  Timecode - Resume:  [1, New TimecodeShow]
20:56:53 WARN  Timecode - Performing the Frame: 264 takes too much time, it exceeds the max. frame duration 195.172ms >= 40ms
20:56:56 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   335 Time: 00:00:13.3854502
20:56:58 INFO  Timecode - Stop:    [1, New TimecodeShow] Frame:   335 Time: 00:00:13.5248318
20:56:58 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:56:59 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Timeslot for ID 12b9c255-1f9f-4a2a-84f5-b9822edec50a-TS already registered
   at org.dmxc.lumos.Kernel.Time.TimeManager.registerFixedTimeSlot(String targetId, ITimeSlot timeSlot) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Time\TimeManager.cs:line 89
   at org.dmxc.lumos.Kernel.Timecode.Timecode.Play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 919
20:56:59 INFO  Timecode - Run:     [1, New TimecodeShow]
20:56:59 INFO  Timecode - Start:   [1, New TimecodeShow] Frame:     0
20:57:00 WARN  Timecode - Performing the Frame: 39 takes too much time, it exceeds the max. frame duration 158.7684ms >= 40ms
20:57:04 WARN  Timecode - Performing the Frame: 139 takes too much time, it exceeds the max. frame duration 179.8303ms >= 40ms
20:57:07 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   236 Time: 00:00:09.4463131
20:57:08 INFO  Timecode - Resume:  [1, New TimecodeShow]
20:57:09 WARN  Timecode - Performing the Frame: 264 takes too much time, it exceeds the max. frame duration 165.9721ms >= 40ms
20:57:12 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   328 Time: 00:00:13.1409705
20:57:13 INFO  Timecode - Stop:    [1, New TimecodeShow] Frame:   328 Time: 00:00:19.0884693
20:57:13 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:57:15 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.AlreadyRegisteredException: Timeslot for ID 12b9c255-1f9f-4a2a-84f5-b9822edec50a-TS already registered
   at org.dmxc.lumos.Kernel.Time.TimeManager.registerFixedTimeSlot(String targetId, ITimeSlot timeSlot) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Time\TimeManager.cs:line 89
   at org.dmxc.lumos.Kernel.Timecode.Timecode.Play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 919
20:57:15 INFO  Timecode - Run:     [1, New TimecodeShow]
20:57:15 INFO  Timecode - Start:   [1, New TimecodeShow] Frame:     0
20:57:15 WARN  Timecode - Performing the Frame: 39 takes too much time, it exceeds the max. frame duration 188.1449ms >= 40ms
20:57:19 WARN  Timecode - Performing the Frame: 139 takes too much time, it exceeds the max. frame duration 165.4547ms >= 40ms
20:57:24 WARN  Timecode - Performing the Frame: 264 takes too much time, it exceeds the max. frame duration 177.6584ms >= 40ms
20:57:26 INFO  Timecode - Break:   [1, New TimecodeShow] Frame:   298 Time: 00:00:11.9164152
20:57:27 INFO  Timecode - Stop:    [1, New TimecodeShow] Frame:   298 Time: 00:00:17.0859307
20:57:27 INFO  Timecode - Stopped: [1, New TimecodeShow]
20:57:29 ERROR Timecode - 

Direkt nach dem Laden eines Projekts, wenn hier bereits ein Gerät / eine Gerätegruppe selektiert ist, kann es in manchen Fällen vorkommen, dass die Property Panel (Intensity, Color, PositionControl,…) nicht auf Änderungen im Programmer reagieren. Erst nach einem deselektieren und erneuten selektieren der Gruppe / des Geräts funktioniert das Update des Panels korrekt. Die Panel hängen sich erfolgreich auf die jeweiligen ProgrammerValueChanged Events der jeweiligen IDevicePropertyFacade. Allerdings wird das Event wenn diese Race Condition auftritt nie gefeuert.

Fehlerbeschreibung

Erwartetes Verhalten

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Hallo,
Ich verwende DMXC 3.3.1 und habe zum testen eines Gerätes Werte in der Channel Overview eingestellt.
Ausgabe passiert hier in Universum 12 über ArtNet.
Soweit so gut.
Lasse ich diese Werte stehen und beende das Program, werden über ArtNet diese Werte immer noch weiter ausgegeben.

Werden über den Programmer oder über Cuelisten Werte ausgegeben werden diese “ordnungsgemäß” gelöscht.

Ich hätte erwartet das auch diese Werte wie bei der Verwendung vom Programmer und über Cuelisten zurückgesetzt werden.

Gruß Steff

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Error Description

Notes

Ich habe verschiedene Einstellungen für den AudioAnalzyer gesetzt und das Projekt gespeichert. Der Fokus liegt dabei auf den Einstellungen, die über die Dropdown-Menüs ausgewählt werden. Diese werden beim erneuten Laden nicht übernommen, sondern nur die Standartwerte gesetzt. Dazu zählen:

• Number of Bands für Spectrum
• Algorithm für Beat Detection
• Audio Device

In dem beigefügten Projekt sind die oben genannten Einträge entsprechend verändert.

Nach der Installation des DMXC 3.3.1-Release lies sich auf einem Windows 10-Notebook der Kernel nicht starten. GUI und Umbra liefen.
Das Kernel-Fenster zeigte nur die folgende Fehlermeldung:

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '6.0.0' was not found.
  - The following frameworks were found:
      3.1.32 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
      5.0.17 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=6.0.0&arch=x86&rid=win10-x86

Nach der Installation des Frameworks aus dem Link in der Meldung funktionierte auch der Kernel.

Können sich zwei PCs im Netzwerk auf Grund unterschiedlicher IP-Adressen nicht erreichen, laufen in GUI und im Kernel stetig die folgenden Log-Einträge auf:

GUI

2025-08-17 00:46:48,187 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:48,188 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:46:51,607 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:46:51,608 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384411.606000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384411.606000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:46:53,640 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:53,641 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:46:55,818 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="Unavailable", Detail="failed to connect to all addresses", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384415.816000000","description":"Failed to pick subchannel","file":"..\..\..\src\core\ext\filters\client_channel\client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1755384415.816000000","description":"failed to connect to all addresses","file":"..\..\..\src\core\lib\transport\error_utils.cc","file_line":165,"grpc_status":14}]}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384415.816000000","description":"Failed to pick subchannel","file":"..\..\..\src\core\ext\filters\client_channel\client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1755384415.816000000","description":"failed to connect to all addresses","file":"..\..\..\src\core\lib\transport\error_utils.cc","file_line":165,"grpc_status":14}]}
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:46:57,043 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:46:59,091 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:59,092 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:47:02,485 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:47:02,487 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384422.486000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384422.486000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:47:04,531 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:47:04,532 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:47:06,912 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 192.168.21.32
2025-08-17 00:47:07,940 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384427.939000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384427.939000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.

Kernel

2025-08-17 16:51:24,632 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:line 694
2025-08-17 16:51:26,652 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 16:51:26,653 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 16:51:29,857 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:line 694
2025-08-17 16:51:31,895 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 16:51:31,896 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 16:51:35,299 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:line 694

Die Fehlermeldung lässt sich in folgender Konstellation reproduzieren, wenn beide an einem unmanaged Switch hängen und bei beiden Laptops zwei vollständige Sessions mit DMXControl 3.3.1 laufen:

• LICHT-LAPTOP-1: IP-Adresse 169.254.1.19 durch Windows vergeben, da Netzwerkprofil (noch) auf DHCP
• LICHT-LAPTOP-2: IP-Adresse 192.168.21.32, statisch vergeben

Ich habe an dieser Stelle die Erwartungshaltung, dass der Aufbau einer Verbindung in einem solchen Fall nach einer bestimmten Anzahl von Versuchen abgebrochen und ich als Nutzer darüber informiert werde - auch wenn der Versuch des Verbindungsaufbaus “nur” alle 5 Sekunden erfolgt. Der Mehrwert einer solchen Information liegt auch darin, dass mir aufgefallen wäre, dass die IP-Adresse des LICHT-LAPTOP-1 nicht passt und ich daraufhin nicht selbst vergeblich versuche, die GUI am LICHT-LAPTOP-2 anzumelden.

Fehlerbeschreibung

Erwartetes Verhalten

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Ich füge eine Special Cue für den Fader eines Macros ein und gehe dabei wie folgt vor:

1. Ich trage über die Tastatur den Wert “1.0” ein und drücke die Enter-Taste.
2. Ich ändere den Wert dann nochmal auf “0.25” und füge die Special Cue über “OK” der Cuelist hinzu.

Wenn ich die Special Cue wiedergebe, gibt diese den Wert “1.0” aus statt den zuletzt eingegeben Wert “0.25”.

Wird die Netzwerkkonfiguration geändert, zum Beispiel wird die Statische IP/Subnetzmaske geändert, hängt der Kernel sich auf.

Discord: bastelpichi

Die Werte des Faders des Cuelist Group Executors werden beim Laden eines Projekts nicht wiederhergestellt. Entweder werden diese nicht korrekt gespeichert oder nicht korrekt geladen (noch nicht untersucht).

Aktuell werden in den Executoren die DisplayNames der Button und Fader beim Speichern verwendet und nicht die Names. Das macht dann natürlich die Nutzung der DisplayNames nicht mehr funktional. Hier müssen wir eine Lösung finden.

Genutzt wurde das folgende DDF (”colortemp”-Teil aus Wiki-Eintrag übernommen: https://wiki-de.dmxcontrol-projects.org/index.php?title=Color_(DDF-Syntax)_DMXC3#Farbtemperatur):

<?xml version="1.0" encoding="utf-8"?>
<device dmxaddresscount="1" type="DMXDevice" dmxcversion="3.2" ddfversion="1.0">
	<information>
		<model>Test Device</model>
		<vendor>Test</vendor>
	</information>
	<functions>
		<colortemp dmxchannel="0">
			<step type="off" mindmx="0" maxdmx="5" />
			<range minval="3200" maxval="7000" mindmx="255" maxdmx="6" />
		</colortemp>
	</functions>
</device>

Setzt man den “colortemp”-Kanal auf “Empty”, so wird der DMX-Wert des Minimalwerts der CTC-Range ausgegeben. (Also hier “255”.)
Zu erwarten wäre ein Wert zwischen “0” und “5”.

Der restliche Bereich funktioniert wie zu erwarten.

Ich habe zwei Cuelists mehreren Cuelist Groups zugeordnet. Beide Cuelist groups stehen auf “Single list running”. Wechsele ich zwischen den Cuelists hin- und her, wird in der Regel die Release time der zu beendenden Cuelist ignoriert. Folglich wird die alte Cuelist hart ausgeblendet und nur die neue faded ein. Der Kernel protokolliert in diesem Moment folgendes, wobei klar ersichtlich ist, dass der Release der Cuelists mehrfach getriggert wird:

2025-03-26 20:30:15,492 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,553 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Stopping Cuelist Cuelist 2 due to Group Group 1 config.
2025-03-26 20:30:15,553 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Stopping Cuelist Cuelist 2 due to Group Group 2 config.
2025-03-26 20:30:15,553 [Log-Thread] WARN  org.dmxc.lumos.Kernel.SceneList.SceneList - Unable to stop Cuelist Cuelist 2, because other Invocation is currently in process
2025-03-26 20:30:15,554 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,554 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Skip Stopping Cuelist Cuelist 1 due to Group Group 1 config as List is releasing.
2025-03-26 20:30:15,608 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,608 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,642 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:15,642 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:15,710 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.SceneList.SceneListGroup - Skip Stopping Cuelist Cuelist 1 due to Group Group 2 config as List is releasing.
2025-03-26 20:30:16,221 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:16,221 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2025-03-26 20:30:16,255 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2025-03-26 20:30:16,255 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack

Schalte ich das Single list running bei einer der beiden Cuelist groups aus, erfolgt der Übergang wie erwartet mit der eingestellten Release time sowie mit der Fade time der neuen Cuelist.

An dieser Stelle wäre meine Erwartungshaltung, dass die Zuordnung von Cuelists zu mehreren Cuelist groups mit der Einstellung “Single list running” nicht darauf Einfluss hat, ob der Release einer Cuelist vollständig ausgeführt wird oder nicht. Soll eine Cuelist keine Release time haben, lege ich dies in den Einstellungen der Cuelist fest.

Um das Problem ggf. besser zu verstehen, habe ich das beigefügte Beispielprojekt gebaut. Hierzu einfach zwischen den drei Cuelists hin- und herschalten, die den Executoren zugeordnet sind.

Bei mir fehlen in den General Settings die folgenden Einstellungen für das Project Autosave / Project Administration:

• Keep files per project
• Maximum MB per project
• Warning MB in project store

Ich kann aktuell nicht nachvollziehen, seit wann diese Einstellungen nicht mehr verfügbar sind. Um die Bezeichnungen der verschiedenen Optionen musste ich im Livestream zu gRPC nachschauen, weil wir dort die Einstellungen gezeigt haben.

In der Konfigurations-Datei für den Kernel sind aber noch alle Optionen vorhanden:

<TreeItem Name="PROJECT.AUTO_SAVE_ENABLED">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="False" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_INTERVAL">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="10" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_SUSPEND_ON_ACTIVITY">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="False" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_KEEP_FILES">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="50" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_MAX_MB">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="250" />
    </TreeItem>
    <TreeItem Name="PROJECT.AUTO_SAVE_TOTAL_MAX_MB">
      <Attribute Name="Value" Type="Primitive" ValueType="String" Value="1000" />
    </TreeItem>

Im Anhang habe ich die Logs sowie einen Screenshot beigefügt, der zeigt, dass die Einstellungen fehlen.

Hello!

I wanted to add a point on DDF RADIX DDF Profiles.

It seems that the <angleoffset> parameter has no effect on changing the orientation of pixel start points, or, in the visual GUI.

I have no idea if this was ever working in previous versions, as I have only started using RADIX Recently. Here is a Demo DDF for a fixture I am trying to make it wori with, but, also trying to make DDF for custom layouts and saving it as a full fixture for efficient processing of many ‘dimmers’

For instance. If pixel one starts at the 3:00 position, and I set ‘angle offset’ to 90 clockwise, the GUI, and actual DMX Fixture have no effect. the First pixel is stuck at default position in DMXC.

I am not sure I I am doing something wrong, But I also tested in other strange ways. Nothing seemed to work.

Thank you!

Fehlerbeschreibung

Erwartetes Verhalten

Weiteres

When using the Matrix Effect: ‘Random’, Changing the value of the ‘Pixel Random’ parameter breaks the effect.

Bitmap Pixel Effect does not recall image from cue.

When saving a bitmap pixel effect to a cue, only the default DMXC Logo appears when recalling the cue. The cue does not recall the Bitmap Source image.

Führt man die Installation auf einem Gerät ohne vorhandene Internetverbindung aus, wird erst zu spät festgestellt, dass diese nicht vorliegt. So werden verschiedene .net-Frameworks nicht installiert bevor man einen Hinweis erhält. Dadurch entsteht der Eindruck, dass bis dahin alles ordnungsgemäß abgelaufen ist.

Im Idealfall prüft der Installer ganz zu Anfang, ob eine Internetverbindung besteht und gibt einen Hinweis, falls diese nicht existiert.

Fehlerbeschreibung

Erwartetes Verhalten

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Version: 3.3 RC5

Fehler:
Bitmap from Resource lädt beim Start von DMX Control nicht die Icons.

Über den Workaround “Manueller Reset des Szenenlisten-Monitors” werden die Icons angezeigt.

Siehe auch Screenshot.

Wird DMXC installiert und ein Programmteil läuft unbeabsichtigt noch, kommt es im Installer zu Fehlermeldungen, die jedoch nicht darauf schließen lassen, dass das Problem ist, dass DMXC - teilweise - noch läuft.

Check in Installer wie schon bereits besprochen

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Ich habe über die Startparameter –correlation=cpu und –correlation=gpu die Gobo-Korrelation jeweils manuell angestoßen. In beiden Fällen versucht der Kernel, die zugehörige Datei im Installationsverzeichnis zu speichern statt im Benutzerdatenverzeichnis. Aus diesem Grund erscheint die folgende Fehlermeldung.

14:16:02 WARN  ResourceManager - Unable to save Resource GoboCorrelations_CPU.csv of Type Application
System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\DMXControl Projects\DMXControl 3.3.0\Kernel\Config\GoboCorrelations_CPU.csv' is denied.
   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream, String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
   at System.IO.File.Create(String path)
   at org.dmxc.lumos.Kernel.Resource.FileAccessUtil.SaveResourceToFileAsync(String relativePath, Stream data, Boolean useLocalPath, IProgress`1 progress, Boolean throwOnError) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\FileAccessUtil.cs:line 296
   at LumosToolsLIB.Tools.AsyncHelper.RunSync[TResult](Func`1 func) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\AsyncHelper.cs:line 0
   at org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResourceToStorage(String relativePath, Stream data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:line 498
   at org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResource(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:line 488
   at org.dmxc.lumos.Kernel.Resource.ResourceManager.SaveResourceInternalAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\ResourceManager.cs:line 230
   at org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.SaveResourceAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:line 768

Ich würde an dieser Stelle erwarten, dass die GoboCorrelations_CPU.csv und GoboCorrelations_GPU.csv im Butzerdatenverzeichnis abgelegt wird und dabei die dortigen Dateien aktualisiert. Normalerweise dürfen die Daten im Installationsverzeichnis ja nicht verändert werden.

Fehlerbeschreibung

Forum: https://forum.dmxcontrol-projects.org/index.php?thread/17686-performance-probleme-bei-vielen-cuelists/

Hallo zusammen,

wir verwenden bei uns Szenenlisten, um Lichtstimmungen passend zu einem Lied vor zu programmieren.

Dabei erstellen wir pro Lied eine neue Szenenliste und fügen dieser andere Szenenlisten, wie Beispielsweise einen Bewegungseffekt, Dimmereffekt oder Farbe hinzu um diese mit der Lied- Szenenliste zu starten.

Die Lied- Szenenliste hat dabei nur den Auftrag alle anderen zu starten (erste Cue (andere Szenenliste) auf Manual und dann alle folgenden mit follow 0ms danach), sodass wir dann nur noch die einzelnen Cuelists mit Mastern in ihrer Intensität und Schnelligkeit reinmischen müssen.

Da bei uns regelmäßig unterschiedliche Bands auftreten, kommen da schnell ein paar Lied- Szenenlisten zusammen.

Nun das Problem:

Mir ist aufgefallen, dass nach ca. 120 Lied- Szenenlisten mein Projekt deutlich langsamer läuft.

So fällt bsp. bei Strobe- Effekten auf, die per Tastatur mit “GO” gestartet werden und beim Loslassen der Taste über Binary Switcher über “STOP” gestoppt werden sollen, nicht mehr gestoppt werden und es einem zweiten oder auch dritten Drücken auf die Taste bedarf bis die Cuelists gestoppt wird.
Auch haben unsere Slider, die die Groupmaster steuern ein deutliches Delay (teilweise ca. 3 Sekunden)

Um das Projekt im Live-Betrieb bedienbarer zu machen, löschen wir vor jedem Konzert alle nicht verwendeten Lied-Cuelists raus. Dies hat einen deutlichen Einfluss auf die Performance.

Aktuell sind wir auf der 3.3.0 RC3 auf einem Laptop mit aktuellem AMD Ryzen 5 und 8GB Ram.
Auf der RC2 und einem anderen Rechner mit i7 und 16GB Ram hatten wir aber auch das selbe Problem.

Vielen Dank
Falko