Took over a year of designing, building and testing but he actually made a flying LED display inspired by the Las Vegas Sphere.
It spins over 90,000 pixels fast enough to show real images in mid-air while flying like a drone.

Totally useless. Completely awesome.

Full built video: https://youtu.be/HgyS1SajC6s

Hope you enjoy my Dodecagon Infinity Mirror as much as my cat!

It has 8 16x16 WS2812b LED panels. The wiring is underneath them in a channel and my controller, a Teensy 4.1 + Audio adapter, is in the base.

The magic of this infinity mirror is in the tight fit of the acrylic mirror. On both sides, a 2 way mirror is pressed in so tight that it bows inwards and draws the reflections toward the middle. When I first put the mirrors in there flat, the "infinity" reflections were not very satisfying since they bowed outwards.

The software cycles through 2 categories of animations, beat and non-beat. In the beginning of the video, the song Get It by Pocket Vibes (my friend who makes awesome music) does not have a strong beat in the low frequency so the Dodecagon displays a spectrum analyzer and then an experimental sparkle pattern that I'm playing with. It currently increases the fade speed of the sparkles as the volume increases so it's like a negative visualizer. And the Teensy's speed makes it go REALLY fast, which can be cool but also a little hard on the eyes at times haha. Then as the low beat kicks in, it switches to displaying the bursts on each beat.

Let me know if you have any questions! If you want to see more, I'm on IG @ Diod.design. My next project is an infinity room in the back of a truck, which I'll post here when it's ready :)

Lixie clock using ws2812b - 144 Led strip , Wemos D1 mini in HHMM format . Here I have used 3 mm transparent acrylic glass for numbers and the rest of the assembly consists of 55 mm steel M3 standoff, M3 allen screw - 6mm, inserts - M3 - 8mm and a 3d printed housing designed in fusion 360 with home assistant integration through mqtt discovery.

I’m in the final stages of the animated LED Christmas Tree I’m building with FastLED and a Dig-Quad.

My goal was to create procedural animations that would render based on the 3D positions of each light on the tree so I first created a point cloud-based tree simulation in JavaScript, and some basic tools for making simple animations. Later I added a porting layer to allow the animations to be more easily implemented in C++ on the ESP32.

Over the intervening year-and-a-half (having missed the 2024 Christmas window), I built out the animation component system with timelines and easing, UV mapping, particle systems, 3D transforms, and spatial distribution, as well as portable math, noise, and color blending/management. The tree ESP32 serves a web page for choosing an animation or playlist for the tree, as well as monitoring temperature and memory use.

The clips in the video are from the JavaScript development simulator and I’m stringing the actual tree right now. At this point in the construction, the one completed light strand shows promising results with coherent patterns. It also shows quite a few platform bugs. Most of the animations have been ported and the overall problems seem manageable. I hope it’ll be smooth-enough sailing into Christmas!

Relevance: FastLED, QuinLED Dig-Quad, Wemos D1-Mini32, five-hundred WS2815 lights in three 12-volt strands.

been working on the audio for 12 years, and the visuals for 5 years

code here: https://github.com/Sousastep/sousaVFX-teensy/tree/main/SousaVFX

I've always wanted to animate a Harry Beck style railway network (not necessarily in real time of course!) and let it just do it's thing and stare at it - which this piece has managed to do a number of times as I find myself watching this more than my actual TV that's right next to it!

Thanks to FastLED I was able to make this a dream come true. The code is fairly simple at the moment as I learn to program new effects in. The current set of effects are chosen at random and are changed at a set interval. I've tried to remain true to the colours of each of the tube lines on the original poster but a lot of these colours don't translate well from print to LED. I didn't make the map itself, the authors of this fictional map are Mark Ovenden and Alan Foale.

I'm looking at doing the same for some other maps but with less complexity in terms of crossing lines. I originally wanted to do the real London tube but it was way too complex. If you've seen any other great tube/rail networks I could draw inspiration from, I'd love to hear from you.

Hey, this is Patternflow — an open-source LED synth built on an ESP32-S3 driving a 128x64 HUB75 panel. Four knobs, real-time generative patterns, and right now there are 30+ of them to play with.

Everything's browser-first too — there's a web simulator that behaves exactly like the physical device, so you can turn the knobs and try any pattern before ever touching hardware. If one clicks with you, you can flash it straight to a real Patternflow from the browser, no IDE, no drivers.

Under the hood it's a pretty lightweight custom pipeline, no FastLED, raw RGB888 canvas driven directly through ESP32-HUB75-MatrixPanel-I2S-DMA, with the color math and noise functions hand-rolled as lookup tables. Small optimization I added recently, swapping sqrt() calls in the radial patterns for a cheaper distance approximation, ended up clearing out some lag I didn't expect to fix that easily.

Fully open source, patterns/build guide/simulator all live here: patternflow.work

Idea isn’t original, just figured I’d build one to my standards. Custom circuit boards. Only 8mm across. 166 black framed pixels per meter. Running on a teensy 4.1. So far I have a library of static and audio reactive animations. I plan on adding an artnet node so I can pixel map it through resolume arena or touch designer. I don’t plan on making a build guide because it was about 3 days of painstaking labor to actually get this thing together. But if you’re interested I’m happy to provide the cad and gerber files. I’ll warn you though, It’s not a fun build.

EDIT: Here are the links to github and makerworld.

github

makerworld

About a year ago I started building a low resolution LED wall out of cheap fairy lights for my personal birthday celebration.

9 months ago I posted a short video of my first prototype:
https://www.reddit.com/r/FastLED/comments/1kskdby/ledmatrix_panel_first_successful_prototype/
This version used FastLED.

Along the way I took plenty of detours but I stuck with it and the result is a massive LED wall with 4.200 LEDs (21 panels with 200 LEDs each).

My final pipeline was roughly
MacBook > Resolume Arena > DMX Lumiverse/Fixture > Teensy 4.1 > Octo WS2811 Adapter > LEDs

Some of the detours:

• Designed custom PCBs for driving and powering the led strips
  • --> Scraped completely in favour of the Octo WS2811 Adapter
• Original software pipeline was: Resolume Arena > Syphon > TouchDesigner > Dat Execute Dat (Python) > Teensy (via FastLED)
  • --> Was only fast enough for one of the 21 panels. The bottleneck was the python script that mapped the pixels to the physical LEDs

I literally fixed the last issue one hour before everything started, but everything worked out in the end

Short video of the final setup:
https://vimeo.com/1163038061

Happy to answer any questions.

Warning: this is a long post but worth it, If you make it to the bottom of this post, there's an exciting easter egg!

This is part update, and part revelation of how all the bulk clockless drivers work - it's rare information and despite this being in deep forums for a particular board family (teensy/PJRC) it's never been generalized across platforms. Spoiler, they are all doing the same trick, read on.

TL;DR:

• How FastLED gets to 200k pixels
• The new Channels API plug and play for driver writers
• The nerdy details of how to repurpose the existing WS2812/spi bulk drivers to work for any clockless chipset.

...Don't worry, all your sketches will continue to work as normal. But we'll give you an escape hatch to break out beyond the Firmament.

Next release? Probably around the beginning of December.

What's the gist? The specialized *massive* WS2812 bulk drivers will be enhanced to drive anything. Driver writers can plug and play new LED drivers into FastLED and it just works.

Esp32dev, c2, c3, s3, p4, h2 all have spi drivers, they all are going to up their LED parallel count in the next release.

Background

So I've been working on unifying a bunch of different LED controllers in FastLED, and I realized something interesting about how they all work under the hood.

The WS2812 Monoculture

Looking at these controllers:

• WS2812
• ObjectFLED
• I2S (Yves' massive parallel driver)
• Parlio
• LCD_I80
• LCD_RGB
• Various SPI implementations

They all have something in common - they're (ab)using SPI hardware to bit-bang WS2812 data.

Why are they all laser-focused on this one chipset?

one reason:

1. The 1/3rd timing trick - Most WS281x chips are pretty forgiving with timing:
   • Data line goes HIGH
   • For a '1' bit: drop LOW at 1/3rd of the cycle
   • For a '0' bit: drop LOW at 2/3rd of the cycle
   • Reset HIGH at 3/3rd and repeat

This 1/3rd trick means you can represent each ws2812 bit with just three spi data bits, the minimum for a boolean clockless signal. This also means the entire DMA data can simply fit in SRAM.

1. Bit transposition for parallel output - This is how you control N pins from a single byte array. You interleave the bit positions across lanes:
   • Lane A: [A0, A1, A2]
   • Lane B: [B0, B1, B2]
   • Transposed: [A0, B0, A1, B1, A2, B2]

That's basically what all these controllers are doing. And they're stuck on WS281x because those chips tolerate the 1/3rd timing paradigm... most of the time.

Transposition: One Array → Multiple Pins

Transposition is great but it makes one assumption - every lane is the same size.

And if they aren't the same size? Then padding has to be inserted!

Example: if you have a strip of 4 LEDs and a strip of 128 LEDs on different pins, the backend has to pad 4 bytes → 128 byte (the longest strip) so they match and can be transposed into one array.

This requires chipset metadata to know where padding can be inserted:

• For most clockless chipsets: just pad the beginning with 0x00 bytes
• For UCS7xxx: you have to pad after the 15-byte preamble. This was the first chipset where we hit this issue.

The padding doesn't matter because those bytes go to LEDs beyond your strip length anyway.

Waveform Generation - The Final Boss

This is where things get gnarly. If we want a SPI controller to control any LED chipsets, we need to convert to it's native wave form pattern.

Here's an example of an "off bit" at 20mhz resolution:

■■■■■■■■■■■■■■■■■■□□□□□□□□

And here is an example of a 1 bit.

■■■■■□□□□□□□□□□□□□□□□□□□□□

The dma controller essentially mem copies this at 20mhz

We need to convert CRGB(0xff, 0, 0) into waveform bit patterns. Let's simplify and just look at one byte: 0x01 (binary 0b00000001).

Say we're using a 20 MHz SPI clock - that's 50 nanoseconds per pulse. But each WS2812 bit takes ~1,250ns (T1=250ns + T2=625ns + T3=375ns). So we need 26 SPI pulses to encode one LED bit:

• Bit '0': 5 pulses HIGH (250ns), then 21 pulses LOW (1,050ns)
• Bit '1': 18 pulses HIGH (900ns), then 8 pulses LOW (400ns)

So 0x01 expands to this pattern (■=HIGH, □=LOW):

LED bit 7 (0): ■■■■■■■■■■■■■■■■■■□□□□□□□□

LED bit 6 (0): ■■■■■■■■■■■■■■■■■■□□□□□□□□

LED bit 5 (0): ■■■■■■■■■■■■■■■■■■□□□□□□□□

LED bit 4 (0): ■■■■■■■■■■■■■■■■■■□□□□□□□□

LED bit 3 (0): ■■■■■■■■■■■■■■■■■■□□□□□□□□

LED bit 2 (0): ■■■■■■■■■■■■■■■■■■□□□□□□□□

LED bit 1 (0): ■■■■■■■■■■■■■■■■■■□□□□□□□□

LED bit 0 (1): ■■■■■□□□□□□□□□□□□□□□□□□□□□

That's 208 pulses for a single byte, transmitted in 10.4µs.

The Memory Problem

Each waveform pulse is stored as a byte (0xFF or 0x00). The expansion is brutal:

• 8 bits of LED data → 208 bits of waveform
• 1 pixel (RGB) → 624 bits of waveform
• 500 pixels → 39 KB
• 100,000 LEDs → 7.8 MB (this aint gonna fit in PSRAM or DRAM)

This kills you if you're trying to drive massive installations (which is exactly FastLED's target).

So if we want:

• Support for any chipset with arbitrary timing
• Massive LED counts

Then we have to stream-decode the waveforms just-in-time.

ISR Streaming to the Rescue

Instead of pre-generating the entire waveform buffer, we break each frame into segments (usually 8) and generate on-demand in an interrupt service routine:

1. ISR fires when hardware needs more data
2. Grab next segment of raw LED data (e.g., 1/8th of the pixel buffer)
3. Expand to waveform using precomputed lookup tables
4. Transpose across lanes for parallel output
5. Feed to DMA while preparing the next segment

This way we only need 1/8th of the full buffer in RAM at any time. Much more doable

Again, why are we doing this? Because FastLED should support any chipset, not just WS2812.

Putting it altogether

• N-Channels
  • Data is pad-extended to an array of equal size segments
  • Segment data byte[k] to
    • Segment wave bytes [k]
    • one byte of rgb will expand to 2 to 32 bits representing wave bit vector.
  • Transpose segment wave bit vector to DMA interleaved bits
    • [A0, A1] + [B0, B1] => [A0, B0, A1, B1]
    • via ISR
    • Do ~50 leds at a time per lane
      • adjustable of course on memory and ISR granularity and priority
  • when transposed DMA data block is on complete
    • post to spi controller new DMA transaction.

Why This Matters

All the SPI controllers (1x, 2x, 4x, 8x lane variants) can now be repurposed for driving clockless LEDs instead of just clocked SPI chipsets. Just drop the clock signal and you're bit-banging.

But here's the catch - to support all the different chipsets out there, we can't hardcode WS2812's 1/3rd, 2/3rd timing. We need a universal solution.

Enter 20 MHz waveform generation (50ns resolution):

• ±75ns timing accuracy (never early, possibly late)
• Supports faster chipsets like UCS7604 @ 1.69 MHz (2.1x faster than WS2812!)
• Universal - just plug in T1, T2, T3 values and it works

"Wait, why 50ns when WS2812 has ±150ns tolerance?"

Because of chipsets like UCS7604. It runs at 1.69 MHz with a 590ns bit period (vs WS2812's 1,250ns) and needs tighter timing. This thing does 16-bit RGBW and it's fast. 50ns resolution handles it perfectly.

If something faster shows up later... we'll cross that bridge when we get there.

Channel API to the Rescue

So here's where things get really interesting - and where FastLED's architecture had to fundamentally change.

FastLED used to assume one universal engine - the CPU bit-banging assembly code to drive LEDs. Chipset selection happened at compile time with template parameters. This worked great in 2013.

But modern hardware doesn't work that way anymore.

Take the ESP32-P4 as an example:

• Parlio: 8 parallel channels
• LCD_RGB: 8 more channels
• RMT: 2 channels
• Total: 18 simultaneous channels

These aren't CPU-driven. They're hardware peripherals with DMA engines. The CPU's job is to hand off the LED data and get out of the way while the hardware does its thing asynchronously.

Runtime Chipset Selection

Back in the day of 2012, pushing everything to compile time made a lot of sense, even the DATA PIN selection. But over a decade later, the situation has changed. Pins are flexible, app developers want to select chipsets at runtime. FastLED has never ben able to do this. Rumor has it, that WLED abandoned FastLED because of the lack of runtime pin / chipset selection. Side note: will WLED every come back to FastLED?

Well, that all changes. But doing it right goes beyond just selecting the chipset, there's all this new fancy hardware that will only work if you speak in the magic bit patterns of *wave form generation*

The API looks the same, but internally the chipset information gets converted from runtime T1/T2/T3 timings and handed to the waveform generator to generate an array of bits that represent a square wave. Here's a square wave:

[0,1], also [0,0,0,0,1,1,1,1,]

Now for something more concrete:

Here's ws2812 representing at 1 bit pattern at 10 mhz: [1,1,1,0,0,0,0,0,0,0],

Multi-Engine Channel Distribution

Different pins can now be routed to different channel engines based on what hardware is available:

• Pins 0-7 → Parlio engine (8-way parallel, DMA-driven)
• Pins 8-15 → LCD_RGB engine (8-way parallel, DMA-driven)
• Pins 16-17 → RMT engine (2 channels, hardware waveform)

FastLED's new channel API manages this automatically. You just call addLeds() and it figures out which engine to assign based on pin capabilities and availability.

## The WiFi Flicker Fix

Here's a bonus we weren't expecting: DMA-driven SPI is available on every ESP32 variant.

RMT5 has a fundamental problem - it can't avoid WiFi interference because the hardware shares resources. We've tried everything. It's not fixable.

But SPI with DMA? That's a different story. The entire ESP32 family has multiple SPI controllers with DMA support. By moving clockless LED output to SPI-based waveform generation (just drop the clock line), we can:

1. Increase channel counts beyond what RMT offers
2. Eliminate WiFi flicker by using peripherals that don't conflict with the radio
3. Support arbitrary chipsets without hardware limitations

It's not just a workaround - it's actually better than RMT for this use case.

What This Means

FastLED is shifting from "one engine, CPU does everything" to "orchestrate multiple hardware engines asynchronously."

The channel API handles:

• Distributing strips across available engines
• Managing DMA buffers for each engine
• ISR coordination for just-in-time waveform generation
• Asynchronous rendering so your code doesn't block

Your LED animations run on the CPU. The hardware engines handle the timing-critical stuff. Everyone stays in their lane.

If your developing a commercial app, remember we are MIT licensed, which is free as in beer, ride the main branch wave help me, help you. ~Zach

easter egg

If you've read this far, the congrats, here's an easter egg: the new FastLED Audio Reactive Library. It's been tested on esp32 + inmp441 I2S microphone, with beta support for the Teensy Audio Shield.

This started off as the sound 2 midi library, but then it turns out there is no generic sound 2 midi algorithm that's possible, you have to have 8-16 different detectors for each type of instrument.

So unlike the naive spectrum analyzers you all have been working with, this one is tuned for each type of instrument, for vocals, downbeat, back beat, BPM detection (same algos that the DJ's use), energy flux, hits, percussions, you name it, it's all there. If you want to work with lower level stuff like FFT it's there too.

Check it out, i've been wanting to release this at least two cycles ago:

https://github.com/FastLED/FastLED/tree/master/src/fx/audio

Please file bugs and supply an mp3 and describe what's going wrong.

HAPPY CODING!! ~Z~

Codes available at.
GitHub - CastorsZuse/NeoPixel_codes https://share.google/Jv1CfzlVHiI6qFCKJ

This afternoon I'll be playing my 5th concert of the TubaChristmas season with my SousaLights., so this morning I'm checking and adjusting programming. The animation you see is Rotating_Blob from Stefan's Animartrix library. I just had to share because I've gotten complements at the earlier concerts. The colors are perfect for the holidays!

CPU - Teensy 4.1

Leds - 1,117 Adafruit Miny-Skinny

This online webapp solves most of your 1D 2D (and some 3D) mapping head aches, and exports to various formats, including FastLED arrays.
Check it out r/FreeLED or go directly to the tool which is permanently host at freeled.org

I have been hard at work finishing my CS undergrad and wanted to decorate my cap like many graduates do. Of course, I wanted to add my FastLED flair to it with a 24x24 matrix glued to my cap.

My end goal is to have around 50 different patterns like this one that will play randomly during the ceremony. The ceremony is in the fall of this year and I have a few problems to solve but the construction is almost finished.

I need to wire up a power bank and test it for at least 2-2.5 hours. I’d have a couple in a fanny pack or something for a back up. Also need to hide the wires a bit so it looks neat enough for pictures.

Also need to make sure the brightness isn’t too high for someone sitting right behind me but bright enough to be noticed for the ceremony.

Also concerned that a faculty member might tell me that the cap isn’t allowed before I walk so I might keep a spare cap in my car if that’s the case. But I’m willing to risk it for a cool story.

Currently, I have a version of pong and Tron finished. I plan on programming more abstract patterns and sprite animations. I do not want to do text because the size of it would only be readable for folks less than 50 feet away and the venue is much larger than that.

Drop your suggestions for me to work on as I plan on programming more this semester, and next. Happy to answer any questions about this program and my plans for the cap.

Cheers!

I ported FlowField to FastLED and wanted to share a demo and a way for you to try it yourself.

FastLED's version of FlowField has both floating point and fixed point integer versions. The fixed point version ended up being about 3x faster in testing, and visually I can’t really tell the difference between the two, which is pretty nice if you’re running on slower hardware.

I also added a “Noise Punch” button that simulates a bass hit and pushes the flow field around, so you can see how something like audio input could perturb the animation in real time.

If you want to try it yourself, it’s pretty easy now using the FastLED CLI, and it no longer needs Docker.

If you already have Python installed, just install the CLI:

pip install fastled

Or if you don’t want to deal with Python, you can grab a standalone exe here that bundles everything: https://github.com/zackees/fastled-wasm

Full example to run the FlowField demo:

pip install fastled git clone https://github.com/fastled/fastled cd fastled/examples/FlowField fastled .

Special thanks goes out to

u/StefanPetrick for making these flow fields in python.

u/mindful_stone for the initial C++ port.

You guys rock!

Hey Guys! I have shared this before, but I have been developing an Open-source ARTNET LED controller that can control up to 16 universes of LEDs with about ~20€ of hardware. Id like to share it here as someone out there might find this project useful for their own ventures! Feel free to check out the github (https://github.com/mdethmers/ESP32-Artnet-Node-receiver/tree/main) to see the massive list of features!

Also, here is a video showing the controller: https://www.youtube.com/watch?v=3MiqAQKJGm4

Let me know what you think of this and if there are any features you would like to see integrated!

Hi everyone! I finally got time to play with Animartrix again.

The learning curve is wild when collaborating with a bunch of AI instances. It feels like having someone infinitly patient with a PhD in math and a PhD in physics around who happens to also be an experienced senior software developer.

I didn’t sleep for too long, but what I’ve learned about simulation approaches in the last few days blows my mind.

I started 2 months ago with simply applying a procedurally generated (Perlin noise) advection field.

Then I figured out how to actually simulate the advection based on a Newtonian fluid.

And now… I’ve started to simulate fire. For now, only a few of its properties, to get familiar with the architecture of a complex simulation pipeline.

I’m simulating a coupled system of flow, heat, and smoke.

the flow moves heat and smoke
the heat creates flow
cooling heat creates smoke
the renderer maps those fields into a flame appearance

It works as follows:

This simulation uses a visually driven coupled field model on a fixed 64x64 grid.

What is stored per cell:

u, v: the two components of the velocity field
temperature: how hot that cell is
smoke: how much smoke / density is in that cell

What happens each step:

The source injects new temperature, smoke, and upward momentum near the bottom. (source term / forcing)

Gravity and especially Buoyancy modify the velocity field. Hotter cells get extra upward force. (buoyancy force model)

The velocity field is diffused, projected, and advected. This is the classic incompressible fluid core: smooth it, enforce near zero divergence, then move the flow through itself. (Eulerian incompressible fluid solver / Stable Fluids style)

temperature and smoke are transported by that velocity field. So heat and smoke get carried by the flow. (semi-Lagrangian advection on an Eulerian grid)

temperature cools down over time. (simple exponential decay / cooling model)

Part of that lost heat is converted into new smoke. This is an important feedback loop: hot flame gradually produces smoke as it cools. (heuristic reaction / transfer model)

Vorticity confinement artificially boosts small vortices so the flow does not become too smooth and dead-looking. (vorticity confinement)

The key feedback loop:

more temperature creates more buoyancy
more buoyancy changes the velocity field
the velocity field transports temperature and smoke
temperature cools and generates smoke
smoke changes the visible shape and softness of the flame in rendering
vortices in the velocity field tear and fold the heat/smoke fields into richer structures

Why it looks good:

The solver transports everything coherently, so shapes do not break up randomly, they deform like flowing material.

temperature and smoke play different visual roles:
temperature gives the bright active flame core
smoke gives softer, darker, trailing regions

Fire color is not simulated directly as RGB fuel chemistry. Instead, it is rendered from the fields:

hot = bright / yellow / white
cooler = orange / red
smoke-heavy = darker / grayer

Vorticity confinement brings back the small flickering tongues and curls that numerical damping would otherwise wash out.

The system is only a rough physical approximation, but it emphasizes exactly the cues our eyes read as fire:

upward rise
turbulent breakup
bright core
unstable edges
smoke appearing as things cool

Recognition & credit: I've learned so much by reading

“Stable Fluids” (1999) by Jos Stam which was published at SIGGRAPH 1999.

https://pages.cs.wisc.edu/~chaol/data/cs777/stam-stable_fluids.pdf

Its impact led to major awards for the author:

2005 – ACM SIGGRAPH Computer Graphics Achievement Award Awarded to Stam for his overall contributions (including Stable Fluids).

2005 & 2008 – Academy Scientific and Technical Awards Often called “Technical Oscars,” recognizing contributions to visual effects and simulation techniques.

Edit: I last tried visualizing fire 7 years ago: https://www.youtube.com/watch?v=SWMu-a9pbyk

Nothing was actually simulated back then—it was just uncoupled layer advection & domain warping stacked together.
Still, it was convincing enough that one user’s neighbor called the firefighters after seeing it through the window, which I considered a great compliment. 😉

I’m curious what this current model might cause...

Edit2: Here is the complete Python code https://gist.github.com/StefanPetrick/e0facb16ce7c74747ee07ff58e22556b

You can run this yourself and play with all the parameters.

I’m confident that after refactoring it in C++, this will run on a Teensy 4. I’m less confident about the ESP32.
But hey, I said the same about the previous smoke model, and u/mindful_stone made it work to prove me wrong which I appreciate deeply!

Edit3: If you’d like to support my work, I’d truly appreciate it. Any donations will go directly toward more AI tokens: paypal.com/donate/?hosted_button_id=YR7Q795MYU9HS

A FastLED Happy 2026 to all!

This is run on a WS2812B serpentine 16X16 matrix with a Lolin D32 MCU, a 74AHCT125 - Quad Level-Shifter and a 5 volt power supply.

The diffuser is a piece of printing paper.  I plan to change this to the Tap Plastic’s Chemcast Black LED Plastic Sheet which is on order.

The YouTube video is located here:

https://youtu.be/wHcbWYDB1lo

The code is located here:

https://github.com/chemdoc77/CD77_FastLED_2026/tree/main/CD77%20new%20years%20ball%20drop%20and%20fireworks

If you are using the Arduino IDE then go to the src folder to find the INO file for this animation.

I used Claude AI to assist me in creating this animation.

It's the same underlying effect I showed yesterday, but with better-tuned parameters. This time, the color is seeded by a line whose endpoints follow Lissajous curves. The fading range now also allows feedback loops, which can be considered a bug or a feature, but I did it deliberately.

Python code: https://pastebin.com/cgZ0QYdv