add hue names header for convenience

[jamadagni]

No description provided.

[obra]

Sorry for the delay in my reply. I like the idea here. Would you consider using the ~standard FastLED hue color list? https://github.com/FastLED/FastLED/wiki/Pixel-reference (Search for HUE_)

Their color list is

Red (0..) "HUE_RED"
Orange (32..) "HUE_ORANGE"
Yellow (64..) "HUE_YELLOW"
Green (96..) "HUE_GREEN"
Aqua (128..) "HUE_AQUA"
Blue (160..) "HUE_BLUE"
Purple (192..) "HUE_PURPLE"
Pink(224..) "HUE_PINK"

(And really, ORANGE is a little more common than RED_YELLOW as a color ;)

[jamadagni]

Hello. I agree to the part about ORANGE (obvlously I was being a little unimaginative there) and I have no problem with using other better names.

But there may a problem with using the hue values which you have copy-pasted, because they refer to the rainbow HSV colour model provided by FastLED which adjusts for a visually-expected broader yellow band.

Further down on that page are the named values for the pure mathematical spectrum model and they correspond to the values I have given (simply because they divide 0–256 into 12 parts). [Well it seems I instead divided 255 into 12 parts so a couple of the values are off by 1 due to rounding but I'll fix that presently.]

The current LEDControl implementation doesn't use the FastLED code for HSV-to-RGB conversion, but instead code from some other webpage (which doesn't seem to be available now BTW) which follows the pure mathematical spectrum model as does most simple code on the web. (To use the rainbow model might be desirable, but that's for another day.)

See also what the FastLED source says about the differences between the two models. Certainly currently the HSV code doesn't attempt to maintain a uniform brightness and you can observe that the basic Rainbow effect becomes brighter whenever it goes through the CMY colours compared to the plain RGB where only one LED component will be working.

Thus I am OK with adding some more readable aliases for the intervening hues but would like to retain the prosaic names as well since they highlight the fact that they bisect the two major hues, and also am not sure these intervening hues all have other more readable names. (FastLED specifies HTML-style names for individual RGB colours but not for other hues AFAICS.)

[jamadagni]

Something like the Material Design palette has a more comprehensive set of hue names (suffixed with 100, 200 etc), but I rather would just like to give a simple list as we're not doing a whole UI here…

[algernon]

For naming, I think we should be aiming at something simple, like HUE_ORANGE. From an end-user point of view, that makes more sense than either HUE_RED_YELLOW or HUE_ORANGE_400, in my opinion.

For values, we should be using hue values that are correct for our implementation, not necessarily the ones from FastLED. So the values in the PR are good, the names less so.

I realize this has been sitting here for more than a month now without any feedback since @obra's, so if you're not feeling up to it, I can change the names and merge it after. In either case, thank you for both the PR, and the patience!

[jamadagni]

Hi @algernon and sorry for the delay. Can you please specify which names exactly you would like changed and I'll do the changes and submit?

[algernon]

No worries! I'll try to give you a list later today (I'm knee-deep in something else at the moment)

[jamadagni]

Hi @algernon I'm cleaning up my old forks of the separate plugin repos. Pl advise what to do with this.

[algernon]

I'd go with the following names & values:

name	value	comment
HUE_RED	0
HUE_ORANGE	25	I found 21 to be too close to red
HUE_YELLOW	43
HUE_GREEN	85
HUE_CYAN	128
HUE_BLUE	171
HUE_MAGENTA	192	213 felt too close to 224, which looks pinkish to me
HUE_PINK	224	Halfway between 213 and 235

Between 85 and 107, I don't see much difference on the keyboard, so I skipped 107. About 149, I'm torn... it might make for a nice HUE_LIGHTBLUE, but then we should introduce light variants for all of them. I'm not entirely sure about HUE_MAGENTA and HUE_PINK. If you think HUE_MAGENTA would be better as 213, I'm ok with that, but then lets not have HUE_PINK (at least not at 224).

[algernon]

FWIW, I used this little plugin to test hue colors on the keyboard:

class HueTest_ : public kaleidoscope::Plugin {
 public:
  HueTest_() {}

  uint8_t hue = 0;

  kaleidoscope::EventHandlerResult onFocusEvent(const char *command) {
    Focus.read(hue);
    return kaleidoscope::EventHandlerResult::EVENT_CONSUMED;
  }

  kaleidoscope::EventHandlerResult afterEachCycle() {
    cRGB color = breath_compute(hue);
    LEDControl.set_all_leds_to(color);
    return kaleidoscope::EventHandlerResult::OK;
  }
};

I used the bin/focus-test tool shipped with Kaleidoscope to send the commands.