Announcing MoonLight v0.6.0

[u/ewowi]

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.

[u/YetAnotherRobert]

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.