Research: Using FastLED under the hood

[corbanmailloux]

FastLED is a great framework for working with digital LED strips (NeoPixels, for example) and animations, but it does also support "dumb" analog LEDs.

I'd like to research if it would be worth including FastLED into this project for some of its features. For example, it support color correction, which could cover #16 (gamma correction to make the strip look better) and #27 (supporting other color temperatures). Some other features, like global brightness and HSV support, could be helpful as well.

I don't think much of the animation stuff would be applicable, but I want to know if FastLED has a standard way to fade between two colors. If so, that would eliminate the big chunk of math and complexity as well as a lot of the timing dependencies.

One possible blocker for this is that FastLED doesn't seem to support RGBW at the moment. There should be ways to make it work in this project because we're dealing with simple, analog LEDs, but native support would be benefitial.

(This is mostly just a brain-dump at the moment. When I get to do some research, I'll update/comment here.)

[corbanmailloux]

One method of fading between two colors in FastLED is called blend (header source), which takes a start and end color as well as the progress of the blend (0 - 255). This pretty much does what calculateVal does in this project. That would mean that I would just have to map the number of seconds into 255 steps. Hmm...

I'm thinking I'll be making a POC of this project + FastLED within the next few days.

[corbanmailloux]

I did a little bit more research into this. FastLED isn't really meant to be used with analog LEDs, but all of the math and blending still works fine. Here's an example of setting up a non-addressable LED strip with the framework.

I haven't found how to use the color correction or color temperature adjustments with analog strips, as that conversion is normally set globally (which we can't use). This also means that we can't use the global brightness.

Edit: Maybe I'm overthinking that. Couldn't we just bitwise AND the color we want to set with the correction values from here?

[corbanmailloux]

I think my edit above is correct. As a quick test, I added the following to setColor:

inR = inR & ((Tungsten40W >> 16) & 0xFF);
inG = inG & ((Tungsten40W >> 8) & 0xFF);
inB = inB & ((Tungsten40W) & 0xFF);

(I acknowledge that there are probably cleaner ways to do that bit manipulation, but this was a quick test.)

In the new structure in #43, this could be contained inside of ColorState. Things start to look a little weird when set to an aggressive color temperature and then the brightness is lowered, so I'll keep playing with it.

[corbanmailloux]

No. I was wrong and I shouldn't do bit math at 11:30 PM.

Also, FastLED to the rescue. They provide scaling functions like scale8 that I think cover this case.
I still need to verify, but I think this does more what I was looking for:

inR = scale8(inR, (Tungsten40W >> 16) & 0xFF);
inG = scale8(inG, (Tungsten40W >> 8) & 0xFF);
inB = scale8(inB, Tungsten40W & 0xFF);

[rvt]

If you use HSB internally instead of RGB, fading between two colors is a lot easier. Here is a example https://github.com/rvt/Arilux_AL-LC0X/blob/master/FadingFilter.cpp

This class fadestowards the desired HSB as given during method call. Fading between the colors is done over the color wheel. Then brightness and saturation are easy as well as white colors.
Note, since this is a filter the required start state as defined during class initialisation and the desired state as in the method call. The alpha variable bstates how fast we filter. Once color transitions are automatically working , almost like set and forget...