[Skin] COs to gather colors in controller mappings and waveforms

[JoergAtGithub]

Feature Description

Modern controllers can show buttons and diplays in user specified colors. Also wafeforms should match the colors of the skin. There are several elements in a skin, where it can make sense to use the color informaton in other places of the code:

• Deck Color ( reference is https://github.com/mixxxdj/mixxx/issues/11199#issuecomment-1402897331_ )
• Intro/Outro-Button-Color can be mapped to hotcue buttons of controllers
• Loop-Button-Color (same color in waveform makes sense)
• Colors for High/Mid/Low EQ frequency in waveforms

[Swiftb0y]

These are ideas worth discussing, but I have a couple thoughts on why I don't think they're a good idea to implement: I don't think CO's are an appropriate way to expose waveform data. I wouldn't even know how to do that to be honest when all we have is doubles. We need another API like we have for Colors. I also doubt we should expose the colors of certain buttons. It would be confusing if they change with the skin. Coloring them a fixed color makes sense when documenting the manual, dynamic colors would likely throw off any color coding designed to make the mapping easier to understand.

[JoergAtGithub]

The idea is, that the skin defines the color for all: Skin, Waveform and Controller-Buttons

[Swiftb0y]

right, but IMO for controller it doesn't make much sense. The practical reasons I mentioned for one and also the fact that controllers have different hard-coded colorschemes, it doesn't make sense visually for my Numark NS6II which is primarily black with red and silver accents to use Deere's blue buttons or latenight classics yellow accents.

If one was striving for colored visual consistency, the relationship should be the other way around since skins can be much more dynamic than physical controller hardware. I doubt skin designers would like that relationship though.

[daschuer]

Just a note: A double can carry the QRgb color value without any data loss. We do it already for the "hotcue_X_color" co.

[Swiftb0y]

I'm aware, I was talking about exposing the waveform as a CO. There is no way to store a giant array of doubles in a single double. :wink:

[JoergAtGithub]

This proposal is not about exposing waveform data as a CO. It's about the opposite direction. parametrizing the waveform with colors, which match to the skin/theme.

[Swiftb0y]

Ah right, yes. Thank you for bringing this discussion back on topic. In regards to that specifically, don't we already support that? I thought we had implemented some <WaveformSignalColor> nodes or something? Though I'm sure @ronso0 would know more about that.

[ronso0]

I thought we had implemented some nodes or something?

Jup, as well as nodes for setting the RGB components, and each marker and range type. @JoergAtGithub This is about making these colors available for controllers? If so, is there any base in Mixxx for drawing waveforms? (I'm not up-to-date regarding Mixxx' current HID/MIDI capabilities...) However, like @Swiftb0y I'm skeptical if controllers would adopt the skin's button colors, I imagin that very confusing.

[JoergAtGithub]

No, there is nothing, which ca draw a waveform on a controller. Neither MIDI nor HID support such functionality. It is just an idea how to allign colors in different parts of the User-Interface (which in this sense includes the controller).

An example could be the color of the loop buttons, which exist on the controller, the GUI and as overlay range in the waveform.