Bugtracker DMXControl 3

Hallo liebe Entwickler,

es besteht seit längerer Zeit von mir als auch anderen Usern des DMX-Control 3.2.3 der Wunsch,
die Schriftgröße des CueList Monitor auf dem Softdesk anzupassen. In unserem Fall würden wir die Schriftgröße gern kleiner
machen wollen, um mehr Informationen in den Ausschnitt des CueList Monitorfenster zu bekommen.

Könnt ihr das bitte in die nächste Version mit einbauen?
Bzw. besteht kurzfristig die Möglichkeit, die Version 3.2.3 noch zu patchen?
Eventuell sind ja nur entsprechende Dateien abzuändern und auszutauschen.
Eine kleinere Schriftgröße z.B. “8” oder “10” als fester Wert würde schon genügen.

Danke für eure Mühe.
DMX Control ist ein super Programm für uns Einsteiger in die Lichtsteuertechnik.
Schön das es so etwas gibt.

Viele Grüße, Dirk.

Hier die Fehlerbeschreibung eintragen. Wo und wie tritt der Fehler auf? Bitte das genaue Vorgehen zur Reproduktion beschreiben
Sobald ich mit dem Eurolite DMX 512Pro MK2 bei einer Gruppe von 64 Generic RGB einen anderen Wert als weiß (1;1;1) einstelle, entstehen komische Farb und Strobo Effekte auf den Geräten bzw. den Pixeln der LED Bar (4 mal PureLight Pixel Bar Switch). Dies tritt auch bei anderen Geräten auf.

Ich habe auf einem PC bereits eine DMXC3.3-Instanz laufen. Dann starte ich auf einem zweiten PC eine weitere komplette Instanz von DMXC 3.3.0. Beide PCs befinden sich aber im gleichen Netzwerk. Hier beschwert sich der Kernel vom PC2, dass er sich nicht mit dem Umbra des PC1 verbinden kann - und in der Situation auch gar nicht soll. Die ersten Zeilen des Logs sehen wie folgt aus:

2024-04-04 23:08:38,105 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra DefaultUnknownServerName @ 192.168.21.31...
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 688

Dieser Fehler ist mir bewusst erst mit dem RC2 unter die Finger gekommen. Grundsätzlich stört es den Betrieb nicht, aber der füllt das Log-File des Kernels.

Wunsch für den Timecodeplayer

eine Spur als tabellenkopf so fixieren zu können das diese immer oben bleibt , auch wenn man weiter runter scollt.

und

das man sich wie im Word “Tabstops” setzen kann um so bei längeren TCShows besser in der horizontalen ebene orientieren kann.

Der linke bereich des TCP könnte sortierbar sein, so das man sich die Spuren sortieren kann ,

Schön wäre auch eine art dropdown , wo man bestimmte spuren gruppieren kann, und diese dan als gruppe minimiert bzw ein/ausblendet .

jetz werden wieder viele denken : “bau alles mit Szenen und du brauchst nur 3-5 spuren”, nein das möchte ich nicht weil:

ich stelle mir den workflow etwas präzieser vor , angenommen man hat eine TCShow von insg. 30min, welche aus mehreren audioschnipseln besteht , bei 30 minuten wären das möglicherweise über 60 szenen die man bauenmüsste und auch evtl. mal bearbeiten müsste ändert sich ein titel oder ähnliches. hinzukommend müsste man jede szene auswendig können. daher eher der Gedanke jede gerätefunktion (bzw. Gerätegruppenfunktion) auf eine ex.spur zu legen und diese dann im TCP anzupassen.

–> wären die Executorspuren gruppierbar ware das eine feine sache (Bugtrackereintrag exestiert)
–> man kann sich einfach Spuren für gerätegruppen hinzufügen, oder jeh nach vorhandenen euqipment “aktivieren oder deaktivieren”

Hintergrund: In namenhaften audioprogrammen wie Fruityloops-Studio hat man pro zeile ja auch nur ein Instrument(element, stimme etc.) da arbeitet man auch nicht mit aufgenommenen Schnipseln die man nur aneinander klatscht . ich vermute auch zukunftsweisend ist das vorteilhafter wie 12 milliarden szenen zu speichern und die nur zeitlich zu verketten. (das könnte der Szeneneditor ja bereits selbst)

Schön wäre wenn man im TCP die abspielgeschwindigkeit anhand eines faders (Pitch) beeinflussen könnte , so wie ein DJ das mit dem Pitch regler macht.

wenn man diesen sogar im inputassigment hätte ,wäre eine Syncronisation mit einem DJ-Program nicht mehr weit entfernt.
Man könnte auch den Fader vom Timecodeplayer-Executorzuges dafür einsetzen

Die Executorzüge sind recht Steif, wenn man einen einfachen Dimmer Ex.-zug hat hat man einen Fader und 4 tasten,
Schön wäre dort das ganze etwas Flexibler zu gestalten, wie :
beim dimmer müssten die Tasten ein paar mehr funktionen bekommen wie zum beispiel: fade auf in x Sec. ; Fade zu in X sec, fade bis wert x
–> dazu könnte man noch kleinere “werte-knöpfe” anlegen im Fader wo man das “X” definieren kann nach bedarf

Beim Colormaster-Executorzug (Fügt man 2 mal den Gleichen CM nebeneinander ein hat man 2 Fader ) da wäre schön den zweiten Fader gegen weitere Tasten Tauschen zu können.
(welche man in der Jeweiligen Farbe einfärben könnte)

generell, Fader oder Tasten, mit dem eintrag “Empty” , sollten einfach komplett ausgeblendet sein, gilt auch für ungenutzte Executorenzüge auf einer seite.

Schön wäre die einzelnen executoren-Seiten auch in einzelne Fenster zu bekommen.

Da executoren sowie das Softdesk beide hervorragend für die Live bedienung ist, wäre es klasse wenn man einzelne Executorenzüge direkt ins Softdesk ziehen könnte .

Ich lege einen 1D-Effekt auf die Farbe und trage dann einen ColorMaster als Wert für die Farbe ein. Schaue ich mir dies nun mit dem Effektvisualizer an, aktualisiert sich die grafische Darstellung des Wertebereichs nicht. Der Regenbogen bleibt konstant bei rot als Startpunkt, selbst wenn der Colormaster ein grün oder ein gelb ausgibt.

Hinterlege ich aber eine feste Farbe, wie zum Beispiel gelb, dann wird dies vom Effektvizualiser berücksichtigt.

Diese Problem betrifft aber nur den Effektvisualizer selbst - die Ausgabe in der Stageview passt.

Bilder und ggf. ein kleines Beispielprojekt können noch nachgereicht werden.

Fehlerbeschreibung

Erwartetes Verhalten

Das Projekt liegt in der Cloud (im üblichen Ort). Wenn man versucht, aus der Main Cuelist die Cue “ES.01.10: Einlass” in den Cue Timing Editor zu laden, dann fliegt folgende Exception:

2024-04-13 18:25:34,465 [Main GUI] ERROR 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.SceneList.SceneEditView.<>c.<SceneEditView_Shown>b__12_1(IDevicePropertyFacade c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\SceneList\SceneEditView.cs:Zeile 57.
   bei System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
   bei System.Linq.Enumerable.<DistinctIterator>d__64`1.MoveNext()
   bei System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   bei System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   bei Lumos.GUI.Windows.SceneList.SceneEditView.<SceneEditView_Shown>d__12.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\SceneList\SceneEditView.cs:Zeile 57.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)

Aus der Async-Function kommen einzelne null Einträge raus, was dazu führt, dass beim Abrufen des DisplayNames die Exception fliegt.

Hallo,
mir ist da beim testen mit der 3.2.3 ist mir da was aufgefallen.
Habe es dann in der 3.3.0.RC2 getestet und hier ist es auch so.
Ich meine das es in einer älteren Version funktioniert hat.
Kann das aber leider nicht mehr testen.

Ich habe dann ein neues Projekt zum testen dafür angelegt.
Projekt und Bilder zur Verdeutlichung sind im Anhang.

Ich habe einen Gerneric Dimmer und acht Gerneric Switch mit entsprechenden Device Group angelegt.

Wähle ich beide Gruppen an und drücke dann den Button LUMOS im Control Intensity gehen der verwendete Dimmer sowie die Switch an.
Beim drücken auf Nox geht das ganze auch wieder aus.

Ich habe dann im IA ein CS mit Buttons und einem Pragrammer Node angelegt.
Button (1) verbunden dem Eingang LUMOS, Button (2) verbunden mit dem Eingang NOX.
Es sind wieder beide Gruppen abngewählt.
Drücke ich den Button der mit LUMOS verbunden ist, geht nur der Dimmer an und die Switch bleiben aus.
Sind Dimmer und Switch an und ich Drücke den Button der mit NOX verbunden ist geht nur der Dimmer aus.

Erwartetes Verhalten

Arbeitet man mit mehreren Cuelist-Tracks, wäre es hilfreich, dass Cuelists vom Cuelist-Track A in den Cuelist-Track B oder C verschoben werden können. Dabei sollen die Cuelists ihren ursprünglichen Startpunkt beibehalten.

Aktuell muss man die betreffende Cuelist im Cuelist-Track B erst erneut manuell an der richtigen Stelle hinzufügen und diese dann im ursprünglichen Cuelist-Track löschen.

Über das Kontextmenü kann man vom Timecode-Player aktuell “nur” normale Cues der entsprechenden Cuelist hinzufügen. Dies funktioniert so bereits sehr gut.

An dieser Stelle würde ich mir wünschen, wenn hier die Möglichkeit zum Einfügen von Special cues ebenfalls ergänzt werden würde.

Ich habe in einem Cuelist-Track bereits mehrere Cuelists an verschiedenen Stellen eingefügt. Hier würde ich mir wünschen, wenn man die Möglichkeit erhält, die aktuelle Cuelist an der aktuellen Position durch eine andere Cuelist zu ersetzen.

Hat man einer Cuelist eine Special Cue hinzugefügt, muss man diese löschen und neu einfügen, sobald man zum Beispiel im Falle der Cuelist einen anderen Befehl oder gar die ganze Cuelist ändern will. Hier wäre es gut, wenn man hierzu die Möglichkeit erhält, eine Special cue ebenfalls zu ändern.

In meinem Showprojekt für das Jahrestreffen musste ich feststellen, dass bestimmte Cuelists mit Timecode-Trigger nach einiger Zeit unsauber wiedergegeben werden. Dies ließ sich sowohl in der StageView als auch in der DMX-Ausgabe real an den Geräten beobachten. Die gewünschten Effekte sehen damit mit zunehmender Wiedergabedauer der Timecodeshow deutlich merklich anderes aus als noch zu Beginn bei den ersten Aufrufen der entsprechenden Cuelists.

Die betreffenden Cuelists sind in dieser besagten Version mehrfach zwei verschiedenen Cuelist-Tracks zugeordnet.

Nachdem ich Cuelists auf die eigenständige Wiedergabe mittels Wait- / Follow-Trigger umgebaut und diese dann über entsprechende Special Cues aufrufe, laufen die Effekte über die komplette Wiedergabe-Dauer der Timecode-Show wie erwartet.

Anmerkung: Das in diesem Ticket beschriebene Phänomen zeige ich am besten live mit der realen Ausgabe und mache dann ggf. auch ein kurzes Video. Dem entsprechend werde ich Projekt und Logs später nachreichen. Die betreffende Version ist gesichert.

In meinem aktuellen Showprojekt kann ich die Timecodes-Show nicht mehr mitten im Song starten, wenn hier bereits eine gewisse Zeit vergangen und / oder eine gewisse Anzahl an Cues abzuwarbeiten waren. Konkret bedeutet das, dass beim Start im Song um die 40. Cue bei 1:31.000 die unten stehende Exception fliegt. Dies hat zur Folge, dass die betreffende (Haupt-) Cuelist der Show nicht mehr auf den vom Timecode-Player verschickten Timecode reagiert und damit nicht mehr ausgegeben wird. Hier muss ich das Projekt einmal komplett neu laden, damit die vollständige Wiedergabe inklusive dieser (Haupt-) Cuelist funktioniert. Andere Cuelists werden aber noch mit dem Timecode gefüttert.

16:02:23 ERROR ThreadManager - Thread TimecodeSceneTrigger exited ThreadStart-Method with Exception: Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.ApplyTimings(OutputValueItem item, Int64 timeOffset, Boolean fadeIn, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Int32 sourceIndex, Int32 destIndex, EGotoOptions options, Nullable`1 valueNew) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 519
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.FadeItem(OutputValueItem item, Int64 timeOffset, Boolean fadeIn, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Boolean clone, Int32 sourceIndex, Int32 destIndex, EGotoOptions options, Nullable`1 newValue) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 514
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.AdjustRunningTimings(FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, Int64 timeOffset, IDictionary`2 toPlayValues, IDictionary`2 toFadeoutValues, Int32 sourceIndex, Int32 destIndex, EGotoOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 651
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.goToForward(Int32 destindex, Int32 sourceIndex, EGotoOptions options, Int64 timeOffset, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 224
   at org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack.goTo(Int32 index, EGotoOptions options, Int64 timeOffset, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\ValuesStack\OutputValuesStack.cs:line 146
   at org.dmxc.lumos.Kernel.SceneList.SceneList.playSceneForward(IScene newScene, Int32 oldIndex, Int64 newSceneOffset, ETriggerReason reason, FadeDelayTimings timings, PropertyFadeDelayTimings propertyTimings, EGotoOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1601
   at org.dmxc.lumos.Kernel.SceneList.SceneList.playScene(Int32 newIndex, Int32 oldIndex, Int64 newSceneOffset, ETriggerReason reason) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1529
   at org.dmxc.lumos.Kernel.SceneList.SceneList.SceneTrigger_SceneTriggered(Object sender, TriggerEventArgs args) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 1786
   at org.dmxc.lumos.Kernel.Scene.Trigger.AbstractSceneTrigger`1.triggerScene(SceneBag`1 bag, Boolean removeRunning, ETriggerReason reason) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\AbstractSceneTrigger.cs:line 284
   at org.dmxc.lumos.Kernel.Scene.Trigger.TimecodeSceneTrigger.triggerScenesByTimecode(Int64 actualTC, Int64 newTC) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\TimecodeSceneTrigger.cs:line 151
   at org.dmxc.lumos.Kernel.Scene.Trigger.TimecodeSceneTrigger.timecodeThreadRun(RunContext ctx) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Trigger\TimecodeSceneTrigger.cs:line 128
   at org.dmxc.lumos.Kernel.Run.ThreadWrapper.WrappedStart() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Run\Thread\ThreadWrapper.cs:line 213

Das Projekt stelle ich bei Bedarf intern zur Verfügung.

Aktuell wird das Dirty Flag gesetzt, wenn sich der Play-State des Timecode Players verändert oder die Position des Zeitmarkers. Das macht aber eigentlich nicht so viel Sinn und wird auch in anderen Programmen (z.B. DaVinci, Adobe Premiere, Adobe Audition,…) nicht so gemacht. Ich will ja eigentlich nur Änderungen an der Timecode-Show an sich speichern, aber nicht, ob die Show gerade läuft oder nicht. Aktuell wird nämlich dadurch im Hintergrund auch automatisch Autosave aktiv, was beim reinen Abspielen einer Show ja aber keinen Sinn ergibt.

Ich habe gerade meine verschiedenen Timecode-Shows umbenannt und dabei das Zeichen “|” verwendet. Der Name lautete “Intro 1 | DMXC-Video-Intro“.

Wird das Projekt gespeichert, führt dies zu folgender Fehlermeldung im Kernel:

12:25:57 WARN  ResourceManager - Unable to save Resource TimecodeShows\Intro 1 | DMXC-Video-Intro_9065fe68-5aa6-49c3-9513-f03fe6eb6689.xml of Type Project
System.ArgumentNullException: Value cannot be null. (Parameter 'filename')
   at org.dmxc.lumos.Kernel.Resource.FileMetadataCache`1.Remove(String filename) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\FileMetadataCache.cs:line 79
   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 487
   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 222
   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

Sobald ich dieses Sonderzeichen entferne und den Namen der Show zum Beispiel in “Intro 1 (DMXC-Video-Intro)” ändere”, kann das Projekt vollständig und ohne weitere bzw. wiederkehrende Fehlermeldung gespeichert werden.

Abschließend sei bemerkt, dass unter anderem das Zeichen “|” sonst soweit im Projekt genutzt werden kann, wie zum Beispiel im Namen von Cuelists.

Benenne ich eine Timecode-Show um, verbleibt die zugehörige XML-Datei mit dem alten Namen weiter in der Projektdatei. Diese wird auch beim erneuten Laden des Projekts eingelesen und dann beim nächsten Speichern wieder in der Projektdatei ablegt.

Aktuell muss ich den Wiedergabemarker an eine bestimmte Position setzen, um die exakte Zeit an dieser Stelle herauszufinden.

Ich persönlich fände es hilfreich, wenn mir fortlaufend auch die aktuelle Position der Maus selbst in der Zeitachse als Zeitwert angezeigt werden würde.

Der PWM static Effekt reagiert nicht mehr auf die Position des zugeordneten Parameter-Masters. Vielmehr wird der Effekt mit einer nicht weiter beeinflussbaren Geschwindigkeit kontinuierlich wiedergegeben - unabhängig des Werts des Parameter-Masters.

Hierzu im beigefügten Projekt die Cuelist ausführen und versuchen, den Effekt über den Parameter-Master 1 zu beeinflussen. Auch die Log-Dateien habe ich angehangen.

Wie es ausschaut, scheint sich dieser Fehler erst in einer der letzten Versionen eingeschlichen zu haben. Im RC1 existiert das Problem aber bereits.