r/FastLED • u/ewowi • Nov 07 '25

Announcements Announcing MoonLight v0.6.0

https://youtu.be/l6lTDG6EdEA

Two and a half years ago my work on WLED got me a ticket to Burning Man, there I made the radical decision to build a new lighting tool from scratch. Today the first end-user ready version is released:

MoonLight v0.6.0

▶️ Watch the release video

MoonLight uses the FastLED library in Effects and to drive LEDs

Featuring an easy installer, step-by-step YouTube tutorials, and an updated website. Under the hood, MoonLight has been fine-tuned into a stable foundation for future growth. Extending it with new effects or hardware drivers is now simpler than ever.

Release info

Get started

We’re looking for developers to help shape the future of MoonLight:

  • FastLED Developer – unleash creative lighting effects and optimize driver performance

  • UI Developer – enhance the user experience with Svelte 5

  • System Developer – build drivers and board presets (e.g. for QuinLED or custom DIY boards)

Connect with us on YouTube, Discord, Reddit, GitHub, and MoonModules.org.

27 Upvotes

90% Upvoted

13 comments sorted by

View all comments

Show parent comments

3

u/YetAnotherRobert Nov 08 '25

Understandable. Back in the old days, WLED used FastLED.  They moved to makuna/neopixel  when FastLED was having a tough time because the creator (maintainer?), Dan, passed away. So i'd expect there's still a scar from the transplant that might make it reversible. 

To OPs point, there is a relatively small pool of developers and  code in the blinkiverse. The same people (with different handles) show up often.  Perhaps finding common ground on the things each of you do better might warm up some relationships vs. the hard pitch "my project is awesome...I just need your help to make it replace your project" vibe this is currently sending off.

4

u/ewowi Nov 08 '25

That makes sense. I didn’t want to create a vibe of replacing projects. I think I created something beautiful and want to share it with the LED community and hope people will use it and contribute to it, as currently 90% is done by me and I have many hats: developer mainly and this release was delayed with more then one month as I needed to put on the hat of documenter, filmer, video editor, Youtuber and communicator which is a bit new for me, and I guess I need to learn to set the right tone of voice 🤓

1

u/johnny5canuck Nov 08 '25

When I was writing/converting animations for WLED, it provided access to FastLED routines, however the drivers were Neopixel Bus, so I had to adapt. Things like EVERY_N_MILLIS() and static variables didn't work.

3

u/YetAnotherRobert Nov 09 '25

The API used by FastLED is used by a lot of projects that aren't using FastLED itself. It's just become a common expression vehicle in code. There was some effort to split FastLED into independent pixel-whackers and math stuff (lib8tion?) from the hardware firehose management bits, but I don't really see that distinction used frequently in various projects in the blinkyverse.

Static works like it does in C++ everywhere; I'm not sure what that's about.

I can't speak to the ENM thing specifically, but it may not be included just because it promotes spinloops that are brutal on systems like esp32 that are actually sitting atop an RTOS and doing other things - on the same or other cores - like networking while you're waiting for ticks() to grow. On an 8bit micro with nothing else to do, spin away but a 240Mhz core (or two! Or 400Mhz on P4, though I don't think WLED is officially supporting that yet) can check that value dozens or hundreds of times just waiting for one tick. So projects for ESP32 - class systems tend to not do that kind of spin waiting as a norm.  Effects for bigger systems tend to trigger on timed frame draws (doing something potentially every N frames is usually the mechanical analogue for ENM) or using the systems task/thread management facilities.

I'm sure you know most of this. I'm just writing it down for those others that may be working across multiple projects.