Open MLDMoritz opened 4 years ago
AFAIK there is no native RGBW but I daily use FastLED with SK6812 RGBW strips with this hack:
https://www.partsnotincluded.com/fastled-rgbw-neopixels-sk6812/
A very important topic for me! Not clear if all effects work with this solution? Especially Fire2012 \ 18? noise effect and others?
A very important topic for me! Not clear if all effects work with this solution? Especially Fire2012 \ 18? noise effect and others?
Yes, besides performances issue with a cheap Arduino a more than 500 leds, everything is good.
And there still is an open issue in here: https://github.com/FastLED/FastLED/issues/106
@focalintent Are there any updates regarding this?
@leonbohmann Sorry to inform you, but Dan (focalintent) isn't with us any more.
https://www.reddit.com/r/FastLED/comments/czenwv/sad_news/
And no, FastLED does not have RGBW support yet.
Oh man, that's awful. Have been using FastLED for years now.
If any help is needed in implementing the RGBW features I'd be glad to help out somewhere sometime.
Is there any indication when this feature may be available? E.g. is it planned for the next release?
I'm also hoping for RGBW support ... (specifically SK6812 RGBW)
Also looking for RGBW support WS2814 etc
Suppliers have since caught up and offer the SK6812 for a resonable price, I would also like to see support for RGBW in FastLED to use them. https://github.com/FastLED/FastLED/wiki/Chipset-reference references some RGBW in the works, but I was unable to find a reference to it. Did anyone find an alternative solution yet?
My suggestion is to implement an RGBW algorithm yourself in FastLED and upstream it with a pull request to mainline.
My humble suggestion for an RGBW algorithm would be to translate RGB values into RGBW values on the fly. Exposing the 4th component (W) to the developer (like CRGBW) is problematic because changing the framebuffer format from CRGB to CRGBW would be a deep and risky change since FastLED is designed to run on a matrix of different chipsets with different configurations, and a CRGBW based framebuffer would likely break a lot of platforms.
Here is a paper on RGB -> RGBW power constrainted conversions:
https://ieeexplore.ieee.org/document/6853788
Non paywalled source: https://web.archive.org/web/20170809142221/http://mirlab.org/conference_papers/International_Conference/ICASSP%202014/papers/p1214-lee.pdf
I'm not sure I understand you correctly. Is the "wire" protocol for these new chips already supported? I couldn't find any references in the wiki. I don't see how the RGBW translation can be used if the module can't be instructed to display any colors, regardless if RGB or RGBW.
There's been a push to change the frame buffer format on FastLed for 16 bit and rgbw.
I wanted to get ahead of that.
No i don't think there is a wire formate yet for RGBW that's implemented in fastled.
But if you wanted an implementation and have some spar RGBW to send me I will implement a device driver for this led.
I haven't ordered any yet, I'm still in the early concept stages for my project. The link above would be one of my picks to order a few, prices are cheap and the seller is recommendable. Is there a "development fund" e.g. from donations or a bounty board, where you could request one to be ordered to you? I'm just a user, not involved in any way. If there is none I can offer to donate/gift some "for the cause", but a regular process with contribution tracking is probably easier. Can someone from the development team chime in with some background?
Cross-referencing this here: I've (finally) started work on the low-level FastLED driver for four-channel (RGBW) WS281x LED strips. I'll be tracking that work over on this Issue: https://github.com/FastLED/FastLED/issues/1540
Hey,
as it seems there is still no RGBW support - How can I help?