GoXLR-on-Linux / goxlr-utility

An unofficial GoXLR App replacement for Linux, Windows and MacOS
MIT License
636 stars 36 forks source link

Colors from the daemon not accurate #21

Closed AdelaideSky closed 1 year ago

AdelaideSky commented 1 year ago

Hi ! I was playing around with the daemon and client when I realised that the daemon seems to send in the status-json the wrong html colours:

For example, i do: goxlr-client lighting faders-all colour 000000 FFF08F No error, the goXlr color changes well, and then goxlr-client --status-json say that the bottom colour of all faders is 00FFF0:

"faders": {
          "B": {
            "style": "TwoColour",
            "colours": {
              "colour_one": "000000",
              "colour_two": "00FFF0"
            }
          },
          "C": {
            "style": "TwoColour",
            "colours": {
              "colour_one": "000000",
              "colour_two": "00FFF0"
            }
          },
          "A": {
            "style": "Meter",
            "colours": {
              "colour_one": "000000",
              "colour_two": "00FFF0"
            }
          },
          "D": {
            "style": "Meter",
            "colours": {
              "colour_one": "000000",
              "colour_two": "00FFF0"
            }
          }
        },

I checked if switching to another colour could change anything, and for example FFFFFF is in the status json 00FFFF. 000000 is still 000000 in the json. Same for top colours. When loading a profile, it seems to show the right colour in the json.

In the profile file, you get this: FaderMeter0colour1="FFFFB380" (so an RGBA hex).

I noticed as well that asking the client after loading my profile (so with all bottoms colours to FFFFB380) to set the bottom colour of all the faders to the default FFFFB3 slightly changes the colour. That's normal as it doesn't care about alpha but it may be useful to add support of alpha in the cli (if possible of course)

FrostyCoolSlug commented 1 year ago

The alpha channel isn't used in the GoXLR, and isn't present in the windows UI which is why it's excluded from the CLI (I'm assuming it's stored in the profile because of the library they use under Windows).

I'll double check the colour settings soon, can you confirm if the same behaviour happens with buttons?

AdelaideSky commented 1 year ago

Oh okay, it's a bit strange then that setting via CLI the same colour as in the profile changes a bit the sliders colours <_>

And yup the same thing happened when testing on the bleep button and sampler select A.

FrostyCoolSlug commented 1 year ago

Thanks, doing some checking here, think I've found the culpret..

So the profile stores the values as ARGB and not RGBA, which has caused various levels of confusion in my code, so from the default 'Red' profile, scribble1colour0="FFFF0000" is pure red, so FF0000.. Because the mistake was consistent in the code, both reading profiles, writing profiles, and sending commands to the GoXLR, they were always displayed properly, the code was just returning ARG in the status response.

This is fixed in 578c633e