while the idea of a FastLED compatibility library is a good idea, it’s such a radically different method of programming LEDs, that doing simple tasks (like most of the patterns in WLED) becomes more about emulating WLED than actually doing the pattern.
So let’s divide this in two pieces:
- Duplicate the pattern, using as close to the ‘PB way’ of doing it.
For example, look at WLED/FX.cpp at master · Aircoookie/WLED · GitHub
and take a simple case: blink() is used for a few patterns.
blink(color1, color2, bool strobe, bool do_palette)
alternate between color 1+2, maybe strobe, maybe use a palette of colors.
Porting this exactly, including segmenting code (which is used a lot in the patterns) seems pointless IF we can port the functionality.
We have ‘segmenting’ code now, the Multisegment pattern and Multimap multi-pattern will do this in either 1d or 2d, and just need a code fragment of a pattern to be installed into them.
Palette aside, doing a blink() is pretty easy.
- Build a FastLED library for porting things where it’s just easier to emulate than to do it the PB way.
I’m all in favor of doing this, but don’t want it in the way of the much simpler task of just ensuring that Pattern X from WLED has a PB equiv. In fact, having a PB equiv rather than a pure port can help teach people the PB way to write things.