# DMX Desk

> A universe is a time budget, not a channel count. DMX512 runs at 250 kbit/s, every
> slot is 11 bits — 44 µs — and a packet is a break, a mark after
> break, a start-code slot and up to 512 data slots: 92 µs + 12 µs + 513 × 44 µs = **22.68 ms, which is 44.1 Hz**.
> **YOU PAY FOR THE SLOTS YOU SEND, NOT THE ONES YOU USE** — send only 128 and the same wire runs at 173 Hz, and most consoles send all 512 whatever is patched. **SIXTEEN BITS BUYS RESOLUTION, NOT SMOOTHNESS**: a 3 s fade gets 132 moments, so 65,536 values means stepping 495 values at a time against 1.93 for eight bits. **AND THE MODE IS THE COST** — the same LED par
> is 4 slots in one mode and 12 slots in another, 128 fixtures a universe against 42, and because a fixture needs CONTIGUOUS slots inside
> ONE universe a width that does not divide 512 strands a tail nothing can use.

## The one thing to know

**A UNIVERSE IS A TIME BUDGET, NOT A CHANNEL COUNT.**

```text
slot     = 11 bits at 250 kbit/s                     = 44 us
packet   = break + mark + (slots + 1) * slot         <- the start code is a slot
refresh  = 1 / packet                                <- the ceiling on everything
moments  = fade seconds * refresh                    <- what smoothness actually is
fit      = floor(512 / mode width)                   <- rounded DOWN, per universe
stranded = 512 - fit * mode width                    <- and this is waste, not spare
footprint= count * mode width
```

**THE REFRESH DEPENDS ON THE SLOTS YOU SEND**, which on most consoles is all 512 whatever is patched — so it has nothing to do with the
size of your rig. A full packet is 22.68 ms and that is 44.1 Hz; stopping at 128 slots gives 173 Hz — 3.92x — for one setting.

**SIXTEEN BITS BUYS RESOLUTION, NOT SMOOTHNESS.** A fade can only change at a packet
boundary, so a 3 s fade at 44.1 Hz gets 132 moments. Sixteen bits gives 65,536 values to choose between and still only 132 moments to choose at, so it steps 495 values at a time against 1.93 for eight bits. Past the point
where the moments run out, bit depth buys precision at a destination rather than
smoothness on the way — and at 10 s an 8-bit fade has 441 moments against 256 values, so it cannot step at all while a 16-bit one still skips 149.

**AND DIVIDING IS NOT THE METHOD.** A fixture needs CONTIGUOUS slots inside ONE
universe, so 64 fixtures at 24 slots is 1,536 slots — which divides into 3 universes — and only 21 fit in each, so it really
needs 4. The 8 stranded slots per universe add up, and division
cannot see them.

**AND THE NETWORK IS NOT THE CEILING.** Art-Net and sACN carry universes over Ethernet
at any rate you like, and both end at a node that clocks DMX512 out of a socket.
Sending a thousand packets a second into a node does not make a fixture update faster;
it fills a buffer. What Ethernet buys is universes and cable runs, never refresh.

## How the packet is built

| Term | Length | Why |
| --- | --- | --- |
| a bit | 4 µs | 250 kbit/s, which is the line rate |
| a slot | 44 µs | 11 bits: one start, eight data, two stop |
| the break | 92 µs | the DMX512-A minimum, and it marks the start of a packet |
| the mark after break | 12 µs | the DMX512-A minimum, before the start code |
| the start code | 44 µs | a slot like any other, and the commonest off-by-one here |
| **512 data slots** | **22.53 ms** | 512 × 44 µs |
| **a full packet** | **22.68 ms** | 92 µs + 12 µs + 513 × 44 µs |
| **the refresh** | **44.1 Hz** | one divided by the packet length |

**44.1 Hz is the ceiling on everything a DMX fixture can be told.** Not the console's frame rate, not the network's, not the fixture's own processor — the wire. Every fade, every move and every strobe step in the rig happens at a packet boundary or not at all.

## The refresh rate at every packet length

| Slots sent | Packet | Refresh | Against a full universe |
| --- | --- | --- | --- |
| 512 | 22.68 ms | **44.1 Hz** | 1x |
| 384 | 17.04 ms | **58.67 Hz** | 1.33x |
| 256 | 11.41 ms | **87.63 Hz** | 1.99x |
| 192 | 8.596 ms | **116.3 Hz** | 2.64x |
| 128 | 5.78 ms | **173 Hz** | 3.92x |
| 64 | 2.964 ms | **337.4 Hz** | 7.65x |
| 32 | 1.556 ms | **642.7 Hz** | 14.6x |

**You pay for the slots you SEND, not the ones you use.** Packet length is linear in slots, so refresh is very nearly inversely proportional to them — halving what you send nearly doubles the rate. Most consoles and nodes send all 512 regardless of what is patched, which means a rig using a quarter of a universe is being updated at 44.1 Hz when it could have 173 Hz for a setting.

## What a fade actually gets

| Fade | At 44.1 Hz | At 173 Hz | 8-bit skips | 16-bit skips |
| --- | --- | --- | --- | --- |
| 0.25 s | **11 moments** | 43 moments | 23.13 values | 5944 values |
| 0.5 s | **22 moments** | 87 moments | 11.56 values | 2972 values |
| 1 s | **44 moments** | 173 moments | 5.78 values | 1486 values |
| 2 s | **88 moments** | 346 moments | 2.89 values | 743 values |
| 3 s | **132 moments** | 519 moments | 1.93 values | 495 values |
| 5 s | **220 moments** | 865 moments | 1.16 values | 297 values |
| 10 s | **441 moments** | 1,730 moments | 0.58 values | 149 values |

**Sixteen bits buys resolution, not smoothness.** The last two columns are how many values a fade across the full range SKIPS at each update, and the 16-bit column is where the argument dies: a 3 s fade at 44.1 Hz has 132 moments and 65,536 values to choose from, so it steps 495 values at a time. The refresh is the limit. Below about 100 moments the steps are visible on a slow move, and shortening the packet is the only thing on this page that moves that number.

## What each mode width costs

| Mode width | Fixtures a universe | Slots stranded | A bar of 24 needs |
| --- | --- | --- | --- |
| 1 slot | 512 | — | 1 universe |
| 3 slots | 170 | **2** | 1 universe |
| 4 slots | 128 | — | 1 universe |
| 6 slots | 85 | **2** | 1 universe |
| 8 slots | 64 | — | 1 universe |
| 10 slots | 51 | **2** | 1 universe |
| 12 slots | 42 | **8** | 1 universe |
| 16 slots | 32 | — | 1 universe |
| 24 slots | 21 | **8** | 2 universes |
| 32 slots | 16 | — | 2 universes |
| 48 slots | 10 | **32** | 3 universes |

**Dividing is not the method.** 64 fixtures at 24 slots is 1,536 slots, and 1,536 slots ÷ 512 is 3 universes — but only 21 fit in each, so it really needs 4. The 8 stranded slots per universe add up, and division cannot see them.

**A fixture's slot count is a menu choice, not a property.** The same LED par is 4 slots in one mode and 12 slots in another, which is 128 fixtures a universe against 42. And because a fixture needs CONTIGUOUS slots inside ONE universe, a width that does not divide 512 leaves a tail that nothing can use: 12 slots strands 8 and 24 slots strands 8.

## The transports, and why none of them helps

| Transport | Can be sent faster | What the fixture sees | Why |
| --- | --- | --- | --- |
| DMX512-A over RS-485 | no | **44.1 Hz** | The wire IS the clock. |
| Art-Net over Ethernet | yes | **44.1 Hz** | Art-Net carries universes as UDP packets and can be sent at any rate, but every node converts to DMX512 on its output — so the fixture sees DMX timing however fast the network was. |
| sACN (E1.31) over Ethernet | yes | **44.1 Hz** | The same as Art-Net: the network is not the bottleneck and the gateway's DMX output is. |

**The network is never the ceiling.** Art-Net and sACN carry universes over Ethernet at whatever rate you like, and both end at a node that clocks DMX512 out of a socket. Sending a thousand packets a second into a node does not make a fixture update faster; it fills a buffer. What Ethernet buys is universes and cable runs, never refresh.

## Thresholds

| Constant | Value | What it decides |
| --- | --- | --- |
| the line rate | 250 kbit/s (4 µs a bit) | everything: it is DMX512's own number |
| bits a slot | 11 | one start, eight data, two stop, so a slot is 44 µs |
| the break | 92 µs | the DMX512-A minimum; a longer one costs refresh directly |
| the mark after break | 12 µs | the DMX512-A minimum, for the same reason |
| slots a universe | 512 | the capacity, and the boundary a fixture cannot straddle |
| full | 90% of a universe | above this a universe that fits is reported as having no room |
| roomy | 60% of a universe | below this there is room for another fixture of the widest mode |
| visibly stepped | 100 moments | below this a fade's steps are reported as visible on a slow move |
| assumed universes | 1 | used when RIG leaves it out, and always reported |
| assumed send | `full` | the pessimistic reading and what most consoles do; always reported |
| assumed fade | 3 s | used when RIG leaves it out, and always reported |

**The first five are the standard's numbers rather than choices**, and they are in this table so a reader can check them rather than take them on trust. The rest are this page's policy, and the harness proves every one of them is load-bearing by moving it and requiring the report to move with it.

## Sheet grammar

Two blocks. `RIG` is `key | value`, one per line. `FIXTURES` is a table.

```
RIG
name      | the studio grid
universes | 1          how many DMX universes the rig has
transport | dmx        dmx, artnet or sacn - none of them changes the ceiling
send      | full       `full` sends all 512 slots every packet; `used` stops early
fade      | 3 s        the fade to price for smoothness; a bare number is seconds

FIXTURES
f1 | the key washes | 8  | 12 | 16-bit RGBW plus strobe and macro
f2 | the movers     | 6  | 24 | full 16-bit pan and tilt
```

A FIXTURES row is `id | what it is | count | slots each | why`. The id, the description, the count and the slot width are all required; the why is not.

**THE SLOT COUNT IS THE WIDTH OF THE MODE, NOT A PROPERTY OF THE FIXTURE.** The same LED par is 4 slots in one mode and 12 slots in another, and that is the number this whole page turns on. Take it from the fixture's mode table, not from the marketing.

**`send` is `full` or `used`, and it is worth more than anything else on the sheet.** `full` means every packet carries all 512 slots, which is what most consoles and nodes do; `used` means the packet stops at the highest patched slot. On a rig using half a universe that is the difference between 44.1 Hz and 87.63 Hz.

**FIXTURES ARE PATCHED FIRST-FIT IN SHEET ORDER**, because that is what a patch sheet follows. Each one takes CONTIGUOUS slots inside ONE universe, so a universe whose tail is narrower than the next fixture strands it — and the order you write the groups in changes how many fit.

**A bare number in `fade` is SECONDS**, because that is what every console marks a fade time in. `ms` is accepted.

## Lanes

- **`plan`** — Patch against the packet, not the plot. A rig gets patched by counting channels until the universes run out, and the refresh rate is discovered on the day the first slow fade looks stepped. This works the other way: start from the packet, decide what refresh the show needs, and spend the slots — and the modes — against it.
  Sections: Summary, The Sheet, The Setting, Reasoning, Next Step.
- **`check`** (primary) — Whether this rig fits, and how fast it will run. The paid read of what the free panel computes. Every group's footprint, where each one lands, what the universes actually hold once the boundaries are honoured, and the refresh rate the packet allows — which is the number nobody checked and the one every fade depends on.
  Sections: Summary, Verdict, Findings, Corrected Sheet, Next Step.
- **`packet`** — The packet question: where the refresh rate comes from. A universe is a time budget. 250 kbit/s, eleven bits a slot, and a full packet is 22.676 ms — 44.1 Hz, and that is the ceiling on everything. This reads the packet apart: what it is made of, what the refresh allows, and what sending only the patched slots would be worth.
  Sections: Summary, What The Packet Costs, What The Refresh Allows, What Shortening It Buys, Next Step.
- **`patch`** — The patch question: where the fixtures land and what the edges waste. A fixture needs contiguous slots inside one universe, so a patch is a packing problem rather than a division — and 512 divided by a mode that does not fit it leaves a tail nothing can use. This reads the placement: group by group, universe by universe, and slot by wasted slot.
  Sections: Summary, Group By Group, Where They Land, What The Boundaries Waste, Next Step.
- **`deliver`** — Decide what changes: a mode, a universe, or nothing. Sorts every finding into what a mode change fixes, what only another universe fixes, and what nothing fixes. The third bucket is the honest one: 44 Hz is not a setting, a faster network does not reach the fixture, and more bit depth does not buy a smoother fade.
  Sections: Summary, A Mode Change Fixes, Only Another Universe Fixes, Nothing Fixes, Next Step.

## Findings

All 30 are computed in the browser and cost nothing.

| Code | Severity | Scope | What it says |
| --- | --- | --- | --- |
| `NO-FIXTURES` | error | rig | No fixtures, so there is nothing to patch |
| `COUNT-NOT-POSITIVE` | error | group | A group with no fixtures in it |
| `SLOTS-NOT-POSITIVE` | error | group | A fixture that takes no slots |
| `WIDER-THAN-A-UNIVERSE` | error | group | A fixture wider than the 512 slots a universe has |
| `IT-DOES-NOT-FIT` | warn | rig | The fixtures need more slots than the universes have |
| `FIXTURES-LEFT-UNPATCHED` | warn | group | Some of this group could not be patched |
| `A-UNIVERSE-IS-FULL` | warn | rig | A universe is close enough to full to have no room for anything |
| `SLOTS-ARE-STRANDED` | warn | rig | A universe has slots left that nothing can use |
| `SENDING-FULL-COSTS-REFRESH` | warn | rig | Every packet carries 512 slots whether or not they are patched |
| `THE-FADE-IS-VISIBLY-STEPPED` | warn | rig | This fade has too few moments to look continuous |
| `UNIVERSES-ASSUMED` | warn | rig | No universe count was given, so one was assumed |
| `SEND-MODE-ASSUMED` | warn | rig | How much of each packet is sent was assumed |
| `TRANSPORT-ASSUMED` | warn | rig | The transport was assumed |
| `FADE-ASSUMED` | warn | rig | The fade length priced for smoothness was assumed |
| `THE-NETWORK-IS-NOT-THE-CEILING` | warn | rig | Art-Net and sACN are faster than DMX and the fixture is not |
| `THE-SLOT-IS-44-MICROSECONDS` | note | rig | What one slot costs, and why |
| `THE-PACKET-IS-THIS-LONG` | note | rig | How long one packet takes |
| `THE-REFRESH-IS` | note | rig | How often a fixture can be told anything at all |
| `SHRINKING-THE-PACKET-BUYS-REFRESH` | note | rig | What sending only the patched slots would be worth |
| `TOTAL-FOOTPRINT` | note | rig | What the rig adds up to |
| `UNIVERSES-NEEDED` | note | rig | How many universes this rig actually needs |
| `HEADROOM-IN-SLOTS` | note | rig | What is left, and how much of it is usable |
| `ROOM-FOR-MORE` | note | rig | How many more fixtures like the widest one would fit |
| `GROUP-FOOTPRINT` | note | group | What this group costs, and the two numbers it comes from |
| `HOW-MANY-FIT-IN-A-UNIVERSE` | note | group | How many of this fixture one universe holds |
| `MODE-IS-A-MENU-CHOICE` | note | group | What a narrower mode would be worth on this group |
| `A-FIXTURE-NEEDS-CONTIGUOUS-SLOTS` | note | group | This group's fixtures cannot be split across universes |
| `THE-FADE-HAS-THIS-MANY-MOMENTS` | note | rig | How many times anything can change during this fade |
| `RESOLUTION-IS-NOT-SMOOTHNESS` | note | rig | What sixteen bits buys, and what it does not |
| `THE-PATCH` | note | rig | Where each group landed |

## What this page cannot do

This page computes from the numbers on the sheet. It has not talked to a console, a node or a fixture.

- **The timing figures are the standard's MINIMA.** 92 µs of break and 12 µs of mark after break are the DMX512-A floor, so 44.1 Hz is a CEILING. Real consoles send longer breaks, insert inter-slot delays and often deliberately slow the rate for old fixtures — all of which make it worse and none better.
- **A console's own frame rate is not modelled.** A desk computing its output at 30 or 40 Hz is a second bottleneck ahead of the wire, and the slower of the two wins. This page reports the wire.
- **Fixture-side smoothing is not modelled either.** Many LED fixtures interpolate between DMX values in their own firmware, which genuinely hides stepping — and how much is a per-fixture behaviour with no published number, so it is stated rather than guessed at.
- **The patch is first-fit in sheet order.** That is what a patch sheet actually follows, but a console's auto-patch or a careful operator will pack tighter. Where the report says fixtures do not fit, re-ordering may be the whole fix.
- **RDM, sACN priority, merging and backup universes are not modelled.** A universe with two sources merging into it behaves in ways no slot count predicts.
- **16-bit is treated as two slots for one attribute.** Fixtures vary in how they lay out coarse and fine, and a few use non-contiguous pairs; the arithmetic here cares only about the total width.
- **Nothing here knows what the show looks like.** Whether 132 moments is enough depends on the move, the fixture, the lens and the camera, and this page has an arithmetic opinion rather than an aesthetic one.
- Nothing here reaches the network, reads a file, or opens a port.

## API

`POST https://api.skillsafe.ai/v1/app-api/run` with a bearer token from
https://dmx-desk.skillsafe.ai/tokens.html. The body IS the input object — there is no
`input` wrapper and no `X-App-Slug` header. `task` is required and must be one of plan, check, packet, patch, deliver. `POST /estimate` is free and validates the same body.
Full documentation at https://dmx-desk.skillsafe.ai/api.html.

## Provenance

Lanes derived from the `openhue` skill in https://github.com/steipete/clawdis.
The arithmetic, thresholds, sheet grammar and findings are this app's own.
Not affiliated with or endorsed by the authors of that repository.