Bugtracker DMXControl 3

Hab eine Cueliste im PlayMode Random mit folgenden Cues:

Number; Trigger; Name
0       Go      "Flash White Device 1"
1       Follow  "Flash White Device 1 Release"
2       Go      "Flash White Device 2"
3       Follow  "Flash White Device 2 Release"
4       Go      "Flash White Device 3"
5       Follow  "Flash White Device 3 Release"
6       Go      "Flash White Device 4"
7       Follow  "Flash White Device 4 Release"
8       Go      "Flash White Device 5"
9       Follow  "Flash White Device 5 Release"
10      Go      "Flash White Device 6"
11      Follow  "Flash White Device 6 Release"
12      Go      "Flash White Device 7"
13      Follow  "Flash White Device 7 Release"
...
XX      Go      "Flash White Device Y"
XX +1   Follow  "Flash White Device Y Release"

Ich möchte das bei jedem Go eine Random Cue mit Number%2==0 getriggert wird. (0,2,4,6,8,10,12)

Der ColorChaser zeig bei mir ein merkwürdiges Verhalten, wenn ich den PlayMode auf Random setze und Use Device Index auf false.
Beim Wechsel der Farben entsteht immer ein merkwürdiges Flackern. Das ist live und auch in der StageView zu sehen.
Ich hab zur Demonstration mal ein Beispielprojetkt angehangen. In dem Projekt ist eine Cuelist angelegt.
Die erste Cue läuft ohne Probleme, bei der zweiten tritt dieses Flackern auf.
Der einzigste Unterschied ist: bei der Ersten Cue ist Use Device Index = True und bei der Zweiten ist es False

Für den fall der fälle, das sich eine Resource ändert, muss es eine möglichkeit geben die verwender der Resource zu informieren, das sich die Resource, die sie verwenden geändert hat.

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

Fehlerbeschreibung

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.

Aktuell werden die Zeiten beim Trapezoid-Effekt für alle vier Segmente (Fade up, Top, Fade down, Bottom) als absolute Zeitwerte eingegeben. Dies macht die Nutzung von Speedmastern an dieser Stelle unübersichtlich, weil ich in jedem der vier Parameter mit den Speedmastern rechnen muss. Und das teilweise doppelt, da ich zum einen erst die Gesamtgeschwindigkeit reduzieren und dann noch den Wert für die vier Parameter anpassen muss.

Um hier eine effektivere Nutzung des Speedmasters oder auch die einfachere Festlegung der Gesamtwiederholdauer zu ermöglichen, würde ich mir folgende zusätzliche Parameter im Trapezoid-Effekt wünschen:

• Neuer Parameter zur Umschaltung zwischen den absoluten Zeitanteilen in Millisekunden und den relativen Zeitanteilen in % oder 0 bis 1 für die Dauer der vier Segmente. Je nach Einstellung dieses Parameters werden die vier Parameter umgeschaltet.
• Im Falle der Wahl des Parameters “relative Zeitanteile” erscheint der neue Parameter Dauer (Duration), in dem die Gesamtdauer eines Durchlaufs angegeben wird, wo wie eingangs gesagt auch der Speedmaster zum Einsatz kommen kann.
• Parameter zum Festlegen des Bezugspunkts für den Takt. Aktuell liegt dieser Punkt fest beim Beginn des Fade Ups. Grundsätzlich lässt sich dieser Punkt zwar über den Offset-Parameter verschieben, aber spätestens bei ungleichen Dauern der vier Segmente muss man zu einem Taschenrechner greifen, um genau den Punkt “Ende Pause Top” zu bestimmen.

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

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.

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.

Im Softdesk funktionieren Kopieren, EInfügen und Ausschneiden nicht über den Rechtsklick

Alpha4

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.

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

Fehlerbeschreibung

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.

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.

Mit 10x DMH-160 MK2 getestet.
Die Geräte haben nur ein Colorwheel.

Wenn ich unten im ColorControl bei Colorwheel eine farbe wähle wird im DeviceControl das ColorProperty gesetzt, das ColorwheelProperty beleibt auf White.
Die DMX-Ausgabe stimmt aber

nicht vorhanden

Zur Zeit werden die Konfigurationsdaten im Standard-Verzeichnis unter

C:\Users\[User]\AppData\Roaming\DMXControl Projects e.V\

grundsätzlich ohne jeden Bezug zu einer Programm-Version abgelegt, welches (seit je her)

DMXControl

heißt - möglicherweise, weil es zu Zeiten von DMXControl 2 ähnlich war. Dies birgt aber den Nachteil, dass man nach dem Starten einer neueren Version nicht mehr ohne weiteres auf ältere Version zurückgehen kann. Einige Konfigurationsdaten werden verändert und sind dann nur noch für die neue Version verständlich. Zwar kann man hier mit Hilfe der Umgebungsvariablen aushelfen, jedoch ist fraglich, wie häufig von dieser Gelegenheit gebraucht gemacht wird.

Aus diesem Grund schlage ich vor, eine Unterscheidung nach Minor-Versionen von DMXControl 3 zu implementieren und die Konfigurationsdaten in den Verzeichnissen wie folgt aufzuteilen:

• DMXControl (alle Versionen bis einschließlich 3.2.x)
• DMXControl 3.3
• DMXControl 3.4
• …

Bei der Installation einer jeweils neueren Version fragt der Installer ab, ob die bestehenden Konfigurationsdaten übernommen werden sollen. Das Verzeichnis der UserDevices wird grundsätzlich kopiert, sollte das Verzeichnis noch nicht existieren.

Wie im Livechat am 19.1. diskutiert fände ich gut wenn es ein Grouphandling gäbe mit dem ich Geräte in einer Gruppe als ein Gerät betrachten kann und gleichzeitig in der “Hauptgruppe” auch einzelne Geräte haben kann. Siehe auch mein Kommentar in ( FS#674 ).

Möchte ich den One Shot Trigger nutzen und füge diesen entsprechend der “Vorgaben” in eine Cuelist ein, funktioniert dieser erst nach dem erneuten Laden des Projekts. Erstelle ich eine neue Szene (egal ob komplett neu oder eine Kopie) mit dem Trigger einer Cuelist hinzu und führe die Cuelist im Anschluss direkt aus, werden die Cues übersprungen. Offenbar überprüft der Trigger nicht die aktuellen Parameter des vorausgehenden Effekts, sobald die Cuelist gestartet wird.

Die einfache Reproduktionsanleitung:

• Beliebigen Effekt wie Chaser oder Triangle auf den Dimmer eine Device Group legen und als Cue in einer neuen Cuelist abspeichern. Trigger ist follow, alle anderen Zeiten 0ms.
• Dummy-Cue mit One Shot Trigger einfügen. Wiederholung beliebig setzen, alle anderen Zeiten auf 0ms.
• Proforma eine dritte Cue zum Beispiel Dimmer 100%, Farbe blau einfügen. Trigger “follow”, Trigger Value 1s, Fade 0ms, Delay 0>5s.
• Cuelist abspielen. ⇒ Ergebnis: man sieht nichts. Auch die letzte Cue “Full on” wird nicht (mehr) vollständig ausgeführt, sofern die Cuelist auf “Release when last cue ends” gesetzt ist.
• Projekt speichern, schließen und erneut laden.
• Cuelist wieder abspielen. ⇒ Ergebnis: Trigger arbeitet wie erwartet und man kann ihn dann auch beliebig verändern. Die letzte Cue wird ausgeführt.

Da es keinerlei Einträge für den Zeitraum gibt, in dem ich dieses Projekt gebaut habe, füge ich keine Logfiles bei. Zur Reproduktion des Fehlers kann das beigefügte Projekt verwendet werden, indem man aus der existierenden Cuelist die Cue mit dem Effekt und die Cue mit One Shot Trigger kopiert und erneut einfügt. Alternativ einfach die Zeiten des Effekts ändern.

Ich habe festgestellt, dass der Parameter “Play Mode” des Color Chasers sich ausschließlich auf die Wiedergabereihenfolge der zugeordneten Color List bezieht. Ich habe bei aktiviertem “Use Device Index” aber keine Möglichkeit, eben diesen zu beeeinflussen. Egal ob Play Mode “Normal”, “Bounce” oder “Reverse”: die optische Laufrichtung des Color Chasers bleibt immer die selbe.

Daher wünsche ich mir für den Color Chaser im Endeffekt alle Parameter zusätzlich, die in den neuen Chaser Einzug erhalten haben:

• Fade Curve
• Break Steps
• Break Time
• Size
• Step Size
• Play Direction (Play Mode für Device Index)

Hinter dem Parameter Play Direction versteckt sich zum einen eben die bis dato fehlende Ansteuerung des Device Index, zum anderen aber auch die bereits für den einfachen Chaser implementierten Play Modes inklusive der Möglichkeit, per csv-Datei weitere eigene zu hinterlegen. Wenn ich dies richtig überblicke, können die Play Modes des neuen Chasers 1:1 auf den Color Chaser zur Ansteuerung des Device Index übertragen werdem.

Durch dieses Update könnte es eventuell sein, dass der bis dato vorhandene Parameter “Index Offset” überflüssig wird, weil er in einer der neuen aus dem neuen Chaser übergeht.

Stand heute gibt es beim PWM Static nur die Möglichkeit, eine Gruppe von Geräten entsprechend der Position des zugeordneten Parameter Masters “aufzufüllen”. An dieser Stelle wünsche ich mir die Möglichkeit, eine feste Anzahl von Geräten (zum Beispiel 3) mittels des Parameter Masters innerhalb der Gerätegruppe hin- und herzuschieben. Beim Minimal- bzw. Maximalwert des Parameter Masters leuchten dann immer drei Geräte am entsprechend korrespondierenden Ende der Gerätegruppe. Bei 50% würden in der Mitte vier Geräte leuchten (die beiden mittleren mit 100%, die äußeren mit je 50% leuchten), wenn Fade auf True gesetzt ist und die Gruppe eine gerade Anzahl von Geräten umfasst.

Hierzu bedarf es neben dem zusätzlichen Parameter für “Size” auch einen weiteren Eintrag für den Parameter “Direction”, der beispielsweise “Group” lauten könnte. In diesem Zusammenhang wäre zu überlegen, ob nicht eine Umbenennung des Parameters “Direction” in “Play Mode” erfolgt.

Im dynamischen PWM-Effekt müssen diese Ergänzungen nicht vorgenommen werden, weil sich dieses Szenario mit dem neuen Chaser abbilden lässt, sofern der Effekt eben automatisch laufen soll.

Beim Verfassen des Tickets FS#4759 ist mir aufgefallen, dass der neue Chaser um vier weitere Play Modes erweitert werden kann:

• Fill from left (>)
• Fill from right (<)
• Fill from center (<>)
• Fill to center (><)

Diese vier zusätzlichen Play Modes stammen aus dem dynamischen PWM-Effekt. Aus meiner Sicht sind diese vier anderen Play Modes der einzige Unterschied, der zwischen dem neuen Chaser und dem dynamischen PWM-Effekt existiert. Von daher würde ich in diesem Zusammenhang vorschlagen, den dynamischen PWM-Effekt nach der Übernahme der oben genannten Play Modes in den neuen Chaser zu entfernen.

Im Zuge der Freischaltung der Funktion “Gruppen in Gruppen” (siehe  FS#674 ) soll das Group Handling dahingehend erweitert werden, dass

• eine nachvollziehbare Ansteuerung auch über n Ebenen möglich ist und dabei nicht für jeden Anwendungsfall eine neue Gruppe angelegt werden muss
• ggf. auf unterschiedlichen Ebenen ein unterschiedliches Group Handling ausgewählt werden kann
• das Group Handling weitere Funktionen anbietet

Das beigefügte Projekt soll einen exemplarischen Aufbau zeigen, bei dem die Ansteuerung der insgesamt 100 Beam-MHs und 12 Spot-MHs am Ende durch ein verbessertes und erweitertes Group Handling deutlich variantenreicher erfolgen soll, ohne zusätzliche Gruppen anliegen zu müssen. Insgesamt gibt es bis zur Device-Ebene drei Gruppen-Ebenen. Folgende Szenarien sollten exemplarisch anhand eines Lauflichts einfach darstellbar sein, wobei sich diese Liste ggf. bei weiteren Überlegungen noch beliebig weiterspinnen lässt:
* Lauflicht innerhalb eine gesamte Zeile über die 25 Spalten hinweg (25 Geräte, Laufrichtung links rechts), egal ob nur bezogen auf eine Zeile oder ein paralleles Lauflicht über alle fünf Zeilen
* Lauflicht innerhalb eines Blocks, beginnend oben links, endend unten rechts
* Lauflicht über die fünf / sechs Zeilen hinweg (Laufrichtung oben unten), egal ob nur bezogen auf eine Spalte oder parallel auf allen 20 Spalten
* Lauflicht über alle 24 Einzel-Zeilen, wo immer fünf bzw. drei Geräte gemeinsam ein- und ausgeschaltet werden
* Lauflicht über die vier Blöcke, wo immer 28 Geräte gemeinsam ein- und ausgeschaltet werden
* Gegenläufige Lauflichter aus der oberen Gruppe heraus, wo Zeilen 1, 3 und 5 links-rechts und Zeilen 2 und 4 rechts-links wiedergegeben werden

Hallo Zusammen,
wie im Stream von euch angeboten das Tickes zu einem Zusätzlichen Effekt wie Sparkle.

Unter Wave/ Lauflicht (Chaser/PWM) verstehe ich einen Effekt der auf der Farbe liegt und diese beeinflusst.

Erstmal die Attribute:

• Fade-In Time (ms): Zeit wie lange der Farbwechsel beim einfaden dauert

• On Time (ms): Zeit wie lange die Farbe gehalten wird

• Fade-Out Time (ms): Zeit wie lange der Farbwechsel beim ausfaden dauert

• Duration (ms): Zeit zwischen dem Start der ersten Lampe und dem Start der nächsten Lampe, Idealerweise mit dem „Speed master“ steuerbar, wird nicht von Fade-In Time beeinflusst

• Run: bei loop, der Durchlauf wird wiederholt, bei single, wird nurch einmal durchgelaufen

• Revers: bei nein, ablauf der Schritte hochzählend (1-2-3-4), bei ja, ablauf der Schritte Rückwärts (4-3-2-1)

• Ping-Pong: nein, der Ablauf beginnt wieder von Vorne (1-2-3-4|1-2-3-4|1-2-3-4|…), bei ja läuft der Ablauf einmal Vorwärts und danach rückwärts und dann wieder vorwärts usw. (1-2-3-4-3-2-1-2-3-4)

Revers und Ping-Pong sind ähnlich dem Play Mode im Chaser

Ablauf:
Start bei Beginn der Gruppe
1: X|0|0|0
2: 0|X|0|0
3: 0|0|X|0
4: 0|0|0|X

Start Mittig der Gruppe
1: 0|0|0|X|X|0|0|0 / 0|0|0|X|0|0|0
2: 0|0|X|0|0|X|0|0 / 0|0|X|0|X|0|0
3: 0|X|0|0|0|0|X|0 / 0|X|0|0|0|X|0
4: X|0|0|0|0|0|0|X / X|0|0|0|0|0|X

Bei “Beginn der Gruppe” wurden weniger Lampen gewählt als bei “Mittig der Gruppe”, damit die Anzahl der Schritte gleich sind.

Wenn das Lauflicht sich einholt, dann soll wieder vom aktuellen Punkt wieder Einfaden, hier würden sich die Zeitkurven einer Lampe überlagern, ähnlich der Zeitkurve im Bild 010.png zu sehen. Blau ist der erste Durchlauf, grün der zweite Durchlauf und rot sich der ergebene Ablauf. Falls der überschneidende Bereich nicht existiert, dann bleibt die eingestellte Farbe gleich und der Lampe fehlt Zeit zurück zufaden.

Wenn sich zwei verschiedene Lauflichter sich überlagern, soll vom jetzigen Zeitpunkt, vom ersten Lauflicht in das zweite hineingefadet werden, ähnlich Bild 020.png

Das fanning der Farbe könnte sich nicht auf den Beginn der Grupe bis Ande der Gruppe legen, sondern Beginn des Lauflichtes Schitt 1 bis zum letzten Schritt

Gruß
Max

Edit 1: genauere Beschreibung ergänzt

Following discussion with JP on the forum, I’m posting this feature request here.

It would be useful to be able to achieve the following effect using the chaser effects:

https://vimeo.com/676900437/6d03543b2e

JP suggested this could be implemented as a ‘Fill’ option on the chasers.

As an example using the Colour chaser, the chaser should change the colour of each device to the next colour on the colour list, in selection order, until all devices have been changed, and then repeat with the next colour on the list.

This should work in combination with the play mode to set the direction that the fill happens in - forward, reverse, bounce or random.

This could also work with the standard chaser to apply the fill effect to dimmer intensity.

s.o. (Reminder für JPK, siehe Projekt SpeedMaster Slider Beispiel)

Zum aufräumen im SpeedMaster

Wenn ich bei einem Executor die Auto Start / Stop Funktion verwende, funktioniert das automatische starten immer mal wieder nicht. Sobald ich den Fader auf null und direkt danach wieder hoch ziehe, startet die Cuelist nicht.

Hällt alle daten cuelists exexutoren, alles und ist im project umschaltbar und kann usern zugeordnet werden

Eine Cueliste die den i halt einer anderen Cueliste 1 zu eins als refferenz übernimmt, aber seperat ausgeführt werden kann

Selection Grid siehe MA
Als Diskussionsgrundlage

S.o.

s.o.

Ich habe meiner DMX-Ausgabe weitere Art-Net-Interfaces hinzugefügt, sodass ich nun insgesamt 4 Instanzen habe. Diese wurden aber nun “frei Schnauze” in die Liste einsortiert, sodass meine Liste nun wie im beigefügten Screenshot aussieht. Hier sollte bitte nach Möglichkeit automatisch immer einer Sortierung der Einträge auf Basis des Herstellers, dann des Modells und dann der Serien-Nummer erfolgen, weil man sich sonst gerade im Fall der Art-Net-Konfiguration im Kreis dreht, wenn die später hinzugefügte Instanz mitten in der Liste eingefügt wird.

Das Ändern der Reihenfolge der Instanzen in der Config-Datei “DMXInterfaceMgmtConfig.xml” hat leider nicht ausgereicht, um die Darstellung in der GUI entsprechend zu beeinflussen.

Ein Lauflicht im Außenkreis wobei der erste Pixel immer der hellste ist und dahinter immer dunkler sind:
https://ak.picdn.net/shutterstock/videos/1034400863/thumb/5.jpg?ip=x480

“Linienscanner” - Ein Senkrechter Strich, der von links nach rechts durchwandert. Der Strich kann im Winkel gedreht werden, sodass bei 90° der Strich waagerecht von oben nach unten durchläuft

Es wäre cool, wenn man mit den Colormastern irgendwie die Radix Pixel ansteuern könnte. Z.b. im Radix Popup die Möglichkeit schaffen für Color 1 und Color 2 einen Colormaster auswählen zu können.
Alternativ nen Filter bauen, wo man zwei CM als Farbe eintragen kann und der dann die Ringe alternierend mit einer Farbe ausfüllt.

Im beigefügten Projekt habe ich in der Cue 1 der Cuelist 1 einen Chaser auf die Gerätegruppe (Device Group) gelegt. Ändere ich nun die Sortierung der Geräte in dieser Gerätegruppe über das Kontextmenü und sortiere sie zum Beispiel zufällig, wird der Chaser trotz Play Mode “Normal” beim erneuten Starten der Cuelist nicht aktualisiert. Aktuell kann ich die Sortierung nur per Drag ‘n’ Drop oder über die Buttons Up und Down ändern. Über letzte habe ich die zur Zeit aktive Reihenfolge realisiert: 1 - 4, 13 - 16, 5 - 12.

Regelmäßig unregelmäßig kam es in bei mir im York vor, dass ein Tastendruck im Softdesk teilweise mit mehreren Sekunden Verzögerung umgesetzt werden. Dieses Problem kommt und geht über den Abend, ohne dass nicht explizit Änderungen am ausgeführten Projekt durchgeführt werden.

@patme hat in der heutigen Beta-Testerrunde berichtet, dass ihm dieses Problem bei einem seiner letzten Langzeit-Testläufe mit DMXControl 3.3.0 Beta 2 ebenfalls unter die Finger gekommen ist.

Ich baue mir aktuell mehrere Cuelists mit einer höheren Priorität, bei ich laufende Cuelists gezielt für folgende Lichtstimmungen überschreibe:

• Moderationslicht
• Einmarsch
• Siegerehrung
• Spiegelkugel-Ambiente

In allen Fällen nutze ich für die jeweiligen Lichtstimmungen meist die gleichen Geräte, die sonst auch für die allgemeine Show mitlaufen. Habe ich nun solche Mehrfachverwendungen, muss ich aktuell immer manuell dafür sorgen, dass ich in den zugehörigen Cuelists zum Beispiel die Gobos und Prismen herausnehme oder den Strobe gezielt auf 0 setze, wenn ich eine “saubere” Ausgabe haben möchte. Sprich: auch wenn ich einen Strobe-Effekt abfeuere, soll das Gerät für das Moderationslicht nicht mit stroben. Dies wird insbesondere bei Moving Heads mit ein paar mehr Funktionen immer aufwendig.

Um die Programmierung zu vereinfachen, würde ich mir eine Möglichkeit wünschen, bei der ich gezielt festlegen kann, dass für in der Cuelist nicht verwendete Funktionen automatisch die Grundwerte von den verwendeten Geräten herangezogen werden. So müsste ich dann für das Spiegelkugel-Ambiente nur Dimmer, Position, Farbe und Iris festlegen. Andere Funktionen wie Gobo oder Prisma werden beim Starten auf die Werte gesetzt, die die Geräte als Default einnehmen (Gobo offen, kein Prisma, kein Strobe).

Fehlerbeschreibung

{ParameterMaster 1:*360/COUNT*(COUNT-1)}

Erwartetes Verhalten

Hinweise

Wie bereits im Forum mit @JPK besprochen (https://forum.dmxcontrol-projects.org/index.php?thread/16686-probleme-bei-benutzung-berechneter-phase) wäre es praktisch eine Konstante zu haben, die den (Phasen-)Winkel zwischen den Geräten einer Gruppe angibt. Um das umzusetzen müssten folgende Punkte implementiert werden:

* Erlauben von Berechnungen im Device Control
* Einführung der Konstante DEVICEANGLE (wäre wohl als 360/AnzahlAnGeräten zu definieren?)

Normalerweise ist der Kernel ab DMXControl 3.3.0 versteckt beim Start. So sieht man allerdings Fehler nicht mehr direkt, sollten diese im Kernel (oder im Umbra) auftauchen. Solche Fehler sollten zwar nicht so häufig auftreten. Wenn es passiert, sollte ein User in der GUI darüber informiert werden. Allerdings ist es sehr nervig, wenn während der Show ein Fehler auftritt und dann ein Popup / eine Message hochpopt. Daher sollte dafür ein Icon unten rechts als Ausrufezeichen in rot erscheinen, und beim Draufklicken sollte eine Info kommen, wo Fehler aufgetreten sind (nur dass und nicht welche). Man kann vielleicht noch eine “Show Kernel” oder “Show Umbra” Funktion anbieten. Aber das nur optional, wenn das einfach möglich ist

Bisher können schon verschiedene Layouts in einem Projekt gespeichert werden. Allerdings ist es noch nicht möglich, eines der Layouts als Startup-Layout für ein Projekt zu definieren. Es sollte eine Einstellungsmöglichkeit geben, in der man auswählen kann, ob ein spezifisches Layout geladen werden soll oder das zuletzt verwendete. Für ersteres muss dann auch noch ein Handling für nicht mehr existierende Layouts implementiert werden. Siehe dazu auch: https://youtu.be/aXtpf6tv3Cw?t=8542

Es gibt ja aktuell in der 3.3 die Makros, was im Grunde nichts anderes als interne Variablen sind um vom Executor aus ins IA zu kommen.

Die Funktion die ich gerne hätte wäre eine andere Art von Makro.

Ich würde mir wünschen, wenn man Makros aufzeichnen kann, um über einen Knopf mehrere Executoren gleichzeitig abfeuern zu können. Wie das hier in der Software für die Blackmagic Switcher gezeigt wird:

https://youtu.be/ka3hXE30Imk

Auf record drücken, alle Knöpfe einmal drücken die in das Makro rein sollen und dann die Aufzeichnung beenden. Sobald man den Makro Knopf drückt, werden die Executoren in der Reihenfolge gedrückt.

Man könnte noch überlegen ob man timings da noch irgendwie mit einbauen möchte, ist aber glaube gar nicht nötig.

Folgendes Szenario. Man hat eine Palette an Cuelists, Parameter- und Colormaster als Baukastensystem zusammengestellt und möchte damit schnell zwischen verschiedenen Lichtstimmungen umschalten.
Aktuell ist das möglich, indem man Cuelisten baut, die wiederum andere Cuelisten starten, oder man baut im Input Assignment ein aufwändiges CS. Für den Livebetrieb etwas unpraktisch.

Deshalb wäre mir persönlich bei diesem Feature wenn es kommen sollte wichtig, dass man das mit wenigen Handgriffen machen kann.

Werden Executoren gleich benannt werden diese im IA unter einem Element dargestellt, die einzelnen Elemte darin werden einfach doppelt in diesem Element angezeigt. Bild hierzu im Anhang.

Selbes Problem, nur noch schlimmer, entsteht wenn zwei Elemte in einem Softdesk gleich heißen, dann weden diese im IA nur noch als ein Element angezeigt, ich habe also zwei Fader im Softdesk aber im IA nur noch einen. Dies hat zur Folge, dass der eine Fader im IA den Output vom zu erst erstellten Fader im Softdesk bekommt, von dem anderen Fader bekommt man gar keinen Output mehr. Selbes Verhalten tritt auch bei Buttons aus dem Softdesk auf, habe mir nicht die Mühe gemacht alle Elemente zu testen, denke sollte aber ähnlich sein.

Logs sind im Anhang, vllt findet da ja jemand mehr als ich^^

Das Pfeilkreuz (im hellen Theme blau, im dunklen Theme rot), um das Fenster zum Beispiel in die linke Hälfte bzw. rechte Hälfte zu verschieben, erscheint nur auf dem primären Monitor.