Can you run DMX in a browser? How that question became FlexViz -Part 1

How it started

We wanted to revo… well, nah.

There’s no “we”. There’s me: Hauke, who got curious one day. And no, I didn’t set out to revolutionize anything.

Okay. Maybe a little.

But in the beginning, there was really just curiosity.

Let’s start from the beginning.

I’ve been working in the lighting industry for about 15 years, mostly as a freelancer, and I’ve been playing around with lighting visualization software for just as long. Yes, I’ve seen Martin ShowDesigner, the early days of grandMA 3D, and the first versions of Capture.

At the same time, I’m a web developer.

Eventually, I left the lighting industry for the most part in favor of more family-friendly working hours, but I never really lost touch with it. I kept following what was happening, while spending most of my professional life building web applications — mainly e-commerce projects in the Shopware universe.

Then, a few months ago, one question suddenly popped into my head:

“What if I could use a browser as a visualization shell?”

It didn’t seem completely unreasonable.

We have Three.js, which is a very capable library for 3D applications on the web. We have WebGL. And over the past few years, WebGPU has become increasingly viable.

So technically, a pretty decent lighting visualization inside a browser should be possible.

Which, naturally, led to the next question:

“Can I get DMX into the browser and visualize it there?”

Of course, I knew Art-Net and sACN. They’ve both been around for quite a while.

There was just one small problem.

They speak UDP.

Browsers don’t.

Cascade of Ideas

When you need real-time communication between the outside world and a browser, WebSockets come in incredibly handy.

But WebSockets still didn’t solve the UDP problem.

So the next idea was fairly obvious:

What if I put something in between?

A small local bridge could listen for Art-Net or sACN on the lighting network, translate the incoming universe data and forward it to the browser through a WebSocket connection.

That sounds simple enough — and, conceptually, it is.

But lighting data is a continuous stream.

A DMX universe contains up to 512 channels, and at full refresh rate it can be updated roughly 44 times per second. One universe is trivial. A few dozen universes are still perfectly manageable, but now you are processing hundreds or even thousands of universe updates every second, while simultaneously forwarding them to a browser with as little latency as possible.

And modern fixtures are very good at making universes disappear quickly. A single pixel fixture can consume dozens — sometimes hundreds — of DMX channels.

So I wanted the bridge to be small, fast, predictable and easy to run on different platforms.

That led me to Go.

Go is very good at exactly this kind of job: network I/O, concurrent streams, lightweight processes and easy cross-platform builds. It also meant I could keep the bridge itself relatively boring.

Which, for infrastructure software, is usually a good thing.

And suddenly the basic chain looked like this:

Lighting console → Art-Net / sACN → local bridge → WebSocket → browser

At that point, the first big question had an answer:

Yes. I could get DMX into a browser.