Anyone involved with FastLED development mind if I extract and fork off lib8tion as a standalone high performance AVR math library? It’s just SO useful and I’ve been using it in other LED projects that don’t use FastLED supported hardware (monochrome displays, for example). I believe the MIT license means that I can actually just go ahead and do this with proper credit due, but wanted to know if any FastLED devs were already planning to release and manage lib8tion as a standalone library, don’t want to step on any toes.
There’s nothing wrong with doing that - though, if we make changes to the code in FastLED proper, you’d have to pull them back - also, you run the risk of making conflicts if someone wants to use both libraries together.
That said - the compiler is really good at cutting out things that you don’t use, so if you do #include <FastLED.h> but only use the stuff from lib8tion, then you won’t have any extra cruft compiled in to your final executable 
What Dan said, above.
Also there are one or two rounding errors (already ticketed) that you might want to wait till they’re fixed before forking.
But basically: use it however you wish! Lib8tion was developed to work as part of FastLED, but most of it works standalone too.
Thanks for responding, guys. The effort to fork/maintain may or may not be worth it; I found that using a standalone lib8tion saves me about 44 bytes of program space and 13 bytes of global variables. Not huge, but it could matter someday 
I do some work on ATtiny (not using Arduino) and it may matter there. I think the main reason is not to avoid any extra resource usage, but to set lib8tion aside and say “here’s this really useful, fast math library” which people might not otherwise realize is part of FastLED. Fast 8-bit or fixed-point math and trig/interpolation/scaling functions are also really great for sensors etc 