Here's one I've never seen anybody ask about...maybe I"m just an edge case?

(Lucas McCallister) #1

Here’s one I’ve never seen anybody ask about…maybe I"m just an edge case?

I’m a biiiiig fan of the lib8tion library functions. I often program stuff using DMX outputs or other lighting control options, and really only get to do Pixel strip/matrix stuff once or twice a year.

Long story short, I often use the lerp8by8 or lerp8by16 to accomplish crossfades for lighting, since it means I can tie the “max” output of certain items to potentiometers for fine-tuning later. I’ve found that sometimes the lerp math is a little off on the very last part of a fade - I’ll hit 255 with my fract, but the final value will be just a bit off from where it should be. This isn’t a big deal when it is on the bright end, but on the low end, it can mean that an LED strip or fixture doesn’t turn completely off.

Right now my workaround is that when the fract hits 255, it activates a switch statement that checks a system state flag. This flag tells which channels should be at which levels, these levels are then assigned and one more write() is sent to my DMX output, pixel strip, or PWM Controller.

I understand that the math is probably a bit inherent in how the steps are calculated. I’ve thought about making a variation of the lerps that forces this step in the function itself, though I’m not sure if it may backfire and cause visible jumps with some cases.

Anybody else have ways of dealing with this?

(David martin) #2