Bugtracker DMXControl 3

Wird ein Executor fixiert → projekt gespeichert → dmxc neu geöffnet, so sind die fixierten executoren nicht mehr fixiert ⇒ executoren müssen nach jedem start von dmxc neu fixiert werden

Edit Patrick 09.10.2023:
In denn in den Kommentaren angehangenen Project sind 67 verschiedene Config/UserContexts/DMXCDefault_*.xml Files.
Ich vermute das Problem liegt hier, denn bei mir funktioniert alles

Im Kernel wird in einer der ersten Zeilen des Logs die genaue Versionsnummer vermerkt:

2022-01-06 16:40:37,100 [Main] INFO  org.dmxc.lumos.Kernel.Run.KernelRunManager - DMXControl V3.3.0.887 Alpha8 starting! (x86)

Ein solcher äquivalenter Eintrag fehlt im Log des Umbras. Hier kann man nur über

2022-01-06 16:51:20,132 [Main] INFO  Umbra.Run.UmbraRunManager - Umbra Build Time: 06.01.2022 13:32:25 UTC

darauf schließen, welcher Build der aktuellen Programmversion zu Grunde liegt.

Ich habe ein neues Projekt mit zwei kleinen Connectionsets angelegt, dieses gespeichert, geschlossen und dann wieder neu aufgerufen.

Wechsele ich in die Graphenansicht, gibt der Umbra in regelmäßigen Abständen die folgende Fehlermeldung aus. Sobald ich wieder in die Tabellenansicht zurückgehe, ist alles “ruhig”.

19:22:15 ERROR BidirectionalStreamBridgeWithResponseFilter - Request Listener ConnectionSetProcessed has faulted.
System.IO.IOException: The client reset the request stream.
   at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2MessageBody.ReadAsync(CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
   at Grpc.AspNetCore.Server.Internal.PipeExtensions.ReadStreamMessageAsync[T](PipeReader input, HttpContextServerCallContext serverCallContext, Func`2 deserializer, CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
   at Grpc.AspNetCore.Server.Internal.HttpContextStreamReader`1.<MoveNext>g__MoveNextAsync|9_0(ValueTask`1 readStreamTask)
   at Grpc.Core.AsyncStreamReaderExtensions.ReadAllAsyncCore[T](IAsyncStreamReader`1 streamReader, CancellationToken cancellationToken)+MoveNext()
   at Grpc.Core.AsyncStreamReaderExtensions.ReadAllAsyncCore[T](IAsyncStreamReader`1 streamReader, CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()
   at Umbra.Bridge.BidirectionalStreamBridgeWithResponseFilter`2.<>c__DisplayClass7_0.<<ClientSideTaskWithFilter>b__0>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\BidirectionalStreamBridgeWithResponseFilter.cs:line 60
--- End of stack trace from previous location ---
   at Umbra.Bridge.BidirectionalStreamBridgeWithResponseFilter`2.<>c__DisplayClass7_0.<<ClientSideTaskWithFilter>b__0>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\BidirectionalStreamBridgeWithResponseFilter.cs:line 60

Die Fehlermeldung kann ich gut mit dem beigefügten Projekt reproduzieren, indem ich in einem der beiden Graphen anfange, die Nodes zu verschieben - spätestens, wenn ich das im zweiten Graphen mache.

1. Bei mir sieht das FFT komisch aus. s. Screenshot. Dazu noch ein Bild von Audacity
2. Wenn ich versuche den Marker zu verschieben, dann ist da immer ein Offset beim verschieben. Liegt bestimmt an meiner Skallierung vom PC.
3. Abspielen und pausieren des Tracks mit Leertaste
6. Ich kann im Node vom der Timecodeshow keine Show auswählen (keine Auswhlmöglichkeit). Wenn ich die Nummer verwende funktioniert es
7. Kontextmenü PE - “Add Audio File” funktioniert nicht

Edit:
In seperate Tickets ausgelagert
4. Mausrad scrollt, Strg + Mausrad - Zoomen (oder anders rum) –> Aktuell Zoomt man nur mit dem Mausrad (FS+4809)
5. Ich würde fen Marker gerne an eine bestimmte Zeit setzen können. Mir wird ein grauer Marker angezeigt, ich kann ihn mit einem Klick aber nicht an die gewünschte Zeitmarke setzen. (FS+4810)
8. Es fehlt die Möglichkeit mit dem Marker wieder an den Anfang der Timecode Show zu springen (FS+4811)

Es fehlt die Möglichkeit mit dem Marker wieder an den Anfang der Timecode Show zu springen

Um das Fenster des Timecode-Players zu öffnen muss bei jedem Neustart von DMXC das Fenster über den Project-Explorer einmal öffnen und wieder schließen, erst dann kann man es über Steuerungsfenster → Timecodeplayer öffnen. Bevor man den TImecodeplayer einmal über den Explorer geöffnet hat ist dieser Eintrag nicht vorhanden. Ich verstehe nicht welchen nutzen das haben soll und würde mir wünschen das Fenster direkt öffnen zu können.

Füge ich beispielsweise eine Cuelist einem Cuelist Track zu, erscheint in der GUI eine Fehlermeldung, die im Log der GUI folgenden Eintrag generiert:

2023-06-25 21:43:11,923 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.Timecode_gClient - AddChildrenToTrackAsync
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Net.gClient.Timecode_gClient.<AddChildrenToTrackAsync>d__32.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Net\gClient\Timecode_gClient.cs:Zeile 275.

Ich habe einem Cuelist-Track mehrfach die gleiche Cuelist zugeordnet. Die sollen mehrfach hintereinander ausgeführt werden. Allerdings geschieht dies aktuell nur ein einziges Mal, nämlich an der Stelle, wo die Cuelist das erste Mal im Cuelist-Track positioniert ist. Die weiteren Male erfolgt keine Wiedergabe.

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.

Aktuell besteht eine Inkonsistenz bei der Angabe der Wiedergabezeit zwischen Timecode-Player und den Timecode-Triggern in der Cuelist. Da im Timecode-Player die Angabe mit tausendstel Sekunden und im Timecode-Trigger in der Cuelist mit 25 FPS erfolgt, kann ich die aktuelle Position des Wiedergabe-Markers nicht 1:1 manuell in den Timecode-Trigger übertragen.

Daher wären folgende Dinge zu überlegen:

* Wird das Anzeige-Format im Timecode-Player auf die 25FPS-Variante geändert oder

• wird der Timecode-Trigger wird mit tausendstel Sekunden angegeben?

Einer der beiden Punkte sollte umgesetzt werden, damit auch die Nachvollziehbarkeit erhöht wird.

Schließe ich ein Projekt mit einer Timecode-Show und lade das Projekt anschließend neu, kann mir die Grafik der Audiodatei nicht mehr angezeigt werden. Der Kernel gibt folgenden Log-Eintrag dazu aus.

Open: Failed to open '[...]\DMXControl 3.3.0\Kernel\Temp\Zack Merci - ray of light [feat. Nieko - NCS Release].mp3.0.tiff'. The process cannot access the file '[...]\Software\DMXControl 3.3.0\Kernel\Temp\Zack Merci - ray of light [feat. Nieko - NCS Release].mp3.0.tiff' because it is being used by another process.
...
23:43:58 ERROR AudioManager - Unable to process FFT / Wave for Zack Merci - ray of light [feat. Nieko - NCS Release].mp3 after several tries....

Bereits beim Schließen des Projekts wirft der Kernel eine Fehlermeldung. Die Dateien liegen zu diesem Zeitpunkt weiter im Temp-Verzeichnis des Kernels.

21:54:48 ERROR ProjectManager -
System.IO.IOException: The process cannot access the file '[...]\DMXControl 3.3.0\Kernel\Temp\Zack Merci - ray of light [feat. Nieko - NCS Release].mp3.0.tiff' because it is being used by another process.
   at System.IO.FileSystem.DeleteFile(String fullPath)
   at System.IO.File.Delete(String path)
   at org.dmxc.lumos.Kernel.Audio.AudioManager.RemoveFFT(AudioMetadata m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Audio\AudioManager.cs:line 318
   at org.dmxc.lumos.Kernel.Audio.AudioManager.removeAudio(String name) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Audio\AudioManager.cs:line 301
   at org.dmxc.lumos.Kernel.Audio.AudioManager.<org.dmxc.lumos.Kernel.Run.ILumosProjectManager.closeProject>b__62_0(String c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Audio\AudioManager.cs:line 1163
   at System.Collections.Generic.List`1.ForEach(Action`1 action)
   at org.dmxc.lumos.Kernel.Audio.AudioManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.closeProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Audio\AudioManager.cs:line 1163
   at org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass48_0.<closeProjectNoLock>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 278
   at System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   at org.dmxc.lumos.Kernel.Project.ProjectManager.closeProjectNoLock(IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 274

Aktuell muss ich DMXC einmal komplett neu starten.

Im Kontextmenü innerhalb eines Cuelist-Tracks besteht die Möglichkeit, eine (weitere) Cuelist diesem Cuelist-Track hinzuzufügen. Allerdings führt dieser Eintrag ins leere. Ein entsprechender Auswahldialog, welche Cuelist aus dem Projekt eingefügt werden soll, fehlt noch.

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.

Wie im beigefügten Screenshot zu sehen, fällt die Fehlermeldung “Nur Timecode-Trigger in Cuelist-Track erlaubt” aktuell sehr technisch aus. Hier sollte der Hinweistext nochmal dahingehend bereinigt werden, dass er als “normaler” Fließtext zu lesen ist.

Ich habe in meinem ersten Test eine Cuelist im Cuelist-Track, die nur ca. 20% des gewählten Musikstücks “verlichtet”. Ist dieser Punkt erreicht, stoppt die Audio-Wiedergabe hart. Um dies aber insgesamt schöner zu gestalten, sollte die Wiedergabe der Timecode-Show erst unter folgenden Bedingungen automatisch beendet werden:

• Wenn das Ende des längsten Tracks erreicht ist. Dabei ist es egal, ob es sich beispielsweise um den Audio-Track oder einen Cuelist-Track handelt.
• Wenn der letzte Audio-Track bei der Lautstärke ausgeblendet wurde und kein anderer Track länger ist.

Nach jedem Start von DMXC braucht der TImecode-Player ca. 10-20 Sekunden um sich zu öffnen. In dieser Zeit reagiert die gesamte GUI von DMXC nicht mehr. Bin mir an der Stelle nicht sicher ob das ein Bug ist oder einfach nicht anders geht. Sollte letzteres der Fall sein würde ich einen kurzen Ladebalken etc. vorschlagen, da ich als User so jedes Mal den Eindruck habe, DMXC sei abgestürzt.

Wird eine Show im TCP gestoptt, springt zwar der Marker wieder an den Anfang, es wird aber nicht automatisch an den Anfang gescrollt. Man muss also immer händisch zurück-scrollen. Dies hat micht verwundert, da in einer laufenden Show im TCP automatisch mit dem Marker mitgescrollt wird.

Wunsch: TCP scrollt nach stoppen automatisch an die Position des Markers.

Ich habe folgendes Test-Setup:

- Drei Cuelisten die jeweils einem Executor zugeordnet sind
- Ein angeschlossenses Midi-Pult, wo für jeden Executor Button 1 und der Fader im IA via Dynamic Executor Page verdrahtet sind
- Eine Show im TCP die nur aus einer Audio (60 bpm click track) und der Aufnahme von erwähntem Button 1 der Executoren besteht

Nachdem ich nun die Show im TCP häufig gestartet, pausiert, gestoppt (sowohl einmaliges Stoppen (→ roter Marker springt auf letzte Startposition) als auch zweites Stoppen (→ roter Marker springt auf null) ) und Executoren aufgenommen habe, habe ich folgende Fehler, welche erst nach und nach aufgetreten sind, aber am Anfang noch kein Problem waren:
- zweites Stoppen (→ roter Marker springt auf Null) funktioniert nicht mehr, nur noch das erste Stoppen (→ roter Marker springt auf letzte Start-Position) funktioniert
- roten Marker durch doppelklicken in der Timeline an einen bestimmten Punkt setzen funktioniert nicht mehr, auch das hat anfangs noch funktioniert

Logs und Projekt im Anhang

Ich habe folgende Testumgebung (identisch wie in  FS#5138 ):

- Drei Cuelisten die jeweils einem Executor zugeordnet sind
- Ein angeschlossenses Midi-Pult, wo für jeden Executor Button 1 und der Fader im IA via Dynamic Executor Page verdrahtet sind
- Eine Show im TCP die nur aus einer Audio (60 bpm click track) und der Aufnahme von erwähntem Button 1 der Executoren besteht

In dieser Umgebung tritt folgender Fehler auf:
Wird ein Executor via Midi geflasht (Fehler tritt bei mir nur auf, wenn er über Midi geflasht wird, nicht wenn er über die GUI bedient wird) und gleichzeitg in einer SHow im TCP verwendet, löst sich der Flash nicht mehr, sobald man ihn nicht mehr flasht. Der Flash Button löst sich dann nur noch lösen, indem man die TCP Show beendet, auch wenn er in der TCP Show eigentlich nicht mehr aktiv war.

Projekt und Logs sind im Anhang.

Ich habe folgende Testumgebung (identisch wie in  FS#5138  und  FS#5139  ):

- Drei Cuelisten die jeweils einem Executor zugeordnet sind
- Ein angeschlossenses Midi-Pult, wo für jeden Executor Button 1 und der Fader im IA via Dynamic Executor Page verdrahtet sind
- Eine Show im TCP die nur aus einer Audio (60 bpm click track) und der Aufnahme von erwähntem Button 1 der Executoren besteht

Nun ändere ich aber einen Faktor: Ich nehme nun nicht nur noch den erwähnten Button 1 im TCP sondern sowohl Button 1 als auch den Fader von drei Executoren via Midi über Dyxnamic Executoren auf.
Damit man sich ein Tempo der Änderungen vorstellen kann: mein Track hat wie gesagt 60 BPM und ich habe auf jeden vierten Takte Änderungen gemacht (also 15 mal pro Minute).
Dies verkraftet DMXC aber absolut nicht mehr. Zu erst hatte ich kurzzeitige Aktualisierungsprobleme in der GUI (heißt der TCP freezte für geschätzt ca. fünf Sekunden). Nachdem ich dies ca. eine Minute lang gemacht hatte, schmierte mir die GUI aber komplett ab und ich habe in der GUI Fehlermeldungen bekommen (siehe Screenshot im Anhang). GUI war nicht mehr responsible und ich musste DMXC komplett schließen und neu starten.

Logs (wie gesagt, habe geschlossen und neu gestartet, es handelt sich also um den vorletzten Start in den Logs) und Projekt sind im Anhang

Eine Show im TCP lässt sich zwar ohne Audio recorden aber nicht wieder abspielen. Projekt mit mehren TCP-Shows ohne Audios als Beispiel im Anhang.

Ich habe das Projekt aus  FS#5180  weitergebaut und in eine Timecode Show überführt.

Führe ich die Timecode Show erstmalig nach dem Laden des Projekts aus, läuft diese bis zum Ende der Release Time wie erwartet ab. In dem Moment, wo der Marker wieder auf 0 springt (weil die sich Cuelist beendet hat), wird der Inhalt der Cue 2 wiedergegeben. Führe ich dann die Timecode Show erneut aus, wird die Cue 1 vollständig ignoriert und nur der Release der Cuelist ausgeführt.

Die Erwartungshaltung ist, dass nach dem automatischen Beenden der Cuelist (Release when last cue ends) und dem Zurücksetzen des Markers die Cuelist wie nach dem Laden des Projekts (oder dem manuellen Stoppen) aus ist und ich die Timecode Show vollständig wiedergeben kann.

Hätte ich als Release Mode “manual only” gewählt, dann wäre das aktuelle Verhalten in Ordnung.

Ich habe das Projekt aus  FS#5181  nun im Bereich der Zeiten von Cues und der Cuelist weiterbearbeitet. Nun ist die Cuelist kürzer als die Audiodatei. Wie im Ticket  FS#5181  soll sie sich aber über “Release when last cue ends” selbst beenden.

Führe ich die Timecode Show das erste Mal nach dem Laden des Projekts aus, läuft diese auch wie gewünscht ab. Auch wird sie mit dem Zurücksetzen des Markers auf 0 nicht erneut in Teilen ausgeführt.

Starte ich die Timecode Show ein zweites Mal, wird ausschließlich die Audio-Datei wiedergegeben. Die Cuelist selbst bleibt “dunkel”. Der Kernel wirft dabei folgende Fehlermeldung:

17:34:13 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.KernelPanicException: WTF
   at org.dmxc.lumos.Kernel.Scene.RealtimeTimestamp.initialize() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\RealtimeTimestamp.cs:line 104
   at org.dmxc.lumos.Kernel.Scene.RealtimeTimestamp.reset() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\RealtimeTimestamp.cs:line 90
   at org.dmxc.lumos.Kernel.SceneList.AbstractSceneContainer.resetTimestamp() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\AbstractSceneContainer.cs:line 89
   at org.dmxc.lumos.Kernel.SceneList.SceneList.play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 986
   at org.dmxc.lumos.Kernel.Timecode.CuelistTrack.<>c__DisplayClass26_0.<proccessNextFrame>g__feed|7(IEnumerable`1 scenelistTimeslots, Boolean triggerPlay) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Tracks\CuelistTrack.cs:line 199
   at org.dmxc.lumos.Kernel.Timecode.CuelistTrack.proccessNextFrame(Int64 tick) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Tracks\CuelistTrack.cs:line 0
   at org.dmxc.lumos.Kernel.Timecode.Track.ProcessNextFrame(Int64 tick) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Tracks\Track.cs:line 191
   at org.dmxc.lumos.Kernel.Timecode.Timecode.<>c__DisplayClass139_0.<processNextFrame>b__4(ITrack t) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 1109
   at LumosLIB.Tools.CommonTools.ForEach[T](IEnumerable`1 source, Action`1 action, Boolean parallel) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:line 598
   at org.dmxc.lumos.Kernel.Timecode.Timecode.processNextFrame() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 1095

Die Erwartungshaltung ist, dass ich an dieser Stelle die Timecode Show ebenfalls mehrfach wiedergeben kann, selbst wenn die Cuelist kürzer als die Audio-Datei ist. Wie aktuell schon der Fall muss die Audio-Datei aber bis zum Ende wiedergegeben werden.

Im Anhang sind das angepasste Projekt sowie die Log-Dateien zu finden.

Veränderte Einstellungen der Darstellung der FFT Grafik (Threshold, Ratio, Bandwith) werden nicht abgespeichert und es wird auch kein Dirty-Flag gesetzt.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

 bei Lumos.GUI.Windows.ProjectExplorerView.<>c.<ShowProperties>b__254_0(IProjectExplorerNode c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\ProjectExplorer\ProjectExplorerView.cs:Zeile 2817.
 bei System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
 bei Lumos.GUI.Windows.ProjectExplorerView.ShowProperties(ICollection`1 nodes) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\ProjectExplorer\ProjectExplorerView.cs:Zeile 2817.
 bei Lumos.GUI.Windows.TimecodePlayer.v3.ExecutorTrackViewModel.<OpenContentProperties>d__27.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\TimecodePlayer\v3\ViewModel\Track\Executor\ExecutorTrackViewModel.cs:Zeile 332.

 bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)
 bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
 bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Fehlerbeschreibung

Hinweise

Fehlerbeschreibung

Wie im beigefügten Screenshot zu sehen, sollte es sinnvoll sein, wenn die Cuelists des aktuellen Projekts im Fenster “Choose a cuelist” alphabetisch sortiert werden würden.

Sollte für die Realisierung dieses Wunsches ein Beispielprojekt der aktuellen Situation benötigt werden, bitte ich um entsprechende Info.

Fehlerbeschreibung

Erwartetes Verhalten

Fehlerbeschreibung

Hallo,
in der StageView kann ich mir ja über “Show/Hide” die “Device/Group Number” anzeigen lassen. Es wäre sehr schön, wenn man sich die DMX-Startadresse (ggf. natürlich entweder Group/Device Nummer oder DMX-Kanal, wenn beides gleichzeitig zu unübersichtlich ist) anzeigen lassen könnte.
Somit kann ich direkt sehen, wo meine Lichter optisch sind und wie diese eingestellt sein müssten.
Als Notation könnte man entweder die Schreibweise 1.xxx (1 für’s Universum und xxx für die DMX-Adresse) benutzen oder halt nur die DMX Adresse (reicht ja schon aus).
Habe mich jetzt erst einmal damit beholfen, dass ich das Hintergrundbild so verändert habe, dass ich darauf die DMX-Adressen eingetragen habe

Mit freundlichen Grüßen

 Michael Röder

Füge ich einem Projekt Geräte hinzu, während in der Stage View die Option “Show Device / Group Number” oder “DMX-Adress” aktiviert und diese sichtbar ist, wird die folgende Fehlermeldung im Log der GUI ausgegeben.

2021-05-10 19:12:45,308 [Main GUI] ERROR org.dmxc.lumos.XNAViews.StageView.StageView - Der Wert darf nicht NULL sein.
Parametername: text
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: text
   bei Microsoft.Xna.Framework.Graphics.SpriteFont.MeasureString(String text)
   bei org.dmxc.lumos.XNAViews.StageView.StageView.DrawIconStrings(RectangleF bounds, Single bottom, Single right, Single& bottomOut, Single& rightOut) in D:\Jenkins\workspace\Lumos_Pipeline_master\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1391.
   bei org.dmxc.lumos.XNAViews.StageView.StageView.Draw(Rectangle clipingRectangle) in D:\Jenkins\workspace\Lumos_Pipeline_master\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1139.

Das Hinzufügen der Geräte selbst erfolgt dabei wie erwartet, weswegen ich keine (weiteren) Logfiles beifüge.

Ich lade exemplarisch das beigefügte Projekt. Wenn ich dann die GUI “hart” neustarte, das heißt die Anwendung über den Taskmanager schließe und die GUI neu starte, werden die Icons der Devic Groups in der Stage View nicht an ihrem ursprünglichen Platz anzeigt. Stattdessen befinden sich beide Icons der Device Groups übereinander gestapelt im Null-Punkt oben links in der Stage View. Die Icons der Geräte selbst befinden sich dagegen an ihrem ursprünglichen Platz.

Im Anhang finden sich die Logs der Sitzung sowohl vor als auch nach dem Neustart der GUI. Kernel und Umbra liefen die ganze Zeit durch.

Fehlerbeschreibung

Hinweise

Fehlerbeschreibung

Ergebnis

Im Softdek kann man einen eingefügten SLider nicht sehen(außer drei Strichen). Ändert man den Style, dann kann man ihn richtig sehen.
Alpha 8

Ich habe die 3.3 Alpha 9 installiert und mein Projekt aus der 3.2.3 neu rübergeholt.
Dabei ist mir aufgefallen das die Silder farblich nicht mehr richtig angezeigt werden.
Bilder vom Softdesk aus der 3.3 Alpha 8 und Alpha 9 sowie das Projekt habe ich angehängt.

Gruss Steff

Slider sind im Softdesk in der Standardeinstellung - im Darkmode - kaum noch zu sehen, siehe Bild im Anhang. Im rot eingekreisten Bereich ist ein Slider, bzw sollte einer sein.

Softdesk hat Anzeigefehler nachdem er verschoben wurde. Screenshot im Anhang.

Fehlerbeschreibung

Erwartetes Verhalten

Log-Nachricht

2023-05-31 18:04:53,748 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Die Sequenz enthält keine Elemente.
System.InvalidOperationException: Die Sequenz enthält keine Elemente.
   bei System.Linq.Enumerable.Max(IEnumerable`1 source)
   bei System.Linq.Enumerable.Max[TSource](IEnumerable`1 source, Func`2 selector)
   bei Lumos.GUI.Windows.Softdesk.Softdesk.ScaleTransformer_Changed(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Windows\Softdesk\Softdesk.xaml.cs:Zeile 209.
   bei System.Windows.Freezable.FireChanged()
   bei System.Windows.Freezable.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
   bei System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
   bei System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)
   bei System.Windows.DependencyObject.SetValueCommon(DependencyProperty dp, Object value, PropertyMetadata metadata, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType, Boolean isInternal)
   bei System.Windows.DependencyObject.SetValueInternal(DependencyProperty dp, Object value)
   bei System.Windows.Media.ScaleTransform.set_ScaleX(Double value)
   bei Lumos.GUI.Windows.Softdesk.Softdesk.zoomOut() in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Windows\Softdesk\Softdesk.xaml.cs:Zeile 750.
   bei Lumos.GUI.Windows.Softdesk.Softdesk.Softdesk_OnPreviewMouseWheel(Object sender, MouseWheelEventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Windows\Softdesk\Softdesk.xaml.cs:Zeile 1114.
   bei System.Windows.Input.MouseWheelEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
   bei System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
   bei System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   bei System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   bei System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   bei System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
   bei System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean trusted)
   bei System.Windows.Input.InputManager.ProcessStagingArea()
   bei System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
   bei System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
   bei System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
   bei System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   bei System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   bei MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   bei System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   bei System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.Run(Form mainForm)
   bei Lumos.GUI.Program.runGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Program.cs:Zeile 198.
   bei Lumos.GUI.Program.Main(String[] param) in D:\Jenkins\workspace\Lumos_Pipeline_3.2_2\LumosGUI\src\Program.cs:Zeile 154.
2023-05-31 18:06:26,671 [Log-Thread] INFO  DMXControl 3 GUI - GUI closing!

Man hat die Möglichkeit Gruppen erneut zu gruppieren.
Die Tiefe ist auf unbegrenzt, ausgenommen Schleifen
Auf diese oberste Gruppe koennen auch Effekte gelegt werden.
Ist ein Gerät in mehreren Gruppen, werden nur die Werte aus der ersten Gruppe verwendet.

Gemäß Diskussion:

(vorerst)
Zuletzt gespeichertes Projekt wird für Kernel zugreifbar gespeichert.
Option: einstellbar, ob vor dem Beenden des Kernels nochmal der aktuelle Stand gespeichert werden soll.
Option: dieses Projekt automatisch beim Start wieder zu laden.

Weiterhin beliebiges Projekt per Startparameter.
=⇒ AL: Started

EDIT/ERGÄNZUNG MARCEL 27.11.2018:

Ich habe zu dem ganzen Projekthandling folgende Idee wie man das Konzept mMn besser gestalten koennte.
DMXC3 wurde als Client/Server konzipiert und ist mMn ein wichtiges Feature, wenn auch (noch) wenig genutzt.

Aktuell wird beim Speichern immer dort eine Kopie erstellt, an deren Ort das Speichern ausgelösst wird. Angenommen wir haben 1 Server und 2 GUIs/Clients:

Client 1 speichert bei sich aus der GUI heraus. Client 2 arbeitet weiter, Client 1 lädt wieder und überschreibt alle Änderungen von Client 2. Und das ohne Rückfrage → Doof

Besser sollte es so sein:

“Projekt speichern” ist bei jedem Client nur noch ein Remote-Befehl an den Server das dieser bei sich in seinem Workdir das Projekt speichern soll.
Ebenso “Projekt laden” öffnet eine Liste und zeigt die auf dem Server abgelegten Projekte an, welche dann auf dem Server geladen werden können.

Neu hinzukommen sollten zwei Einträge:
“Projekt Downloaden/Exportieren” → Packt das Projekt in aktuellem Zustand als ZIP auf dem Server und schickt es an den entsprechenden Client zum runter laden.
“Projekt Hochladen/Importieren” → Lädt ein ZIP und transferiert es auf den Server in das Workdir und macht es somit in der “Remoteliste” zum öffnen verfügbar.

In diesem Zuge kann man darüber nachdenken auf dem Server nicht mehr als ZIP zu speichern und jedes Projekt optional sogar in ein lokales GIT oder ähnlich zu packen. Dann hat man sogar eine Versionierung.

Es wird für den Anfang einen rumimentären Audioplayer geben. Dieser wird dann sukzessive weiter ausgebaut.

Es sollten Timeouts für die Sessions eingebaut werden.

Besonders ist das beim speichern des Projektes zu beachten (ca. 30s).

Außerdem könnten Clients die sich länger nicht mehr melden rausgeworfen werden.

Eigene Endung für DMXC3 Projekte: .dmxc3

Eigene Endung für DDFs: .ddf3

Cool!