WLED pattern porting?

Patterns and Code
2

That’s a great idea, and as a starting point can I suggest that it would be an idea to put together a compatibility library? IIRC, WLED stuff is written for FastLED so some concepts are completely orthogonal to the PB way and other things can be fairly easily ported as library-able functions.

What I’m thinking is that we’d probably want a skeleton program that defines a FastLED-like environment with pixel framebuffers and a standard render() function to output them, and as as many compatibility functions as we can provide to make the process of “porting” mostly a copy-and-paste into the preRender() function and some minor syntax fixups.

I’ve already started playing with a couple of FastLED patterns so I made my own FastLED-like skeleton:

//  Framebuffers
var pixelReds = array(pixelCount);
var pixelGreens = array(pixelCount);
var pixelBlues = array(pixelCount);
// standard renderer
export function render(index) { RGB(pixelReds[index], pixelGreens[index], pixelBlues[index]); }

and a PB function to mimic the “EVERY_N_MILLISECONDS” macro:

////////////////////////////////////////////////
//  FASTLED emulation functions (mine)
var maxTimers = 10;
var elapsedTime = array(maxTimers);
function EVERY_N_MILLISECONDS(delta, accumulator, target, func) {
  elapsedTime[accumulator] += delta;
  if (elapsedTime[accumulator] > target) {
    elapsedTime[accumulator] = 0;
    func();
  }
}

Then to use it:

// Just an example; a real pattern ought to do something more interesting!
export var hue = 0;
function changeHue() {
  hue = (hue + 1/6) % 1;
    for (index=0; index<numPixels; index++) {
        pixelReds[index] = hue;
        pixelGreens[index] = hue;
        pixelBlues[index] = hue;
    }
}
export var brightness = 0;
function changeBrightness() {
  brightness = (brightness + 1/10) % 1;
}
export function beforeRender(delta) {
  EVERY_N_MILLISECONDS(delta, 0, 500, changeHue);
  EVERY_N_MILLISECONDS(delta, 1, 50, changeBrightness);
}

Easy patterns like chasers will be simple enough to port, but a lot of the nicest patterns depend on things like palettes, blending, blurring and fading functions that we don’t have yet.

And at the moment I’m struggling with the difference in floating point representations and what FastLED functions do internally with them; for instance, the pattern code may calculate a 16.16 number which it then passes to “beatsin88” which expects an 8.8 number, so the C compiler silently does a downcast and/or a truncation, and then the parameters to beatsin88 are treated as an integer if less than 256 but as a 16.16 fixed-point number if greater. With all the side-effects it can be very difficult to tell by eye what some numbers used as parameters to FastLED functions are really doing; sometimes it’s necessary to single-step through in a debugger to see how it winds up.

Still, I think it would be a very worthwhile exercise, and when we’ve squeezed all the goodness we can out of the WLED pattern library we can move on to the other FastLED-based engines (I’ve seen quite a few patterns I like in the SoulMate library).

Embrace and extend!