Just thought it would be nice to give an idea of the stuff I’m working on. This was an installation done 2 years ago that run for 2 months in winter. Actually it doesn’t use FastLED at all, but DMXsimple with 12 Eurolight Led par56 (projected on tracing paper).
Perlin noise is used in combination with a colorpalette with gradients based on color harmony theory. Every morning and evening the palette is changed. It runs on two Arduino Uno’s. One connected on ethernet to be able to remote control the installation (and switch colors with a cronjob), the other Arduino is running the code.
I prototyped on Processing and ported everything to Arduino. Even when using floatingpoint math I could reach about 30fps (but the maximum lights would be 24 in this setup).
Thanks to the effort of Daniel and Mark I’m able to rewrite things with integer math (which is quite a challenge for me). Some things I don’t even have to rewrite since it’s already implemented (like the ColorPalette recently added by Mark). A huge compliment for their code, because they write very clear so I’m able to understand and use bits and pieces as well.
The biggest benefit is speed of course. Instead of controlling 24 spots I can now easily update 120 (my current test setup) including dithering, color correction and other stuff with 200 fps or more.
http://vimeo.com/kasperkamperman/color-e-motion
Ah very cool installation! Thank you for sharing this video of it-- and those are some big pixels there!
Really, though- looks great.
That looks fantastic! (Also, as an aside - you know FastLED has an output driver for DMX devices - so you can basically treat a DMX universe just like another led controller 
Regarding the DMX aspect of the library, will there be more documentation in the future regarding the use of this feature?
Actually, it seems to have suffered some bitrot and isn’t currently compiling, but when I fix that, yes. Though - really, it’s no different than any other led chipset. It’d be DMXSIMPLE or DMXSERIAL based on what dmx library you were using. DMXSIMPLE can take a pin because it does its own bit juggling, DMXSERIAL uses the UART - so not a whole lot to document (but DMX requires other outboard hardware to use).
It seems that I have a bit more research left on the subject.
Look up the DmxSimple and DmxSerial libraries, for starters. Honestly, unless you are driving dmx native devices, I’d say avoid it - it’s a slow data protocol, you’re only allowed 512 bytes in a universe (or 170 RGB LEDs).
True story - when I first started doing led work (summer, 2010), I had a board that took SPI and would pwm drive up to 32 RGB LEDs (or non-addressable RGB led strips), and I used a dmx to spi interface and then an arduino with a dmx shield to drive it all.
I was annoyed at how slow it was, as well as how cumbersome the setup was, realized I could do spi from the arduino, cutting out the middleman, then got annoyed at how slow the arduino spi libraries were and the result was a little library called FastSPI_LED which I put online in advance of doing a 5 minute rant about bit banging spi at Five Minutes of Fame and the rest, as they say, is history.
Cool story. Thanks for the info.
Ok - now it’s compiling again - but it may be a bit on the untested side - but short version, say you’re using DMX Simple, and you have your DMX interface on pin 10:
#include<DmxSimple.h>
#include<FastLED.h>
#define NUM_LEDS 30
CRGB leds[NUM_LEDS];
void setup() { LEDS.addLeds<DMXSIMPLE,10>(leds, NUM_LEDS); }
void loop() {
leds[0] = CRGB::Red; LEDS.show(); delay(100);
leds[0] = CRGB::Black; LEDS.show(); delay(100);
}
et. voila! Er, in theory. I can’t find my DMX gear to test this with at the moment… oops.
(This was something that I threw together for a contract job that was DMX based, but I still wanted to use the rest of the library)