Hi,
hier triffst du auf einen Teil von DMXControl 3, der aus verschiedenen Gründen so kompliziert ist, wie er ist. Hier geschieht sehr viel hin- und hergerechne im Hintergrund, was man auf den ersten Blick nicht sieht. Dröseln wir das mal auf: Standard-Farben werden in DMXControl 3 üblicherweise auf RGB normalisiert. Sprich, alle Eingaben, die du über das Farbkreis-Control oder in dem "Color"-Eintrag (nicht zu verwechseln mit den Fadern unterhalb des Color-Eintrags!) tätgst, sind in RGB. Selbst die Eingaben für die Farbfilter bei Moving Heads laufen über RGB und HSV und CMY werden ebenfalls auf RGB umgerechnet. Diese Werte werden dann so durch die verschiedenen Teile von DMXControl 3 durchgereicht, gemixt und verrechnet. Fast am Schluss hat man dann die Farbe (in RGB), die das Gerät haben soll. Erst an diesem Punkt wird dann die eigentliche Farbe auf den Farb-Kanälen ausgerechnet und beruht dann auf deinen Einstellungen bezüglich "Ersetzen" und den anderen Modi. So wird dann eben z.B. bei "Ersetzen" des Amber-Kanals der Rot und Grün-Kanal entsprechend reduziert und Amber ausgegeben. Oder es wird der entsprechende Farbfilter auf dem Farbrad ausgewählt. Das kennt aber nur der Hardware Abstraction Layer von DMXControl 3, wie er es korrekt mixen muss, damit es auf dem Gerät korrekt ankommt. Die anderen Teile von DMXControl 3 kennen davon nur wenig.
Nun fragst du dich sicher, warum ich oben explizit die von dir angesprochenen Fader ausgeschlossen habe. An diesem Punkt beginnt jetzt das "Chaos". Ein valider Punkt, der schon recht am Anfang angefragt wurde und den wir auch anbieten möchten ist, die einzelnen Farbkanäle explizit anzusteuern. Das ist einerseits nötig, weil es keine Möglichkeit gibt, UV aus RGB herauszurechnen und auf der anderen Seite möchte man manchmal doch durchaus mal noch etwas genauer einstellen, wie dann z.B. das Weiß bei Pastellfarben dazugemischt wird. Daher kann man jeden einzelnen Farbkanal des Scheinwerfers auch einzeln per Fader ansteuern. Diese Werte werden zusammen mit den RGB-Werten abgespeichert und bei dem Weg durch die Software mittransportiert (in einem Objekt, was wir LumosColor nennen 
). Diese zusätzlichen Farbwerte umgehen einen Teil der Berechnung und überdrücken dabei teilweise die Werte aus der RGB-Berechnung. Und diese Kombination macht uns auch massiv das Leben schwer, wenn man z.B. in einer Szene einen RGB-Wert gespeichert hat und in der nächsten Szene einen Wert, der mit den Fadern eingestellt wurde. Wir müssen trotzdem sauber dazwischen überblenden. Und die Farbmaster machen es an dieser Stelle auch nicht einfacher..... Das alles und der Fakt, dass dann die Stage View auch wissen müsste, wie genau die Geräte hier reagieren, um die Farbe korrekt darzustellen ist der Grund, warum das nicht so dargestellt wird und es auch keinen einfachen Weg gibt, das sauber zu machen. Wir haben hier immer eine Überbestimmtheit, sprich es gibt den eigentlich mit RGB voll bestimmbare Farbraum. Aber dieser wird von den Scheinwerferherstellern um zusätzliche, überlagerte / abhängige Farbdimensionen erweitert. Das sorgt dafür, dass wir a) bei der Steuerung diese Parallelität fahren müssen und b) bei der Ansteuerung diesen Aufwand treiben müssen. Daher ist eben das Farbsystem auch so komplex und so tief integriert, dass wir hier nur sehr schwer grundlegende Änderungen machen können. Und das ist letztendlich auch der Grund, warum die Stage View das so darstellt, wie sie das tut.
Ich hoffe, so wird etwas klarer, warum das eher schwierig wird, diese zusätzlichen Fader in der Stage View sauber zu visualisieren.
Viele Grüße
JP
Soon5 und ich sind dem Problem mal auf den Grund gegangen und haben es nun behoben (kommt dann im RC4). Dieses Problem bestand bei allen Sinks im Input Assignment, die aus der GUI heraus erstellt werden (also die Outputs wie z.B. ein MIDI Out oder eben die Cuelist Monitor Sink). Der Punkt mit den nicht leuchtenden Midi Buttons sollte damit dann auch behoben sein. Falls es interessiert, was das Problem war: Hier gab es eine sog. Race Condition zwischen zwei Aktionen. Dabei hat die GUI das Erstellen einer Sink im Kernel angefragt und dann darauf gewartet, dass sie das OK bekommt, bevor sie diese Sink bei sich selbst einfügt. Der Kernel hat aber während dem Erstellen schon eine Update-Nachricht mit den aktuellen Werten geschickt. Je nachdem, ob die Nachricht "Sink wurde erstellt" oder "Update der Sink" zuerst in der GUI ankam, wurde der Cuelist Monitor korrekt initialisiert oder blieb halt leer, weil für das Update die passende Sink nicht gefunden wurde (weil die GUI ja noch auf das OK für das eigene Hinzufügen gewartet hat). Der entsprechende Bug dazu ist 
). Am besten wäre es, vielleicht noch einen Kommentar unter FS#5286 zu setzen, damit klar ist, dass das auch bei anderen Mastern auftritt.
Heute sind hauptsächlich die Stage View sowie die Haupt-Cuelist oder die Executoren offen 
