Hello im Ben After a bit of help setting up fastled for my 1st

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

many thanks

Hello @Ben_Cooper Currently FastLED does not support RGBW, only RGB LEDs.

@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.

One of the Adafruit libraries supports RGBW.

As it is now, the current version of FastLED can not control just the RGB part of a RGBW strip. You might find something interesting in this discussion though:

and also this post:

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…

My understanding is it’s not that trivial to incorporate it into all the FastLED code. There are a few implementations out there though. Here’s another by @Juergen_Bruegl

Hi the links above where interesting and led me to the link below. May be of interest to someone.