I’m trying to learn/teach through some FastLED tutorials, and was playing around with various ways to make a pixel go back and forth or cycle a strip with a fading tail behind it. I was going to give fadeLightBy() or fadeToBlackBy() a try, but get really weird results! Here’s the code: --------
void loop()
{
leds[lead_dot].b = 255;
lead_dot = lead_dot + 1;
for(int dot = 0; dot < NUM_LEDS; dot++)
{
leds[dot].fadeToBlackBy(64);
}
FastLED.show();
delay(20);
} --------
It runs a couple of blue pulses and then just freezes for a bit before turning the pixels a bunch of yellow/red tones (attached pic, though as you can figure it’s hard to capture). Then it literally acts “laggy” when it resumes and the lead pixel/tail stop toward the end of the strip indefinitely.
If I simply replace the fadeToBlackBy() line with this, it’s fine:
leds[dot] /= 2;
Why can I divide all channels by 2, but not use fadeToBlackBy()?
I hate counting up and counting down a strip in order to move pixels. I also hate that about as much as using delays (especially when I’ve got button polling routines to run). Without going into all the code, I’d recommend that you try:
beatsin8() to move your active pixel back and forth and to use EVERY_N_MILLISECONDS() to call the fadetoblackby() function every few milliseconds.
Hmmm. Your use of fadeToBlackBy had me look up the docs. I was following the github wiki which just seems to pass the function a fractional amount to fade by. Your code (and the 3.1 docs now that I checked) pass it the array, num_leds, and a fade value. Maybe the issue was mixing old function syntax with v3.1?
Thanks @Andrew_Tuline ! So, couple of revelations… while I’m ~99% sure I had it at one point, I don’t have a line like if(lead_dot > NUM_LEDS - 1) { lead_dot = 0; }! I think that’s what was glitching things. Not sure about the internals of FastLED, so I’m not sure what happens when it sends data including values for a pixel that doesn’t exist in hardware. Using that line fixed the issue.
I also confirmed that both variants of fadeToBlackBy work (the one inside the for loop above, as well as removing the for loop entirely and just using fadeToBlackBy(leds, NUM_LEDS, amount) each loop.
Lastly, thanks so much for the intro to beatsin8. That works just swell, as does the EVERY_N_MILLISECONDS line. Is EVERY_N_MILLISECONDS just a wrapper for a millis() based timing check? Like:
Yeah, I’m not really able to digest that, but I’m going to take it as “Yes, this is implementing a millis()-based timer” vs. a delay. I definitely get the advantage and have run into this using encoders, so I’m glad it’s there. For simple stuff I often just use delay().
