Hello im Ben
After a bit of help setting up fastled for my 1st project (led strip yet to be delivered) WS2812b rgbww. in the IDE part titled “FastLED Defintions”
am i right in thinking that for #define LED_TYPE (i put) WS2812b
and for #define COLOR_ORDER (i put) GRBW
@marmil that’s a shame there is a lot of support for fastled. would you know of an alternative program that does, And do you know if I would still be able to control the RGB part of a RGBW strip with fast led.
I too would love to see RGBW support from FastLED, and I’m tempted to poke at the underlying code to see if I can’t “duct-tape on” rudimentary support for a project.
Efficiency/performance isn’t my main concern, and I could live with using a single value for every white LED in the project. Given those concessions, could this be as simple as inserting W values in the right places in either the outgoing bitstream or the array behind it?
EDIT: I read through the thread linked above re: issue #483. Zefiro’s comment on Mar 2 represents the kind of brutal high-level “duct-tape” hack I may attempt this weekend. It requires 2.3x as much RAM, it won’t work with dithering or any other feature that depends on knowledge of the real color of each pixel, and it adds big performance hits, so it’s definitely nothing to write home about, but it might just work:
First, tell FastLED your project has 4 LEDs for every 3 RGBW leds in your pixel-array (remember to disable dithering etc). Then, before calling show(), interleave W bytes between each trio of RGB bytes, producing a new array of 4 bytes per pixel. If I’m not mistaken, FastLED will just blast out bits, unaware that every 4th byte is actually the W value for the RGBs represented by the previous 3 bytes …
Sure, I’ll need to allocate 2.3x as much memory for the job, and yeah, I’ll have no dithering etc… and of course I’ll sacrifice performance… but it may just work for simple projects without altering FastLED at all…