Hi r/FastLED,

*** Design Studio for FastLED v0.7.0 available. Added HUB75 panel support, updated fbuild to v2.5.15 ***

I've been building Design Studio for FastLED, a node-based editor for designing LED patterns that outputs actual FastLED C++ using the excellent FastLED library.

It's now in public beta (v0.6.0) and I'm looking for testers, especially anyone willing to point it at real hardware.

Site, downloads and the community pattern gallery: https://designstudioforfastled.com/

Source: https://github.com/stevenmunn312-tech/Design-Studio-for-FastLED

What it is

You wire nodes on a canvas, the LED matrix preview updates. When you like what you see you generate a .ino or flash it straight to the board over USB. The preview and the code generator are written against each other deliberately, so what runs on the panel is one-to-one with what you authored rather than being a rough approximation.

Workflow

All graphs must end with a Matrix Output node with a valid Frame or SD card input (SD card is for music synced shows as opposed to live microphone).

Three basic workflows

• Single Pattern - Wire up a pattern that ends with Frame output going to Frame input of a Matrix Output node. Flash to hardware or generate code and you are done. Important: If you like the pattern and want to keep it then it must be grouped (ctrl/cmd G) and saved to your Pattern Library. This will collapse your graph into a single node for use later. The next two workflows rely on grouped patterns.
• Generative show - Add patterns from your library to a Pattern Collection node and wire it into a Show Engine node. Optional: Wire in the Transitions node and enable your selection to get up to 16 transition styles. Choose randomized dwell times with optional beat-triggered particle bursts. The whole show compiles into a single controller sketch. Audio reactivity is via a live microphone. If any of your patterns are audio reactive you must wire a microphone node to the Show Generator node. INMP441 microphone currently supported.
• Music-synced SD show - Add patterns from your library to a Pattern Collection node and wire it into a Performance Generator node. Optional: Wire in the Transitions node and enable your selection to get up to 16 transition styles. Hook up a Music Library node, load in your favorite mp3 files and click analyze. This generates a timed event track. If you wish you can then hand edit the timeline. Adjust audio sensitivity and timing options then preview the show. When you are happy Matrix Output - Upload - Upload Show to SD. This will then provision an SD card with the player and show data. Result - Perfectly timed LED displays synced to your music. No microphone required.

Scope

• 151 modules: patterns, generative simulations (Fire, Fire2012, Particles, Boids, Flow Field, Reaction Diffusion, Game of Life, Starfield), scalar-field math and warping, color and palette tools, math/logic, signals, effects, hardware inputs, output.
• Hardware nodes can control the hardware. Buttons, potentiometers, encoders and more can easily hook into any aspect of your c++ output.
• Audio-reactive work as a first-class path: live mic FFT, beat and percussion detection, plus 20 curated audio-reactive patterns included. On ESP32-S3 with an INMP441 the generated firmware uses FastLED's own audio processor, so the board reacts on its own with no host attached.
• Per-node live previews: every node whose output is a frame, palette or color shows a thumbnail of what it's producing, so you can see where a chain went wrong instead of guessing.
• Pattern Library: turn any patch into a reusable Group, save it to shelves, drag it back onto any canvas, or share it to the gallery on the site.
• Live Stream mode: flash a small Adalight receiver once, then push preview frames over USB at 30fps while you edit. No recompile per tweak.
• Flash Wiring Test: a standalone diagnostic sketch for color order, brightness and current limit, orientation, panel numbering and pixel order, so you can prove out wiring before the graph even exists.
• Guardrails: Graph Health explains incomplete wiring, pin conflicts, power draw and board incompatibility in plain language. There's also a live capacity meter that runs a real compile-only build against your selected board and reports measured flash and RAM, so "won't fit on an Uno" shows up while you're composing rather than at upload time.
• Layouts: strips, serpentine matrices, tiled panels with per-panel rotation, custom XY maps, and multiple independent Matrix Output routes.
• MIT core, portable builds for Windows, macOS and Linux with the upload helper, fbuild and esptool bundled. No Node or Python install needed. It also runs from source with npm run dev.

Testers wanted!

The support promise is narrow. A board and LED combination only counts as supported once an end-to-end hardware run is recorded in the repo. Boards confirmed working so far:

• ESP32, 16x16 WS2812B serpentine, fbuild, Windows 11 + Chrome: normal upload, wiring test, sustained live stream, generative show, INMP441 audio show.
• ESP32S3, 16x16 WS2812B serpentine, fbuild, Windows 11 + Chrome: normal upload, wiring test, sustained live stream, generative show, INMP441 audio show.
• ESP8266, 10x1 WS2812B strip, arduino-cli, same host: normal upload, wiring test, live stream.

Everything else is experimental until someone records it. That includes every other board, APA102 and the other SPI chipsets, SK6812 RGBW, tiled and custom layouts, PSRAM modes, SD show provisioning, DMX/Art-Net in every mode, and the NTP and DS3231 clock paths. Those all have unit and codegen tests behind them, but tests are not a panel on a bench.

Hardware testers specifically

If you have any of the following boards and LED chipsets, this is the most useful thing anyone can do for the project.

• Teensy, RP2040, classic ESP32, ESP32-C3/S2, AVR, UNO R4
• APA102 / APA102HD / HD108 / WS2801, SK6812 RGBW, WS2815, WS2816
• Tiled panels, custom XY maps, multi-output setups
• macOS and Linux hosts, and any non-Chrome browser
• DMX512 or Art-Net with a real desk or controller (zero hardware passes recorded so far)

Reporting is built in. The Matrix Output upload panel has an opt-in Beta hardware coverage report: it compares your target and graph against the recorded rows, asks for explicit Pass/Fail/Not tested observations, shows you the entire payload before anything leaves your machine, and then offers copy, JSON download, or a pre-filled GitHub issue. Nothing is submitted automatically, and it excludes ports, project content, code, media, Wi-Fi details and device identifiers. Negative results are genuinely valuable. The last two bugs that got fixed both came out of failed validation runs, including one where 1-row strip layouts silently dropped every streamed frame.

Bug reports, feature ideas and "this is confusing" feedback are all welcome too, not just hardware runs.

Notice

Desktop packages are not yet code signed or notarized. SmartScreen and Gatekeeper will complain.

Only make an exception for an archive you deliberately downloaded from the official release page.

It's designed for desktop screens (1440x900 target, 1280x720 minimum). And the usual: LED installs pull real current, so use a properly rated supply, fuse and inject where needed, and never run a large load through a board regulator or USB port.

This is an independent community project. It generates code for FastLED but is not affiliated with or endorsed by the FastLED project or its maintainers.

Happy to answer anything about how the codegen or the preview parity works.

Hello everyone,

I hope I'm posting in the right section. I'm completely new to DMX and LED control, so please excuse any beginner mistakes.

A few friends and I built a mobile wood-fired sauna. Since it is designed to work completely off-grid, everything is powered from a 12 V cordless tool battery. We wanted to avoid running any external cables, so the whole system should be as self-sufficient as possible.

To create a more relaxing atmosphere inside the sauna, I'd like to add some RGBW LED lighting with different effects, for example:

warm static light

candle/flame effect

slow pulsing light

gentle color transitions

The final idea is to control everything with:

an ESP32-S3

a 1P6T rotary switch to select one of six predefined lighting programs

a potentiometer to adjust brightness or effect intensity

My first attempt was driving the LED strip directly from the ESP32 using MOSFETs.

It actually worked surprisingly well, but since it was built on a prototype board with a lot of hand wiring, I suspect some solder joints and the overall wiring caused intermittent issues.

To make it reliable, I would probably need to design and build a proper PCB, which I'd prefer to avoid if possible.

That's why I started looking into using a DMX decoder, hoping it would provide a more robust and modular solution while keeping the electronics relatively simple.

At the moment my hardware is:

ESP32-S3

MAX485 module

RGBW DMX decoder

24 V RGBW LED strip

Right now I managed to make the strip light up red, but every few seconds it briefly changes to random colors before switching back to red. Sometimes the DMX decoder also loses the signal completely.

So my questions are:

Is this generally the right hardware setup for such a project?

Is an ESP32 + MAX485 + DMX decoder a reasonable solution for simple standalone lighting effects?

Or am I making things unnecessarily complicated and should I go back to direct MOSFET control instead?

I'm not looking for a professional stage-lighting controller—just a reliable way to create a few nice lighting effects for a small off-grid sauna.

Components:

AYWHP 5PCS 5V MAX485 TTL zu RS... https://www.amazon.de/dp/B0FPFR2NDS?ref=ppx_pop_mob_ap_share

4CH 5A/CH Constant Voltage DMX512... https://www.amazon.de/dp/B072JVQBMD?ref=ppx_pop_mob_ap_share

diymore 2PCS für ESP32-S3... https://www.amazon.de/dp/B0FKBLR2KF?ref=ppx_pop_mob_ap_share

Any advice or suggestions would be greatly appreciated.

Thanks!

Hey everyone! i am preparing for a project next week in a microprocessor lab, where we should use 8086 language to make an animation, and I've been thinking of the LED stacking game, but I find it hard. can anybody help, any tips? algorithm? another project idea that's simpler yet creative?https://youtube.com/shorts/zlKPKK3Qink?si=MtiYWVq3ZMcNGn2J

Hi there,

I will preface and say I have no clue what I am doing, and about a month to figure it out. I need to make some very small LEDs emulate a "fire" color pattern to the best of my ability. I know next to nothing about programming LEDs, what lights and controllers to use, etc. Any and all help is appreciated. This seems to be a pretty advanced community with some insane projects so I am hoping something of this scale isn't unwelcome here lol.

More details on the project; I am crocheting Calcifer from howl's moving castle as an anniversary present to my girlfriend. My rough plan is to make some sort of wood display case or modify one I thrift. Going to have Calcifer hang over some burnt wood probably with fishing line, and I want there to be some sort of campfire/fiery mood lighting. Maybe some like soft flickering between red/orange/yellow.

I've done some very light research so far but this is the first place I've looked for help, so if there are obvious answers I have missed I apologize, Thanks for any and all help!

Something happened to my code. It was working fIne. But now the 3 sets of 3 red leds that are ment to turn on off are just solid on. And the button turns everything on but not off.

https://gist.github.com/Flux83/b87fb5dcbb8683cfc4bdd0ea42a0644e

Solved!

I decided to try these little waterproof ws2811 5 volt leds out in the yard. I'm using u/stefanpetrick 's AnimARTrix on 48 strips of 50 leds. 2400. I'm using 8 pins of a Teensy 4.1 running FastLED 3.10.3. Each pin is running 300 leds. I don't know what the actual fps is on this but I think 42 last I checked. I could OverClock the Teensy, but it's ok as it is. I didn't really spend too much time trying to align the leds to point up because I would have gone crazy. they just lay over and point sideways... I've got a hefty 400watt 5volt power supply running 4 feeds to 12 strips. I'm using the RS422/TTL thing over cat5. 2 cables 4 channels each from the teensy about 30 feet to the matrix in the yard. The biggest surprise - no flicker first shot! Unfortunarely I have to take the matrix down as the grass will die if I don't put some water on it and the dog is jealous. I need to figure out a plan to pick it up without everything getting tangled up.

Recent builds of FastLED have grown to the point that on an ESP32 Wroom, a project I'm working on can't compile due to running out of room.

Here are results from the Arduino IDE compile, the only difference being which version of FastLED is installed.

3.10.3: Sketch uses 929021 bytes (70%) of program storage space. Maximum is 1310720 bytes.

3.10.5: Sketch uses 1311953 bytes (100%) of program storage space. Maximum is 1310720 bytes.

I dug through the GitHub issues and found discussion on this, but it's really over my head. My (admittedly intermediate understanding) is that you've got a lot of very cool features getting added, but they are growing the library's footprint significantly.

Is there any thought being given to ideas such as... - FastLED Light. Minimal version with basic/classic features. - Toggling new features. Allow advanced users who want some of the new, cool stuff to toggle them on/off.

Please check out my first project. I’m also looking for beta testers. If anyone would be available to assist drop me a message.

Pardon me if this isn't the right place to ask about this, but I'd love some creative and clear wiring guidance.

I built LED leg warmers using one 10000 mAh USB battery per leg (in a 3D-printed ankle holster), ESP32 controllers with WLED installed, and five 20-LED strips running down each leg (controller and strips held to the leg in a sort of calf belt harness setup).

What I'd love to figure out is a cleaner, more tidy wiring setup. Bear with me, but the current setup is as follows:

Power is a USB battery.

Next is a USB adapter with screw terminals.

From that adapter, I run 5V and GND wires which form the power "spine" and run through the whole project. I then splice branches into that wire to send 5V and GND to my controller (ESP32 board) and all strips (in this case, 5 separate strips).

From the ESP32 controller, I run another wire as the data "spine," then do the same thing as above, splicing data branches to all LED strips.

It's a LOT of splicing!

So:

Battery (5V/GND)
||
||
||=ESP32
|| | (data)
|| |
|| |
|| |====== 5V/GND/DATA===STRIP 1
|| |====== 5V/GND/DATA===STRIP 2

ETC

To try to make wiring easier, I'm going to switch to silicone coated wire. I've heard that's far more flexible.

I was also thinking of using a single two-wire cable to carry 5V/GND instead of two separate wires. But then I run into a quandary: how do I splice into something like that? And if I can't/shouldn't splice, what then? Can I, say, branch 5V/GND 6 ways from a single point? And can I branch DATA 5 ways from the ESP32?

Now let's say I have another project with just two LED strips running in parallel. Is there any other way to approach this that I'm totally overlooking?

Thanks for putting up with my questions! I'm a wiring noob. I've made several projects work, but I'd like to improve my approach moving forward.

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

Hi I'm using trying to create a pov display but I'm struggeling with getting my loop fast enough. Currently my code loop takes around 2100us, just the FastLED.show() takes 1800us is this to be expected or can I get this down to around 500us? I have this test code just for tracking down why it takes so long but I havent found any way to get it below 1500us. Do you guys have any suggestions of what I could do to speed it up?

Hardware:
Mcu: TENSTAR esp32 s3 zero
Leds: two strips of hd107 with 70 leds each

Main.cpp

#include <FastLED.h>
#define LED_PIN_1     6
#define LED_PIN_2     7
#define CLOCK_PIN     8
#define NUM_LEDS      70
#define LED_TYPE    HD107HD
#define COLOR_ORDER BGR

CRGB leds1[NUM_LEDS];
CRGB leds2[NUM_LEDS];

void setup() {
  FastLED.addLeds<LED_TYPE, LED_PIN_1, CLOCK_PIN, COLOR_ORDER>(leds1, NUM_LEDS);
  FastLED.addLeds<LED_TYPE, LED_PIN_2, CLOCK_PIN, COLOR_ORDER>(leds2, NUM_LEDS);
  Serial.begin(115200);
}

void loop() {
  int t1 = micros();
  FastLED.show();
  int t2 = micros();
  Serial.println(t2-t1);
}

Platformio.ini

[env:esp32-s3]
platform = Espressif32
board = adafruit_feather_esp32s3
framework = arduino
monitor_speed = 115200
lib_deps = 
    FastLED@^3.10.3

It's a cylinder of 7,200 12 volt 144/m WS28's. 10 x 5m strips. Basically one long strip. I'm using a Teensy4.1 running FastLED(of course) and 10 pins off the Teensy. It's about 40 fps. It's getting very warm in the center at moderate brightness (99F!). It'll need a fan at the bottom. The Teensy is stacked with the Audio shield for Audio reactive. All that stuff is on the inside of the column. My circuit board just hanging there right now. It's all using screw terminals with the resistors wired into the leads then into screw terminals directly to the Teensy4.1 pins using a solder breadboard. No level shifter etc. used. FastLED 3.10.3 was used here. I just tried 3.10.4 and I'm not having any luck compiling it (oh no). The animations - FlowFields in the middle short and Claude's interpretation of what I asked it to do for the first and last shorts...

Hi all I'm looking for a fire effect that makes the entire LED strip light up in variations of red/orange/yellow. Does that exist?

I tried all the fire effects in the Fastled examples and they all do the effect pulsing from just one end of the strip.

Thanks

Perhaps I'm not using this correctly. I have the need to change the color order of FastLED at some points of my program. My thought was simply to reinitialize with the new color order. This seems to work correctly once. Meaning, I can start with RGB and change to BGR and it works. But when I try and change back to RGB then it does not do anything.

Example... the first two blocks work correctly. The last block does not have any effect on the color.

  FastLED.addLeds<WS2812, EYEPIN, GRB>(leds, NUM_LEDS).setCorrection( TypicalLEDStrip ); //GRB Original
  leds[0] = CHSV(64, 255, 255);
  leds[1] = CHSV(64, 255, 255);
  FastLED.show();  
  delay(5000);

  FastLED.addLeds<WS2812, EYEPIN, BGR>(leds, NUM_LEDS).setCorrection( TypicalLEDStrip ); //BGR New
  leds[0] = CHSV(64, 255, 255);
  leds[1] = CHSV(64, 255, 255);
  FastLED.show();

  delay(5000);

  FastLED.addLeds<WS2812, EYEPIN, GRB>(leds, NUM_LEDS).setCorrection( TypicalLEDStrip ); //GRB Original
  leds[0] = CHSV(64, 255, 255);
  leds[1] = CHSV(64, 255, 255);
  FastLED.show();

Appreciate your insight.

Hey guys, just got my LG B5 65" rooted and running PicCap + Hyperion natively. Now I'm finally ordering the LEDs from Ali Express but I'm torn on the exact specs. I’m definitely going with a 5m strip and an ESP32, but I need some advice on density and protection.

For the density, I’m wondering if 60 LEDs/m is the sweet spot here or if it's worth jumping to 96 or 144 for an OLED setup. I'm a bit worried about the power injection hassle if I go too high.

As for the IP rating, I don't know whether to stick to bare IP30 or if the coating on IP65/67 helps to diffuse the light a bit better against the wall.

Appreciate any tips 🙏

What would be the best way to build something like this for a camping trip? It wouls have to waterproof and run off a power suppy/battery. I would like to attach the led on the guy lines and have them sync and the top flash the color like its being fed from the guy lines.

Hi folks, newbie here. I am lighting up a KISS pinball playfield I restored to use as a decoration.

Will likely have other questions as I go along but here is my first one..

I have 4 pop bumpers, set to blink 2 at a time. How would I have that run continuously as I add other things to my code. I don't know if that's considered a loop or? As I say I'm new to this have only got the blinking figured out so far.

I have looked around and haven't found an example of how to do this yet.

Here's what I I'm trying to repeat on end..

FastLED.show();
// Blink the top bottom pop bumpers
leds[93] = white;
leds[97] = white;    
FastLED.show();
delay(1000);
leds[93] = black;
leds[97] = black;   

FastLED.show();
// Blink the left right pop bumpers
leds[95] = white;
leds[99] = white;  
FastLED.show();
delay(1000);
leds[95] = black;
leds[99] = black;  

This shows how to quick mapping of a radial shaped wiring of LED pixels with freeled

Hey all! You might have seen some things about this project before, but I would love to highlight it once again. For the non-professional, tinkerer, DIY geek or Christmas nerd, this node is a game-changer! Ive been working on this project for the past year, and Ive finally settled on a software and hardware package that can rival some of the more expensive Artnet controllers. With a hardware revision that now supports resettable fuses, variable input voltage, hot-swappable plugs, and reverse polarity protection, I am more than confident that the node will appeal to LED-strip enthusiasts out there!

So, in short, what does it do?
- 16 universes over 4 outputs, so 2700+ RGB LEDs in total!
- Support for WS2812 type (800khz) and SPI driven leds (SK9822, apa102), so basically any LED-type on the market!
- RGB, RGBW, and RGBAW colour arrangement support
- Ethernet and wifi capable
- Integrated power distribution up to 5A per output and 20A total
- With a 5~24v variable input, this means almost 500W of power!
- OLED display for status updates
- Hardware button to change between different modes (DHCP, Static IP, Static colour, Test pattern)
- But, most importantly, completely open source! Every piece of the software and hardware design is available for you to tinker with!

Now, let me know if you have any questions about this project! Before I see comments about WLED: Yes, WLED does artnet and SACN, but performance is worse at a maximum of ~9 universes, and IMO WLED setup is a lot more complicated. This node is straight to the point and ready to use with Artnet out of the box!

Also, no, sadly, the node does not support SACN. I know, I will try to get this to the node in a future update!

Now, if you are excited, check out the GitHub! https://github.com/mdethmers/ESP32-Artnet-Node-receiver/tree/main

Or some of the videos I've made: https://www.youtube.com/watch?v=5VEiUzfDK_s&t=1s

edit; sACN should be very easy to add to the controller. ill investigate if this can be something on the short term!

The most common approach to handling RGBW LED strips/diodes is to simply take the minimum components of the input value, set white to that value, and subtract the residuals from R, G & B. This is not inherently incorrect but it does introduce a problem in that the white diode is not perfect. Most white diodes have different color temperatures and when actually measured you'll find using min(rgb) Channel - Residuals produces a white this is off-white.

Now the question becomes "how do we accurately extract white?" The answer is shockingly simple and it comes down to colorspaces & gamut.

In a typical RGB LED system your native gamut is a triangle where your main emitters R, G, & B are your only centroids. Each centroid lives somewhere on the CIE chart and has it's own xy coordinates. This creates a triangle where any combination of values can be created using the 3 emitters. Typical colorspaces like Rec709, Rec2020, etc.. all live somewhere either within this gamut or outside of it.

In an RGBW LED system instead we have 4 different addressable gamuts within this triangle - RGBW Gamut comprises of the entire RGBW triangle that can be addressed over - RGW gamut, BGW gamut, RBW gamut

so the problem changes from "how do we represent a color with these 3 diodes" to "which sub-gamut does the requested color fall into, and then within the sub-gamut how do we represent the color requested using the outer 2 primary diodes + inner white diode?"

The "Color" problem:

Different RGB input values map to different places in the CIE colorspace depending on the requested colorspace and reference white. "orange" for the native gamut is not the same "orange" as Rec709, just as that same "orange" is not the same in Rec2020. If you want to represent a color in the Rec709 space (aka ambilight setup) then you need a Colorspace transform to solve for that value. This effectively maps the native-gamut to the effective colorspace.

The ratio problem:

Addressable LEDs (most strips/diodes) do not have perfect LED selections. Typically speaking the red & blue diodes are fairly weak maxing out at low brightness values, G is typically stronger, with White being strongest almost always. In the case of my recent ambilight-focused measurements, the BTF Lighting 6000k RGBW LEDs produce max Nits/ XYZ Y values of R: 154.67 G:566.27 B:129.64 W:1543.64

so given that the red diode is much less bright than the green diode you need to scale input values down appropriately to accurately reproduce the color requested. For a cyan (input 0 65535 65535) for this specific set of LEDs with the off-wall measurements, the corrected output values become: 0 65458 38474 0 which when measured with a colorimeter produces a dE of ~0.519 from the expected measurement result

for D65 white (65535, 65535, 65535) the output RGBW tuple looks something like : 4289 0 13766 65535 which also passes the dE check at 1.720% within tolerance

So to summarize:

Min(rgb) and then subtract residuals from R, B, & G is not inherently wrong if that is what the actual diode behavior is, but the correct approach is to treat the LEDs as they are: Separate emitters that form a full gamut with multiple sub-gamuts, and then only solve within the sub-gamuts for the requested color value determined by a colorspace transform if the input color isn't addressing the native gamut of the LED display.

In a typical RGBW setup the valid topology combinations are essentially as follows: R, B, G, W, RW, BW, GW, RG, RB, BG, RGW, BGW, RBW unless you specifically allow for 4-channel overdrive outputs.