DMXRouter 1.9.6

Fixture Check (Web tablet)

• Change Address from the tablet — open any fixture's detail pane on the web client and you'll see a new Change Address button at the bottom. Tap it for a compact dialog with universe and channel spinners pre-filled with the fixture's current address, and a live warning that flags any landing zone that would push the fixture past channel 512 of the chosen universe given its footprint. Apply commits the change, the patch tree and detail pane refresh automatically. Cells and multi-cell containers don't show the button — those inherit their address from the parent fixture and have no independent DMX placement, same as on the desktop. The dialog accepts Enter to apply (when the values are valid) and Escape to cancel, useful with a Bluetooth keyboard

• Remove fixture from the tablet — next to Change Address, a Remove button. Tap to get a confirmation card showing the fixture's name, manufacturer/model, and current address so you can verify before pulling the trigger. Two extra warnings appear when relevant: removing a single cell of a multi-cell fixture is called out so you don't think you're pulling the whole unit, and removing a multi-cell container surfaces the cell count so you know exactly what's about to disappear. Confirm and the fixture is gone from the patch on every connected client. The detail pane closes automatically (the fixture it was showing no longer exists), and if you had the Change Address dialog open on the same fixture when it was removed from another client, that closes too — no chance of submitting a request against a dead UUID

• Walk-the-rig now starts on the first fixture, not the second — picking a group of fixtures on the tablet and tapping Start Walk used to skip past element 1 and land directly on element 2 as the active head. The intent of "Start Walk" is "begin from the beginning", not "advance one step", so this is now what you get: tap Start, the first fixture you picked is the one that lights up. Subsequent Next presses still advance through the group exactly as before. Desktop multi-select walk behaviour is unchanged

• List rows scroll into view when a walk step crosses MVR layer boundaries — during a multi-fixture walk that spans different MVR layers (Stage Left → Stage Right, Front Truss → Back Truss, etc.), the next-fixture row could land off-screen or behind a collapsed group, leaving you hunting through the tree to find what was currently lit. The newly active row now scrolls into view automatically on every walk step, including expanding its layer group if it was collapsed. Steps within the same already-visible layer don't jiggle the scroll position — only motion that needs it triggers the scroll

• List filters and sort persist across reloads — the "Overridden only" and "Show cells" chip toggles, alongside the existing Sort chip, now remember their state across page reloads and tablet wakeups. Operators who left "Show cells" on for the previous session come back to the same view instead of having it silently reset to the default

Fixture Check (Desktop & Web)

• Gobo and colour wheels no longer sweep through positions during release fades — fading out an override on a gobo wheel, colour wheel, or any fixed-position discrete attribute used to drag the DMX byte linearly from override value back to the underlying value. On the actual fixture this manifested as the wheel motor visibly stepping through every intermediate position during the fade, which is the exact problem GDTF's Snap=Yes attribute exists to prevent. Channels declared Snap=Yes in their GDTF profile now hold the override value for the entire fade duration and then snap to the underlying value when the fade completes. Other attributes of the same fixture (Dimmer, Pan, Tilt, anything continuous) continue to fade smoothly during the same release, so a release fade of a fixture with a gobo and a dimmer will see the dimmer fade out gracefully while the gobo holds position until the very end — the correct mixed behaviour per spec

• Conditional ranges (ModeMaster) are honoured — many fixtures use a control or macro channel to switch what the rest of a channel means: when Macro = Off, the colour wheel selects basic colours; when Macro = Disco, the same channel runs preset chases. GDTF expresses this with a ModeMaster declaration on each conditional range, naming another channel and the DMX window in which the range is selectable. DMXRouter previously parsed these declarations but ignored them at runtime, so every range showed up in the Channel Set combo regardless of whether the master channel made it actually selectable. Now the ranges that aren't currently selectable appear greyed out and disabled (with a tooltip explaining which master channel they depend on and what value it would need to be at), and they automatically become live the moment the master moves into range — same behaviour on desktop and on the web tablet. Channels with no ModeMaster ranges keep working exactly as before

• Channels boot at the value the manufacturer declared as initial — GDTF's InitialFunction attribute on a LogicalChannel tells DMXRouter which ChannelFunction represents the channel's boot state, when there's more than one. Previously DMXRouter always took the first ChannelFunction listed in the XML as the source of the channel's home value, regardless of what the manufacturer declared as the initial. For most fixtures this happened to coincide; for some macro and mode-select channels it didn't, and the channel would Home to a value the manufacturer never intended as the rest position. The InitialFunction declaration is now honoured: the channel boots at the value of the function the GDTF says it should. When a fixture's <DMXChannel Default="..."> is set explicitly, that still wins (it's the spec-explicit channel default per Table 58); when InitialFunction is missing or points at a function that doesn't exist (broken GDTFs), the previous first-wins behaviour kicks in as a fallback so no fixture regresses

Network

• Faster startup when a profile references an interface that's no longer there — loading a profile whose enabled-interface list includes a NIC that's been unplugged, has had its cable disconnected, or whose IP has changed since the profile was saved used to leave DMXRouter waiting up to two minutes for the missing interface to appear. During that wait the entire transport stack stayed suspended: no Art-Net send, no sACN send, no node discovery, no merges flowing — to the operator it looked like the application had frozen at startup. The wait is now bounded to eight seconds, after which DMXRouter continues with whatever interfaces did show up and logs which ones it gave up on. The missing interface can still be re-enabled later from the Interfaces panel as soon as it actually appears (cable replugged, dongle attached, DHCP lease renewed). On top of the timeout, interface matching is more forgiving: an interface saved as ethernet_X:192.168.1.50 that's now showing the same physical NIC at a different IP will be matched and enabled automatically, instead of being treated as missing because the IP drifted

---

DMXRouter v1.9.6 — Built for the stage.