Fade Verhalten von Weiß und Amber

We proudly present: The release of DMXControl 3.3.3!


On September 29, 2026, we held our release show for DMXControl 3.3.3. During our usual “hour-long” session, we showed you all the new features in this version and what it now has to offer.
Read all about it in the corresponding news article: We proudly present: The release of DMXControl 3.3.3!


  • Hallo,

    Im Anhang habe ich ein Projekt mit Generic RGBWAUV Geräten. Jedes Gerät habe ich zum Test unterschiedlich in den Einstellungen für den Weiß- und Amber-Kanal konfiguriert.

    Nun habe ich eine Cuelist (Fader) mit verschiedenen Farben gemacht. Bei den Geräten wo Amber als Farbe automatisch mit eingemsicht wird, entstehen kuriose Fade-Übergänge. Beim Übergang von Szene 3 zu 4 (Orange zu Grün) [auch zurück, und mittels goto zu 5/blue und zurück] sieht man im Channel Overview, dass bei den Geräten, bei denen Amber gemsicht wird, Schnellere Fade-Zeiten auftreten. Frage Nr. 1: Wodurch kommt das zustande?


    In unserem Zirkus haben wir leider nicht so viele Geräte, weshalb ich gerne RGB plus W nutzen möchte. Nun habe ich die Einstellung gefunden, dass das Gerät auch dementsprechend verändert werden kann. Jedoch habe ich das Gefühl, dass mir dann das Amber etwas verloren geht.

    Natürlich kann man das auch direkt über das Device Control steuern, ist dann (siehe Übergang Szene 8 auf 9) aber nicht mit der Einstellung, die man über die normale Farbe macht, kompatibel. Bei dem ÜPbergang springe einige Channels auf einen Wert und Faden dann von da aus. Das widerspricht sich meines Erachtens aber mit einem "Fade-Übergang". Frage Nr. 2: Ist der Übergang bei solchen Teilen so gewollt, wird geplant da was zu ändern, oder ist das einfach zu aufwändig das zu beheben?

    Nun habe ich überlegt, ob man nicht die Kanäle für die Farben über das device control mittels Parameter-Mastern machen könnte. Nun kann man zwar über Regler die Farbe-steuern, aber leider nicht den eingestellten Wert speichern (Cuelist ParameterMaster). Frage Nr. 3: Gibt es eine Möglichkeit die Kanäle relativ direkt anzusprechen (ohne direkt ins device control zu müssen) und die Werte zu speichern?


    Ich freue mich sehr über eine Antwort.

    Beste Grüße, Ludwig

  • Jetzt wollte ich nochmal nachhaken, da euer Treffen ja nun vorbei ist.

    Also zu der ersten Frage, kann ich ergänzen das nur der Amber Kanal so schnell ist. Kommt das durch die (etwas kompliziertere als bei Weiß) Mischung aus RGB zustande? Also bei Cue 3 auf 4, wird Amber relativ schnell ausgeblendet, sodass relativ schnell grün erscheint. Danach verändert sich nur das Grün noch etwas.

    (Oh Fehler, Bei Frage 2 meinte ich Übergang Szene 7 zu 8)

    Zur Zweiten Frage: Bei den Geräten, wo ich Weiß automatisch (ersetzend oder dazu) Mische, ist in Cue 7 nur RGB also weiß aktiv. Jetzt wird aber nur Weiß, bzw. Weiß dazu gemischt. In der nächsten Szene habe ich Weiß im Device control extra hochgedreht, sodass auch bei den Geräten, wo nicht weiß gemischt wird, der Kanal aktiv wird. Nun entsteht aber ein seltsames Artefakt, denn beim Übergang wird der Weiß Kanal zunächst auf Null gesetzt (war im Device Control in der vorigen Szene ja Null) und fadet dann wieder hoch. Ist das so gewollt? Oder sollte ich da einen Bug-Eintrag für machen?

    Zu Frage Nr. 3

    Um nun selber die Kanäle relativ direkt ansprechen zu können (und speichern) habe ich überlegt die mit Parameter-Mastern auszustatten und dann auf ein Pult zu legen. Jetzt habe ich aber das Problem, dass ja nur die P.Master gespeichert werden, aber nicht der Wert von denen. Gibt es hierzu eine Möglichkeit dieses Verhalten hinzubekommen?

    (Ich habe mir überlegt ich könnte Dummy-Geräte einfügen mit "normalen Kanälen" und für diese Geräte einen Input im IA auf den Programmer legen, diese Werte in Cues speichern. Im IA dann diese Werte auslesen (DMX-IN oder DMX-Mixer) und diese dann auf den P.Master legen. Der P.Master ist dann auch in der Szene unter dem Gerät gespeichert. Das ganze erschien mir dann aber doch zu aufwändig und ich würde mich eher dafür entscheiden die Funktionalität, nur Amber anzeigen zu können, verlieren [Geräte mir Add White und Amber None, sodass ich Amber doch noch mit ColorTemp einmischen kann])

    Würde mich sehr über Antworten freuen.

    Beste Grüße, Ludwig

  • Hi,

    ich hatte leider bisher noch keine Zeit, dein Projekt anzuschauen. Werde das aber heute Abend machen (wenn ich es nicht vergesse). Dann bekommst du eine ausführlichere Antwort dazu :)

    Viele Grüße

    JP

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Hallo,

    so, ich habe mir dein Projekt mal angeschaut und habe Antworten zu deinen Fragen:

    Zu Frage 1: Tatsächlich sind die Fadezeiten nicht kürzer ;) Auch diese Scheinwerfer blenden in der angegebenen Zeit von Orange nach Grün. Der Grund, warum es anders aussieht ist die Arbeitsweise der Auto-Mischfunktion für Amber. Ich hole jetzt ein klein wenig aus. Im Grunde sind die Farben ja durch die Kanäle R,G und B vollständig bestimmt. Nun haben wir ja aber bei den LEDs keine saubere RGB-Mischung, weshalb das Weiß und auch das Amber (fast) immer komisch aussieht. Daher die zusätzlichen LEDs in diesen Farben. Damit ist aber das Farbsystem überbestimmt, weshalb jetzt DMXControl 3 Mechanismen braucht, um diese LEDs trotzdem sauber anzusteuern. Dieser Mechanismus ist bei Amber ein Trapez (siehe https://wiki-de.dmxcontrol-projects.org/images/DDFCreatorAmberSettings.png). Dieses Trapez bestimmt, bei welcher Farbe im Farbkreis die Amber-LED eingeblendet werden soll und zu wie viel Prozent. Damit lässt ich das Verhalten nun erklären. Während dem Fade auf Grün startet man mit voll eingeblendeter Amber-LED und wechselt dann, weil man über die Rampe an der einen Seite des Trapezes kommt, zur R + G- Ansteuerung. So reduziert sich zwar der Amber-Kanal, aber gleichzeitig erhöhen sich die R und G-Kanäle, bevor dann der R-Kanal wieder sinkt (weil er ja nicht in der Farbe Grün enthalten ist).

    Zu Frage 2: Da konkurrieren zwei Farbsteuerungen in DMXControl 3, die Auto-Mischfunktion und die direkte Farbwahl um den selben DMX-Kanal. Dann gilt in diesem Fall der letzte Wert gewinnt (LTP). Wenn du in Szene 6 Weiß setzt, beginnt die Auto-Mischfunktion damit, auch den W-Kanal anzusteuern und geht auf 100%. Das wird so ausgegeben, weshalb der Kanal entsprechend angesprochen wird. Davon bekommt aber die Ansteuerung im DC (prinzipbedingt) nichts mit. Dort steht immer noch der Wert 0. Da hier keine Änderungen vorgenommen wurden, wird dieser Wert aber halt einfach nicht ausgegeben. Wenn du nun aber in der nächsten Szene die direkte Ansteuerung setzt, dann wird hier der Wert das erste Mal geändert, was dazu führt, dass nun dieser Wert der neuere ist und daher ausgegeben wird. Deshalb springt die Ausgabe hier.

    Zu Frage 3: Du willst den Wert eines ParameterMasters speichern? Das geht tatsächlich mit einem kleinen Trick. Lege einfach einen Generic Dimmer als Dummy-Gerät in irgendein unbenutztes Universum (z.B. auf Kanal 16.1 oder 16.512). Dann gehst du ins Input Assignment und fügst dort in einem neuen Verbindungssatz folgenden Aufbau ein:

    Links ist der DMXC-Mixer mit dem Dummy-Dimmer, rechts der entspechende ParameterMaster. Wichtig dabei ist, dass du im Dreisatz als Max-Wert für den Eingang 100 einstellst. Dann kannst du mit der Helligkeit des Scheinwerfers den ParameterMaster einstellen. Nun hast du aber auch ein Gerät, dessen Helligkeit sich wieder in einer Szene speichern lässt.

    Viele Grüße

    JP

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Vielen Dank!

    So habe ich mir das schon gedacht.

    Ich wollte nicht drängeln, nur nochmal ins Gedächtnis holen, falls die Frage vergessen wurde ;) .

    Zu Frage 2: ist das so gewollt? Oder wird da geplant etwas zu ändern, oder ist das zu aufwendig? Ich kenne die internen Strukturen nicht.

    Wird zuerst der Wert der alten Szene geholt und dann linear mit dem neuen verrechnet? (Sodass nur an einer anderen Stelle der alte Wert geholt werden müsste, oder ist das wesentlich komplizierter)

  • Ich sehe es eher als Bug. Normalerweise würde man sich einen Crossfade von dem Automatischen Wert auf den Manuell eingestellten Wert wünschen. Daher nein, dass soll nicht so sein. Wird sich kurzfristig was ändern? Vermutlich nicht, weil es gemessen an den anderen Baustellen ein kleiner Fehler ist.

    Ich behalte das mal im Hinterkopf, wenn ich da im Code vorbei komme, schaue ich mal wie Aufwendig das ist das zu fixen.

    Das Leben ist NP vollständig!

  • Naja, Frage Nr. 1 kann auch sein, dass du in den Einstellungen der Cuelist eine andere "Goto" Zeit eingestellt hast. Dann wird beim Goto nicht die Cue Fadezeit genommen, sondern eine fixe Goto Zeit. Hab nicht in das Projekt geschaut, fällt mir nur gerade so ein.

    Das Leben ist NP vollständig!

  • Ich dachte nur wenn der den Übergang von Amber/Weiß Kanal beim fade aus dem gespeicherten Wert der letzten und der nächsten Cuelist linear berechnet wird, dürfte das Verhalten (das JPK erklärt hat) so nicht eintreten. Daher ist meine Annahme wohl falsch, dass so der Fade-Übergang programmiert ist. Es scheint vielmehr so zu sein, dass der Amber-wert in jedem Schritt beim Übergang neu aus den RGB- Werten berechnet wird.

    Ja, Goto Zeit ist was anderes.. Aber dazu fällt mir gleich eine Frage ein: Werden die Werte im Cue Timing Editor bei Goto und GoBack auch in irgeneiner Weise berücksichtigt?

  • Ich dachte nur wenn der den Übergang von Amber/Weiß Kanal beim fade aus dem gespeicherten Wert der letzten und der nächsten Cuelist linear berechnet wird, dürfte das Verhalten (das JPK erklärt hat) so nicht eintreten. Daher ist meine Annahme wohl falsch, dass so der Fade-Übergang programmiert ist. Es scheint vielmehr so zu sein, dass der Amber-wert in jedem Schritt beim Übergang neu aus den RGB- Werten berechnet wird.

    Naja, der Fade-Übergang ist linear von der aktuellen Ausgabe hin zum neuen Wert. Aber es gibt eben zwei konkurrierende Ansteuerungen, die Auto-Mischfunktion, die tatsächlich den Amber-Wert aus den RGB-Werten berechnet und die direkte Ansteuerung des Amber-Kanals. Da beide nichts von einander wissen, kommt es eben zu dem Sprung. Das ist genauso, wie wenn du mit zwei Cuelists die Farbe des gleichen Scheinwerfers setzt (und einstellst, dass LTP auf Basis der gestarteten Cues arbeitet). Da kommt dann immer die Cuelist durch, die zuletzt eine Cue gestartet hat. Bei dem Amber-Wert ist es ähnlich. Die Ansteuerungsweise, die zuletzt einen Wert geliefert hat, gibt diesen auch aus.

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Ich meinte nur, dass in jedem Fade-Schritt der Amber Kanal neu gemischt wird, und nicht (bei Auto-Mischfunktion) der Amber-Kanal selber als linear betrachtet wird. Tschuldige, wenn ich da nicht deutlich genug gewesen bin.

    Besten Dank für eure Antworten! :thumbup:

  • Newly created posts will remain inaccessible for others until approved by a moderator. The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.