FadeCandy is awesome, and I had used it in a number of projects in the past. Notably I used it to drive LEDs from a Raspberry Pi in the Synthia project, both V1 and V2:
FadeCandy gives you 4 kinda big things that my expanders don’t:
- Temporal dithering for a bit more than 8-bits per element - though this is a double-edged sword. It will limit you to 64 pixels per channel because the way it works is software PWM on top of the 8-bit per channel PWM on the LEDs. It has to send new values to it quickly, and needs to do this at 400-500 FPS or it would flicker badly, thus limiting to 64 pixels per channel. (@Scruffynerf, the mention of 48 is for RGBW - extra byte on the wire).
- Keyframe interpolation. If your animation ran at 30 FPS, this would interpolate between each frame and boost the apparent frame rate. Even if your animation ran at 1FPS, it would output buttery smooth fades. The only downside is that it doesn’t work well if there is a lot of jitter in when those animation frames arrive, so it has to be consistent for best results. In other words, if your animation took a variable amount of time to generate each frame, the frame interpolation wouldn’t be transitioning quite right. It also looses benefit if you are pushing high frame rates already.
- Native USB connectivity.
- An Open Pixel Control (OPC) server that would talk to FC over USB and give you a nice network interface to push pixels to. This was often used along with Processing, but could be used with anything else pretty easily (perhaps it wouldn’t be too hard to build an OPC server for PB expanders, but that doesn’t yet exist). The server also had a minimal web GUI that was handy for testing.
In Synthia, I had to disable both temporal dithering and keyframe interpolation because I was sending animation frames at around 100 FPS, and those features were both unnecessary and caused issues with the very high frame rate animation.
We’ve talked about adding things like temporal dithering and keyframe interpolation to the expander before. Limiting to 64 pixels is a non-starter for me, and not a limit I would want to impose in order to achieve temporal dithering. That said, it’s technically possible and anyone is free to modify the expander code to make it do that.
Keyframe interpolation could be very interesting, but would require a lot of CPU for as many pixels as the expanders can handle. It might be doable with modest limits on the newer expander models MCU (STM32L432) using some of the ARM SIMD DSP instructions.
I love the direction @zranger1 is taking with this, and perhaps an expander with native USB would make sense at some point.