Have the FastLED authors considered a simulation controller that would allow projects to be built on Linux with a window that would display the L.E.D. patterns. I had this in a project I am revisiting that used an old version of FastSPI. It had multiple abstracted views that allowed it to run and build on multiple platforms. Maybe it would be useful to a wider audience if FastLED did this to allow people to develop without hardware?
Oh you want an led emulator!
We’ve considered it a great deal-- and have had a wide range of ideas, good, bad, weird, and possibly practical.
I know that a few people have already written some kinds of emulators. One of the LED arrays I sometimes program is a Color Kinetics (now: Phillips) “iColor Tile FX 2:2”, a 12x12 LED array – which weighs 27 lbs. And that’s without the power brick. So: I am highly motivated to use a simulator vs dragging that monster around with me! I have a simulator that I wrote for that but that thing doesn’t even use FastLED, so it’s not of much help to anyone else.
If someone writes it, we’ll promote it!
However, I’m not aware of any generic simulator yet.
I’ve given it a lot of thought - sadly, the time I have for things related to FastLED is on the limited side right now, and so things like platform and led chipset support and bug fixing keep winning out in the battle for “what do I do with my time tonight, Brain?” ("Same thing we do every night, Pinky… ")
Should I use the 2.1 branch to have a play with this idea? It seem very far ahead and I see you’ve already fixed one issue I found on there.
Yeah - the 2.1 branch is going to become master pretty soon.
I did a simulator once in Unity (free) that received Artnet data from Processing. I can share the code if you want (receiving artnet in Unity). However I should clean it up a bit I think.
You could setup an Arduino that sends FastLED output over Artnet (I only have code right now that receives Artnet) and read that in Unity. That saves you porting the whole library to another platform (where you can’t test the speed). There are already Artnet/Fastled combinations like: https://github.com/media-architecture/OpenPixelNode
Another interesting thing could be OPC: http://openpixelcontrol.org
This seems only to be used by FadeCandy right now, but the protocol (like Artnet) is kind of simple. So by supporting OPC you can also test FadeCandy applications and stuff.
Arduino has already an EthernetUDP library: http://arduino.cc/en/Reference/EthernetUDPBegin
I’ve thought about this a bit, and as far as I can see the problem of “write a FastLED simulator” reduces to either “write a C++ parser” or “write an Arduino emulator”. Once you make the call to FastLED.show(), displaying an array of CRGB objects on your emulator is fairly much trivial. But getting to there involves parsing the input .ino and .cpp files and working out what they’ll actually write to the leds array OR compiling it down to a binary and running it on a software emulated Arduino (and then listening to the output pins).
Unless you’ve got an intermediate format like Artnet or OPC (which would be a bear to parse on a memory constrained Atmel-based Arduino) it turns out to be quite a hard problem.
Am I being overly pessimistic?
Agreed. A real simulator is kind of hard (you have to take different processors in account). However a previsualizer wouldn’t be so hard.
Thinking about the memory constrains. You could of course introduce a 2nd Arduino (or Teensy) that receives the FastLED.show() data on a pin and passes that to a computer. I suppose the Teensy also has an USB host function, so you could probably do it without ethernet. However I think you should forget sending 400fps to a computer as you could do with a normal ledstrip.
If you’ve got any hardware connected to the computer at all it kinda takes away half the reason for having the simulator in the first place. But I suppose simulating your LED array/strips is of some value (as opposed to simulating the whole setup, including the controlling Arduino.)
Hmm… I was going a much simpler route. (No external hardware should be required) I was going to build all the c++ on linux and stub out all the hardwarey stuff from Arduino and override FastLED.show() to just display the LED patterns in a window. I don’t need to write a C++ parser as Linux comes with one (g++).
The two paths here seem to me to be
(Type1) a hardware-level emulator that can execute AVR or ARM assembly code, is clock-cycle-accurate, includes the memory constraints of various AVR or ARM chips, and emulates the AVR(or ARM) I/O ports and interrupt architecture. You’d also want it to emulate the power and I/O cycle timing of different types of LEDs (WS281x, LPD8806, APA102, etc) This would be SUPER useful to me, and to Dan-- especially the ability to write and test assembly code for timing.
(Type2) something that just lets you run plain C/C++ code (no AVR or ARM assembly allowed or supported), and lets you get a general idea of how something is going to look on a generic set of LEDs, possibly arranged in a layout of your own design. This would be SUPER useful to everyone else. 
There’s also a Type1.1, where you stick a LeoStick (or similar) http://www.freetronics.com/products/leostick into your USB port, the code executes on it (yay assembly code and cycle-correct timing!), and the ‘LED data’ is fed BACK INTO the computer and displayed on the screen somehow. Basically, “FastLED.show()” would transmit the data back into the computer, instead of out over a pin.
You’d still have to carry a small piece of hardware, but you’d have all the right constraints in terms of code size, RAM, speed, etc.
Type 1.1 is then possible with any Arduino? Is this not simple sending data out of the serial port? However that cost processing time as well.
Yep, that would be the trade-off. On the other hand, the MCU wouldn’t have to spend/waste time signaling data out to physical LEDs.
Even the slow ws2812s with their 800kbps data rate would smoke the standard Arduino 115kbps serial port :). (Which is why I haven’t done that type of simulator yet)
Yeah. So. There is no easy solution that retains timing accuracy and lets you write assembly.
But the Type2 is still a mighty useful idea…
I don’t understand how you’d do “Type 2” without any assembly—is there a level at which you could “stub out” the Arduino hardware, but FastLED would itself function? Isn’t there a bunch of inlined assembly in lib8tion and the CSV-HSV code et al?
I’m talking about “Type 2”. If you look in lib8tion for example there is C fallback code for any platform with no ASM defined. e.g.:- x86
I have found this sort of simulation really improved my code quality. in my previous project where I added this simulation at a higher level with an abstraction layer around LED display it make you consider timing and not depend on the platform. I had this on Windows/Linux/AVR/ARM and cross compiling with different compilers also catches different problems/warnings/errors.