I've been thinking about animation speeds lately;

Archive FastLED Archive
1

I’ve been thinking about animation speeds lately; that is to provide a fixed animation speed for a routine even if other overhead has been added to the overall code. The 3 things that come to mind are:

// insert a delay to keep the framerate modest, as used in demoreel100
FastLED.delay(1000/FRAMES_PER_SECOND);

I’m not really sure that this would help us out, but then I’m not sure how FastLED.delay() works.

The other options that I think are more viable to keep a fixed animation speed are to use:

EVERY_N_MILLISECONDS(20) { routine(); }

Note: There is a method to make the above ‘20’ a variable, so this could be used by routines with different animation speeds.

Another method would be to use mills() instead of an incremental counter between frames in a routine. As the overhead increases, the frame rate decreases. By using millis(), the animation appears the same, but the pixels may move imperceptibly more or less between animations.

Any thoughts on this?

2

You could measure the amount of time taken in the loop so far, and then calculate the delay required to maintain a constant update rate, similar to what is used in some game loops.

3

I’ve been thinking about this as well, but more in terms of LED strip length. I.e. being able to maintain same speeds regardless of if you’re writing to 100 LEDS or 1000. But that may be a harder problem to solve, especially if you want to make a longer strip fast. E.g. I have a routine that does a Knight Rider type pattern, but it’s crazy slow with several hundred LEDs. Eventually I solved it by moving blocks of LEDS instead of individual. Maybe that could be generalized into a formula that the code uses to adapt patterns based on length.

Anywho – different problem but related, so I thought I’d mention it!

4

I personally like storing millis() :

static unsigned long LastAnim;

if (millis()-LastAnim>= Delay) {
LastAnim = millis();

//Animation…

}

It worked perfectly for me in the past. The only thing that can mess up the timing is how precise millis() are on the specific board you’re using.

For example, I’m experimenting with the new Adafruit Trinket M0 and the millis() are insanely fast, almost two times faster. I had to re-tune all my animations, and also beatsin8() is super slow for some reason. I have no idea why, probably something interrupt-related caused by using WS2811 leds.

5

Here’s a simple proof of concept program, for which I hope to have a video up today or tomorrow: