Bugtracker DMXControl 3

In einem mir zur Verfügung gestellten Testprojekt ist folgender Fehler im GUI-Log aufgetaucht:

2019-03-28 22:32:43,413 [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 449.

Das zugehörige Projekt kann ich bei Bedarf intern zur Verfügung stellen.

Ich lege ein neues Projekt und füge einem neuen Softdesk mehrere Controls hinzu. Dann schließe ich nur die GUI, während das Softdesk weiterhin im Designer geöffnet und das Projekt noch nicht gespeichert ist. Nach dem Neustart der GUI (den Kernel habe ich nicht beendet) sind alle neu eingefügten Controls verschwunden. Habe ich alternativ statt neue Controls hinzuzufügen auch nur bereits existierende Controls geändert (zum Beispiel verschoben), sind diese Änderungen ebenfalls nach dem Neustart der GUI weg.

Folglich fehlt ein entsprechender Befehl vom Softdesk Designer an den Kernel, das aktuelle Softdesk beim Beenden der GUI zu speichern. Denn wenn ich den Softdesk Designer vor dem Schließen der GUI manuell schließe, wird das Softdesk entsprechend im Kernel zwischengespeichert.

Aus den beigefügten Log-Files geht nicht hervor, dass das Softdesk beim Schließen der GUI automatisch gespeichert wird. Dafür wird aber in Folge dessen bemängelt, dass das in der ersten Session noch angelegte Control nach dem Neustart der GUI fehlt:

2021-03-29 11:31:46,518 [Main GUI] ERROR Lumos.GUI.WindowManager - Error when instantiating Object from persistString: Lumos.GUI.Windows.Softdesk.Designer.SoftdeskDesigner#c8aa2b0d-a9e3-4e64-98ef-47dcf6744d18
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> org.dmxc.lumos.Kernel.Exceptions.NotExistingException: Can't find a SoftdeskModel with ID c8aa2b0d-a9e3-4e64-98ef-47dcf6744d18
   bei Lumos.GUI.Windows.Softdesk.SoftdeskWindow.getSoftdeskModelFromID(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Windows\Softdesk\SoftdeskWindow.cs:Zeile 71.
   bei Lumos.GUI.Windows.Softdesk.Designer.SoftdeskDesigner..ctor(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Windows\Softdesk\Designer\SoftdeskDesigner.cs:Zeile 83.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
   bei System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   bei System.Activator.CreateInstance(Type type, Object[] args)
   bei Lumos.GUI.WindowManager.GetContentFromPersistString(String persistString) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\WindowManagement\WindowManager.cs:Zeile 1817.

Ein (Beispiel-) Projekt kann nicht zur Verfügung gestellt werden, weil wie oben beschrieben zu keinem Zeitpunkt etwas gespeichert wurde.

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

Da es scheinbar immer aus verschiedenen Gründen wieder Probleme gibt, Plugins nachzuinstallieren, schlage ich vor, einen kleine Installerfunktion im Pluginmanager zu integrieren, die wie folgt arbeitet:

1. Alle Plugins erhalten entweder eine Hilfsdatei mit Verzeichnisangaben für die Daten oder vorgeschriebene Verzeichnisse, in denen die erforderlichen Daten ablegt werden müssen.
2. Der User lädt das entsprechende Plugin als ZIP-Archiv herunter.
3. Der Plugin-Manager erhält einen zusätzlichen Button mit den Namen “Add plugin”
4. Der User wählt das Plugin aus dem Dateisystem aus und bestätigt die Auswahl.
5. Die Installerfunktion verschiebt die Daten des Plugins in die richtigen Verzeichnisse.
6. Nach dem “Installationsvorgang” fordert DMXControl 3 den User zum Neustart der Software auf.
7. Nach dem Neustart ist das installierte Plugin automatisch aktiviert.

⇒ Plugins werden aus Sicherheitsgründen nicht über DMXControl selber installiert, sondern über ein separates Programm

Getestet mit Build 1402

Der Installer legt aktuell noch nicht die Verknüpfung im Startmenü zu den eigenen DDFs an.

Die Fanning-Operatoren ? und ?? sollen liefern einen zufälligen Wert zurück. Soll dieser Wert seine Gültigkeit behalten

• für die gesamte Laufzeit einer Cuelist?
• nur für die einzelne Cue und somit mit jedem Aufruf einer oder auch der selben Cue direkt neu generiert werden?

Diese Situation betrifft nicht nur die Properties selbst, sondern zum Beispiel auch die Werte für Fade, Delay etc. in den Cuelists selbst. Diese Frage bzw. das Verhalten dieser Operatoren sollte ggf. nochmal diskutiert werden.

Wenn ich wie im beigefügten Projekt zwischen mehreren Cuelist mit Hilfe einer Cuelist Group direkt (also hart und ohne Fades) wechseln möchte, so erfolgt beim Umschalten kurzzeitig keine Ausgabe. Dies ist sowohl in der Stage View als auch in der Channel Overview zu beobachten.

Im Anhang befindet sich ein entsprechendes Testprojekt. Um das Problem zu reproduzieren, einfach über die Executoren zwischen den drei verlinkten Cuelists wechseln.

Das Ticket entstammt aus einer Rückfrage im Forum, wo das Problem auch schon bei DMXControl 3.1.3 aufgefallen ist.

Die im Screenshot dargestellte Eingabe wird mir als fehlerhaft gekennzeichnet, obwohl ich gemäß des Tooltipps im richtigen Wertebereich liege.

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.

Ich würde mir eine weitere Variante wünschen, bei der ich die Nodes, gerade aus der Kategorie Logic, in der Graphenansicht nicht ausschließlich über das Kontextmenü auswählen muss, sondern im Idealfall diese direkt mit nur einer Mausbewegung in das Connectionset einfügen kann.

Aktuell ist der Style “Lumos” der einzige Style für den Button, bei dem die Properties für OnColor und OffColor genutzt werden können.

Da diese beiden Properties die Gestaltung des optischen Feedbacks um ein Vielfaches vereinfachen, diese bitte auch für die anderen Styles des Buttons sowie weitere Controls umsetzen / einpflegen, welche über die Änderung einer Farbe ein sinnvolles optisches Feedback generieren können. Ggf. werden hierbei OffColor und BaseColor zusammengeführt.

Die Möglichkeit, einen Button auch durch das Übergeben von RGB-Werten im Input Assignment dynamisch einfärben zu können, muss aber weiterhin bestehen bleiben.

Ich habe mit im Softdesk verschiedene Controls entsprechend des beigefügten Beispiels angeordnet. Hierbei ist mir aufgefallen, dass die Ebenen für die Softdesk Controls für Eingaben mit Maus und per Touchscreen nicht “durchlässig” sind. Im konkreten Fall bedeutet dies:

1. Ist die Box im Vordergrund und umschließt Buttons oder wie im Beispiel Fader, können diese nicht mit Maus oder per Touchscreen bedient werden.
2. Die gezeigten Slider müssen jeweils seitlich vom Label “gegriffen” werden, um sie auf einen Wert zu bringen, welche hinter dem Label liegen.

Meine Erwartungshaltung wäre hier, dass die Anordnung von Controls in mehreren Ebenen keinen Einfluss darauf hat, ob sich das ganz unterste Control bedienen lässt oder nicht.

Da bekanntermaßen das Arbeiten mit den RGB+-Offsets wie zum Beispiel

<matrix dmxchannel="2" rows="1" columns="12" whiteoffset="3" amberoffset="4" uvoffset="5" />

zur Zeit noch nicht möglich ist, habe ich die Matrix wie folgt definiert:

<matrix rows="1" columns="12">
  <rgb>
    <red dmxchannel="2" />
    <green dmxchannel="3" />
    <blue dmxchannel="4" />
    <white dmxchannel="5" />
    <amber dmxchannel="6" />
    <uv dmxchannel="7" />
  </rgb>
  ...
    <amber dmxchannel="72" />
    <uv dmxchannel="73" />
  </rgb>
</matrix>

Grundsätzlich werden die RGB+Kanäle richtig angesteuert. Dies ist besonders gut zu sehen bei der Farbe Amber.

Allerdings wird mir in den Geräte-Einstellungen für die RGB+-Farben (hier Amber und UV) nicht die Optionen für das Mischverhalten angeboten (Add, Only, None). Die RGB+-Farben werden mit den Default-Einstellungen eingebunden, was hier Add ist. Zur Zeit ist die Option nur für Weiß verfügbar. Gleiches gilt hier auch für die Radix.

Ich habe mir zwei Cues angelegt, welche zwischen langsam exemplarisch zwischen der Farbe gelb und blau hin- und herfaden. Gebe ich die Farben im:

• RGB-Modus oder im CMY-Modus an, so wird direkt von gelb nach blau gefaded
• HSV-Modus an, erfolgt der Fade von gelb über grün und hellblau nach blau

An dieser Stelle hätte ich jetzt nicht erwartet, dass der Wechsel der Art der Eingabe für die Farbe sich auf auf den Fade der Cues auswirkt und im HSV-Modus über Zwischenfarben gefaded wird. Bis jetzt hatte ich gedacht, dass der Wechsel zwischen RGB, CMY und HSV nur eine andere Art der Eingabe ist, um zum Beispiel mittels HSV einen statischen Regenbogen zu erzeugen.

Als Ergänzung hierzu: teile ich die Cues auf zwei Cuelists auf (also Cuelist 1: gelb, Cuelist 2: blau) und schalte die Cuelists mit Hilfe einer Cuelist Group um, erfolgt der Übergang zwischen den Farben wieder direkt, sprich wie ich es auch vom RGB-Modus kenne.

Ich habe nun auch noch ein Beispielprojekt in der 3.2.2 erstellt. Wenn beim Öffnen das letzte Fensterlayout geladen wird, können über die ersten drei Executoren die automatisch laufenden Farbwechsel von gelb nach blau und zurück für die Modelle RGB, CMY und HSV gestartet werden. Die letzten vier Executoren dienen dem manuellen Wechseln zwischen gelb und blau - einmal im RGB-Modus und einmal im HSV-Modus.

Verschiebe ich Objekte (Cuelists, Devices) in Verzeichnisse, so wird dieses zwischen den GUIs nicht synchronisiert.

Ich habe an einem Projekt Änderungen vorgenommen, die auch vom DirtyFlag registriert wurden. Schließe ich dieses geänderte Projekt nun, ohne die Änderungen manuell gespeichert zu haben, sind meine Änderungen weg.

Daher sollte (wie bei anderen Programmen auch) die Abfrage erscheinen, ob getätigte Änderungen vor dem Schließen des Projekts noch gespeichert werden sollen.

Aus der Diskussion zwischen Arne und Jens-Peter geht hervor, dass die Abfrage muss an insgesamt vier Stellen erfolgen muss:

• Projekt schließen direkt in der Menüleiste
• Projekt schließen in der PA beim aktiven Projekt
• Beim Laden eines neuen Projekts
• Beim Laden eines neuen Projekts im Kernel über Komandozeilenabfrage

Im Falle der GUI steuert diese den Prozess selbst und fragt den Status des DirtyFlag ab.

Ich habe mich mit dem PC 1 in einer 1:1-Verbindung auf dem Umbra verbunden, der gemeinsam mit dem Kernel auf PC 2 läuft. Nun ändere ich währenddessen die IP-Adresse des PC 2. Nach einem kleinen Moment stürzt die GUI ab.

Die Verbindung zwischen Umbra und Kernel bleibt auf dem PC 2 bestehen und auch beide Programme laufen weiter. Nach einem Neustart der GUI war ein direktes Verbinden und weiterarbeiten mit dem ggf. aktuell geladenen Projekt möglich.

Das erwartete Verhalten wäre an dieser Stelle, dass die GUI es zumindest abfangen kann, wenn die ursprüngliche Verbindung unterbrochen wird - was ja auch in anderen Konstellationen vorkommen kann.

Die Logfiles sind für beide PCs (PC 1: GUI, PC 2: Umbra und Kernel) im Anhang beigefügt.

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.

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.

Ich habe nach einigen anderen Arbeiten an dem in der Sitzung geladenen Projekt gegen 18:10 Uhr das Master-Fenster in den Vordergrund gerufen. Die Sitzung lief dabei seit rund vier Stunden. Beim Aufbau des Fensters hänge sich die GUI auf. Der Kernel und Umbra liefen weiter und nach dem Neustart der GUI konnte das Projekt “fortgesetzt” werden. Bei dem zweiten in den Vordergrund rufen des Master-Fensters wurde dieses ganz normal geladen.

Das Master-Fenster war Bestandteil des zuletzt geladenen Layouts des Projekts. Hierdurch war das Master-Fenster als weiterer Reiter in einem ausgedockten Fenster im Hintergrund geöffnet. Ich habe dieses Layout in beiden Fällen geladen.

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.

Damit der Installations-Manager die Plugins für DMXControl 3 automatisch in die richtigen Verzeichnisse kopieren kann, muss eine Hilfsdatei erstellt werden, dessen Inhalte es zu definieren gilt. Folgende Informationen könnten möglicherweise hilfreich sein:

• Art des Plugins (Kernel, GUI)
• Angabe der Verzeichnisse der Dateien
• Author
• Plugin-Version
• kompatible DMXControl-Version
• Checksumme für die im ZIP-Archiv enthaltenden Daten

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

Unter dem Ticket  FS#2680  hatte ich vorgeschlagen, den Syntax im Device Control derart zu erweitern, um eine Cue mit folgender Lichtstimmung etwas einfacher programmieren zu können:

• rot, rot, rot, blau, blau, weiß

Da der seiner Zeit vorgeschlagene Syntax möglicherweise zu schwierig ist, kam mit beim Programmieren an einem aktuellen Projekt von mir der entsprechende Gedanke, auch beim Group Handling alternierende Fannings zuzulassen. Um die gezeigte Lichtstimmung zu programmieren, wären folgende Eingaben erforderlich:

• Device Control: 255; 0; 0 # 0; 0; 255 # 255; 255; 255
• Group Handling, Modus Concat Group: 3 # 2 # 1

Ich habe mittlerweile DMXControl 3.2 und DMXControl 3.1.3 auf dem gleichen PC, aber in getrennten Verzeichnissen installiert. Bei der Installation hat der Installer nun aber den Pfad im Registry-Eintrag für DMXControl 3 geändert, sodass ich DMXControl 3.1.3 nicht im No-Network-Modus starten kann. Hier wird nun der Kernel der 3.2 aufgerufen. Starte ich GUI und Kernel getrennt, klappt aber alles.

Im Zuge des anstehenden Beta-Tests schlage ich daher vor, bei der Installation von DMXControl 3.2 einen neuen Registry-Eintrag anzulegen, um beide Version auf dem gleichen PC noch weiter voneinander “zu trennen”. Ich könnte mir hier auch vorstellen, dass es bei einer späteren Deinstallation von DMXControl 3.1.3 Probleme entstehen, sondern der Uninstaller auf die entsprechenden Einträge zurückgreift.

Die Stage View kann vor Ort durchaus auch immer wieder für handschriftliche Notizen genutzt bzw. auch zum Patchen der Geräte genutzt werden. Um einen guten Ausdruck generieren zu können, wäre hier eine Exportfunktion des aktuellen Ausschnitts als Grafikdatei hilfreich. Im Idealfall wird die exportierte Datei entsprechend gerendert, sodass sie dann in einer höheren Auflösung als die Ausgabe auf dem Bildschirm zum Ausdruck zur Verfügung steht.

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.

Geprüft mit Build 1602

Im Rahmen der Vorbereitung der Video-Tutorials kam nach einer Diskussion zu den Default-Werten der Cuelists der Wunsch auf, die Optionen

• Use cue time as back time
• Use cue time as goto time

per Default auf true zu setzen. Für einen Einsteiger ist unter Umständen auf den ersten Blick nicht ersichtlich, dass hier für die Cuelist globale alternative Zeiten gelten, wenn man direkt zu einer Cue springt.

Getestet mit Alpha 3, Build 11

Die Schreibweise der Anschlüsse in den Nodes und somit auch in der Baumstruktur des Input Assignments sowie in den Properties der einzelnen Nodes sollte nur nach einem einzigen Schema erfolgen, zum Beispiel nur der erste Buchstabe eines Wortes groß oder nach der allgemein gültigen Rechtschreibung. Durch die Schreibweise teilweise in Großbuchstaben sieht es so aus, als ob es “höherwertige” oder “minderwertige” Anschlüsse an den Nodes gibt. Dies führt unter Umständen zu vermeidbaren Erklärungen und Erläuterungen.

Aus meiner Sicht könnte es hilfreich sein, wenn die automatischen Regeln zum Erstellen eines Graphen nicht nur im Hintergrund in der Tabellenansicht angewendet werden, sondern auch in der Graphenansicht selbst.

Beispiel: ich ziehe in der Graphenansicht den Button eines Softdesks auf das GO einer Cuelist und einen Slider auf die Intensity. Die erste Verbindung wird gemäß der Standardvorgaben automatisch um den Binary Switcher erweitert, die zweite um einen Rule of Three.

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.

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.

Analog zu den Cuelists sollte auch bei Softdesks durch Copy & Paste eine Kopie des zuvor ausgewählten Softdesks angelegt werden.

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.

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

Da die Funktionen zum Klonen und Verschieben eines Connectionset (CS) aktuell nur über das Kontextmenü eines gewählten CS (Bild 1) erreichbar und somit gefühlt recht versteckt sind, würde ich es begrüßen, wenn diese im Menü zum Eintrag Connectionset (Bild 2) ergänzt werden. Der Eintrag zum Löschen eines CS ist ja dort bereits vorhanden, allerdings noch nicht funktionsfähig.

Möchte ich zum Beispiel das Feedback für einen Button dahingehend darstellen, dass dieser in Abhängigkeit seines Status die Farbe wechselt und ggf. auch anfängt zu blinken, wenn er aktiviert ist, benötige ich eine Reihe von verschiedenen Nodes.

Um das Handling gerade über mehrere Connectionsets zu vereinfachen, würde ich mir an dieser Stelle ein Art Makro-Node (oder Baugruppen-Node oder Blackbox-Node) wünschen, dass ich analog zur Siemens S7 an einer Stelle mit mehreren Nodes fülle, die Nodes konfiguriere und dann die Ports angebe, über die ich dann Werte in das Makro-Node hineinschicke und zurück erhalte.

Das Ziel soll am Ende sein, dass man

• nachträglich Teile eines komplexeren Connectionsset in meine anderen Connectionsets einbauen kann
• entsprechend komplexe Teile eines Connectionsets nur einmal ändern muss (Properties der genutzten Nodes selbst als auch Hinzufügen oder Entfernen von Nodes) und diese Änderung sich auf alle Connectionssets auswirken, in dem dieses Makro-Node verwendet wird
• solche Makros auch projektübergreifend nutzen kann und somit wie eine Bibliothek zur Verfügung stehen, ggf. auch über eine Import- und Export-Funktion

Aktuell kann ich die Breite des Colorscroll-Effekts nicht konsequent beeinflussen. In bestimmten Situationen wird die Pixelbreite hochgesetzt.

Daher wünsche ich mir an dieser Stelle einen zusätzlichen Parameter im Effekt, welcher die Breite des Effekts grundlegend festlegt, also wie viele Pixel die gleiche Farbe zeigen sollen. Um langfristig flexibler zu sein, wäre auch zu überlegen, ob man einen Teil der Fanning-Operatoren zulässt, wie zum Beispiel das #. Sollte dies aber den Rahmen sprengen, könnte man hier auch umgekehrt über eine entsprechende Anpassung der Colorlist arbeiten.