Hey, some timing issues are cropping up in 2.1 that are not present in 2.0 - at least, I think they’re timing issues. Using the Trinket core on an Attiny85, if NUM_LEDS is > 43 it fails and starts displaying erratically, at some point it just starts flashing white. Dropping back to 2.0 and it works fine all the way up to 100 pixels, after that it fails which I would expect.
Not time, memory - try the dithering branch - which has a bunch of work that I did to pull the memory usage back, 2.1 had some changes that pushed up the usage.
Gotcha. I’ll grab that branch and test that.
I’ve been able to run 110 LEDs on the dithering branch, and over 120 with some techniques that I will document as part of the 2.1 beta/preview releases.
Cool. I’m just abusing an attiny85 right now, see how far I can push it before the magic smoke comes pouring out.
When we wrap up the 2.1 stuff and I stop flipping out about locus, I have a plan for some fairly severe attiny abuse 
It would be nice if somehow, we can make FastLED work with the tiny-cores from http://code.google.com/p/arduino-tiny/ as that opens up a few more options for various tinys, however they may be missing key pieces that you rely on for FastLED.
Added issue #42 to GitHub to track arduino-tiny support
Ok, with dithering as-is, same code, it runs fine up to 120 then starts acting up after that. I know, memory … there’s only so much a tiny has available.
#include “FastLED.h”
#define NUM_LEDS 120
#define DATA_PIN 0
#define CLOCK_PIN 2
CRGB leds[NUM_LEDS];
void setup()
{
FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, BRG>(leds, NUM_LEDS);
}
void loop()
{
static uint8_t hue = 0;
for (int px = NUM_LEDS - 1; px > 0; px–)
{
leds[px] = leds[px - 1];
}
leds[0] = CHSV(hue++, 255, 255);
FastLED.show();
delay(10);
}
At 120 LEDs, you have 360 bytes being used by just led data, the controller is about 32 bytes, roughly, so now you are at 392 bytes. Now there are other things that are taking up memory, global variables used by some of the arduino library stuff, not to mention your call stack - which can be anywhere from 8-40 bytes per call currently on the stack[1], et voila you are at your 512 bytes. When the stack starts crossing into other variable values, then you can get all sorts of weird effects happening.
Still, I think there’s a few more bytes that I can squeeze out of the world, but I probably won’t get to that for the 2.1 view of the world.
There’s always room to trim out more, though
[1] which means a shallower call stack can give you more room! ultimately! and there are some things that I am looking into that will make it easier to get a shallower stack.