Pre-programming without a venue: Flux Lights and an external visualizer over Art-Net

The situation is ordinary. The fixtures are in the warehouse, the get-in is tomorrow morning, and the show has to be ready by the evening. Nobody will give you four quiet hours in the room to build cues — in the room you will be focusing, fixing patch errors and talking to the sound department.

So the show has to be built before the venue, on the table. The console sends DMX over the network, a visualizer receives it and draws the fixtures. You get a picture, and the picture is enough to check the logic.

Why this works at all

Art-Net and sACN are DMX over Ethernet. Not "a way to talk to a node" — the same 512 bytes per universe, wrapped in a UDP packet.

A visualizer does not care where the packet came from. It sees universe numbers and channel values, exactly as a dimmer or a moving head would. To it there is no difference between a console, a node, a test utility or your laptop.

That is why any console with a network output works with any visualizer with a network input. There is nothing to integrate and no plug-in to install: both sides implement the same published standard, and that is the whole mechanism.

One computer: 127.0.0.1

The simplest case, and the one to start with. Console and visualizer run on the same machine, and the packets never leave it.

In Flux Lights: Settings → Network output, add an Art-Net output, node IP 127.0.0.1. That is the loopback address — the machine's own address, which always exists and never depends on a cable, a router, a Wi-Fi network or an IT department.

In the visualizer, switch the input to Art-Net and, if it asks for an interface, pick the local one (usually shown as 127.0.0.1 or localhost).

Two things worth knowing about loopback. It has no bandwidth limit that matters here, so twenty universes are not a problem. And it is immune to everything that normally breaks a network at a venue — nothing to unplug, nothing to route wrongly.

If a firewall on Windows asks about network access, allow it. Loopback traffic is usually allowed by default, but a strict policy can block it too.

Two computers: static addresses

Sometimes the visualizer lives on a second machine — a stronger one, or simply the one with the licence on it. Then it is a real network, and it needs real addresses.

Set static addresses on both machines, in the same subnet. Art-Net historically lives in 2.0.0.0/8, so the classic pair is 2.0.0.1 for the console and 2.0.0.2 for the visualizer, mask 255.0.0.0. The 10.x.x.x range works exactly as well and is more convenient if the same network carries other things too.

Turn DHCP off on that interface. An address handed out automatically will change on the day you least want to think about it.

Unicast is the tidier option. Enter the visualizer's address as the node IP and packets go to that machine and no other. Broadcast (255.255.255.255) also works, and is sometimes the fastest way to check that anything at all arrives — but it floods every device on the wire with tens of universes at 40 frames per second, and other equipment on that network will not thank you for it.

Universe numbers: this is where it breaks

If the visualizer stays black, look here first, before you check anything else.

Art-Net numbers universes from zero. The first universe is 0. Many programs — consoles, visualizers, patch sheets — show universes from one, because that is how people count. Both are correct, and together they give you an off-by-one.

So the console's universe 1 leaves as Art-Net universe 0, while the visualizer, counting from one, expects it in its own line 1 — where universe 1 of the wire arrives, which is the console's second universe.

In Flux Lights the output has a base field: the device universe the range starts from. For Art-Net the default is 0, and internal universes 1..n go out as 0..n-1. For sACN the base starts at 1, because sACN numbers from one.

The practical rule: if the picture is empty, shift the base by one in either direction and look again. In the overwhelming majority of cases that is the whole problem. Try it before you rebuild the patch or reinstall anything.

Check that data is arriving

Do it before you start programming, not after the first cue fails to work.

Bring one fixture up to full — dimmer 100%, and open the shutter if the profile has one. Then look at the screen. Something moved, lit up or changed colour: the chain works, and everything after this point is your patch and your cues. Nothing happened: the problem is in the transport, and there are only three places for it — the address, the universe number, or a firewall.

Half a minute now saves an hour of programming into the void, which is the expensive kind of mistake: you find out the show was never being received when the show is already finished.

Worth checking one more thing: that the fixture that lit up is the one you expected. Patch is the second most common source of a wrong picture, right after universe numbering.

Which visualizers accept Art-Net

Practically all of them, because it is the common language of the trade. Among the ones you will meet: Capture, L8 (l8.ltd), Depence, MA 3D, WYSIWYG, Vectorworks Vision.

Most of them have a free or demo edition, usually limited by the number of fixtures — commonly a few dozen. For pre-programming a club show or a mid-sized concert set that is often enough, and it costs nothing to find out.

Which one to take is not a question this article can answer: they differ in render quality, fixture library, price and how they feel to work with, and that choice is yours. The mechanism above is the same for all of them.

What a visualizer will and will not tell you

It will show you direction, colour, gobo, timing. That means it checks the logic of the show: does the chase run the right way round, does the colour change land on the beat, is the fade too slow, does a cue leave a fixture lit that should be dark, do the positions read as a group or as noise.

That is most of the programming work, and it is the part that takes the hours you do not have in the room.

It will not do the focusing. The angles in the visualizer come from your model of the venue, and the model is never the venue: the truss ends up half a metre lower, the fixture hangs at a different tilt, the beam aimed at the vocalist lands on the drum riser. Positions will need touching up on site, all of them.

It will not tell you that a head runs into the truss, that a beam blinds the first row, or that the haze drifts the wrong way. Nor will it show you what the fixtures really look like — brightness, beam edge and colour on stage depend on the room, the haze and the eye, and no render is that honest.

That does not make it less useful. It changes what you arrive with: instead of an empty console and four hours of work, you come in with a finished show that needs positions corrected and timing adjusted to the real room. That is a different evening entirely.

The built-in 2D stage

Flux Lights has its own visualization — the Stage tab. It shows the layout, the beam direction, the colour and the state of each fixture on a plan view.

That is enough not to get lost among the fixtures: to see which head you selected, that the group is picked correctly, that colours run along the line in the right order. In everyday work it is what you actually look at.

It is not a photorealistic render, and it does not try to be. There is no room, no haze, no beam in the air, no view from an audience seat. If you need to see how the show reads from the tenth row, that is a job for an external visualizer — and it is exactly what the network output is for.