Bugtracker DMXControl 3

Im Ticket  FS#3722  kam der Wunsch auf, die Ports der Art-Net-Ausgabe etwas sinnvoller zu sortieren, dass immer direkt 8 Universen am Stück adressiert werden. Durch das neue Ausgabe-Plugin hat sich dieser Dialog in der Hinsicht vereinfacht.

Als Folgeproblem hat sich aber nun durch das neue Ausgabe-Plugin für Art-Net ergeben, dass jedes weitere immer mit dem 1. DMX-Universum angelegt wird - und war sowohl innerhalb der Übersicht der DMX-Interfaces als auch in den erweiterten Einstellungen selbst. Um das Anlegen mehrerer Art-Net-Interfaces zu vereinfachen und zu beschleunigen, sollte hier an beiden Stellen bei den DMX-Universen automatisch “hochgezählt” werden. Net und Subnet bleiben konstant.

Deaktiviere ich die DMX-Interfaces über den Main-Switch, fliegt im Kernel die folgende Exception

20:54:46 ERROR DMXInterfaceBag - Error setting interface Serial: ArtNet, Model: Art-Net, Vendor: Artistic License enabled state to False:
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
   at System.Collections.Generic.List`1.Remove(T item)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.RemovePort(ArtNetInterface port) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 147
   at org.dmxc.lumos.Kernel.DMX.ArtNetInterface.OnDisable() in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNet.cs:line 150
   at DMXLIB.AbstractDMXInterface.set_Enabled(Boolean value)
   at DMXInterfaceMgmtLIB.DMXInterfaceBag.SetEnabledInternal(Boolean target, Boolean byHeartbeatRestart, Boolean byMainSwitch) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\DMXInterfaceMgmtLIB\DMXInterfaceBag.cs:line 267

Der Speedmaster kann ja mit DMXControl 3.2.2 nun auch direkt auf einen BPM-Wert gesetzt werden. Hier wäre es hilfreich, wenn der AudioAnalyser diesen ebenfalls direkt so als Input anbieten kann.

Der aktuell vorhandene Zählwert für den Beat lässt den Speedmaster zu sehr springen, was das Ergebnis merklich verfälscht und in einem großen Spektrum stark springen lässt. So habe ich Titel, wo der AudioAnalyzer mit seiner Analyse konstant bei beispielsweise 128 BPM liegt. Der Speedmaster macht daraus allerdings BPM-Werte zwishcen 120 und 160 BPM, je nachdem wie die Zählwerte über den Beat to Bool Konverter am Learn-Input ankommen.

Als zum Ticket  FS#3167  ergänzende Funktion soll es möglich sein, bei einem beliebigen DMX-Ausgabe-Plugin nachträglich die Ausgangs- und Eingangs-Universen neu zu patchen, ohne dabei das betreffende und bereits konfigurierte DMX-Ausgabe-Plugin entfernen zu müssen. Angedacht ist hier ein Fenster, in dem man angeben kann, ab welchen DMX-Universium bzw. DMX-Adresse die verfügbaren Ports entsprechend fortlaufend belegt werden sollen. Sprich soll das Art-Net-Ausgabeplugin fortlaufend ab DMX-Universum 3 Werte ausgeben oder erst ab dem 5. DMX-Universum.

Im QRM-Meeting vom 16.03.2021 wurde vereinbart, dass das Fenster des Add Interface Dialogs um einen zusätzlichen Zweig über dem Zweig der Non Auto Detect Interfaces erweitert wird, in dem alle automatisch erkannten Interfaces gesammelt werden, die auch noch nicht in Verwendung sind. Das zugehörige Stichwort wie auch in dem ursprünglichen Ticket  FS#4369  beschrieben, ist “Discover-Mode für Auto-Detect-Interfaces”. Dieser Modus ist ein zusätzlicher Entwicklungsstrang parallel zum Punkt “Anpassung des Add Interface Dialogs selbst”.

Aktuell existiert im Executor-Fenster grundsätzlich der Button “Add Page”. Dieser sollte für den Live-Betrieb aber abschaltbar sein, um dort nicht versehentlich neue Seiten anzulegen.

Eventuell könnte eine Variante sein, diese Option in die Properties des Zweigs für die Executor Pages.

Ich habe eine einfache Cuelist mit zwei Cues gebaut, die in Schleife wiedergegeben wird:

1. Cue 1: Dimmer [100%], Farbe [ColorMaster 1]
2. Cue 2: Dimmer [100%], Farbe [ColorMaster 2]

Beide Color Master habe ich mir in den verschiedenen Modi RGB, CMY und HSV in eine Executor Page geliegt.

Jenachdem, welchen Color Master Typ ich nutze, um die Farbe einzustellen, ändert sich der Farbübergang zwischen den beiden Cues. Entweder direkt oder entlang des Farbkreises. Dass die Kombination des Farbtypes / Farbmodells den Fade beeinflusst, ist grundsätzlich bekannt (siehe Ticket FS#4279).

An dieser Stelle kann es zu Verwunderungen führen, wenn eben dieses Verhalten nicht bewusst ist. Die Verwunderung kann noch größer sein, wenn man einmal die Farbe per Fader festlegt (der als HSV konfiguriert ist) und dann die Farbe per Button setzt - innerhalb eines Executorzugs. Auch dies beeinflusst den Farbübergang.

Grundsätzlich kann man diesen Punkt dokumentieren, bis er sich bei der Umsetzung des Tickets FS#4279 “erledigt”. Die Frage ist aber, ob dies ein praktikabler Weg ist und ob es nicht besser wäre, dem ColorMaster eine Einstellung mitzugeben, dass er die Farbe nur intern in einem bestimmten Farbmodell vorhält.

Aus der Erfahrung heraus gibt es für LED-Scheinwerfer eine Reihe von Farben, die man gerne wiederverwendet, weil man weiß, dass sie auf den Geräten gut aussehen. Solche Farben sind aber oft Mischfarben. Diese Mischfarben kann man mit einem Fader jedoch nur schwer schnell und reproduzierbar “treffen”.

Grundsätzlich besteht die Möglichkeit, diese Farben in mehreren Cuelists zu speichern, gerade wenn man sie über mehrere Geräte unterschiedlich aufrufen möchte. Um das Projekt flexibler zu gestalten, kam mir daher der Gedanke, dass man durch die Kombination eines Color Masters auf einem Executor mit einer selbst definierten Color List ggf. vereinfachen könnte. Hierzu wähle ich statt eines Faders wie Hue, Saturation, Red oder ähnlich eine meiner vorbereiteten Color Lists aus. Auf Basis dieser Color List erhält man im Bereich des Faders statt des Faders untereinander angeordnete Buttons mit den Farben aus der ausgewählten Color List. Damit ließen sich eigene Farben entsprechend schneller anwählen und man benötigt für einen Color Master auch nur einen Executor-Zug.

In gewissen Situationen habe ich gleich mehrere Cuelists, die ich gemeinsam live manipulieren möchte, wie unter anderem Timing (Fade Factor), Effect speed, Limit, Temp. Aktuell muss ich hierzu entsprechend viele Executoren anlegen, kann aber dann die Werte immer noch nicht für mehrere Cuelists gemeinsam setzen.

Um dies zu ermöglichen kamen mir hier zwei mögliche Ansätze in den Sinn:

• Es wird ein neuer Executor-Typ “Cuelist Group” eingeführt. Für alle in dieser Cuelist Group enthaltenen Cuelists kann man dann gemeinsam alle verfügbaren Werte gemeinsam ansprechen. Zusätzlich erhält man Zugriff auf die Funktionen wie “Alle starten” oder “Alle stoppen”, die das Cuelist Group Node bereits anbietet. Dieser Ansatz würde dann auch zu dem Ticket FS#4325 passen, die genannten Funktionen auch im Node direkt hinzuzufügen.
• Man kann einem Executor mehrere Elemente zuordnen. An dieser Stelle würde es dann ggf. keine Differenzierung geben, dass es bei den Cuelists erlaubt ist, bei den verschiedenen Mastern aber nicht.

Bei Effekten wie Rechteck, Trapez oder weiteren, bei denen explizit mit Zeiten gearbeitet wird (fade up time, fade down time, pause) sollte nicht die Phasenverschiebung nicht als Winkel in Grad, sondern als Zeitwert in (Milli-) Sekunden angegeben werden.

Wenn ich die Größe einer Matrix nachträglich über die Properties ändere (egal ob Vergrößerung oder Verkleinerung), kommt diese Änderung im PropertyGrid zahlenmäßig erst an, nachdem ich einmal den Matrix FormEditor geöffnet und mit OK wieder geschlossen habe. Die Matrix-Effekte kommen nach (und auch während) der Änderung allerdings direkt richtig an. In den meisten Fällen sollte dieser Schritt meiner Meinung unnötig sein und könnte aktuell noch zu Verwirrungen führen.

Hat man in ein Feld im Property-Grid geklickt, um einen Wert einzutragen, sollte beim Betätigen der Tab-Taste der Cursor direkt in das darunterliegende Feld springen und ggf. sogar direkt den Eintrag aus dem Feld auswählen. Hat ein Feld mehrere, durch ein Semikolon getrennte werde, so werden diese jeweils einzeln von links nach rechts durchgeschaltet (als ob es einzelne / getrennte Felder wären) und ebenfalls direkt zum Überschreiben ausgewählt. Durch drücken der Kombination Umschalt + Tab springt der Cursor ins vorherige Feld.

Beispiel der Tab-Reihenfolge für einen LED-PAR entsprechend des Aufbaus im Property-Grid: DIMMER > STROBE > COLOR (rot) > COLOR (grün) > COLOR (blau) > DIMMER

Aktuell ist es so, dass der Cursor quasi eine Kreis dreht: Wert > Dropdown-Pfeil für Schiebebalken > Umschaltmenü Values, Group Handlung, Registerkarte Properties > Wert

Führt man einen Doppelklick im Property-Grid aus, so wird bei Feldern mit durch Semikolon getrennte Werte immer noch das Semikolon und das dahinter folgende Leerzeichen mit ausgewählt. Dies macht das schnelle Ändern gerade bei Color und Position unnötig aufwendig, da hier folglich auch immer das Semikolon mit neu gesetzt werden muss.

Mit einem einfachen Chaser kann man zwar ein Random-Strobe generieren, jedoch sind diese Einstellungen an die Anzahl der aktiven Geräte innerhalb einer Gruppe gebunden und bei dem einfachen Chaser ist immer nur ein Gerät aktiv.
Der Random-Strobe-Chaser geht über den einfachen Chaser hinaus und sollte über folgende Parameter zum Einstellen verfügen. Die nachfolgend genannten Parameter sollen dabei unabhängig von der Anzahl der aktiven Geräte innerhalb der Gruppe gelten.

• Anzahl der gleichzeitig aktiven Geräte
• Zeit Dimmer an
• Zeit Dimmer aus
• Zufällige Pausenzeit
• Maximale Helligkeit
• Zufälliger Helligkeitswert / Mindestwert
• Laufrichtung des Strobes (vorwärts, rückwärts, von der Mitte aus, zur Mitte hin, zufällig)

Die zufällige Pausenzeit soll den Strobe-Effekt zufällig entsprechend unterbrechen, sofern hier ein Wert eingetragen ist.

Ist ein Wert im Feld „zufälliger Helligkeitswert“ gesetzt, soll hier durch jedes Gerät leuchtet immer mit einer anderen zufällig generierten Helligkeit zwischen dem Mindestwert und dem Maximalwert, wobei der Wert „zufälliger Helligkeitswert“ den Mindestwert angibt. Auf diese Weise lässt sich gerade bei einer größeren Zahl an Geräten eine besondere Tiefenwirkung erzielen.

Ein zusätzlicher Clou wäre an dieser Stelle, wenn sich der Wert für die Anzahl gleichzeitig aktiver Geräte live vom Softpult aus beeinflussen ließe, beispielsweise über die Effekt-Speed der Cueliste.

An verschiedenen Stellen fehlt aktuell noch die von DMXControl erwartete Einheit der Eingabe im Device Control in Abhängigkeit der GUI-Einstellung für den Wertebereich, unter anderem in:

• Frequency (unter anderem bei den Effekten Circle, Polygon, Hypozykloide)
• Amplitude X und Y
• Rotation Frequency (unter anderem bei Polygon)

• Anfang und Ende eines Adressbereichs für ein Gerät besser kennzeichnen, zum Beispiel durch abgerundete Ecken
• Adresse in die Mitte verschieben(Fett), Darunter dann der DMX-Wert
• Vergrößerung der Balken für Kanalwerte(auf voller Breite aber hinter Adresse und Value)
• Highlighting der Kanäle der gerade in der StageView ausgewählten Geräte
• Farbliche Kategorisierung der einzelnen Kanalfunktionen wie Dimmer, Color, Position, Gobo, Strobe / Shutter (ENTSCHEIDUNG)

Wie im Projektgespräch vom 06.08.2017 vorgeschlagen sollte der Shortcut zum Aufrufen der (geplanten) Kommandozeile vom Benutzer einstellbar sein. Die aktuelle Belegung F12 aus dem Input Assignment zu entfernen, könnte umgekehrt Verwirrung stiften und es würde sowieso dieser Vorschlag unterbreitet werden.

Öffne ich Cuelists zur Ansicht kann ich die Cues in den Programmer legen. Allerdings sieht es scheinbar so aus, dass ich auch Werte aus dem Programmer wieder in die zur Ansicht geöffnete Cuelist abspeichern kann. Tatsächlich werden die Werte aber in der Cue abgelegt, die im Edit-Modus einer Cuelist geöffnet ist.

Daher wäre es zu überlegen, die Menüpunkte zum Bearbeiten von Cues in der zur Ansicht geöffneten Cuelist zu entfernen. Welche dies sind, wäre noch festzulegen. Möglicherweise reicht der Menüpunkt “Add Cue” aus.

Aktuell ist es so, dass man im Patching-Dialog nur Gerät für Gerät den Patch ändern kann. In manchen Situation ist es aber vom Handling her einfacher, direkt für mehrere Geräte den Patch zu ändern. Daraus abgeleitet, wären folgende zusätzlichen Funktionen erforderlich:

• Auswahl von mehreren Geräten in ein anderes DMX-Universum umpatchen. Die Adressen innerhalb des Universums werden 1-zu-1 übernommen. Der User gibt nur das Ziel-Universum an.
• Auswahl von mehreren Geräten ab einer bestimmten DMX-Adresse neu patchen. Für das erste Gerät der Auswahl gibt der User die Start-Adresse sowie den Freiraum zwischen zwei Geräten an.
• Aktivierung der Auswahlmöglichkeit von mehren Geräten in der Kanalübersicht des Patching-Dialogs.

* Auswahl von mehreren Geräten ab einen bestimmten Wert eine neue Device-ID zuweisen. Für das erste Gerät der Auswahl gibt der User den Start-Wert sowie den Freiraum zwischen zwei Geräten an. ⇒ Hat nix mit DMX Patching zu tun

Ergänzung: Grundlegend sollte die Vergabe der neuen DMX-Adressen immer an Hand der Sortierung der Spalten erfolgen, die jeweils im Patching-Dialog vor dem Starten der automatischen Patching-Funktion gesetzt ist.

Beim Umbau und Anpassung eines vorhandenen Projekts auf ein neues Licht-Setups sind mir im Dialog für die Device Properties folgende Optimierungsmöglichkeiten aufgefallen:

• Sind mehrere Geräte ausgewählt, können unterschiedliche Einstellungen zum Beispiel bei Pan- & Tilt-Reverse, nicht gemeinsam auf einen neuen Wert gesetzt werden. Hier wäre der Vorschlag, dies zwar entsprechend zu kennzeichnen, dass die Geräte in der aktuellen Auswahl an dieser Stelle unterschiedliche Einstellungen aufweisen, am Ende aber Änderungen für alle Geräte zuzulassen.
• Das Einstellen von individuellen Offsets bei Pan und Tilt für mehrere Geräte könnte beschleunigt werden, wenn das Dialogfenster unten links noch zwei zusätzliche Buttons mit “<” und “>” erhält. Über diese Button kann man dann zum Gerät mit der niedrigeren (<) bzw. höheren (>) Device-ID springen. So spart man sich eine Reihe von Mausklicks, um den Dialog für das nächste Gerät aufzurufen.

Wird über einen Group-Master für eine Geräte-Gruppe eine Helligkeit festgelegt, verlieren insbesondere Blinder- und Strobe-Effekte ihre Wirkung. Um diesem entgegen zu treten, schlage ich die Integration eines neuen Syntax für Helligkeitswerte: FL.

Wird in den Cues anstelle von 100% der Wert FL eingetragen, so gelten für diesen Cue die Einstellungen in den Groupmastern nicht mehr. Die einzige Möglichkeit zur Steuerung der maximalen Helligkeit bleibt dann nur noch über die Cuelist Intensität selbst.

Alternativ könnte man noch über die Einführung einer Einstellmöglichkeit in den Cuelist Optionen nachdenken, dort den Zugriff der Groupmaster auf die jeweilige Cuelist zu deaktivieren.

Zur einfacheren Bedienung schlage ich vor, das Panel Color wie folgt zu ergänzen:

• Aufnahme der Farbtemperatur im Reiter mit den Colorpicker
• Einbau zweier Schieberegler für die kontinuierliche Rotation und Indizierung des Farbrads analog des Panels für Gobo

Ich habe gerade mein Projekt wieder für die nächste Show vorbereitet und musste mich hier durch eine Reihe von Ordnern klicken, in die ich meine Cuelists verteilt habe.

Um eine Cuelist noch schneller zu finden, könnte ich mir eine Suchfunktion im Projekt Explorer gut vorstellen, bei der man bei Bedarf auch auswählen kann, in welchem Hauptordner (Cuelist, Device, Stage View etc.) gesucht werden soll. Auf diese Weise ließen sich zum Beispiel nachträgliche Änderungen an Cuelist Settings noch schneller durchführen, wenn diese auf verschiedene Ordner verteilt sind.

Da aktuell die Saved Effects eine Programmeinstellung und somit an den PC gebunden sind, können die selbst erstellten Effekte nicht auf einem anderen PC genutzt werden.

Es ist daher zu überlegen, ob die eigene Effekte mit Bestandteil eines Projekts werden. Dies hätte zur Folge, dass diese dann auch in den Project Explorer aufgenommen werden.

Für das Device Control wünsche ich mir zwei Buttons, mit dessen Hilfe ich das Fanning im ausgewählten Feld “durchschalten” kann. Dies kommt vor allem bei alternierenden Fannings zum Tragen. Die Buttons könnten daher einfach mit « und » beschriftet sein. Beim Drücken von » würde folgendes passieren:

• 255;128;0 # 0;128;255 # 64;192;48
• 64;192;48 # 255;128;0 # 0;128;255
• 0;128;255 # 64;192;48 # 255;128;0

Der Button « tauscht die Werte innerhalb des Fannings entsprechend Schritt für Schritt wieder zurück. Ähnlich würde es bei einem linearen Fanning laufen, wenn der Button » gedrückt wird:

• 255;128;0 > 0;128;255
• 0;128;255 > 255;128;0

Da sich DMXControl 3 an vielen Stellen über Tastatur Shortcuts steuern lässt - unabhängig von der Belegung im Input Assignment - sollte es ggf. in den Einstellungen eine zentrale Übersicht über die verfügbaren Shortcuts geben. Photoshop bringt unter anderem eine solche komplette Übersicht mit. Die Übersicht könnte optional nach den entsprechenden Bereichen gruppiert sein, zum Beispiel Stage View oder Cuelists.

Um während des Live-Betriebs ein unerwünschtes Verhalten der Software zu vermeiden, sollte es in dieser Übersicht einen einzigen einstellbaren Eintrag geben - nämlich die globalen Shortcuts zu aktivieren oder zu deaktivieren. Die restlichen Einträge ist festgesetzt und können vom User nicht geändert werden.

Getestet mit Build 1572

Da durch das Electricity-Feature nun ein weiteres Icon in der Menü-Leiste des Project-Explorers hinzugekommen ist, würde ich nun die generelle Sortierung überdenken und stelle folgenden Vorschlag in den Raum:

1. Create Cuelist
2. Add Device
3. Create Cuelist Group
4. Create Device Group
5. Create Executor Page
6. Add Softdesk
7. Add Power Source
8. Create Stage View
9. Create Item List
10. Import Files

Da die Sortierung meinem persönlichen Empfinden entspricht, habe ich das Ticket mal auf Usability Relevant gestellt und ein paar Personen eingeladen. Die aktuelle Anordnung der Icons in der Menü-Leiste sind im Anhang zu sehen.

Sortiere ich mir die Tabelle im Input Assignment nach einer bestimmten Spalte und wechsele durch die Bänke oder in einen Graphen und wieder zurück, wird die Sortierung nicht beibehalten.

Ich habe die Cuelists A, B und C. Die Cuelists A und C sind bereits einer Cuelist Group zugeordnet. Nun lege ich noch Cuelist D an. Alle Cuelists A bis D möchte im Anschluss nun der gleichen Cuelist Group zuordnen, wähle dazu alle aus und ziehe die Cuelists auf die Cuelist Group. Nun sperrt mir die GUI das Ablegen der Auswahl, da ja bereit eine Cuelist (hier A und C) innerhalb der Auswahl bereits im Ziel (also der Cuelist Group) enthalten ist.

Das “Sperren” ist in dem Sinne unschön (weswegen ich das Ticket als Fehler gekennzeichnet habe) und vom Workflow her ineffektiv ist, dass ich immer vorher erst schauen muss, was ist im “Zielordner” (meist Cuelist Group, Device Group, Stage View und Eletricity Management) bereits enthalten. Im zweiten Schritt muss ich über eine Mehrfachauswahl die Cuelists o. ä. anwählen, die ich dem Zielordner hinzufügen möchte. Hierbei laufe ich aber Gefahr, entweder Cuelists zu vergessen oder ich erwische doch nochmal eine, die bereits in der Cuelist Group enthalten ist, worauf ich die Auswahl nochmal ändern oder möglichst alle Cuelists einzeln der Cuelist Group zuordnen muss.

An dieser Stelle wünsche ich mir einen Workflow, bei dem diese “Vorabkontrolle” entfällt, ob eine Cuelist in einer Cuelist Group enthalten ist oder nicht.

Auch wenn das Verhalten bereits in der 3.1 schon so war, habe ich das Ticket mal mit zur 3.2 gepackt, weil es hier nun nochmal explizit aufgefallen ist.

Die Einträge im Fenster Cuelist Properties sind in Bereich mit den “allgemeinen” Kernel Properties aktuell recht unstrukturiert. Insbesondere sind Einstellungen rund um das Timing der Cuelist bunt verteilt, wie im beigefügten Screenshot zu sehen ist.

Im Zusammenhang mit dem Ticket  FS#3628  sollten diese Einträge nach Möglichkeit neu strukturiert und sinnvoll gegliedert werden, wie es bereits für das GoNext-Verhalten, die Ansichtseinstellungen der Spalten und die Defaults gemacht wurde.

Zur besseren Übersichtlichkeit und möglicherweise auch schnelleren Änderungsmöglichkeit sollten folgende Objekt-Nummern im Project Explorer als zusätzliche Spalte anzeigt werden:

• Cuelist Group Number
• Executor Number
• Executor Page Number

Die Reihenfolge der Einträge

• Name
• Objekt-Nummer (Group Number, Executor Number)
• Image (sofern vorhanden)

fällt in den Properties für

• Cuelist (siehe hier auch Ticket  FS#3628 )
• Device Group
• Executor
• Executor Page

unterschiedlich aus. Hier wäre der Wunsch, die Reihenfolge dieser Einträge aus Gründen der Konsistenz zu vereinheitlichen und sie ggf. einer eigenen Untergruppe mit dem Titel “Information” oder “Name” zuzuordnen.

Da bei einem schmalen Cuelist-Editor-Fenster vor allem die Slider für Intensity, Speed und Face Factor schwierig zu bedienen sind, soll die gesamte Menüleiste in mehrere Gruppen aufgeteilt werden, sodass diese frei und auch in mehreren Zeilen frei positioniert werden können. Mögliche Gruppen können sein:

1. Go, Pause, Stop
2. Add Cue, Edit, Up, Down,
3. Mode, Options, Autoscroll
4. Intensity, Time (Fade Factor), Speed

Nachdem auf meinem PC der Bildschirmschoner ansprang, hat die GUI das Logfils mit der folgenden Fehlermeldung geflutet, sodass die Datei am Ende auf über 143 MB angewachsen ist.

2019-11-23 15:17:17,144 [Log-Thread] WARN  org.dmxc.lumos.XNAViews.GraphicsDeviceControl - Failed to Draw!
System.InvalidOperationException: An unexpected error has occurred.
   bei Microsoft.Xna.Framework.Graphics.GraphicsDevice.CreateDevice(GraphicsAdapter adapter, PresentationParameters presentationParameters)
   bei Microsoft.Xna.Framework.Graphics.GraphicsDevice..ctor(GraphicsAdapter adapter, GraphicsProfile graphicsProfile, PresentationParameters presentationParameters)
   bei org.dmxc.lumos.XNAViews.GraphicsDeviceService.ResetDevice(Int32 width, Int32 height, Boolean withoutEvent, Nullable`1 handler, Boolean hardReset) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\XNA\GraphicsDeviceService.cs:Zeile 146.
   bei org.dmxc.lumos.XNAViews.GraphicsDeviceControl.OnPaint(PaintEventArgs e) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\GraphicsDeviceControl.cs:Zeile 470.

2019-11-23 15:17:17,158
2019-11-23 15:17:17,171
2019-11-23 15:17:17,185
...
2019-11-23 15:50:20,200
2019-11-23 15:50:20,222
2019-11-23 15:50:20,245

Durch die Größe des Logfiles hat möglicherweise auch dazu geführt, dass die GUI von Windows geschlossen wurde.

Wenn ich ein Preset nutze, halte ich im Nachgang keinerlei Info darüber, in welcher Form das jeweilige Preset in der Cue hinterlegt wurde. Insbesondere bei Device Presets und Property Presets lässt sich dies weder im Programmer, noch im Programmer Filter, im Device Control oder in der Cue nachvollziehen. Im Programmer wird aktuell nur mitgeteilt, dass ein bestimmtes Preset verwendet wurde.

Bei einem Reference Preset ist die Verwendungsart durch die Benennung der Cue selbst klar ersichtlich.

Ich musste durch mein Projekt in einem Club mit vielen Device Groups arbeiten, um mit deren Hilfe besondere Effekte auf eine Teilauswahl der Geräte legen zu können. Für die Effekte war die Sortierung in den Device Groups entsprechend wichtig, aber auf Grund der Pixel pro Gruppe auch schnell aufwendig.

Ich würde mir daher eine Möglichkeit wünschen, nicht nur wie bis jetzt alle Devices in einer Device Group nach bestimmten Kriterien sortieren zu können, sondern diese Sortiermöglichkeiten auch nur für eine (zusammenhängende) Auswahl von nur 10 Geräten innerhalb der ansonsten 50 Geräte umfassenden Device Group nutzen zu können.

Sind in einer Device Group so viele Geräte einhalten, dass in der Liste gescrollt werden muss, bleibt der Fokus nicht auf dem Gerät, welches ich gerade umsortiere. Durch jeden Klick wird der Inhalt der Liste aktualisiert und mit der Aktualisierung wird die Liste immer zum obersten Eintrag hochgescrollt. Dies bedeutet am Ende, dass ich die Geräte im Blindflug umsortieren muss, sollte der Bildschirm in der Höhe nicht genügend Fläche zur Verfügung stellen.

Als Testprojekt kann das Projekt aus Ticket  FS#3999  verwendet werden.

Bei den Properties der Intelligent Cuelist Group Settings werden verschiedene Texte verdeckt, sodass diese entweder abgeschnitten oder auf zwei Zeilen umgebrochen werden und in beiden Fällen trotz verfügbarer Fensterbreite nicht komplett zu lesen sind.

Wähle ich mittels eines Doppelklick gezielt Werte im Device Control aus, zum Beispiel den Pan-Wert im Feld für Position oder einen Farbkanal im Feld für Color, so umfasst die Auswahl immer auch das nachfolgende Semikolon. Im Falle eines negativen Wertes, zum Beispiel für die Position, fehlt zudem das Minuszeichen.

Darüber hinaus kommt es wiederholt vor, dass bei einem Doppelklick auf den Wert für die Farbe rot im Feld für Farbe die Werte für grün gewählt wird. Im Screenshot 1 ist die Position des Mauszeigers zum Zeitpunkt des Doppelklicks entsprechend markiert.

Hintergrund des Tickets ist, dass so zur Zeit ein zusätzlicher Handgriff erforderlich wird, um das Semikolon einzufügen, was den Workflow bremst.

Bislang erkennt man eine Special Cue, mit der eine andere Cuelist gestartet, gestoppt etc. wird nur an der besonderen Benennung der Cue. Hier wäre es hilfreich, wenn diese ebenfalls gesondert gekennzeichnet wird - zum Beispiel analog zu den Cues, bei denen der Cue Timing Editor aktiv ist.

Aus der GUI geht sowohl im Programmer auch nicht im Device Control hervor, welches Farbmodell man für eine Device Group oder einem Device genutzt hat. Hier würde ich mit eine entsprechende Kennzeichnung wünschen.

Ich ändere einen Text in einer beliebigen Zelle, zum Beispiel den Trigger value oder den Namen im Cuelist Fenster oder den Namen eines Connectionsets im Input Assignment.

Wenn ich den Cursor mit Hilfe der Pfeiltasten verschiebe, kommt es sehr häufig vor, dass hierbei der Text in der Zelle vom ersten Zeichen an bis zur Cursorposition ausgewählt wird. Somit ich immer mit der Maus an die richtige Stelle klicken, was die Korrektur des Textes je nach Situation erschwert.

Wenn ich eine Cuelist, ein Softdesk oder eine Stage View über das Menü oder über die Schnellzugriffsleiste neu erstelle, könnte ich es mir als hilfreich erachten, wenn dieses Element dann direkt im Bearbeitungsmodus geöffnet wird. Das bedeutet

• eine neue Cuelist wird direkt im Cuelist Editor,
• ein neues Softdesk wird direkt im Softdesk Designer und
• eine neue Stage View wird direkt geöffnet.

Aktuell muss ich hier die Einträge nochmals aufrufen, damit ich die Bearbeitung der Elemente entsprechend vornehmen kann. Insbesondere im Falle eines neu angelegten Softdesk könnte dies wie eingangs gesagt durchaus hilfreich sein.

Aus der Projektbesprechung vom 14.03.2021 ging der mehrheitliche Wunsch hervor, dass eine namentliche Nennung der beteiligten Personen für Entwicklung, Übersetzung etc. erfolgen soll. Die Art und Weise ist dabei noch nicht final festgelegt, ob diese Nennung direkt in der Software oder im Wiki oder auf der DMXC-Homepage erfolgt.

Wie bei den Menüeinträgen zur Cuelist, Softdesk und Stage View sollte der Eintrag Macroboard Profile aus Konsistenzgründen ebenfalls dahingehend erweitert werden, dass man aus den neuen Untermenüpunkten direkt ein vorhandenes Macroboard-Profil öffnen und ein neues anlegen kann.

Über die Buttons half und double kann man den aktuellen BPM-Wert faktorisieren. Hier wäre es gut, wenn dieser Faktor angezeigt wird. Ein typisches Anwendungsbeispiel ist, dass ich mehrere Speedmaster zwar gleichzeitig Lerne bzw. Synchronisiere, aber jeden Speedmaster einzeln faktorisiere.

Ich habe mehrere Cues programmiert, wo ich die Farbe explizit im HSV-Modell angeben musste. Dies war in der Vielzahl allerdings recht umständlich, da ich im Device Control bei jedem erneuten Anwählen einer Gerätegruppe oder eines Geräts immer erst das Farbmodell umschalten musste.

An dieser Stelle könnte das Device Control entsprechend unterstützen, indem es sich merkt, welches Farbmodell zuletzt verwendet wurde. So muss ich nur noch umschalten, wenn ich bewusst wechseln möchte. Eine separate Einstellung hierfür, um das favorisierte Farbmodell vorzugeben, sehe ich hier nicht.

Aktuell verfügen die Macroboard-Profile über kein Eigenschaften-Fenster, wie es eben Devices oder Cuelists der Fall ist. Im Eigenschaften-Fenster der Macroboard-Profilen könnte ich mir aktuell folgende Parameter vorstellen:

• Name
• Macroboard-Profil-Nummer

Insbesondere der Parameter “Profil-Nummer” kann hilfreich sein, wenn man über eine numerische Zuordnung der Profile zu einem Macroboard arbeitet, wie zum Beispiel beim Durchblättern durch mehrere Seiten (respektive Profilen).

Optional würde ich folgende Einstellmöglichkeiten in den Raum werfen:

• Statisches Hintergrundfarbe oder -bild
• Verhalten der Buttons (Push oder Toggle)
• Anzahl der Buttons pro Zeile und Spalte

Können durch diverse Filter (voreingestellte Filter oder durch manuelle Textfilter aus Suchmaske) keine passenden Ergebnisse gefunden werden, soll hierauf durch einen Text wie “No results found” hingewiesen werden. Im Fall der Gobo List ist es aktuell so, dass dann man nur ein leeres Fenster sieht.

Der neue Dialog zum Auswählen eines Hintergrundbildes für die Stage View sollte aus meiner Sicht wie der neue Sound Selector die Möglichkeit erhalten, eine Bilddatei direkt aus dem Dateisystem auszuwählen. Damit entfiele der bislang notwendige Umweg, das gewünschte Hintergrundbild erst anderweitig ins Projekt ins Projekt importieren zu müssen und würde sich zudem eben an die Möglichkeiten im neuen Sound Selector angleichen.