I built a browser-based live visual instrument with WebGL, Web MIDI and separate performer/audience outputs

For a long time I kept coming back to the same question:

Why can a musician perform almost everything on stage — except the visuals?

That question eventually became LumaDeck Web.

It is a browser-based live visual instrument for DJs, VJs, musicians and performers.

The idea was not to build another passive music visualizer, but something that could actually be played.

The basic idea

LumaDeck has three ways of working:

• Auto — the music drives the visuals.
• Perform — the artist takes direct control.
• Create — local videos and custom GLSL shaders become part of the instrument.

The important part is that these modes are not isolated workflows.

You can let automation run, trigger a blackout or strobe manually, launch another scene with MIDI, and then immediately let the automatic system continue the show.

That continuity became one of the main design goals.

One screen for the performer, another for the audience

One of the architectural decisions I cared about most was separating the operator interface from the final output.

The performer needs to see things like:

• scene launchers
• MIDI mappings
• mixer controls
• live effects
• BPM and audio analysis
• local media
• shader controls

The audience should see none of that.

So LumaDeck keeps a complete Master surface for the performer while a separate browser surface outputs only the final visual composition.

That changes the interface completely.

The control surface can behave like an instrument instead of having to double as something presentable on the projector or LED screen.

MIDI as a performance layer

Web MIDI became a major part of the workflow.

The current Web Pro surface exposes:

• 48 scene pads
• 19 live controls
• MIDI Learn
• physical controller mapping

The goal was to make the visual system behave more like the hardware musicians already understand.

Instead of clicking a scene with a mouse during a performance, a pad can launch it.

Instead of dragging a virtual parameter, a physical fader can control it.

That changes the relationship with the visuals from selecting content to actually performing it.

WebGL and GLSL

The visual engine runs in the browser using WebGL and GLSL.

LumaDeck currently includes 48 free audio-reactive scenes, with a larger catalog available through visual packs.

Artists can also load their own:

• local video loops
• custom GLSL shaders

Those assets stay local to the browser workflow rather than being uploaded to a remote media server.

That was important to me creatively as well as technically.

The built-in content should make the instrument useful immediately, but it should not force an artist into somebody else's visual language.

Why build it in the browser?

I originally chose the browser because it removes a huge amount of friction.

No heavy installation.

Immediate access.

A natural way to separate control and audience surfaces.

But I also wanted to know whether a browser-based visual instrument could stay stable during genuinely long sessions.

During development I left LumaDeck running continuously on the same machine for more than nine days as a real-world soak test.

I eventually stopped the test manually.

The application had not crashed.

Obviously that does not mean every browser, GPU, driver and operating-system combination will behave identically.

But it changed my own view of what a browser-based performance system can realistically do.

For LumaDeck, the browser is not being used as a convenient wrapper for a webpage.

The browser is the runtime of the instrument.

Where I think it fits

I am not trying to reproduce Resolume or TouchDesigner inside a browser.

Those are extremely capable professional environments.

The space I was interested in is somewhere between:

“press play on a music visualizer”

and

“become a specialist visual programmer before you can put something meaningful on a screen.”

I wanted someone to be able to open the instrument, get useful visuals immediately, and then progressively move into MIDI, custom media and GLSL if they want more control.

What I would genuinely like feedback on

LumaDeck Web is live now, and the free version can be used without creating an account:

https://lumadeck.app/

I am especially interested in feedback from people working with:

• WebGL
• Web MIDI
• browser performance
• realtime graphics
• creative coding
• live audiovisual systems

One of the questions I keep thinking about is:

If you were using a browser as a real performance instrument, where would you want the boundary between automatic behaviour and manual control to sit?

That transition between automation and direct human intervention has been one of the hardest — and most interesting — parts of building LumaDeck.