Hey is there also a “light” release of FastLED? For, let’s say, someone who only wants to control some leds…
Do you mean non addressable LEDs?
If so, yes.
https://github.com/FastLED/FastLED/blob/master/examples/AnalogOutput/AnalogOutput.ino
But there isn’t a “light” version.
Also, the compiler only includes code that you use. So if all you use are the LED drivers (and no palette or HSV functions), that’s all that gets built into your sketch executable.
I just like to keep my codebase clean, that is all. No biggie, will clean it up my self.
I’m curious what you mean here by cleanup? Just trying to understand how folks are using the code?
There is literally no code benefit to deleting any source files. So… what “cleanup” are you thinking of?
Also keep in mind that if you alter your copy of the library (which you’re welcome to do!), it makes upgrading to newer, faster versions of the library a pain.
First, I am to lazy to do the timings myself for driving the bitbanged world-semi hardware. So will use the stuff from the led lib, time win.
Second, there is a lot more benefit from having a clean codebase. If I need to transfer or share my stuff with someone else, they will need to go through all the files. So, to keep it simple for anyone who will have to deal with my code during R&D, I remove stuff that does not need to be there. Whenever I get a project on my desk that blinks a led but, has 60 cpp files in their codebase, a bell starts ringing… I like precision tools, no Swiss army knife 
Ok! Best of luck and let us know what you keep and what you delete. Always curious where users find value.
You may also be interested in this size comparison: https://plus.google.com/112916219338292742137/posts/6AUgfAKWVs5
Oh I like the simple declaration on the front-end, that is a nice idea. And the CRGB struct is a nice implementation with the operator overloads but, the corrections and the conversions are something I would never do embedded 
Good to know.
Just so you also know, the brightness adjustment and color corrections are done “for free” inline: they don’t cost any CPU cycles. We do the necessary math in the interleaved microseconds between I/O operations clocking the data out to the LED strip. There is exactly zero runtime overhead; there is literally no faster way to do it. You see, Daniel and I are rather obsessed with speed, compactness, and efficiency – as you may have noticed!
In general our philosophy is to turn a feature on by default only if there is no penalty. Other features, such as the current power management API, do have an overhead, and so they’re strictly optional. This guideline has kept the library extremely tight while also letting us offer optional features that people can use or ignore as they wish.
Thanks again for letting us know what’s important to you!
Are you working on a particular project, or more just experimenting at this point?