RGB Strip for Real-Time Art Pieces

A category, not a product

"RGB LED strip" names a category the way "screen" names a category. Underneath it sits a range that varies by a factor of fifty across every property that decides whether a piece looks good — how many points along the strip we can control independently, how smoothly it dims towards black, how it behaves in front of a camera, how far it can run before the colours drift. The strips at opposite ends of that range are separated by a few euros per metre.

That is what makes this worth writing down rather than solving at the checkout. The price signal is nearly useless: the cheapest strip and the most capable strip look identical in a listing photograph and differ by about €5 per metre. Worse, most of these properties are invisible until the piece is finished. Nobody discovers that a strip flickers on camera while holding a reel. They discover it when the documentation photographer sends the files back.

We are about to start building art pieces with addressable strip inside them, each running its own software the way OI-Frame does — unattended, on hardware inside the object, with no studio machine in the room. This document is the technology survey behind that: what exists in 2026, which parts are good and which are traps, how the two serious control options compare, and what we should buy to start testing. The gallery lighting project is separate and stays separate — but it needs the same pixel layer, so everything settled here arrives there for free.

What a strip is made of

An addressable strip is three things chosen independently: a driver IC that receives data and sets brightness, the LED packages it drives, and the flexible circuit board that carries both. Almost every buying mistake comes from reading one number — usually "LEDs per metre" — and assuming it describes the other two.

The driver IC is the part that matters most, and the whole market divides into two families by how that IC is talked to.

1. Clockless — one data wire. The controller sends a self-timed pulse train and the IC decodes it against hard-coded internal timing. Three wires total, cheap, universal. The cost is precision: the timing is fixed, the brightness is 8-bit, and the internal dimming runs slowly. WS2812B · WS2813 · WS2815 · SK6812 · WS2811 · WS2814 · WS2805
2. Clocked — a data wire and a clock wire. The controller supplies the clock, so it sets the data rate. Four wires, slightly dearer, far more tolerant of long cable, and dramatically faster internally. This is the family used when the strip has to hold up under scrutiny. SK9822 · APA102 · HD107s · HD108

The default assumption in every hobby tutorial, every Amazon listing and most professional installs is the clockless family, because it is what WS2812B is and WS2812B is what most people have heard of. For an object that gets photographed at close range, that default is wrong. Section 4 is the argument.

The four numbers

Four properties decide a purchase. Everything else is a consequence of them.

Pixels per metre — and why it is not LEDs per metre

This is the single most common and most expensive misreading in the category, so it is worth being blunt about. On a WS2812B or SK6812 strip, one LED is one pixel, so 144 LEDs/m really is 144 independently controllable points. On strips with an external driver IC — which includes every COB strip on the market — one IC drives a whole group of LEDs, and the group can be thirty-six of them.

A strip advertised as "720 LEDs per metre" gives us twenty addressable points per metre — one every five centimetres. A plain 60/m strip has three times the resolution and one twelfth the LED count. Both are legitimate products; they are simply answering different questions. COB gives a continuous line of light with no visible dots, which is beautiful and which a generative patch can barely address. SMD gives resolution and visible dots.

Note the two WS2805 rows. On grouped-IC strips the group size follows the supply voltage — three LEDs per IC at 12 V, six at 24 V — so the same strip at 12 V carries twice the addressable pixels. Where that applies it is free resolution, paid for in brightness and maximum run length. It does not apply everywhere and has to be checked per listing.

PWM refresh rate

An LED does not dim by receiving less current. It dims by being switched fully on and fully off very quickly, and the ratio of on to off is the brightness. That switching frequency is the PWM refresh rate, and across this market it ranges from about 400 Hz to 27 000 Hz — a factor of nearly seventy. It is never on the listing. Section 4 is entirely about this number.

Bit depth

Almost every strip is 8-bit per channel: 256 steps from off to full. That sounds ample and is not, because human perception of brightness is not linear. The bottom of the range is where the steps are visible, and the bottom of the range is exactly where a slow fade to black lives. One chip, the HD108, is 16-bit — 65 536 steps — and it is the only one that fades to black without stepping.

Voltage

Voltage decides run length. A 2.5 V drop along a run is 50 % of a 5 V strip, 21 % of a 12 V strip and 10 % of a 24 V strip; the first produces visibly wrong colours at the far end, the last is invisible. This matters enormously for a thirty-metre architectural cove and rather little for an art piece, where runs are typically one to five metres. For pieces, 5 V and 12 V are entirely adequate, which is convenient — see section 5.

The chips, with verdicts

Two honest caveats on that table. Newer WS2812B revisions are advertised at higher PWM than the classic 400 Hz figure; we have not verified that claim and are assuming 400 Hz until we measure it ourselves. And a 16-bit clockless part called WS2816 is sold, but we could not confirm it from a primary source, so it is not listed.

The camera constraint

Here is the finding this document exists to deliver. An art piece is not judged only in the room. It is judged in the photographs, in the portfolio, in the press images and increasingly in video. If the strip inside it bands or strobes on camera, the piece photographs badly forever, and no amount of software fixes it.

The rule of thumb the lighting industry uses is that a strip's PWM rate should be at least thirty times the camera's frame rate. A 60 fps camera therefore needs at least 1 800 Hz. That single line disqualifies most of the market:

• WS2812B, WS2811, WS2814, WS2805 at ~400 Hz — will band on essentially any camera.
• SK6812 at 1.2 kHz — fine at 24 or 30 fps, visible at 60 and above.
• SK9822 at 4.7 kHz — safe to roughly 150 fps.
• APA102, HD107s, HD108 at 20–27 kHz — safe for anything, slow motion included.

Plotting the actual products against the two properties that matter — how finely we can address them, and whether a camera survives them — produces a map with an uncomfortable shape.

The shape of that map is the argument. The two strips a studio reaches for by instinct — the cheap WS2812B because everyone uses it, and the gorgeous dotless COB because it looks like real architecture — are both in the bottom half. Neither survives a camera. The upper half is reachable only through the clocked family, and the upper right corner, where fine resolution meets camera safety, contains exactly one product class: HD107s and HD108 at 144 LEDs per metre.

The top-left quadrant is empty, and that emptiness is itself a finding. Continuous dotless COB light and a fast driver IC do not currently ship in the same product. If a piece needs a seamless line of light and has to be filmed close, that is an unsolved problem we would have to work around with diffusion rather than buy our way out of.

Where the software runs

The strip is half the system. The other half is not a controller box on a network — it is a small computer inside the object, running code we wrote. That distinction matters more than any product comparison, so it is worth stating before the hardware.

These pieces have to work the way OI-Frame works: their own software, running unattended, configured from a phone on the same network, with the studio machine present only during development. A piece that goes dark because a computer somewhere else stopped is not a piece, it is a demo. So the question is not "which box translates our network data into pixels". It is where our code runs, and how it reaches the strip.

The good news is that the strip recommendation from section 4 survives the reframing untouched, and picks up a second, entirely independent argument behind it.

Why a clocked strip makes our own code easy

Clockless strips encode data as pulse widths with hard-coded timing measured in hundreds of nanoseconds. Nothing about that suits a general-purpose computer. On a Raspberry Pi it needs DMA or PWM peripheral tricks; on an ESP32 it needs the RMT or I2S peripheral, and a frame can still be corrupted when a Wi-Fi interrupt lands in the wrong microsecond.

Clocked strips are the opposite, and the reason is structural: because the controller supplies the clock, the strip is insensitive to timing variation. An interrupt mid-frame stretches the clock and nothing notices. Driving one is a buffer and an ordinary SPI write — the same interface every microcontroller and every Pi has in hardware.

So the strip we chose on camera grounds turns out to be the strip that makes our software portable across every runtime below. That is a rare piece of luck and it is worth taking.

Three places the code can live

1. An ESP32 — our own firmware. C++ under Arduino or ESP-IDF. Hardware SPI, so the strip is a solved problem. No operating system and no filesystem to corrupt: it boots in under a second and runs for years. It can serve its own configuration page to a phone, which is how WLED already works. Enough compute for procedural content over a strip by a very wide margin. Not enough for media files or anything wanting a GPU, and it is a toolchain the studio does not otherwise use. USD 21–25 · ESP32-P4 · ESP-IDF · a direct SPI write
2. A Raspberry Pi — our own Node application. This is the OI-Frame stack, which already builds and ships for linux-arm64. Hardware SPI over spidev, so the strip is equally solved, and full Linux gives us a browser, a GPU and every library we already use. The cost is an operating system: twenty to thirty seconds of boot, and an SD card that corrupts on a hard power cut unless the root filesystem is made read-only. Buy this for the renderer, not for the strip. EUR 40–90 · Pi 4 or Pi 5 — not the Zero 2 W · Node + spidev · read-only rootfs
3. A small PC — Electron, or an exported vvvv executable. What OI-Frame actually does today. The right answer when the content genuinely needs a GPU: shaders, video, heavy audio analysis. Physically the largest and the hungriest, so it suits a piece that already has a screen and a mains supply rather than a small object. NUC-class · Electron · exported vvvv gamma exe

Sizing the computer to the job

It is worth doing the arithmetic before choosing, because it is smaller than instinct suggests. A three-metre strip at 144 pixels per metre is about 430 pixels. Computing 430 RGB values sixty times a second is roughly 77 000 values per second — nothing. An ESP32 does that with the great majority of its cycles idle, and the WLED measurements in the previous section put a classic ESP32 at 65 000 to 85 000 whole LED updates per second even inside a general-purpose firmware doing far more than we would ask of it.

A strip is one-dimensional and short. OI-Frame renders a 320 × 540 field through a WebGL shader, which is why it wants a GPU; a strip does not. So the reason to reach for a Pi is not compute — it is the renderer and the stack. That distinction decides the choice:

• Procedural content over a strip — noise, waves, palettes, a microphone, a sensor. An ESP32 is correctly sized, and the Pi's operating system is pure overhead.
• Content that reuses the OI-Frame renderer — WebGL shaders, media files, heavy audio analysis. Then a Pi, and a real one.

Not the Pi Zero 2 W. It has 512 MB of RAM, which is precisely the wrong amount: ample for a Node process computing a pixel buffer, and miserable for the Electron and Chromium stack that is the only reason to have chosen a Pi in the first place. Its wired ethernet also has to arrive over a USB adapter. If the answer is a Pi, it is a Pi 4 or a Pi 5. And current pricing argues against over-reaching there too — the memory shortage has pushed a 16 GB Pi 5 from $120 to $305 over 2026, while the Pi 4 1 GB holds at $35.

The Pi's failure mode is worth naming, because it will bite once: SD card corruption after a hard power cut. The fix is well established — a read-only root filesystem with writes redirected to a RAM disk, plus a supply that does not brown out. It is a day of setup that then applies to every piece, and OI-Frame needs exactly the same treatment.

Wired ethernet, and the one specification that decides the board

Ethernet into a piece is worth having. Wi-Fi in a gallery is a shared, congested, unmanaged medium, and a piece that stutters because someone opened a laptop is not acceptable. On this point there is a hard hardware fact that reverses the obvious choice:

The ESP32-S3 has no ethernet MAC. It does not support RMII at all, so wired ethernet on an S3 means adding a W5500 controller on the SPI bus — an extra chip competing for the very interface we want for the strip. The classic ESP32 has a built-in ethernet MAC and drives an ordinary RMII PHY such as the LAN8710 or LAN8720 for full 100 Mbit.

So for this work the newer S3 is disqualified, and its advantages — more memory, more headroom — are ones a strip never needed anyway. That leaves two families that qualify: the classic ESP32, and Espressif's ESP32-P4, a newer RISC-V part which does carry a built-in 10/100 MAC with RMII. The P4 is where the interesting hardware now is.

The last two rows are reference. The decision is the first two, and they are the same decision made twice — develop on the Waveshare board, deploy on whichever ESP32-P4 board the piece actually needs. Because both carry the same chip, that is a packaging choice rather than a port: one codebase, one toolchain, one set of habits.

The Waveshare board is the superset and costs $3 more than the plain module. Its ESP32-C6 companion, reached over SDIO, restores the Wi-Fi 6 and Bluetooth that the P4 has no radio for — which is the one property the M5Stack unit genuinely lacks, and the reason a piece built on the M5Stack needs a network cable not only to run a show but to be configured at all. Between the microSD slot, the camera and display connectors and 28 broken-out GPIOs, it also means that when a piece turns out to want a screen or a camera, nothing about the platform has to change. The studio already has a sibling board from the same family on order for another project, which settles the argument on familiarity alone. Two of these boards are now ordered; the packaging decision waits until a piece is real enough to need a box.

Three cautions worth writing down rather than discovering. The silicon is new: ESP-IDF supports the P4 properly and our own SPI driver is trivial, but third-party library support trails the classic part, so nothing outside the core SDK should be assumed. The Wi-Fi path runs through co-processor firmware on the C6 over SDIO — it works, but it is one more component to keep in version step. And the M5Stack unit specifies a 0–40 °C operating range, worth checking against the inside of a sealed object containing a warm strip.

One caveat on PoE, so nobody plans around it wrongly: 802.3af delivers about 13 W at the device and the M5Stack unit budgets 6 W out. Either powers the controller comfortably and the strip not at all — three metres of HD107s at full white is far beyond both. The strip keeps its own supply; PoE simply means the data cable can also keep the brains alive.

Standalone and network-driven, from one switch

The requirement is not standalone or driven from the studio. It is both, and the architecture gives us both for almost nothing. The piece's software renders a buffer of pixel values and writes it to SPI; where those values come from is a single branch above that write.

• Generate — our own content, computed on the device. The default, and how a piece behaves in a gallery with nobody around.
• Receive — take frames from sACN arriving on the network and display them unchanged. Development, testing, and any occasion where we want to drive the piece live.

Both paths end at the same SPI write, so adding the second is a receiver library and a source switch rather than an architecture. For context on the numbers: one sACN universe carries 512 channels, so 170 RGB pixels, and a one-metre 144/m strip fits inside a single universe with room left over. The stream runs at roughly 44 frames per second, the historical DMX rate and still the practical target.

vvvv keeps its place as the tool we design and test the look in, and an exported executable stays available for a piece that genuinely warrants it. Nothing hangs on it being present.

What this does to the controller question

It largely dissolves it — and one recommendation from this document's first pass has to be corrected rather than quietly adjusted.

Advatek is out for art pieces. A PixLite is a closed appliance. It converts network lighting data into pixel data extremely well, and it cannot run our code. Under an architecture where the piece is the computer, it is a €480 box in the middle doing a job the Pi's own SPI port does for nothing. That is not a criticism of the product — it stays the right answer for the gallery, where fixtures are permanent, pixel counts run into the thousands, and nobody wants to maintain firmware. It is simply the wrong shape for an object that thinks for itself.

QuinLED survives, as hardware rather than as firmware. The Dig-Quad is an ESP32 on a well-made carrier board: proper level shifters, onboard fuses, reverse-polarity protection and screw terminals for power injection. All of that is worth having whatever code runs on it, and the ESP32 is ours to flash. We would buy it for the board and put our own firmware on it, not run WLED in production.

WLED becomes a bring-up tool, which is genuinely useful. Flash it, confirm the strip lights and the wiring is right, then replace it with our own code. An hour well spent, at no cost, and it removes “is it the hardware or is it my driver” from every later debugging session.

One consequence worth recording: the QuinLED 24 V defect stops mattering. The board's onboard converter fails at an elevated rate on a 24 V input, and the project's own advice, published 22 July 2026, is to wait for the revised board if 24 V is planned. Our strip is 5 V and our runs are metres, so we never build at 24 V and the fault never reaches us.

Sourcing and the parts list

Buying direct from China is fine and we should do it. Essentially all of this hardware is made there regardless, and the European resellers are the same product with a markup. The risk is not the country of origin, it is the listing, which is written to sell rather than to inform.

What to check before ordering

1. ICs per metre, not LEDs per metre. This is the number that decides what our software can do with the strip. If a listing does not state it, ask, and assume the worst until answered.
2. Copper weight of the flexible PCB. Good factories use 2 oz or 3 oz double-sided rolled copper. Single-layer or 1 oz means voltage drop and early failure.
3. Watts per metre, cross-checked against the LED count. If 720 LEDs/m is quoted at 8 W/m, one of those two numbers is fiction.
4. CRI with an R9 figure. A bare "CRI 90" with no R9 and no test report is marketing, not a measurement.R9 is the deep-red score — the one that decides whether skin and warm materials look right
5. IP rating matched to the job. IP30 bare for inside a piece or a profile; IP65 silicone coating for damp. Avoid IP67 sleeved strip indoors — the sleeve traps heat and shortens life.
6. Price 30 % under the market is a warning, not a bargain. It buys thin copper or off-spec dice every time.
7. "RGBIC" on a consumer listing usually means fixed built-in effects, not an addressable strip. Look for the actual chip name.

In practice: order one-metre samples, never reels, and buy connectors and pigtails from the same seller in the same order, because pitch and polarity vary between factories. Solder the joints that matter; solderless clips are for prototyping. BTF-Lighting is the most consistently documented brand in this space and publishes real specification sheets, which makes it a sensible starting point rather than an endorsement — nothing below has been tested by us.

The parts list

Sized to answer questions rather than to build anything. Roughly €300–400 all in. The two development boards are already ordered. The carrier board, the production-form module and the Raspberry Pi are all marked deferred until something actually needs them, and the list deliberately does not include an Advatek.

The first milestone

Two Waveshare boards are ordered, so the work has a starting point. The sensible first target is deliberately small: one board, one metre of HD107s, and a gradient that moves. Everything else in this document sits downstream of that working.

1. Board alive. ESP-IDF over USB-C, a blink, serial output coming back. Do this first so that nothing later can be blamed on the toolchain.
2. Ethernet up. An IP address on the RJ45, before any content is written. On new silicon this is the step most likely to surprise us, so it should surprise us early.
3. Strip alive. One metre of HD107s, a level shifter on data and clock, every pixel red. A buffer and an SPI write — this is the twenty lines the whole architecture rests on.
4. A frame loop. A gradient moving at sixty frames a second, with the achieved rate printed to serial. This is where we find out what the board really sustains rather than what a datasheet claims.
5. Generate. Real procedural content computed on the device. This is standalone mode, and it is the mode a finished piece ships in.
6. Receive. Swap the source for an sACN listener and drive the same strip from vvvv. This is test and show mode.
7. Both. A switch above the SPI write. With two boards the modes can be run against each other on the bench — one generating, one receiving.

Steps 1 to 4 are an afternoon, and they de-risk the entire architecture: once a buffer reaches the strip at a stable frame rate over hardware SPI, the rest of this document is a shopping exercise. Steps 5 and 6 are the two halves of the source switch in section 5, and they can be built in either order.

Two practical notes on wiring. All addressable strips want a 5 V data signal, and both an ESP32 and a Raspberry Pi output 3.3 V, so a level shifter is not optional beyond the first few centimetres — the QuinLED has proper ones built in, which is most of what the €85 buys. And measured data-wire limits are about 10 m on thin cable with a level shifter, or 20 m on 0.75 mm² kept away from interference. Neither is a constraint at art-piece scale.

Why this matters

"The two strips a studio reaches for by instinct — the cheap one and the beautiful one — are the two that photograph worst."

The decision this document asks for is small and cheap: about €300 of samples, and a preference for a strip family that costs perhaps €5 more per metre than the obvious one. The reason to make it deliberately rather than at the checkout is that the properties that separate these products are invisible at the point of purchase and expensive at the point of discovery. A piece built around the wrong strip is not a strip problem afterwards. It is a rebuild.

The specific finding worth carrying out of here is the camera one. We are a studio whose work is seen mostly through other people's screens. A pixel layer that bands in every photograph and every video of a piece has failed at the thing the piece is for, and no amount of real-time control compensates. That constraint points at one narrow corner of the market, and the good news is that the corner is neither exotic nor expensive — it is HD107s at 144 LEDs per metre, and it costs about what a mid-range WS2812B strip costs.

The control decision runs the other way from expectation, and it saves money by removing a component rather than by choosing a cheaper one. There is no controller box in this architecture. The piece is the computer, and a Raspberry Pi's own SPI port drives the strip directly. A professional pixel controller cannot run our code, and running our code is the entire point — so it would be €480 spent on a translator we do not need. That box is the right answer to the gallery's question, not to this one.

The two decisions also turn out to reinforce each other, which is worth noticing because it rarely happens. We chose a clocked strip because cameras demand it. A clocked strip is also the one our own software can drive from an ordinary SPI port on any platform — no timing tricks, no interference from Wi-Fi, the same twenty lines whether the code runs on an ESP32, a Pi or a PC. One choice, two problems solved, and the runtime decision stays open until we have written something.

What we get for €300 is the ability to stop guessing: six strips on a bench, one controller, a phone filming at 240 frames per second, and an afternoon. After that the arguments in this document are either confirmed or replaced with measurements, which is a better thing to build on.

Glossary

Terms and acronyms used in this document, in plain language.

APA102

A clocked driver IC with roughly 20 kHz refresh. The long-standing choice for strip that will be filmed.

Art-Net

An older way of carrying lighting data over ethernet. Broadcast-based, very widely supported, and what vvvv speaks natively.

Bit depth

How many brightness steps exist between off and full. 8-bit gives 256; 16-bit gives 65 536.

Clocked

A strip with a separate clock wire alongside the data wire, so the controller sets the speed. Four wires instead of three.

Clockless

A strip with one data wire and hard-coded internal timing. Three wires, cheaper, slower.

COB

Chip on board. Hundreds of tiny LED dice under a continuous phosphor layer, so the strip reads as a line of light with no visible dots.

CRI / R9

Colour Rendering Index. How faithfully a light source shows colour. R9 is the deep-red component and the number that actually matters.

DDP

Distributed Display Protocol. A leaner alternative to sACN, used when pixel counts get high enough that the universe structure becomes overhead.

DMX512

The original stage-lighting data standard. 512 channels per universe, about 44 frames per second. sACN and Art-Net both carry it over ethernet.

ESP32

A cheap Wi-Fi microcontroller. The chip inside almost every hobby-grade LED controller, including QuinLED. The newer S3 variant adds memory but drops the built-in ethernet controller, which is why the classic part is the right one here.

ESP32-P4

A newer Espressif chip: dual-core RISC-V at 400 MHz with a built-in ethernet controller, camera and display interfaces — and no radio of its own at all.

ESP32-C6

A small Espressif radio chip. On the Waveshare board it sits beside the ESP32-P4 and provides the Wi-Fi 6 and Bluetooth the P4 has no radio for.

FCOB

Flexible COB — COB construction on a bendable strip.

HD107s

A clocked driver IC running at 27 kHz. Compatible with APA102 controllers. The recommendation in this document.

HD108

Like HD107s but 16-bit, giving genuinely stepless fades. Not supported by WLED.

IP rating

How sealed a strip is. IP30 is bare, IP65 is silicone-coated, IP67 is inside a sealed sleeve.

Level shifter

A small circuit that raises the controller's 3.3 V data signal to the 5 V the strip expects.

OI-Frame

The studio's existing audio-reactive light piece. Node and Electron, shipping linux-arm64 builds, running unattended on a small PC and configured from a phone. The reference architecture for these pieces.

MT3608

The small voltage converter on QuinLED boards that fails when fed 24 V. The subject of the known fault in section 5.

Pixel

One independently controllable point of light. Not the same as one LED — on grouped strips a pixel can be 36 LEDs.

PixLite

Advatek's range of commercial pixel controllers.

Power injection

Feeding power into the middle or far end of a strip as well as the start, so the far end is not dim or discoloured.

PWM

Pulse-width modulation. LEDs dim by switching on and off rapidly. The switching frequency is the PWM rate, and it decides camera behaviour.

QuinLED

A small Dutch project making purpose-built ESP32 boards for driving addressable strip. Runs WLED.

PoE

Power over Ethernet. One cable carrying both network data and power. About 13 W at the device — enough for a controller, nowhere near enough for a strip.

RMII

The interface an ESP32's built-in ethernet controller uses to talk to an ethernet chip. The classic ESP32 has it; the ESP32-S3 does not.

RMT

A timing peripheral inside the ESP32. Needed to drive clockless strips; not needed at all for clocked ones.

sACN

Streaming ACN, formally ANSI E1.31. The modern standard for carrying lighting data over ethernet, using multicast so each device receives only what it asked for.

SELV

Safety extra-low voltage. The safe low-voltage side of a power supply — everything downstream of the Mean Well unit.

SK6812

A clockless IC available in RGBW, with a genuine white LED alongside the colours. 1.2 kHz refresh.

SMD

Surface-mount device. Conventional discrete LED packages in a row, as opposed to COB. Visible dots, higher addressable resolution.

SPI

Serial Peripheral Interface. A plain, universal hardware interface with a data line and a clock line. Every microcontroller and every Raspberry Pi has one, which is why clocked strips are easy to drive.

spidev

The Linux device file that exposes a Raspberry Pi's SPI port to ordinary software, as /dev/spidev0.0.

Universe

One block of 512 lighting channels — 170 RGB pixels or 128 RGBW pixels.

vvvv gamma

The visual live-programming environment the studio uses for real-time work. Programs keep running while they are edited.

WLED

Open-source firmware that turns an ESP32 into an addressable-LED controller speaking sACN, Art-Net and DDP. Current stable release is 16.0.1.

WS2812B

The most common addressable IC in the world, and the default in most tutorials. 5 V, 8-bit, ~400 Hz — which is why it bands on camera.