Bugtracker DMXControl 3

Das ist aber auch schon in der 3.2.2 so. Und die Aussage hierzu war, dass die HAL die Farbe bestimmt und diese Informationen soweit nicht ins Device Control zurückfließen soll(t)en. Ursprünglicher Aufhänger waren da die RGB+-Farben, aber für das Farbrad ist das in dem Sinne vergleichbar.

Das Problem wäre: Wenn man das nicht so macht, und eine Mischung aus MHs und z.B. RGB PARs markiert dann würden die RGB PARs aus bleiben, weil die ja kein Farbrad haben. Daher wird die "Farbe" übertragen und nicht die Auswahl auf dem Farbrad.

Wir können da gerne nochmal in einem QRM drüber reden, aber dabei auch diese Cases bedenken.

QRM 22.2

• Das visuelle Problem wird im Rahmen des WPF-Umbaus angegangen.

Ich habe mir den Punkt nun nochmal mit der Beta 2 angesehen. Dabei fällt mir bei dem beigefügten DDF auf, dass hier DMX-Werte für die RGBA-Kanäle gesetzt werden, sobald ich eine Macro-Farbe aus dem Color Panel wähle. Hier wäre aber die Erwartungshaltung, dass die als Colorwheel definierten Farben (hier in Form eines virtuellen Farbrads) über den DMX-Kanal 5 gesetzt werden.

Wähle ich die Farbe direkt im Device Control aus, stimmen die DMX-Werte (RGB auf 255, A auf 0 und DMX-Kanal 5 entsprechend der Auswahl).

Ich bin der Meinung, dass Patrick im QRM auch das Beispiel mit dem Geräten mit CMY-Mischung gebracht hatte, wo ja in der Regel trotzdem noch ein Farbrad verbaut ist, weil sonst ein CYM-rot im ein vielfaches dunkler wie ein Farbrad-rot wäre.

Das visuelle Problem kann davon wie besprochen davon bis zum geplanten WPF-Umbau ausgenommen werden.

   Eurolite LED BAR-6 QCL RGBA (... (1,7 KB)

Weil mir dieser Punkt gerade wieder unter die Finger gekommen ist: macht es Sinn dieses Ticket zweizuteilen? Es sind ja zwei, wie ich zuletzt berichtet habe:

1. Korrektur des visuellen Problem
2. Virtuelles Farbrad setzt RGB+-Werte anstelle der DMX-Werte für Farbmakros bzw. Farbrad + CMY setzt CMY anstelle von Farbrad