Bugtracker DMXControl 3

Wenn ein Graph Fehler wirft oder in der Verarbeitung zu lange läuft sollte nach z.B. 10 Fehlern der Graph abgeschaltet werden, um nicht das ganze System auf zu halten.

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

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.

In den Einstellungen eines Gerätes in DMXC3 können nur alternative Dimmerkurven gewählt werden, wenn das Gerät einen einzelnen Dimmerkanal hat. Hat es allerdings nur Farbkanäle (R, G, B), fehlt der ganze “Dimmer”-Aufzählungspunkt, obwohl Dimmerkurven ja auch auf Farbkanäle angewendet werden können sollten.

Ich wünsche mir also alternative Dimmerkurven auch ohne Dimmerkanal. Die können dann auch gerne alle Farbkanäle gleichzeitig beeinflussen.

Aus Gründen der Konsequenz könnte man Preheat und Limit (die beiden anderen Punkte unter “Dimmer”) auch gleich übernehmen, braucht zwar kaum ein LED-PAR, aber ist trotzdem schick zu haben.

Ausgangssituation: Es gibt mehrere Moving Heads, die zeitversetzt eine Welle (Sinus auf Tilt) durchlaufen sollen. Hierzu gibt es drei Cues, einen mit dem Sinus auf dem Tilt, die One Shot-Cue und eine statische Cue, um die Welle zu beenden. Da es ein gefanntes Delay für alle drei Cues eingetragen ist, bin ich davon ausgegangen, dass nun auch alle Heads die Welle zeitversetzt durchlaufen und jeder mit seinem entsprechenden Delay wieder zum stehen kommt. Das ist aber nicht der Fall. Nachdem der erste Moving Head die Welle durchlaufen hat, beenden alle die Welle irgendwo mitten drin und gehen gleichzeitig direkt auf die statische Stimmung.

Wenn ich in einem Blade als Maximalen trust 0.8 (80%) angebe, wird dies auch für die DMX-Ausgabe zwar beachtet, aber die InputControls und das StageView-Icon zeigen immer noch 100%

    <blades>
      <bladeindex dmxchannel="37">
        <range range="120" mindmx="0" maxdmx="255" />
      </bladeindex>      
      <bladetop dmxchannel="38">
        <range minval="0" maxval="0.8" mindmx="0" maxdmx="255" />
      </bladetop>
      <bladetopangle dmxchannel="39" pointofrotation="center">
        <range range="50" mindmx="0" maxdmx="255" />
      </bladetopangle>
      <bladeleft dmxchannel="40">
        <range minval="0" maxval="0.8" mindmx="0" maxdmx="255" />
      </bladeleft>
      <bladeleftangle dmxchannel="41" pointofrotation="center" >
        <range range="50" mindmx="0" maxdmx="255" />
      </bladeleftangle>
      <bladebottom dmxchannel="42">
        <range minval="0" maxval="0.8" mindmx="0" maxdmx="255" />
      </bladebottom>
      <bladebottomangle dmxchannel="43" pointofrotation="center">
        <range range="50" mindmx="0" maxdmx="255" />
      </bladebottomangle>
      <bladeright dmxchannel="44">
        <range minval="0" maxval="0.8" mindmx="0" maxdmx="255" />
      </bladeright>
      <bladerightangle dmxchannel="45" pointofrotation="center" >
        <range range="50" mindmx="0" maxdmx="255" />
      </bladerightangle>
    </blades>

Wenn ich mit der Maus per Drag&Drop ein oder mehrere Geräte in eine “Device Group” ziehe, dann bekomme ich kein Feedback. Ich sehe im Projekt Explorer keine Änderung und muss erst die Gruppe öffnen, damit ich sehe, dass beim Hinzufügen alles geklappt hat.

Für den Benutzer wäre es hilfreich, eine Reaktion vom Programm zu bekommen.

Eine Möglichkeit wäre, dass nach dem Drag&Drop die Gruppe kurz das Aussehen verändert. (Irgendwo habe ich einmal eine pulsierende Reaktion in einem anderen Programm nach einem Drag&Drop gesehen, das ziemlich ansprechend war)
Eine andere Möglichkeit wäre, dass im Tree vom Projekt Explorer mit angezeigt würde, wieviele Geräte aktuell in der Gruppe drin sind. Diese Anzahl würde sich dann natürlich nach dem Hinzufügen veränden.

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

Es wäre sehr sinnvoll wenn im Programmer auch Angezeigt wird, wenn auf einem Kanal ein Effect oder Filter angelegt ist.

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.

Bei externen “Controls”, die kein Feedback erlauben (z.B. nicht motorisierte Fader, Potis, DMX-In), gibt es das Problem springender Werte, wenn sich Werte in der Software ändern, aber natürlich nicht am Control selbt. Fasst man das Control das nächste mal an, würde der Wert einfach auf den zuletzt am Control eingestellten Wert springen.
Um das zu umgehen, gibt es z.B. bei der MidiBox verschiedene Modi, die man einstellen kann:

Normal, Snap, Relative, Parallax
http://www.ucapps.de/midibox_tutorial.html (Nach “Normal Mode” suchen)

Diese Einstellung auch in DMXC zu haben (z.B. für DMX-In, wo es prinzipiell kein Feedback gibt, also auch das Pult dieses Verhalten nicht implementieren kann) wäre für mich sehr sinnvoll.
Wahrscheinlich reicht es, das pro MIDI- oder DMX-In-Device konfigurieren zu können, also nicht unbedingt für jedes Control einzeln.

Wenn ich den graphen einer Verbindung geöffnet habe, sollte der Name der Verbindung irgendwo angezeigt werden.

Es wird immernoch nicht der Node für Random in Gobowheel und Colorwheel gelesen bzw. wird nich angezeigt und kann deshalb nicht drauf zugreifen.

MfG
Patrick

Aus Nutzersicht wäre es super, “virtuelle” Eingänge (z.B. Go / Stop  FS#3321 ) zu haben, die im Hintergrund einen Graphen generieren. Dadurch könnten viele Standard Fälle abgedeckt werden, ohne das Input Assignment zu verschandeln.

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.

hat ein Gerät mehrere Beams, wird es als 1 Icon im LV angezeigt.

Für die folgende Erklärung sei Beispielhaft folgendes Gerät gegeben:

Beam 1:
- RGB
- Position (gilt für alle Beams)
Beam 2:
- RGB
Beam 3:
- RGB

Lösung:
0. Es gibt einen “Master Beam” (der 1. Beam) welcher allgemeine Eigenschaften enthält, die sich die Beams teilen. Per Konvention ist das der 1. <function> Block im DDF. Die Eigenschaften (e.g. <dimmer>) werden mit “global=true” markiert, falls es eine globale Eigenschaft ist. In diesem Fall wird die Eigenschaft auch angezeigt, wenn ich einen anderen Beam selektiere. Der Masterbeam ist also so etwas wie eine “Beamgruppe”.

1. Darstellung im Stageview ist umschaltbar zwischen Einzeldarstellung und Beam Darstellung
⇒ Darstellung als Multibeam nur, falls Gerät > 1 Beams besitzt.
⇒ Einzeldarstellung: Wie aktuell, nur bei “Multibeam” Devices wird unter dem “Hauptbeam” angedeutet, dass es zusätzliche Beams gibt (e.g. Icon oder kleine Vierecke). Die Einzeldarstellung ist quasi der Masterbeam.
⇒ Multibeam Darstellung: Die Beams werden als “Matrix” dargestellt und jeweils gezeichnet wie aktuell der Hauptbeam
⇒ Dies gilt natürlich für Geräte UND Gruppen ⇒ Sollte Beam 1 nur Global Eigenschaften enthalten, wird er in der Beam Darstellung NICHT angezeigt. Begründung: Die Global Eigenschaften des Masterbeams werden auch in den anderen Beams dargestellt. Ergo ist eine separate Darstellung nicht notwendig.

2. Selektion Beam / Master
In der Einzeldarstellung selektiere ich den “Masterbeam”. Über ein Tastaturknopf kann auf Beam Selektion umgeschaltet werden und es werden nur die einzelnen Beams markiert. Das Selektieren einzelner Beams ist für Fanning wichtig.
⇒ Wenn Masterbeam selektiert ist, werden die gemergden Eigenschaften aller Beams im PG angezeigt:
Beispiel:

- RGB (Beam 1-3)
- Position

Wenn ich nun das RGB ändere, ändere ich das RGB aller 3 Beams

⇒ Wenn Beams selektiert sind, wird jeder Beam mit seinen Eigenschaften dediziert im PG angezeigt (Beispiel Beam 2, 3 selektiert)

- Global
  - Position
- Beam 2
  - RGB
- Beam 3
  - RGB

3. Fanning
Master selektiert ⇒ Fanning über Geräte (wie bisher)
Beams selektiert ⇒ Fanning über Beams

Folgendes Vorgehen löst den Fehler aus, auch in der 3.3 Alpha6 vorhanden, Logs der 3.3 anbei.

Device Group mit Generic RGB, Farbe auf Rot in Cuelist speichern. → funktioniert wie erwartet
Anschließend alle Devices aus der Gruppe löschen, Projekt speichern und neu laden.
Projekt neu laden, wieder Geräte in die Gruppe hinzufügen, Cuelist starten → keine Farbe mehr vorhanden, bei “Edit in Programmer” wird keine Eigenschaft aufgerufen, der Programmer bleibt leer.

Hintergund:
Ich habe für mich ein Standard-Projekt erstellt, dieses hat 4 Gruppen und je nach Veranstaltung werden andere Geräte in die Gruppen aufgeteilt, teils mit vollkommen unterschiedlichen Setups. Mir ist es nun schon passiert das ich mir beim Anpassen des Projektes alles zerstört habe weil ich erst einmal alle Gruppen geleert haben.
Beim letzten Mal wollte ich das ganze verhindern und habe ein Gerät in die Gruppe gesteckt das ich sonst nicht nutze, leider tritt der Fehler auch auf wenn das Gerät keine Farbeigenschaft hatte, daher hat mir die Nebelmaschine in der Gruppe auch nicht vor dem Verlust geschützt.

Hallo,

ich glaube wieder einen Bug gefunden zu haben.

Die erste Cue wird nicht geladen, wenn im Loop-Modus, der Trigger für die erste Cue mit follow oder wait und 0ms und letzte Cue mit Fade-Time 0 eingestellt ist.

Zum Reproduzieren:
Projekt erstellen, Gerät(e) hinzufügen (auch bei Gruppen), Cuelist mit 4 Farben hinzufügen, alle Cues als Trigger follow einstellen mit 0 ms. Die Zweite und letzte Cue mit 0ms Fade-Time einstellen. Mode der Culist auf Loop stellen, und abspielen (ich hoffe keinen Schritt vergessen zu haben).

Das Verhalten tritt auch auf bei Trigger auf Wait eingestellt.

Der Anwendungsfall ist wahrscheinlich sehr selten, und es lässt sich umgehen, indem eine Zeit auf 1ms gesetzt wird.

Beste Grüße, Ludwig

DMXControl 3 kann auf zahlreichen Wegen diverse Informationen und Signal von außen erhalten. Dies sind neben diversen Hardware-Komponenten wie MIDI, Streamdeck, MPA-Pulte auch datenbasierte Inputs wie zum Beispiel das OSC- oder das MQTT-Protokoll. Nahezu jeder Input bringt verschiedene grundlegende erforderliche Konfigurationsoptionen mit. Solche grundlegenden Konfigurationen sollten alle an einem zentralen Ort zusammengefasst werden, der hier exemplarisch als External Input Manager bezeichnet wird.

Im Falle des MQTT-Nodes würden beispielsweise die Einstellungen für Host-Adresse, Benutzername, Passwort und Port zentral in den External Input Manager wandern, da diese sonst aktuell bei mehrfacher Verwendung des Nodes jedes Mal individuell zu hinterlegen wären.

Ich habe in dem beigefügten Setup mehrere Gruppen in Gruppen abgelegt. Die Gruppe “Complete Setup” enthält alle Geräte, indem ich dieser Gruppe die untergeordneten Gruppen zugeordnet habe. Nun möchte ich auf der Gruppe “Complete Setup” Werte für zwei Funktionen abspeichern. Da die Werte eben nun auf der Gruppe “Complete Setup” liegen, wäre meine Erwartungshaltung, dass im Programmer Filter eben nur die Gruppe “Complete Setup” aufgeführt wird, wie es auch im Device Control der Fall ist.

Aktuell ist es aber so, dass die untere Ebene im Programmer Filter aufgelistet wird. Auch werden die Eigenschaften der jeweiligen unteren Gerätegruppen aufgeführt und mir zum Abwählen angeboten. Hier sehe ich ein Konsistenz-Problem, wenn ich feingliedriger Abwählen kann als im Device Control “eingestellt” ist sowie meine Einstellungen mit Hilfe des Programmer Filter nicht mehr korrigieren (also filtern) kann.

Grundsätzlich besteht dieses Problem auch jetzt schon, wenn ich manuell mehrere Gruppen auswähle.

Aktuell verfügen Cuelists nur über die Play Modes “Once”, “Loop”, “Bounce” und “Random”. Hier vermisste ich kürzlich den Play Mode “Reverse”, woraufhin ich die Reihenfolge der Cues selbst anpassen musste, um das gewünschte zu erreichen.

Mittlerweile gibt es ja beim neuen Chaser weitere gute Play Modes. Die Play Modes “Switch” und eben “Reverse” kann ich mir ebenfalls sehr gut als Play Modes für Cuelists vorstellen. Vielleicht lassen sich auch noch weitere Play Modes vom Chaser auf die Cuelists adaptieren - inklusive der Icons.

In der Bank-Übersicht ist aktuell Rechtsklick/Delete die einzige Möglichkeit Connectionsets zu löschen. Um den Workflow zu verbessern wäre gut, wenn es auch mit der “Entf”-Taste geht, sowohl bei Einzel- als auch bei Mehrfachauswahl

Color-Chaser → Speedmaster auf Duration, bei auslösen eines Sync wird kein Schritt ausgelöst, gleiches auch bei anderen Effekten
zB Speedmaster steht auf 30 BPM, ich drücke einmal die Sekunde auf Sync → Color-Chaser bleibt stehen

Lege ich eine Cuelist an, mit Beat als Trigger, wird korrekt auch bei Sync ein Schritt ausgelöst.

Test/Idee: Wenn möglich, sollten alle Effekte einen Schalter für “Bounce” bekommen, wodurch der mathematische Effekt umgekehrt durchlaufen wird. Außerdem sollte die “Laufweite” (Anfangswinkel und Endwinkel) des mathematischen Effekts einstellbar sein.

Bislang verfügt das Position Control nur über einen Output, um Objekte anzusprechen. Im Zuge der Implementierung der Positionmaster wäre es sinnvoll, wenn das Position Control auch einen Input erhält, damit sie die aktuellen Werte der Positionmaster etc. anzeigen kann.

Dieses Ticket steht im ähnlichen Kontext wie das Ticket FS#4603.

Für mein Club22-Projekt bestand die Anforderung, dass automatisch eine Reihe von unterschiedlichen Cuelists nach Ablauf einer vorgegeben Zeit durchwechseln. Da die Cuelists zum Teil auch aus mehreren Cues bestehen, war es nicht möglich, alles in einer Cuelist abzubilden. Um das Umschalten der Cuelists nach einer vorgegebenen Zeit anzustoßen, habe ich mir nun weitere Cuelist gebaut, die durch Befehle per Special Cues die Cueslists umschalten.

Dieser Weg ist zwar durchaus praktikabel und hat seine Daseinsberechtigung - allerdings ist dieser für den beschriebenen Anwendungsfall “bessere Sound-To-Light-Steuerung” ein wenig zu aufwendig.

Daher kam mir der Gedanke, ob man die Cuelist Groups dahingehend erweitern kann. Das ginge dann in die Richtung, dass ich die Cuelists, welche regelmäßig durchgeschaltet werden sollen, in eine gemeinsame Cuelist Group einfüge. Die Cuelist Group erhält die zusätzliche Option, die enthaltenen Cuelists

• nach einer vorgegebenen Zeit
• entsprechend verschiedener Play Modes analog zu den Cuelist

automatisch durchzuschalten.

Ob der Nutzer die Möglichkeit zum Starten auch aus der normalen GUI erhält, wäre zu diskutieren. Im jeden Fall sehe ich hier eine Erweiterung des Cuelist Group Nodes um die Eingänge

• Go bzw. Play
• Time
• Play Mode

Bislang verfügt der Color Bar nur über einen Output, um Objekte anzusprechen. Im Zuge der Implementierung der Colormaster wäre es sinnvoll, wenn die Color Bar auch einen Input erhält, damit sie die aktuellen Werte der Colormaster etc. anzeigen 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.

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.

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.

Die Ausgangssituation für diesen Vorschlag ist folgender: Ich habe zum Beispiel zwei Gerätegruppen, wo in der einen Gruppe 7 Geräte und in der anderen 18 Geräte enthalten sind. Die Geräte sind in ihrer Reihe allesamt mit dem gleichen Abstand versehen und beginnen mit dem jeweils 1. Gerät auf der gleichen Seite. Hierdurch steht die zweite Reihe entsprechend nach “hinten” über. Vergleichbar wäre das mit zwei unterschiedlich lang abgeschnittenen LED-Stripes, wo beide auf der einen Seite auf der gleichen Höhe starten.

Für diese Anordnung möchte ich nun einen Effekt bauen, der zwar auf beiden Gruppen parallel läuft, sich jedoch auch auf beiden Gruppen auf die gleiche Anzahl von Geräten (zum Beispiel Wiederholung alle 5 Geräte) streckt.

Um einen solchen Effekt mit den aktuellen Möglichkeiten zu realisieren, müsste ich den Effekt auf beide Gruppen einzeln anwenden und dabei die Parameter individuell an die Anzahl der Geräte abstimmen. Ein Griff zum Taschenrechner ist unumgänglich. Den Group Handling Modus “Parallel Groups” kann ich ich an dieser Stelle nicht nutzen, weil hierdurch der Effekt bei der 1. Gruppe auf 7 und bei der 2. auf 18 Geräte gestreckt wird.

Um diesen Punkt besser abzudecken kam mir der Gedanke zu diesem neuen Modus, bei dem ich über den Zahlenparameter eben angebe, wie groß diese “virtuelle” Untergruppe ist. Dem entsprechend wird der Effekt bei N+1, 2xN+1, 3xN+1 wiederholt. Passt die Größe der Gruppe nicht zu der Angabe, wird hinten abgeschnitten.

Ich verwende DMXC 3.2.2 und habe oben schmale Slider die um 90 Grad rotiert sind.
Die Werte auf den Slidern werden aber leider auf die unrotierte Breite bezogen angezeigt.
Wie auf dem angehänten Foto zu sehen ist. Dieses ist aus meinem größerem Projekt.
Das angehängte Projekt ist nur zum Zeigen.
Die angezeigten Werte könnten für die Senrechten Slider (0 Grad Rotation) Hochkant angezeigt werden.
Bei Rotation könnten die Werte dann mit rotieren.

Es wäre hier schön wenn man die Anzeige der Werte abschalten könnte.

Um eine Cuelist (bzw. später eine Timecodeshow) über mit externem Timecode zu fahren. Dies ist nötig, wenn man eine DAW oder sonstige Software hat, die den Timecode vorgibt.

Autoprepare funktioniert nur wie gewollt, wenn der Shutter eines Gerätes geschlossen ist. Wenn ein Gerät keinen Shutter hat, funktioniert Autoprepare überhaupt nicht. Bei Geräten mit Shutter greift Autoprepare schon während des Ausfadens, sofern nicht auch der Shutter geschlossen wird.

Aufbau eines einfachen Projekts zum Reproduzieren:

Cuelist mit 4 Cues:
Cue 1: Dimmer 0% und/oder Shutter geschlossen (siehe unten)
Cue 2: Dimmer 100%, Shutter offen, Farbe Blau, Position A
Cue 3: Wie Cue 1
Cue 4: Dimmer 100%, Shutter offen, Farbe Rot, Position B

Hierbei sind mir diese unterschiedlichen Verhalten aufgefallen:

Generic RGB, Cue 1/3 enthält Dimmer 0%, kein Shutter vorhanden:
Cue 2 faded Dimmer und Farbe gleichzeitg (Wechsel von Weiß zu Blau ist erkennbar). Hier sollte Autoprepare ja eigentlich die Farbe voreinstellen.
Gleiches gilt für Cue 4 mit dem Fade Blau → Rot

Generic RGB mit Subdevice Generic Shutter, Cue 1/3 enthält Dimmer 0% und Shutter geschlossen:
Funktionier wie erwartet, die Farben für Cue 2/4 werden während Cue 1/3 voreingestellt, sodass beim Triggern der Cue nur der Dimmer faded.

Generic RGB mit Subdevice Generic Shutter, Cue 1/3 enthält nur Dimmer 0% und NICHT Shutter geschlossen:
Cue 2 verhält sich wie bei Generic RGB ohne Shutter (Kein Autoprepare). Beim Triggern von Cue 3 wird jedoch schon während des Ausfadens die Farbe zu Rot gefaded. Hier greift Autoprepare also zu früh.

Generic RGB mit Subdevice Generic Shutter, Cue 1/3 enthält nur Shutter geschlossen und NICHT Dimmer 0%:
Funktioniert wie erwarten, kein Unterschied zu Dimmer und Shutter in Cue 1/3.

Das Verhalten der Generic RGB mit Shutter konnte ich auch mit einem Stairville MH-X25 reproduzieren, hierbei war zusätzlich zu Farbe auch ein Positionswechsel in den Cues enthalten.
Auch hier galt, Shutter geschlossen führte zum erwarteten Verhalten von Autoprepare (mit und ohne Dimmer 0%), Shutter offen lassen und Dimmer 0% führte zu Autoprepare schon während des Ausfadens, durch die Positionsänderung noch deutlicher erkennbar.

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”.

Der Parametermaster muss an mehr Stellen angewendet werden. Wichtig sind vor allem bei XY-Positionen um Live die Position von Effekten zu beeinflussen und auch bei Amplituden von diesen Effekten. Insgesamt gibt es noch einige weitere Stellen, wo diese (noch) nicht eingesetzt werden können.

Kurzbeschreibung

Die Steuerung der Geschwindigkeit von 1D Effekten hat zwei Fehler:

1. Bei Übergabe eines SpeedMasters läuft der Effekt nicht synchron mit anderen Effekten
2. Die Gerätesteuerung erwartet Werte für die Frequenz [Hz], nutzt diese aber als Dauer [s].

Langbeschreibung

Ich möchte, dass mein RGB bei jedem Beat in einer anderen Farbe aufleuchtet und dann ausblendet. In DMX 3.2.2 geht das theoretisch mit einer einzelnen Cue. Auf die Farbe lege ich einen Color Chaser Effekt. Auf den Dimmer lege ich einen invertierten Sägezahn. Für beide Effekte gebe ich bei der Dauer / Frequenz den {SpeedMaster 1} an. Dem Speedmaster gebe ich mit ein paar Taps ein krummes Tempo um die 130 bpm vor.

Wenn ich diese Cue starte, sieht am Anfang alles gut aus. Aber nach ca. 40 Beats sieht man, dass es eine Phasenverschiebung zwischen den zwei Effekten gibt. Nach ca. 80 Beats ist es offensichtlich. Sprich: Die beiden Effekte laufen unterschiedlich schnell! (Also nicht nur Jitter.)

Stellt man den SpeedMaster statt dessen über den Schieberegler ein, sind die BPM Werte deutlich weniger krumm. Die Phasenverschiebung tritt dann auch auf, aber sehr viel später.

Stellt man die Frequenz von Hand ein, stellt man den zweiten Fehler fest: Ein Wert von 2 lässt den Effekt 2 Sekunden dauern und nicht wie erwartet 0,5 Sekunden.

Stellt man die Frequenz von Hand auf einen Wert von 0,5 ein und die Dauer auf 500 ms, so laufen beide Effekte über lange Zeit synchron.

Mögliche Ursachen

Für mich sieht es danach aus, als würde bei der Umrechnung von Frequenz in Dauer ein Rundungsfehler auftreten, der mit der Zeit sichtbar wird. Gleitkommazahlen sind ja nicht beliebig genau und wenn man damit rechnet summieren sich die Fehler manchmal schnell auf.

Dafür spricht auch, dass bei 2 Hz die Effekte synchron bleiben. Hier lässt sich der Kehrwert ohne Rundungsfehler bilden.

Anhänge

1. Beispielprojekt mit zwei Cuelisten sowie einem Softdesk, um den BPM Wert zu prüfen.
2. DMX Ausgabe während die Effekte synchron sind
3. DMX Ausgabe während die Effekte nicht mehr synchron sind

Wenn ich mich in der Graphenansicht befinde, sollte die Menüleiste zum Hinzufügen von Bank, CS usw ausgeblendet werden. Stattdesseb sollte eine Menüleiste eingeblendet werden, die die Elemente enthält, die bei einem Rechtsklick im Graphen erscheinen. U.A. (und das finde ich besonders wichtig) der ADD Nodes-Befehl. Dieser ist mir etwas zu versteckt nur über den Rechtsklick erreichbar.

Im Network Explorer gibt es bereits das Icon für Autoposition. Dieser Button sollte genauso wie ein neuer Button für “Show the whole graph” in der Menüleiste der Graphenansicht mit aufgenommen werden, da beide Funktionen aktuell nur über das Kontextmenü zu erreichen sind.

Nachdem ich mir den dritten Blocks meines Live-Tutorial “Clubshow mit DMXControl 3” nochmal angesehen habe, ist mir erst bewusst geworden, wie häufig ich eigentlich in die Properties eines Nodes springe, um dort die Zuordnung einer Cuelist, eines Masters etc. zu ändern. Diese Änderung ist immer mit vergleichsweise vielen Mausklicks verbunden:

• Einem Doppelklick (2) zum Öffnen der Properties (egal ob das Node ausgewählt ist oder nicht) oder drei Klicks, wenn man über das Kontextmenü geht.
• Zwei Klicks (3 und 4), um den Auswahldialog zu Öffnen.
• Ein Klick (5) zur Auswahl des neuen Objekts.
• Zwei Klicks (6 und 7) um beide Dialoge mit OK zu schließen.

Diese Tätigkeit kommt immer dann zum Tragen, wenn man eben ein vorhandenes Connectionset vervielfältigt und die Kopien entsprechend anpasst. Aus diesem Grund wünsche ich mir eine Möglichkeit, insbesondere bei den Wrapper-Nodes die Zuordnung eines Objekts wie Cuelist, Master, Executor nach der Auswahl des Nodes in der Graphenansicht direkt vornehmen zu können, ohne hierzu in die Properties springen zu müssen. Ideal wäre hier folgender Ablauf:

• Ein Klick (1) zum Auswählen des entsprechenden Nodes.
• Ein Klick (2) zum Aufrufen der Liste der verfügbaren Cuelists, Master etc.
• Ein Klick (3) zum direkten Ändern der Zuordnung ohne weitere Bestätigung.

In meinem Live-Tutorial “Clubshow mit DMXControl 3” habe ich mir Connectionsets mit einem Button inkl. entsprechendem Feedback gebaut. Aktuell muss ich bei der Anpassung der Kopie dieses Connectionsets für die Nutzung des Button 2 hier sowohl den Button 2 auf der Inputseite als auch auf der Outputseite per Drag&Drop ersetzen.

Um die Anpassung einer Kopie eines Connectionsets weiter zu beschleunigen, wünsche ich mir eine Möglichkeit, den Input und Output eines Buttons, Sliders etc. in einem Rutsch ersetzen zu können - gerade unter dem Gesichtspunkt, wenn diese in einem Connectionset mehrfach verwendet wurden.

Leider werden die Einstellungen des Audio-Analysers, also eingestellte Soundkarte, Level Correction, Number of Bands nicht gespeichert, so das sie nach jedem Neustart vom DMXControl wieder erneut ausgewählt werden müssen.

Fehlerbeschreibung

Beim klonen wird immer nur eine Klon erstellt. Das nervt bei z.B. 32 Connections ziemlich ;) Also als neues Feature im Context-Menü bei Rechtsklick auf CS “Clone multiple” und dann in einem PopUp-Fenster die Auswahl, wie viele CS erstellt werden sollen.

Moin,
wenn man im Connectionset etwas rausgezoomt hat, um die verbindungen besser zu sehen, kann es manschmal schwer sein die Verbindung zu sehen.

Gruß
Max

In den GUI-Einstellungen gibt es die Wahl zwischen zwei Themes.

Deutsch: Standard/Dunkel
Englisch: Default/Dark

Mein Änderungswunsch:

Deutsch: Hell/Dunkel
Englisch: Light/Dark

Warum?: Ist Standard/Default ist nicht selbsterklärend, außerdem folgt die Benennung keinem klaren Muster. Führt zudem zu mehr Klarheit, sollten irgendwann noch mehr Themes dazu kommen (Stichwort Barriefreiheit, High Contrast).

Bei Menübar “Einstellungen\Einstellungen” zurücksetzen “Settings\Reset Settings” öffnet sich ein Pop-Up Fenster zum Bestätigen der Aktion. Dieses lässt sich nicht durch ESC schließen.

Matrix-Filter sollten eine Index-Property erhalten, die das selbe macht wie bei einer Gobo-Index Funktion. Sprich die Ausrichtung von Matrix-Filtern soll entsprechend rotiert werden können. Wenn das zu aufwändig ist, sollte zumindest in einem ersten Schritt eine Drehung in 45 / 90° Schritten möglich sein.

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.

Es gibt ja Matrixfilter, die gerichtet (Bewegung in eine Richtung) und ungerichtet (keine Bewegung / Bewegung um zentralen Punkt herum) sind. Die gerichteten Matrix-Filter haben aktuell keine einheitliche Ausrichtung. Dies sollte korrigiert werden, damit alle Filter in eine Richtung gehen. Es würde sich anbieten, dass alle Matrix-Filter in DMXControl 3 von rechts nach links gehen. Dies ist am Text-Filter orientiert. Dann hat man auch eine einheitliche Ausrichtung für FS#4440.