Skip to content

History — index

The backward-looking half of the docs (the forward-looking half is ../backlog/). This folder is not present-tense and agents don't read it automatically — only when planning new work. See CLAUDE.md § Documentation for how history/ and backlog/ relate.

Living index — kept current as the friend-repo digests are updated each month; the git log carries exact dates.

What's here

Three kinds of document:

Friend-repo activity digests

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

Prior-project inventories

One-time surveys of earlier projects, used to decide what to harvest into projectMM. Reference, not maintained.

Our own lessons

  • lessons.md — hard-won debugging lessons and gotchas (a bug, its cause, the fix), recorded with the code that proved them and pruned as they are absorbed (the PR-merge carry-forward gate writes here). Genuine architectural decisions live in ../adr/ instead; a lesson that hardened into a rule lives in CLAUDE.md / coding-standards.md.

Reading across the friend-repo digests, the themes the wider ESP32-LED ecosystem converged on over this release cycle (Sept 2025 → 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 modernised 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 colour/math); projectMM already made the same call (own colour 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 projectMM's MoonModule-driven, no-hardcoded-knowledge UI principle. Convergent design. NightDriverStrip's 2.0.0 (June 2026) crystallised 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 projectMM 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 projectMM doesn't (yet)

Observational — where the landscape is ahead of projectMM. These are not commitments; real adoption decisions live in the ../backlog/, cross-referenced where one already exists.

  • Parallel multi-strip output on S3/P4 (PARLIO/LCD_CAM, and hpwit's I2S/shift-register drivers) — the direct parallel drivers ship (MultiPin/Moon on LCD_CAM, Parlio on P4, driving up to 16 strands and 12,288+ lights). The shift-register/'595 expander path also ships but is dormant: it works at prime-only geometries yet has a known lapping-ring sparkle at the largest configs, so it stays off by default. See the LED-driver analysis.
  • Audio-reactive input — none of projectMM's effects are audio- or motion-reactive yet. The Peripheral role + the Pi-sensor backlog entry are the foundation; the producer→effect wiring is backlog.
  • A guided setup/installer wizard on-device (NightDriverStrip's Setup Wizard, WLED's installer) — projectMM has the web installer + Improv, but no on-device first-run wizard.
  • A large built-in effect library — projectMM ships a focused set (concrete-first); the WLED family ships dozens. Breadth is a deliberate non-goal until the core is proven.
  • On-device live effect scripting (hpwit's ESPLiveScript) — projectMM effects are compiled C++; there's no runtime script path. Not a goal today, noted as a landscape contrast.

Refreshing

To add a new month (or a new friend repo), run the digest prompt below. When a thread meaningfully shifts, update this index's "cross-repo trends".

Digest prompt (reusable)

Friend-repo monthly digest. For the repo <NAME> (local clone at <PATH>, or via gh api repos/<owner>/<NAME>), summarise what landed on its main/default branch during <MONTH YEAR>.

  1. Read the merged commits on the default branch with author-date in that calendar month (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 prioritising — 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 summarising. 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 summarising 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.
  5. Add it as a ## <MONTH YEAR> section to docs/history/<NAME>.md, newest month on top. Don't editorialise or compare to projectMM — just report what they shipped.
  6. State the commit range / count and the issue query summarised so the digest is auditable.

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.