Skip to content

Friend repos, monthly activity digests

Monthly logs of what shipped on related open-source LED projects, the live landscape MoonLight watches to sharpen its own designs under the Textbook solutions principle (CLAUDE.md Β§ Principles): study to think, write fresh, never copy. Generated by the digest prompt below.

  • FastLED-FastLED.md: the LED-animation library; ESP32/Arduino driver + color math.
  • wled-WLED.md: upstream WLED firmware.
  • MoonModules-WLED-MM.md: MoonModules' WLED fork (the direct lineage).
  • troyhacks-WLED.md: troyhacks' personal fork of WLED-MM (PixelForge, RMTHI, audio-reactive hardening).
  • blazoncek-WLED.md: blazoncek's (BlaΕΎ Kristan, a WLED core developer) personal fork of WLED (segment blending and transitions, alpha channel, bus and HUB75 rework); the work lives on dev, not the default stable.
  • Funkelfetisch-MoonLight.md: a fork of THIS project building a commercial product on it (HELIO, a physical infinity-sphere lamp), now at Funkelfetisch/projectMM on GitHub; the work lives in feature branches, not on its default branch.
  • PlummersSoftwareLLC-NightDriverStrip.md: Dave Plummer's LED matrix/strip firmware.
  • hpwit-I2SClocklessLedDriver.md: hpwit's I2S/LCD DMA clockless LED driver (parallel multi-strip output).
  • hpwit-I2SClocklessVirtualLedDriver.md: the shift-register "virtual pins" variant of the above (dormant since 2024).
  • hpwit-ESPLiveScript.md: hpwit's live C-like script compiler for the ESP32 (main quiet since June 2025; the version branches the work moved to, quiet since February 2026).
  • hpwit-new-parser.md: ESPLiveScript2, hpwit's from-scratch rewrite of the above (repo is named new-parser; the library lives in asmparser2/). Dormant May 2025 β†’ August 2026, then an active rewrite whose stated goal is a verifiable compiler: host builds plus QEMU running the actual compiled Xtensa bytes, and since October 2026 a differential fuzzer against C.

Each month below reads across the digests in up to three parts. Cross-repo trends: what the ecosystem converged on. What these projects do that MoonLight doesn't (yet): observational, not commitments; real adoption decisions live on the Project, cross-referenced where one already exists. Candidates for MoonLight: concrete ideas waiting for a decision, each leaving its list when it is decided. One that asks whether MoonLight has the same defect is checked in the code: found, it is fixed; absent, it is dropped. Any other joins the card, plan or issue that already covers it. With none, it becomes a backlog card when it removes more than it adds, is the textbook answer, fits the architecture and someone wants it; otherwise it is dropped. Study to think, write fresh, never copy.

November 2026

Candidates for MoonLight

From Funkelfetisch's nebulite-helio-7, November 2026, one recommendation each: πŸ› a defect MoonLight shares, βœ… useful to take, πŸ’‘ an idea that needs a plan, πŸ” MoonLight solves it another way, ❌ product-only, stays in the fork.

  • πŸ’‘ Brightness shown as a percentage (737aa344): a percent descriptor flag, the value staying 0 to 255; a UI choice for the product owner.
  • πŸ’‘ The preview shows only what each light's outputs emit (7fab5c60): RGB strips show no white. A correct generic preview rule, redone against our PreviewDriver rather than cherry-picked.
  • πŸ’‘ A connection status LED (b84d8501): an onboard LED blinking reachable, waiting or updating, generic for any board with one; read the header first.
  • πŸ’‘ Moving a WLED S3 to MoonLight without USB (0d05bd4f): an S3 migrator after our C3 one, for every WLED S3 whose two-slot table cannot hold MoonLight; a plan for a product-neutral version.
  • πŸ’‘ The BLE layer under the product protocol (963cbd86, e9379508): the NimBLE lifecycle, MTU 517, the retried notify, the peer table and the desktop stub, as the first step of the Bluetooth plan PR #158's review asked for; pairing against his open lighting mode is the question to settle first.
  • πŸ’‘ Publisher-signed firmware images (60bd5ee7): claims of target, size, security version and hash, signed with P-256; MoonLight verifies no signature. Worth a plan once signed releases are wanted.
  • πŸ” Product firmware leaving out modules (dbce2f47): one more compile flag beside MM_NO_ETH, MM_NO_WIFI and MM_PANEL_CARDS; the shape for both repos is a module list per firmware variant driving the registry, replacing all four.
  • πŸ” mdns pinned to 1.14 (a05f466d): MoonLight moved to 1.15.1, which compiles under GCC 15, so the pin can go.
  • πŸ” The docs gate on shared headers (d9fccfd0): mostly fork-only members, and the shared hunks conflict with headers that moved since.
  • ❌ Pad hold through resets (db9fe35d): a clean gpioHold platform call, kept for the day a MoonLight board needs a pin held.
  • ❌ The product layer: NEBULITE and HELIO effects, the branded dashboard, the battery service, the BLE scene and preview protocol, the handset remote, src/helio/ and the shared-file changes made for them.

October 2026

  • Audio measurement moves past the plain FFT. troyhacks reads 31 third-octave bands from biquad filter banks, checked bar for bar against a hardware RTA; WLED moved its audio-reactive usermod onto ESP-IDF 5 with a background ADC manager; WLED-MM now follows the Audioreactive V2 usermod and its audio-driven palettes; FastLED removed its unused ESP-DSP FFT adapter.
  • Footprint becomes a release issue. FastLED shipped 3.10.6 at 2.5x the flash of 3.10.3 and spent 3.10.7 on a memory sweep; WLED trimmed about 8 KB of flash; new-parser halved its compiler's peak heap so a 730-line script compiles without PSRAM.
  • Large panels expose effect math. WLED fixed seven 2D effects that broke at 128 pixels wide and up, blazoncek updated four effects for large matrices, and WLED's HUB75 buffers moved to PSRAM so a 128x128 panel fits on an ESP32-S3.
  • Hardening against crafted input. WLED fixed a security advisory in playlist JSON and is weighing hardening every network input; blazoncek discards incomplete or oversized UDP packets; new-parser's safe_mode bounds-checks script arrays.
  • The ESP-IDF 5 and 6 migration continues. WLED keeps nightly builds off while main migrates; FastLED builds the IDF 6 release candidate and cuts its ESP32 layer loose from the Arduino core; outside pull requests bring I2SClocklessLedDriver to IDF 6.
  • Verification by execution. new-parser's differential fuzzer runs random programs under QEMU and as C, troyhacks added a checker that reads a running board's audio state, and FastLED records a footprint scorecard per board.

Candidates for MoonLight

  • Differential fuzzing of MoonLive against C (hpwit-new-parser, October 2026): random programs in the C-shaped subset, compiled under QEMU and as C on the host, traces compared and failures auto-reduced; seven compiler bugs in its first run, each kept as a regression script. Builds on the QEMU tier above.
  • Bounds-checked script arrays that stop the script and name the fault (hpwit-new-parser, October 2026): an out-of-range index stops the script with array, size and index reported instead of corrupting memory, at one unsigned compare per indexed store.
  • A fixed-point type written like a float (hpwit-new-parser, October 2026): ffloat (Q16.16) keeps float syntax in an effect script while compiling to integer instructions; a 128x96 Mandelbrot frame takes 50 ms against 62 ms in float.
  • Bound every packet parser by the received length (wled-WLED, October 2026): WLED found three over-reads in one month (playlist JSON, UDP sync, Art-Net and E1.31) where a check compared against the buffer size; worth one audit of MoonLight's DDP, Art-Net and JSON inputs.
  • Run effect tests at large panel sizes and at unlimited frame rate (wled-WLED, October 2026): seven WLED 2D effects broke at width 128 and up (int8 math, infinite loops, float to uint8 casts); a 192x64 test size plus a zero frame time would pin the same class.
  • Fail the build when a board's firmware grows past its budget (FastLED-FastLED, October 2026): FastLED measured size per commit and still shipped 3.10.6 at 2.5x the flash of 3.10.3; MoonDeck's size ratchet records growth without failing anything.
  • Pin every third-party dependency to an exact version (PlummersSoftwareLLC-NightDriverStrip, October 2026): a ^3.10.1 caret range let a FastLED minor release break every NightDriverStrip build with no change in the repo.
  • Same brightness and gamma on network outputs as on wired ones (blazoncek-WLED, October 2026): the fork aligned its virtual bus with its digital buses; worth checking MoonLight's Art-Net and DDP outputs scale the same way as its LED drivers.
  • Measure audio bands with filter banks instead of an FFT (troyhacks-WLED, October 2026): 31 third-octave bands from two biquad banks, verified against a hardware RTA; input for the audio engine issue (#229).
  • Palettes driven by the audio spectrum (MoonModules-WLED-MM, October 2026): five palettes whose colors follow the music make any effect audio-reactive without an audio-aware effect.

September 2026

Candidates for MoonLight

  • Run compiled MoonLive code under QEMU in CI (hpwit-new-parser, September 2026): a tier that executes the compiled Xtensa bytes found three compiler bugs in its first week, the class host tests cannot see.
  • Run every effect with the clock started near a wraparound (wled-WLED, September 2026): WLED's Stream effect broke after an hour at top speed from a 32-bit time compared against a 16-bit one.
  • Temporal dithering and RGBW gamut mapping at output (FastLED-FastLED, September 2026): applied at show time, with a power limiter that charges for the extra white diode; overlaps the parked 16-bit Layer work.
  • Read WLED's "Version 17 - key features" issue (#5867) (wled-WLED, September 2026): the topics a maintainer proposes for WLED's next major version, worth comparing against our own.

September 2025 to June 2026

  • ESP32-P4 / S3 parallel output. FastLED poured effort into the PARLIO and LCD_CAM drivers (P4/S3 parallel LED output, big encode speedups); NightDriverStrip added custom RMT output; hpwit's I2SClocklessLedDriver pushed IDF-5.5 + arduino-less-ESP-IDF support for its I2S/LCD DMA driver (the canonical implementation of this technique), and troyhacks ran ESP32-P4 bring-up branches. The frontier is parallel, DMA-driven output on the newer chips.
  • PSRAM strategy is unsettled everywhere. All four wrestled with PSRAM this cycle, WLED-MM moved preview buffers into PSRAM, NightDriverStrip did a full PSRAM-default reversal (then tuned the threshold), WLED added S3-no-PSRAM builds. Nobody has a clean answer; the cache-disabled-during-flash hazard recurs across repos.
  • Audio-reactive maturing. FastLED added a silence-gate + ESP-DSP FFT backend; WLED-MM and WLED both refined audio sync and auto-disable-during-realtime; NightDriverStrip modernized its SoundAnalyzer/FFT. Audio-reactive is table stakes now, and the polish is in not reacting to noise/silence.
  • The FastLED dependency question. WLED merged a full FastLED replacement (its own color/math); MoonLight already made the same call (own color math, no FastLED in core). Two independent projects concluded the dependency wasn't worth it.
  • UI as a firmware-driven consumer. Both WLED and NightDriverStrip pushed toward "the official UI knows nothing the firmware doesn't publish over the wire", exactly MoonLight's MoonModule-driven, no-hardcoded-knowledge UI principle. Convergent design. NightDriverStrip's 2.0.0 (June 2026) crystallized this: a brand-new web UI, a browser-based installer, and settings (like strip type) moved from compile-time to runtime-selectable on the device, the same "reconfigure live, no reflash" direction MoonLight builds around.
  • Effect velocity. WLED and WLED-MM shipped many new effects (PacMan, Color Clouds, Shimmer, the user_fx pack); new effects remain the most visible user-facing output.
  • Display / HDMI output beyond LED strips. troyhacks ran a cluster of branches probing HDMI video output and large hardware panels (WaveShare 10.1β€³, M5Stack, ESP32-P4 panels), driving displays, not just addressable strips, off the same firmware.
  • On-device live scripting. hpwit's ESPLiveScript compiles small C-like effect scripts that run live on the ESP32 with no reflash, a different answer to effect authoring than C++ recompilation or a fixed effect table.

What these projects do that MoonLight doesn't (yet)

  • A guided setup/installer wizard on-device (NightDriverStrip's Setup Wizard, WLED's installer), MoonLight has the web installer + Improv, but no on-device first-run wizard.
  • A large built-in effect library: MoonLight ships a focused set (concrete-first); the WLED family ships dozens. Breadth is a deliberate non-goal until the core is proven.

Refreshing

Adding a month or a new friend repo is the friend-repos workflow, and its prompt lives there. This folder's own documents are records rather than a feed: they change when the thing they record changes.

Digest prompt (reusable)

Friend-repo monthly digest. For the repo <NAME> (local clone at <PATH>, or via gh api repos/<owner>/<NAME>), summarize what landed on its digest branch during <MONTH YEAR>: the default branch, or the branch or branches its entry's Branch note names where the work lives elsewhere.

  1. Read the merged commits on the digest branch with committer date in that calendar month, once per branch where the Branch note names several (git log --first-parent --since/--until on the local clone, or the GitHub API). Use --first-parent so it's the merged-feature view, not every squashed sub-commit. The default branch isn't always main/master, check (git remote show origin); e.g. WLED-MM's is mdev. 1b. Also investigate the issues over that month. The REST gh api repos/<owner>/<NAME>/issues endpoint returns pull requests too, filter them out (--jq '.[] | select(.pull_request == null)') or use the GitHub search API, which already excludes them: search/issues?q=repo:<owner>/<NAME>+is:issue+created:<YYYY-MM-DD..YYYY-MM-DD> (and the same with closed:). Only real issues, not PRs. The commit log shows what shipped; the issues show what users hit and what the maintainers are prioritizing, the two together are the real activity picture. Skim: notable bugs opened (recurring pain points, hardware quirks), fixes closed that map to a commit, and any heavily-discussed feature request or design thread. Fold the user-facing ones into the summary below (a widely-reported bug that got fixed, a feature the community is pushing for); an issue with no user-facing outcome yet is still worth a one-line "watching:" note if it signals a direction. Don't list every issue, surface the few that matter, the same bar as the commit summary.
  2. Split a month at any release boundary, but only if the release was cut from the branch you're summarizing, judged per branch where there are several. If a versioned release was published mid-month (check git for-each-ref refs/tags / the GitHub releases API; ignore rolling tags like nightly and prereleases), AND the tag is an ancestor of the digest branch (git merge-base --is-ancestor <tag> <branch>), split that month at the release date into ## <Month Year> (up to v<X>) / ## <Month Year> (post-v<X>). If the tag is NOT an ancestor (the project cuts releases from a separate release branch, e.g. upstream WLED tags off 0_15/release branches, not main), do NOT split: keep the month whole and just note which release shipped that month as context, since the trunk you're summarizing feeds future releases rather than being the release line. Whole months with no in-branch release stay one section.
  3. Write an end-user-readable summary: what changed that a user of the library would notice or care about, new features, new hardware/platform support, notable fixes, breaking changes. Skip internal refactors, CI, test-only, and dependency bumps unless they affect users.
  4. Format as short bullet points, each one line, plainest language, minimal jargon. Group only if there's a natural split (e.g. "New" / "Fixed"); otherwise a flat list. 4b. Follow the documentation standards: American spelling, no em-dashes (use a comma, colon, parentheses or a full stop), and one line per paragraph with no hard wraps, since check_docgen reports all three as errors on the file you write. Leave a blank line before every list, including one under a bold group label such as New: the site's Markdown otherwise renders the bullets as one paragraph of dashes.
  5. Add it as a ## <MONTH YEAR> section to docs/friend-repos/<NAME>.md, newest month on top. Don't editorialize or compare to MoonLight, just report what they shipped.
  6. State the commit range / count and the issue query summarized so the digest is auditable, a range per branch. Branches with different results each get their own line, as the Funkelfetisch and troyhacks entries do; when every branch has the same result, one line covering them all is enough, as the hpwit entries do.
  7. Then add any idea worth deciding on to Candidates for MoonLight under the month's section in index.md, creating the section if it is the month's first: one line each, naming the friend repo and month, linked to its digest. Once every repo's digest for the month is in, add the month's Cross-repo trends there too. Here, and only here, the comparison with MoonLight belongs.

When backfilling several months (e.g. since the last release), run this once per month for a consistent timeline, then optionally add a ## Since v<last-release>, overview intro at the top with 3–5 bullets naming the multi-month threads the per-month slices can't show on their own.