Reference
Five hundred and twelve slots, and who decides what's in them
A DMX universe is 512 numbered slots, and nothing on the cable says what any of them is for. The fixture decides that from whichever mode its menu is set to; the console decides it again from its fixture library; and they agree only because somebody made them. This page is the bookkeeping: addresses, 16-bit channels, personalities, RDM, the two ways the same data travels over Ethernet, and GDTF and MVR, the pair of file formats that try to write it all down once. Pinouts, timing and termination are on the XLR, AES3 and DMX page.
Universes, addresses and footprints
absolute = (universe − 1) × 512 + address
Universes and addresses both count from 1. (Slot 0 carries the start code and isn't an address anyone patches.) A fixture's footprint is the number of consecutive slots its current mode uses, starting at its start address, and the whole footprint has to sit inside one universe, because a universe is one cable and the fixture is on one of them.
The same slot gets written several ways. Universe 2, address 2 is 2/2 in ETC's port/offset form, 2.2 in the string form the GDTF and MVR specs allow, and 514 as an absolute address, which both specs also accept and grandMA3's DMX sheet will show if asked. They're all the same slot, and a patch that crosses from paperwork in one form to a desk showing another is how a fixture ends up a universe away from where it's hung.
MVR files usually carry the absolute form. MA's demo rig patches one fixture at 3313, which is universe 7, address 241.
| Footprint | Per universe | Slots spare |
|---|---|---|
| 1a dimmer channel | 512 | — |
| 3RGB | 170 | 2 |
| 4RGBW | 128 | — |
| 616-bit RGB, the Vectorworks generic below | 85 | 2 |
| 8 | 64 | — |
| 12 | 42 | 8 |
| 16 | 32 | — |
| 20 | 25 | 12 |
| 24 | 21 | 8 |
| 32 | 16 | — |
| 40 | 12 | 32 |
| 64 | 8 | — |
| 300the 10 × 10 pixel wall below | 1 | 212 |
Fixtures that fit one universe, packed end to end from address 1. The spare slots at the top are free for anything smaller, which is where the hazers usually go.
Coarse and fine
An 8-bit slot has 256 values. That's fine for most things and nowhere near enough for a moving head pointing at something 20 m away, so pan and tilt (and on better fixtures dimmer, zoom and focus) take two slots: coarse, the high byte, and fine, the low one, for 65,536 steps. A desk that patches the pair as one 16-bit parameter hides this from you; a desk with the wrong profile shows you the fine channel as a separate fader that does almost nothing, which is a clue.
| Axis | Range | 8-bit step | at 20 m | 16-bit step | at 20 m |
|---|---|---|---|---|---|
| Pan | 540° | 2.12° | 0.74 m | 0.0082° | 2.9 mm |
| Tilt | 270° | 1.06° | 0.37 m | 0.0041° | 1.4 mm |
One DMX step, as an angle and as the distance the beam moves on a surface 20 m away. On coarse alone, a fade of a position across a stage moves in visible jumps of about 0.7 m. Mechanical resolution and backlash are the fixture's problem and usually worse than the 16-bit figure.
GDTF writes DMX values with their byte count attached, as value/bytes, so a value means the same thing whatever resolution the channel has. By default it scales by byte mirroring: 255/1 in a 16-bit channel is 65535. Add an s for byte shifting and 255/1s is 65280. A pan default of 16384/2 on a channel whose physical range runs 180° to −180° works out at 89.999°, which is the 90° somebody meant: a quarter of 65,535, not of 255.
Personalities, and why one fixture has seven DMX charts
A personality (or mode, or profile, depending on whose manual you're reading) is the fixture's map from slot to function. Manufacturers ship several because addresses are a budget. Forty wash lights on two universes want a small mode with 16-bit position and a global colour; the same fixture doing pixel effects wants every LED cell on its own slots and is happy to eat a universe each for the privilege.
Martin's MAC Aura XIP is a good example of how far that goes. Its manual lists seven modes, and the last two exist so the fixture can pretend to be its predecessor: set an XIP to XB Standard or XB Extended and it answers to a show file written for a MAC Aura XB. That's a personality used for what the word suggests.
Nothing on the wire checks that the desk and the fixture agree. The desk's library describes one mode, the fixture runs whatever its menu says, and the first sign of disagreement is a fixture doing something odd when you touch an unrelated parameter. GDTF takes the problem seriously enough to say that a firmware change that alters a footprint should be a new mode, and MVR requires every fixture's mode name to match one in its GDTF.
| XIP mode | What it adds or does |
|---|---|
| Compact | 16-bit dimmer, RGB, zoom, pan and tilt; 8-bit strobe, colour temperature, tint and virtual colour wheel |
| Basic | Compact, plus FX, the crossfade to P3 video, and the Aura backlight in its own colours |
| Extended | Basic, plus RGB for each Beam pixel |
| Ludicrous | Extended, plus RGB for each Aura filament |
| Compact Direct | Compact with direct control of the white emitters, and no colour temperature, tint or colour wheel |
| XB Standard | behaves as a MAC Aura XB in its Standard mode, from firmware 1.2.0 |
| XB Extended | behaves as a MAC Aura XB in its Extended mode, from firmware 1.2.0 |
From the MAC Aura XIP user manual, revision D. The two XB modes are documented in the MAC Aura XB's own manual, not the XIP's.
An easy version of the problem to make is two mistakes at once. The desk is patched in a 24-slot mode at 1, 25, 49 and so on; the fixtures are in their 16-slot mode, and whoever addressed them counted in 16s. Here's where each one actually starts reading.
| Fixture | Desk thinks it starts at | It actually starts at | Which is the desk's |
|---|---|---|---|
| 1 | 1 | 1 | fixture 1, parameter 1 (lines up) |
| 2 | 25 | 17 | fixture 1, parameter 17 |
| 3 | 49 | 33 | fixture 2, parameter 9 |
| 4 | 73 | 49 | fixture 3, parameter 1 (lines up) |
| 5 | 97 | 65 | fixture 3, parameter 17 |
| 6 | 121 | 81 | fixture 4, parameter 9 |
| 7 | 145 | 97 | fixture 5, parameter 1 (lines up) |
Fixtures 1, 4 and 7 land on the start of a desk fixture, because 24 and 16 meet every 48 slots. If the small mode shares its first few channels with the big one, every third fixture behaves and the rest point at the ceiling, which looks like a fault in the fixtures and isn't one.
RDM: asking the fixture instead of climbing to it
RDM (ANSI E1.20) adds a return path on the same pair, so a controller can find what's on a line and set its address and mode without a ladder. Every responder has a 48-bit UID: a 16-bit manufacturer ID that ESTA assigns, and a 32-bit device ID the manufacturer picks, usually written MMMM:DDDDDDDD in hex. That's room for 65,536 manufacturers with 4,294,967,296 devices each, which should do.
Discovery is a binary search. The controller asks "anything with a UID between these two?"; if several answer at once the replies collide, so it halves the range and asks again, and mutes each device as soon as it's found. A single device can be pinned down in at most 48 halvings.
Once found, it's GET and SET on parameters. The useful thing for this page is that a fixture will tell you its current personality, and for any personality its footprint and a description, which is enough to catch a mismatch before you program on top of it. It won't give you the slot-by-slot chart; that's still the library's job.
RDM needs every splitter and buffer on the line to pass the return path, and the XLR page covers why three-pin infrastructure often doesn't. Over a network, Art-Net carries RDM in its own packets and RDMnet (ANSI E1.33) does it natively.
| PID | Parameter |
|---|---|
| 0x0001 | DISC_UNIQUE_BRANCH"Anyone with a UID between these two?" The binary search. |
| 0x0002 | DISC_MUTEStop answering discovery: you have been found. |
| 0x0060 | DEVICE_INFOModel, current personality, footprint, start address, sub-device and sensor counts. |
| 0x0082 | DEVICE_LABELA name you can set, such as "SR truss 3". |
| 0x00E0 | DMX_PERSONALITYGet or set the mode, by number. |
| 0x00E1 | DMX_PERSONALITY_DESCRIPTIONFor a mode number: its footprint and a text description. |
| 0x00F0 | DMX_START_ADDRESSGet or set the start address. |
| 0x0201 | SENSOR_VALUETemperatures, fan speeds and whatever else the fixture measures. |
| 0x0401 | LAMP_HOURSWhat it says. |
| 0x1000 | IDENTIFY_DEVICEFlash, wiggle or otherwise wave at you. |
The parameters you'll meet first. IDs from the Open Lighting Architecture's implementation of E1.20.
DMX over a network: Art-Net and sACN
Both put DMX universes in UDP packets, a node at the far end turns them back into cable, and most consoles and nodes speak both. They differ in how a universe is named and in what happens when two sources send the same one.
| Art-Net | sACN | |
|---|---|---|
| Who | Artistic Licence. Royalty-free; current version Art-Net 4 (2016). | ANSI E1.31, an ESTA standard. ESTA lists the 2025 revision, which adds IPv6. |
| Transport | UDP port 6454. Unicast to the nodes that want a universe; broadcast for discovery. | UDP port 5568. Multicast, one group per universe; unicast also allowed. |
| A universe is | A 15-bit Port-Address, Net:Sub-Net:Universe (7, 4 and 4 bits), from 0. | A number from 1 to 63999, joined at 239.255.hi.lo. |
| How many | 32,768. Art-Net II had only Sub-Net and Universe, so 256, and old gear may ignore Net. | 63,999. 0 and 64000 upwards are reserved. |
| Two sources | No priority in the DMX packet. A node merges two sources, highest takes precedence unless set to LTP. | Priority 0–200, default 100. Highest wins; a tie at the top is left to the receiver. |
| Source lost | Up to the node. | After 2.5 s of silence, or at once if the source sends a stream-terminated flag. |
| Discovery | ArtPoll and ArtPollReply. | Universe discovery packets on universe 64214. |
| RDM | Yes, in its own packets. | No. That's RDMnet, E1.33. |
Art-Net originally broadcast on 2.x.x.x and 10.x.x.x networks; these days DHCP or any static scheme is fine. ETC's per-address priority is a second stream on the same universe with start code 0xDD, which ETC registered with ESTA; it isn't part of E1.31 and gear that ignores it falls back to the universe priority. A node that ignores start codes altogether reads it as levels, and every channel flashes to about 39 % (a priority of 100 out of 255) each time one arrives.
The trap is the numbering. Art-Net counts from 0 and sACN from 1, and most desks map their universe 1 to Art-Net 0:0:0 and sACN 1, so the two protocols name the same universe with different numbers. Some desks and nodes label Art-Net from 1 instead. When a node lights up one universe off, it's nearly always this.
| Desk universe | Art-Net Port-Address | Net:Sub-Net:Universe | sACN group |
|---|---|---|---|
| 1 | 0 | 0:0:0 | 239.255.0.1 |
| 2 | 1 | 0:0:1 | 239.255.0.2 |
| 16 | 15 | 0:0:15 | 239.255.0.16 |
| 17 | 16 | 0:1:0 | 239.255.0.17 |
| 256 | 255 | 0:15:15 | 239.255.1.0 |
| 257 | 256 | 1:0:0 | 239.255.1.1 |
| 32,768 | 32,767 | 127:15:15 | 239.255.128.0 |
| 32,769 | — | past the end | 239.255.128.1 |
| 63,999 | — | past the end | 239.255.249.255 |
With desk universe 1 mapped to Art-Net 0:0:0. Sub-Net steps every 16 universes and Net every 256; Art-Net runs out at 32,767, which is 127:15:15.
GDTF: the fixture, described once
Every console, visualiser and CAD package has kept its own fixture library for decades, each typed in separately, each wrong in its own way. GDTF, the General Device Type Format, started by MA Lighting, Robe and Vectorworks, is the attempt to have the manufacturer write one file that all of them read. It's standardised as DIN SPEC 15800:2022-02 (GDTF 1.2), and the files are shared on GDTF Share, which its founders say passed 7,000 files in 2025.
A .gdtf is a zip named Manufacturer@Fixture@comment, holding a description.xml, a thumbnail, gobo images under wheels/ and 3D models under models/ (3DS, glTF and SVG views, each with low and high detail variants). The XML's sections come in a fixed order: attribute definitions, wheels, physical descriptions (emitters, filters, colour spaces, measured curves), models, the geometry tree, the DMX modes, revisions, presets and the network protocols it speaks.
A DMX mode is a list of channels, and each channel names the geometry it acts on and the attribute it controls. Its Offset is the slot or slots it occupies, coarse first: 1,2 is a 16-bit pair. An empty offset is a virtual channel that takes no slot at all, which is how a fixture with no dimmer channel still gets a dimmer on the desk. Repeated parts (pixels, cells, emitters) are described once and placed many times with GeometryReference, and each reference gets its own DMX offset, so a mode can be a short template that unpacks into hundreds of slots.
| Attribute | Offset | Slots | Default |
|---|---|---|---|
| Dimmer | empty | 0 | 0/4 |
| ColorAdd_R | 1,2 | 2 | 65535/2 |
| ColorAdd_G | 3,4 | 2 | 65535/2 |
| ColorAdd_B | 5,6 | 2 | 65535/2 |
| Footprint | 6 |
The one mode of Generic@LED_RGB8_16_bit.gdtf, as shipped in Vectorworks 2025 (GDTF DataVersion 1.0, dated 2019). 4 channels declared, 1 virtual, 6 slots. The dimmer reaches the colour channels through three Multiply relations.
MVR: the rig, in one zip
MVR, My Virtual Rig, is the same idea one level up: the whole show rather than one fixture. It's DIN SPEC 15801:2023-12, which is MVR 1.6. A .mvr is a zip with a GeneralSceneDescription.xml at its root, every GDTF the rig uses, and the 3D models and textures for the scenery, all at the top level (no folders), stored or deflated, never encrypted.
Each fixture in the scene carries a UUID, a position matrix, the GDTF file and mode name it uses, its fixture ID and unit number, its DMX addresses (absolute, or Universe.Address), a colour, and the protocols it's reached by: Art-Net, sACN, RDMnet, PosiStageNet, OSC, CITP and NDI are predefined. The UUIDs are the point. The plot goes from CAD to the console, the programmer repatches, the visualiser adds focus positions, and the file goes back to CAD with every object still recognisably itself. The spec says an application must keep an unchanged GDTF as it found it, must add a revision to one it changes, and must change only what the user meant to change.
MVR-xchange moves the file between applications without a USB stick. In TCP mode the applications find each other by mDNS (_mvrxchange._tcp.local., with the project's group as a sub-service) and need no configuration, but it won't cross a router. WebSocket mode needs a server address and will. Either way the conversation is a handful of messages: join, commit a new version, request a file, leave.
What real files do that the specs don't mention
These turned up building simpleVIS against real files rather than the spec's examples: MA Lighting's demo rig (MVR 1.5, 119 fixtures on 28 universes, seven manufacturers' GDTFs packed inside) and the generics Vectorworks ships. None of them fails loudly. Each one looks like a bug in whatever is reading the file.
- The XML isn't well-formed. Every description file examined from MA's library ends with a NUL byte after the closing tag. A strict parser throws the whole document away over it. Strip trailing NULs before parsing.
- A mode is a template, not a footprint. MA's Generic LED Wall 10x10 declares 4 channels, one of them virtual, and 100 geometry references. Read literally it's a 3-slot fixture and only its first pixel lights. Unpacked, it occupies 300 slots. Each instance lands at break offset + (template offset − 1).
- A virtual dimmer has to read as open. The wall's dimmer is virtual with a default of 0, and so is the one in Vectorworks' generic RGB file above. Honour the default and the colours multiply by zero forever, because there's no slot that could ever raise it.
- MVR and GDTF disagree about matrices, in the same zip. An MVR <Matrix> is four groups of three (the u, v and w vectors, then the origin) in millimetres. A GDTF Position is four groups of four, the rows of a 4×4, in metres. Both parse whichever way round you read them; only one way gives numbers that make sense.
- Colours are CIE xyY. MA writes white as 0.312712,0.329008,100, which is D65 and converts to sRGB white . Read it as RGB and it's rgb(0, 0, 100), a near-black blue .
- Physical ranges run backwards. Pan 270 to −270, tilt 134 to −134, zoom 50.2 to 6.6, colour temperature 5800 to 2850. Always interpolate from PhysicalFrom to PhysicalTo; sort them and every fixture mirrors. Some files write the literal string None there instead of a number.
- Channels aren't in slot order. One fixture writes its blade channels 33 to 36 before 29 to 32. Position comes from the offset, never from where the channel sits in the document.
- Fixture models are 3DS, scenery is glTF. The GDTFs in MA's demo carry only models/3ds, while the MVR's own scene objects are .glb. A loader that only looks for glTF draws the truss and none of the lights.
- DMX breaks count from different places. GDTF's DMXBreak defaults to 1; MVR's Address node defaults its break to 0. Neither spec spells out how the two pair up, so check what your importer does with a multi-break fixture before trusting its patch.
Patch a run
Put in where the run starts, the footprint of the mode the fixtures are actually in, and how many there are. It packs them in order, moves to the next universe when a fixture won't fit in what's left, and gives you the Art-Net and sACN names for every universe it uses.
| Universe | Fixtures | Slots used | Art-Net | sACN group |
|---|
| Fixture | Universe/address | Absolute | Last slot |
|---|
This calculator needs JavaScript. The footprint table above covers how many of each size fit a universe.
A fixture never straddles a universe here, because it can't on a real cable. Fixtures with more than one DMX break (some LED products want a universe per break) need each break patched on its own; treat each break as its own run.
Sources
- GDTF, DIN SPEC 15800:2022-02, read as the markdown copy in mvrdevelopment/spec (gdtf-spec.md): the archive layout and file naming, the section order, DMX channel Offset and virtual channels, GeometryReference and breaks, the DMXValue byte mirroring and shifting example, the row-major metre matrix, and the rule that a changed footprint is a new mode.
- MVR, DIN SPEC 15801:2023-12 (MVR 1.6), the same repo's mvr-spec.md: the archive rules, the Fixture node, absolute or Universe.Address addresses, CIE xyY colours, the millimetre 4×3 matrix, the predefined protocol names and MVR-xchange's two modes. GDTF Share's 7,000-file figure is a headline on gdtf.eu.
- Real files. Vectorworks 2025's Generic@LED_RGB8_16_bit.gdtf and Generic@LED_RGBW8.gdtf, unzipped and read here. MA Lighting's Demostage_MVR.mvr, which ships inside grandMA3, read while building simpleVIS; the traps section is from those notes.
- sACN, ANSI E1.31. ESTA's published-documents list shows the 2025 revision as current. The text is free but behind a registration form, and I didn't read it: the port (5568), the multicast mapping, the default priority (100), the discovery universe (64214) and the 2.5 s source timeout are taken from the Open Lighting Architecture's implementation, and the 1–63,999 range from the same and from Martin's MAC Aura XIP manual, which offers the same range on the fixture's menu.
- Art-Net, Artistic Licence's Art-Net 4 specification, which I couldn't fetch (the PDF sits behind a captcha). The Port-Address layout, the ArtDmx fields and the HTP merge default are from OLA's Art-Net plugin; UDP 6454, the version history and the 2.x/10.x addressing from Wikipedia.
- RDM, ANSI E1.20 (ESTA lists a 2025 revision). The UID layout and the parameter IDs are from OLA's UID.h and RDMEnums.h. RDMnet is ANSI E1.33-2019.
- Martin, MAC Aura XIP User Manual, revision D, for the seven DMX modes and the XB modes' firmware 1.2.0 start. ETC's Eos online help for port/offset notation, and ETC's support articles on per-address priority and the node that flickers when it reads 0xDD as levels; MA Lighting's grandMA3 manual for the DMX sheet's absolute and universe views.
Assembled 3 November 2026 with AI assistance. The address, Art-Net and sACN arithmetic is computed and round-tripped over its full ranges at build time, and pinned to worked values taken from real files; the GDTF footprints are recomputed from the offsets in two real fixture files and asserted. Three of the standards behind this page (E1.31, E1.20 and Art-Net 4) weren't read directly, and their figures come from a well-used open-source implementation instead, which is a step removed from the text. The mode-mismatch table is arithmetic, not a recording of a real rig. Shout if any of it is wrong.
Companion pages: XLR, AES3 and DMX for the cable, the timing and why RDM dies at a three-pin splitter; Ethernet cabling for the network that Art-Net and sACN ride on; and simpleVIS, which reads an MVR and takes Art-Net, sACN or DMX in.