Bugtracker DMXControl 3

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

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.

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.

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.

Fehlerbeschreibung

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

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

Project laden,
SoftDesk Öffnen
MacroBoardProfil öffnen
Converter-Effecct auf die Matrix in der StatgeView legen und warten bis es knallt

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.

I have a simple preset (dimmer and colour values for LED Pars), and this preset is used in a number of cues. When I ‘Edit in programmer’ the preset, change the colour values and then ‘Update’ the preset, the next time I go to play the cuelist the cues won’t play and a series of error reports appear in the kernel output. I’m also unable to save the project after this.

I can’t see a way to attach a log file to this report, but here’s a Dropbox link to the log zip file: https://www.dropbox.com/s/i6we4ho0szycprv/DMXControl3Logs_2022430_213811.zip?dl=0

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?)

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

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.

Aktuell kann man ja jederzeit ein neues / anderes Projekt laden, was “ohne Rücksicht auf Verluste” so auch ausgeführt wird. Dem entsprechend können andere Projekte auch geöffnet werden, wenn eine Show, sprich eine Cuelist läuft.

Um hier ggf. das Bewusstsein zu schärfen, dass entweder sowohl mindestens eine Cuelist aktiv ist oder auch aktuell Werte im Programmer enthalten sind, könnte an dieser Stelle eine Rückfrage hilfreich sein. Diese Rückfrage taucht unter den zuvor genannten Kriterien auf, sobald man ein neues / anderes Projekt laden möchte.

Folgender Test-Aufbau:
Softdesk, Colorbar mit Colormaster verdrahtet.
Colormaster mittels “Bitmap from Color” auf Button visualisert. Funktioniert wie erwartet. Lade ich das Projekt neu ist der Button wieder grau, der Colormaster hat weiterhin die zuvor eingestellte Farbe. Gleiches Verhalten wenn die Colorbar in “Bitmap from Color” verschaltet wird. In der 3.2.3. funktioniert dies noch einwandfrei.

Lege ich zum Beispiel den Sparkle-Effekt auf die Farbe, kann ich pro Effekt immer nur eine Farbe bestimmen, mit der der Effekt arbeiten soll. Möchte ich ich mit mehreren Farben arbeiten, muss ich hierzu mehrere Effekte hinzufügen und diese jeweils einzeln parametrieren.

Um dies zu vereinfachen, könnte es an vielen sinnvoll sein, hier mit einer Color List zu arbeiten. Die gewählte Color List übergibt dann mehrere Farben an den Effekt.

Hallo,
bei mir funktioniert der One Shoot Trigger nicht. Ich beginne mit einem Lauflicht über 8 RGB PARs. Danach folgt die Cue mit dem One Shoot Trigger, gefolgt von einer Cue, die die PARs auf eine Farbe einfadet.
Wenn ich die List starte, wird die One Shoot Cue sofort auf gelb gesetzt und das Einfaden beginnt. Währenddessen kann man sehen, dass das Lauflicht läuft bis es von der dritten Cue überschrieben ist.
Es gibt keine Fehlermeldung, weswegen ich auch keine Screenshots beisteuern kann. Ich habe lediglich das letzte Log File und das Projekt zum Anhängen.

Gruß, Herbert

P.S.: Sorry, die untenstehende Verknüpfung war ein Versehen. Ich dachte hier fügt man Verknüpfungen zu anderen Trackern ein, und jetzt kann ich sie nicht mehr löschen

So, wie aktuell Projekte grün markiert werden, wenn sie geladen sind, sollte auch die geladene Version grün markiert werden, damit man dies direkt sieht.

Beim erfolgreichen Laden eines Projekts erscheint irgendwann eine Abfrage, ob das letzte Layout geladen werden soll. Zukünftig sollte diese Abfrage ein Dropdown umfassen, in dem alle im Projekt enthaltenen Layouts aufgeführt sind. Hier sollte das zuletzt geladene Layout vorausgewählt sein. Es sollte auch eine Möglichkeit geben, das Laden des Layouts abzubrechen. In Hinblick auf FS#4954 (was im Zuge dieser Integration auch umgesetzt werden kann) wäre gut, wenn es drei Optionen gäbe:

• Jedes Mal nachfragen (Ask) (Standardmäßig eingestellt)
• Immer das letzte Layout laden (Load always last Layout)
• Immer “Layout xyz” laden (Load always “Layout xyz”)
• Kein Layout laden (No Default Layout)

Die Abfrage kommt nur im ersten Fall hoch.