DMXRouter 1.11.2

The headline feature of v1.11.2 is MVR export from the Fixture Check pane — DMXRouter can now write a complete .mvr archive (GeneralSceneDescription.xml + bundled GDTFs) from any patch loaded in the Fixture Check tab. Combined with the RDM discovery and RDM → Fixture Check pipeline, this closes the loop for a commissioning workflow that lives entirely inside DMXRouter: walk on stage, scan the rig over RDM, send the discovered devices to Fixture Check, optionally override-and-test each fixture to confirm wiring and addresses, then export an MVR for import into a lighting console, a previz tool, or a 3D-visualisation pipeline. The other use case the export covers is the relay path — import an MVR from a design tool (Vectorworks, MA3, Capture), edit fixture addresses or modes inside DMXRouter, and export it back out for the next step in the workflow with all the original non-fixture scene content preserved: trusses, supports, scene objects, focus points, group containers, AUXData symbol/class definitions and any UserData from other providers all round-trip verbatim alongside the fixtures DMXRouter actually understands, with the original layer organisation intact. If MVR-xchange is enabled and peers are joined, the export dialog can also push the freshly-written file to those peers in the same gesture via a built-in checkbox — no separate hop through a USB stick or an MVR share dialog.

v1.11.2 also has two primary focus areas for daily-use workflows. The first is the node port configuration workflow — Apply now diffs each row against the last ArtPollReply and only sends the per-port settings that have actually changed, pending edits are visible at a glance with an indicator on the port-number cell, and editing one field no longer freezes the rest of the table from refreshing as new poll replies arrive. The three changes together aim to make targeted port edits during a live show predictable: the operator can tell what they've modified, what will be sent on the wire, and which other rows are still tracking the node's reported state. Reported on GitHub against v1.11.1.

The second focus is the GDTF assignment workflow — the "Assign GDTF manually" dialog gets a full overhaul into a two-pane catalogue/modes view with online-library access built into the bottom of the dialog, mode selection in the same gesture as file selection (so commissioning a fixture is one step instead of two), and correctness fixes that surface ambiguities and outright misses through dedicated status-bar indicators. The library matcher also gets smarter at picking between same-footprint modes by scoring against the RDM device's slot labels, and a new ESTA-ID fallback lets RDM devices resolve against the library even before their MANUFACTURER_LABEL has been fetched. Persistent decisions now cover any fixture identity, not just placeholders. Reported across multiple sessions during commissioning of touring rigs where two or three GDTFs of the same fixture (different uploaders, different revisions, different mode sets) live in the library and the operator needs to pick a specific one — the legacy single-column picker collapsed those into visually identical rows.

The rest of the release rounds out daily-use workflows and platform robustness. The RDM panel gains two finding-fixtures aids: a label search bar that filters the device tree by the RDM DEVICE_LABEL, and a visible highlight for fixtures newly discovered during the last Thorough Discovery run; the PID Browser tab is now a draggable splitter so its parameter list doesn't collapse to a single row on low-resolution screens. The PSN map adds a floor-plane toggle so trackers using the Z-up convention render the same way as PSN-spec Y-up trackers. The Fixture Patch tree gets a Change Fixture ID action on its right-click menu that renames one fixture or renumbers a whole selection consecutively from a starting value, useful for repairing MVRs that arrived with missing or wrong FIDs and for numbering fixtures added via RDM discovery or the manual-add dialogs. A long-standing correctness bug in the RDM-to-Fixture-Check pipeline is fixed: sACN-port-hosted devices now land at the operator's expected universe instead of one off, and the patch-linkage cross-reference matches the same fixture across both naming conventions. Network handling tightens with strict per-NIC isolation for sACN multicast subscriptions, removing fallback paths that quietly routed traffic onto cables the operator hadn't enabled, and the sACN sequence-error counter no longer false-positives once per second on universes coming from ETC consoles (per-address priority packets were consuming a sequence number on the wire that the stats tracker wasn't accounting for). The Stats & Log viewer fixes two GUI-freeze paths — bursty subsystem logging and filter changes used to block the main event loop for several seconds at a time. And the first interface refresh on Linux no longer blocks the UI on a synchronous nmcli query for friendly interface names.

MVR export from Fixture Check

• A new "Export MVR…" button on the Fixture Check toolbar writes a complete .mvr archive of the currently-loaded patch. Click opens an Export MVR dialog with a destination-file picker (defaults to Documents with a timestamped filename, remembers the last directory the operator chose across sessions), a layer-name field (defaults to "DMXRouter Export" — the single layer the exported fixtures will live in inside the archive), and an optional system-note field that lands in the MVR's UserData section as a human-readable tag for the operator on the receiving side. A live preview at the bottom of the dialog shows fixture count, unique GDTFs that will be bundled, estimated archive size, and any warnings (fixtures skipped for not having a GDTF assigned, GDTFs the library couldn't locate). Clicking Export builds the archive, writes it to disk, optionally pushes via MVR-xchange (see below), and reports a summary. The archive is MVR 1.6 conformant (DIN SPEC 15801) — readable by every major lighting console, previz suite, and CAD tool that supports MVR import.

• An optional "Also send via MVR-xchange after writing the file" checkbox in the Export dialog publishes the freshly-built archive to MVR-xchange peers in the same gesture. The checkbox is visible only when the MVR-xchange service is bound (the normal case); it's pre-checked when the service is enabled and peers are joined, pre-checked with an explanatory tooltip when the service is enabled but no peers are currently joined (the MVR is still committed locally so peers can request it when they connect later), and shown disabled with an explanatory tooltip when the service is turned off. Behind the scenes, the export hands the archive bytes to the same publishing path Phase 2 of MVR-xchange used in v1.11.1 — fresh FileUUID, MVR_COMMIT broadcast to joined peers, automatic cold push to peers that haven't joined the inbound listener yet. The dialog's summary message reports both the file write and the MVR-xchange action so the operator gets a single confirmation for the whole workflow.

• The export bundles each fixture's original GDTF unchanged inside the archive. When a fixture in the patch was matched to a real GDTF in the local library (the normal case after MVR import, after the RDM → Fixture Check resolver picks a library entry, or after a manual GDTF assignment from the patch tree), that GDTF file is read from disk and added to the archive verbatim — no re-parsing, no re-serialisation, so DataVersion / FixtureTypeID / mode tables / wheel definitions / 3D model references all round-trip exactly. Multi-cell parent containers (LED bars, pixel matrices) are emitted at the top level; their cells are not duplicated as standalone fixtures because the console expands them itself from the GeometryReference in the parent's GDTF.

• Fixtures without a GDTF assignment (typically RDM discoveries where the library matcher returned no hit, or rare MA2-library imports without a GDTF counterpart) are flagged in a pre-flight prompt before the Export dialog opens. The prompt lists each affected fixture with its operator-assigned name and manufacturer/model so the operator can locate them, and offers three actions: "Resolve in Patch tree…" jumps the focus to the patch tree so the operator can right-click each fixture and use the new Assign GDTF Manually picker (with online-library Browse for one-step download); "Continue and skip" proceeds with the export omitting the unresolved fixtures entirely (no <Fixture> node is emitted for them, and they don't contribute to the archive's bundled GDTFs — the receiving console therefore doesn't see them at all, rather than seeing them with a missing-GDTF reference); "Cancel" backs out without exporting. This replaces the previous silent-skip behaviour where the only signal of a dropped fixture was a small warning line in the export preview.

• MVRs imported from another tool round-trip through DMXRouter without losing their non-fixture content. Trusses, supports, scene objects, video screens, projectors, focus points, group containers, AUXData symbol/class definitions, and any UserData from other providers are all captured verbatim from the source archive at import time (along with the geometry, texture, and 3D-model files they reference) and re-emitted into the exported MVR alongside the fixtures DMXRouter actually understands. The original layer organisation is preserved too: each fixture lands back in its source layer with its UUID, name, and matrix intact; the receiving console sees the same scene structure the operator originally imported, plus whatever fixture-level edits (address changes, mode swaps, GDTF resolutions) were made along the way. Fixtures added during the DMXRouter session that didn't come from the source MVR (RDM discoveries, manual additions) are collected into a separate "DMXRouter Export" layer appended at the en...

DMXRouter 1.11.1

This release adds MVR-xchange support — DMXRouter can now discover other MVR-xchange capable applications on the local network, pull their currently-loaded MVR file directly into the patch, and (when the operator opts in) advertise its own loaded MVR back so the chain works in either direction. The standard the protocol implements is the same one grandMA3, Vectorworks Spotlight, BlenderDMX, Production Assist and Zactrack already speak, so a typical pre-show workflow becomes "designer publishes in Vectorworks → operator pulls into the console of choice → DMXRouter pulls the same file" without a USB stick or a Dropbox link changing hands. The Universe Monitor gains a per-cell channel-label band that abbreviates the GDTF or MA2 attribute name above each value cell so the operator can identify Pan, Dim, R, G, B, Zoom, Iris, etc. at a glance without going to the Fixture Check panel. Several real-world bugs reported against v1.11.0 are fixed.

MVR-xchange

• A new "MVR-xchange…" entry in the patch panel's Add ▾ menu opens a single-page dialog that covers both halves of the standard at once — discovery and sharing. A toggle button at the top — "Activate MVR-Exchange" — switches everything on together: DMXRouter joins the mDNS multicast group as <station-name>.<group>._mvrxchange._tcp.local. with the full record set (PTR, SRV, two TXT records carrying StationName and StationUUID, and an A record), starts a TCP listener on an OS-assigned high port and advertises that port in the SRV record, and begins browsing the network for other MVR-xchange capable stations. While the service is active, the Identity section (Station name defaults to DMXRouter on <hostname>, Group defaults to Default matching every other MVR-xchange capable application — grandMA3 in particular is case-sensitive on this name, and the persistent Station UUID is read-only) is locked so a rename mid-show doesn't briefly black out joined peers — stop, edit, start again is the supported pattern. A transaction log at the bottom of the dialog scrolls every protocol event in real time (IN MVR_JOIN from gMA3, OUT MVR_COMMIT to gMA3 @ 192.168.1.50:42424, IN MVR_REQUEST file=test.mvr, ✓ gMA3 acknowledged) so the operator can see at a glance who's talking and whether the handshake is going through, without reaching for Wireshark.

• An "Interface" selector picks which NIC DMXRouter advertises on, defaulting to "All interfaces (auto)" which broadcasts on every up-and-running IPv4 NIC including loopback — the right choice for the common case where DMXRouter and a peer application live on the same workstation. The default sends one announce per NIC with the A record pointing at that NIC's IP, so a peer receiving the announce over loopback gets a 127.0.0.1 address it can connect to, and a peer on the show LAN gets the show-LAN IP for the same DMXRouter — no mismatched routing that would have the peer trying to TCP-connect to an interface it can't reach. The selector also exposes "Loopback (127.0.0.1)" only for tight same-host setups where the operator wants to keep the chatter off the public LAN, and each detected IPv4 NIC by name and address for show-floor setups where traffic must be confined to one network. Selecting an interface restarts the announce burst immediately so peers pick up the new egress without waiting the next periodic re-announce tick. The choice is persistent — DMXRouter remembers the last selection across restarts and re-applies it on the next Activate.

• Discovered stations appear in a tree as soon as they answer the mDNS query — name, IP, application provider (grandMA3, Vectorworks, BlenderDMX, …) — and a parallel TCP connection runs in the background to fetch each station's commit list, which populates as child rows under the station with the file name, size and free-form comment the publisher attached. Pick a commit, click Download & Import and the dialog requests the binary, hands the bytes to the same MVR import pipeline the file-picker side uses, with the existing Replace / Merge prompt when a patch is already loaded. The browse runs indefinitely until the operator stops or closes the dialog — there's no fixed timeout that would miss stations whose mDNS responder takes a few seconds to wake up. Once a file has been pulled successfully, MVR-xchange stops itself automatically: the dialog closes into the import flow and the operator is heading into patch edits, not waiting for more network chatter. Re-opening the dialog and clicking Activate again re-arms the service.

• Importing or replacing the loaded MVR mid-session propagates to every currently-visible peer automatically. Whether the bytes came from the file picker, from a Download & Import in this same dialog, or from any other input path, the moment the local store gains a new commit DMXRouter opens a fresh outbound TCP to every discovered peer (and to every peer that previously joined us inbound) and pushes an MVR_COMMIT describing the new commit (FileUUID, file name, size, comment). The peer's UI updates to show the new entry, the operator on that peer can pick it and pull it back. Clearing the patch propagates as a "no current commit" signal. The host serves the same bytes the operator loaded, byte-for-byte — DMXRouter does not regenerate or re-export the MVR on patch edits (manual fixture additions, address changes, mode changes), so the file every peer in the chain sees is exactly the one that came in from upstream, no quality loss in the link. The push is robust against peer quirks: clients that only listen for MVR_COMMIT on connections where they're the TCP server (grandMA3 falls in this group) get a fresh outbound from us regardless of which side initiated the original handshake.

• A short initial announce burst surfaces DMXRouter on the local network within milliseconds rather than waiting for the steady-state re-announce tick. When the service activates, DMXRouter emits a sequence of five mDNS announcements at 0, 250, 500, 750 and 1500 ms before settling into a 10-second re-announce cadence — comfortably below the records' published TTL so peers that join the LAN late see DMXRouter without waiting for full TTL expiry, and dense enough at the start that a peer like grandMA3's Bonjour Service catches the announcement even when its own mDNS initialisation is partway through. The cache-flush bit is set on the SRV / TXT / A records so a peer that had us cached from a previous session (different TCP port after restart, possibly different station name) replaces the old entry immediately rather than talking to a dead port for the rest of the cached TTL. Stopping the service sends a goodbye announcement with TTL=0 so well-behaved peers prune DMXRouter from their list immediately rather than waiting for the records to age out.

• A peer that joins DMXRouter inbound while the local store is still empty is remembered, so when the operator finally loads an MVR the commit reaches that peer retroactively. This handles the very normal show-floor sequence "operator opens the dialog and activates the service → designer's laptop sees DMXRouter and connects → operator imports an MVR from a USB stick" — without the queue, the designer's app would have been stuck showing DMXRouter with no shared file and would have needed a manual refresh to notice the new commit. The same queue handles the reverse race where DMXRouter has an MVR loaded but the peer connected inbound before mDNS discovery resolved their listen address (common when the peer had a cached entry from a previous session and reconnected the instant our TCP listener came up); as soon as discovery surfaces the peer's SRV record, the queued cold push fires.

• Service identity persists across DMXRouter restarts (Station name, Group, Station UUID — stored alongside the chosen Interface in QSettings), but the enabled state does not — the operator opts in explicitly each session. A station that was visible to a peer yesterday will be the same station UUID-wise today, so the peer's commit dedup logic recognises us; but the service does not start automatically at launch — the operator has to open the dialog and click Activate. This matches the pattern grandMA3 and Vectorworks use (an explicit toggle, off by default) and avoids surprising operators with an open mDNS responder and TCP listener on a network they may not be ready to publish to.

Universe Monitor

• Each cell of the grid now carries a small label band above the value reading, showing an abbreviated form of the GDTF or MA2 channel name — Pan, Tilt, Dim, R, G, B, W, Zoom, Iris, Strobe, Focus, Gobo, Color, CTC, etc. — so the operator can identify what each channel does without leaving the monitor for the Fixture Check panel. Single-cell fixtures show the channel name as it appears in the GDTF or MA2 personality (compact form: "Pan", "Dim", "R/G/B/W", "Zoom", "Iris", "Strobe", "Focus", …); 16-bit and 24-bit fine channels are suffixed ".f" / ".u" so the operator can tell "Pan" (coarse 8-bit) from "Pan.f" (fine) at a glance. Channels for which the patch doesn't provide semantic information (e.g. raw DMX with no fixture mapping, an unrecognised attribute) fall back to best-effort truncation of the original name preserving casing. The band height is fixed so cell value digits remain centred and equally tall regardless of whether the label is present. Priority view, which paints the per-source priority byte instead of the merged value, suppresses the label band (the bytes shown there are priority values, not fixture data — labelling them with attribute names would be misleading). The full GDTF / MA2 attribute lexicon — ~220 entries covering both standards' common naming variants — is normalised before display so technical names from MA2 ("PAN", "GOBO1POS") and friendly names from GDTF ("Pan", "Gobo1 Pos") render with the same abbreviation regardless of source.

• **The column / row lab...

DMXRouter 1.11.0

This release adds bidirectional OSC and MIDI bridging between DMX and the outside world — any process engine input can now receive OSC or MIDI from an external source and feed it into the merge as if it were a DMX source, and any output can emit OSC or MIDI alongside or instead of Art-Net / sACN. Both directions are first-class peers of DMX: every merge mode, every failsafe path, every test pattern, every fixture override layer applies to OSC and MIDI sources and destinations identically to network DMX. That symmetry — DMXRouter as a peer to dedicated DMX↔OSC and DMX↔MIDI converter boxes in either direction, configured per-engine rather than per-box, with the same engine-level reliability features the DMX side already had — is what motivates the version bump to v1.11. The remaining sections (PSN, VLAN, About / Licenses) cover changes that accumulated alongside.

OSC / MIDI ↔ DMX Bridge

• A process engine output can now be configured to emit OSC or MIDI instead of DMX, routing the merged channel data to any compatible receiver — TouchOSC, Reaper, QLab, Ableton Live, Resolume, samplers, video loopers, a DAW with a virtual MIDI port, or any custom integration — alongside or instead of Art-Net / sACN. Each output in the engine editor has a new "OSC/MIDI…" button in the rightmost Bridge column: clicking it opens a per-output configuration dialog with two protocol radios (OSC, MIDI) at the top and the corresponding form below. DMX is the absence of a bridge rather than a peer of the radios — to switch a non-DMX output back to DMX the dialog exposes a "Revert to DMX" action button next to OK / Cancel that's visible only when the current state is already non-DMX. OSC reveals destination host, UDP port (default 9000), an address-scheme template with {u} and {c} placeholders for universe and channel (default /dmx/u{u}/c{c} produces /dmx/u1/c47 for universe 1 channel 47), and a value-format selector (32-bit big-endian integer 0–255 for receivers that want raw DMX, or 32-bit big-endian float 0.0–1.0 for audio-domain receivers that expect normalised values); MIDI reveals a port selector populated with the system's MIDI output ports (including any virtual port via loopMIDI on Windows, the IAC bus on macOS or snd-virmidi on Linux), a MIDI channel 1–16, and a message-type chooser between Control Change and Note On/Off. Control Change is the continuous mode: every DMX value change emits a CC message on the mapped CC number with the value right-shifted to 7-bit — DMX channel 1 maps to the configured first CC, channel 2 to the next CC up, and so on through CC 127, with channels beyond CC 127 silently dropped. Use it for MIDI mixers, DAW plugin automation, and any receiver expecting smooth value streams. Note On/Off is the trigger mode: each DMX channel maps to a MIDI note number starting from a configured first note (default 60 = middle C), and the sender watches for the DMX value crossing a configurable trigger threshold (default 1, meaning any non-zero value fires). When the channel rises through the threshold from below, a Note On is emitted with a velocity captured at the moment of the crossing — either proportional to the DMX value at that instant, or a configurable fixed velocity (default 100) for cue-trigger use cases that want every fire at the same strength; when the value falls back below the threshold, a Note Off is emitted. There is no retrigger while a note is held — a sustained-above-threshold channel produces a single Note On and a single Note Off when it eventually drops, which matches how samplers, video loopers, and lighting consoles that take MIDI Note as cue triggers expect to behave. Cleanup is explicit: when an output that's emitting Note Ons is removed, reconfigured to a different message type or channel, has its port changed, or is flipped to a different bridge protocol (Note → CC, Note → OSC) or back to DMX, the sender sends "All Sound Off" on the affected channel before reconfiguring so samplers don't get stranded with held notes — shutdown does the same flush. Once an output is flipped to OSC or MIDI, the DMX-specific columns of its row (Net/Subnet/Universe address, Interface, Tx Mode, Priority, Delay, Dest IP) become read-only and the Bridge button label changes to show the destination at a glance ("OSC: 192.168.1.50:9000" with a blue tint, or "MIDI CC: loopMIDI Port" / "MIDI Note: loopMIDI Port" with a purple tint); the button text reads "OSC/MIDI…" in plain styling while the output is still DMX. The routing table in the main window mirrors the same distinction — non-DMX outputs render as their destination plus a "[OSC]", "[MIDI CC]" or "[MIDI Note]" tag rather than the DMX-universe-and-interface format. When the engine stops emitting (disabled, removed, or Hold failsafe) the OSC/MIDI receiver retains the last value it got; neither protocol has a "stream presence" concept like sACN, so the operator's intent is to keep the receiver state where the engine left it. Failsafe modes that substitute frame content (Output Zeros, Output Full, Output Scene) flow through normally — Output Zeros transitions every previously-non-zero channel to zero exactly once on OSC and CC outputs, and releases every held Note On with a Note Off on Note outputs.

• A process engine input can now be configured to receive OSC or MIDI from an external source and feed it into the merge engine as if it were a DMX source on the row's universe — the symmetric counterpart of the output-side bridge. Each input row has a new Bridge button in the rightmost Bridge column ("OSC/MIDI…" when the input is still DMX, "OSC :9000" or "MIDI " once configured): clicking it opens a per-input configuration dialog with two protocol radios (OSC, MIDI) at the top and the corresponding form below. As on the output side, DMX is the absence of a bridge rather than a peer of the radios — a "Revert to DMX" action button next to OK / Cancel is visible only when the current state is already non-DMX. OSC mode opens a UDP listener bound to a configurable port (default 9000) and interface (default all NICs, with "Localhost only" as a convenience option and named NICs for multi-network rigs) and parses every incoming address against a path-scheme template — {c} extracts the DMX channel number from the address, and an optional {u} filters by the row's universe so multiple OSC sources can share the same listener safely. A value-decoding selector picks how the OSC payload is interpreted: Auto reads the typetag (,i as 0..255 int, ,f as 0..1 float scaled ×255 — accepts whichever the sender produces, ideal when you don't control the sender's format), Int forces every message to be read as a 32-bit int clamped to 0..255, and Float forces every message to be read as a 32-bit float in 0..1 range and scaled to 0..255. MIDI mode opens an input port (listed alongside the same hardware and virtual port set the output side offers) and converts Note On/Off or Control Change messages into DMX channel values, scaled 0..127 ×2 → 0..254, with a channel filter (1..16, or "Any" for any channel) and configurable first-CC / first-Note offsets that decide which DMX channel CC 0 or Note 0 maps to — set first-CC to 16 to keep DMX channels 1..16 free for other inputs to merge with the MIDI feed. In Note mode, Note On with velocity > 0 writes velocity × 2, Note Off (or Note On with velocity 0) writes 0. The decoded values feed the merge engine on the input's configured universe like any other DMX source — every merge mode (LTP, HTP, Priority, Backup, XFade, Switch, Custom), every failsafe path, every test-pattern substitution and every fixture override layer works against OSC and MIDI inputs identically to network DMX. Once an input is flipped to OSC or MIDI, the DMX-routing cells of its row (Net/Subnet/Absolute, Interface, Source IP) become read-only and the Bridge button label changes to show the protocol and primary destination at a glance ("OSC :9000" with a blue tint, "MIDI loopMIDI Port" with a purple tint); the universe spin stays editable because that's where the OSC/MIDI data lands in the engine. Clicking OK on the bridge dialog applies the changes to the running engine immediately — the receiver binds its socket or opens its MIDI port the moment the dialog closes, so the operator can tweak the path scheme or first-CC offset and hear the receiver respond without closing the parent Edit Engine dialog. Disabling the engine releases the OSC / MIDI listener immediately — the bound UDP port and the open MIDI handle are freed at the OS level so a second engine can pick up the same port without restart — and re-enabling the engine re-opens them transparently from the same configuration.

• For OSC outputs that need different addresses per channel — Resolume's /composition/layers/1/opacity continuous fade alongside /composition/columns/3/connect one-shot trigger, QLab cues at distinct paths, custom integrations where each receiver registers a unique address — the path-scheme template can be replaced with an explicit per-channel mapping table. A "Use custom per-channel mapping" checkbox at the bottom of the OSC configuration dialog reveals a five-column table — Channel, Path, Mode, Value, Threshold — where each row defines one DMX-channel-to-OSC-address binding independently of the others. Six modes are available per row: Pass int and Pass float forward the live DMX value to the configured path as a 32-bit int 0–255 or normalised float 0.0–1.0 on every change, the same payload shapes the template-mode value format produces but with per-row routing; Fixed int and Fixed float send a configured constant value to the path whenever the source DMX channel changes value, useful for sending a known "switch on" payload that doesn't depend on the fader's current position; Trigger int and Trigger float send the configured constant value only when the source channel rises through a configurable threshold (1 = ...

DMXRouter 1.10.1

Universe Monitor

• The sACN range cap is now a multi-range filter and a new Art-Net range filter has been added, both reached from a new "Universe ranges" button in the Monitor toolbar that opens a dialog with two scrollable text areas (one per protocol) — the old single-spinbox "join universes 1 through N" cap was the only way to scope the Universe Monitor and at large counts it was sending the local IGMP querier into a wall: on tight networks a tour with acts at universes 1-10, 532-540, and 1044-1060 had to either join everything from 1 up to 1060 just to see the highest range or lose the highest range entirely. The sACN field is now a free-form text input that accepts any combination of single universes and ranges separated by commas (or newlines, one per line), e.g. 1-10, 532-540, 1044-1060, so the IGMP query table only carries the universes the operator actually wants — discontiguous high-numbered ranges are reachable without joining anything below them. The same field shape is now also available for Art-Net as a pure display filter (Art-Net DMX is unicast so there are no joins to manage, but operators monitoring large multi-net rigs benefit from the same scoping for readability). Empty input means "no contiguous filter" — for sACN that disables the field's contribution to multicast joins entirely (engine inputs still join their own universes, and only those will be visible in the list), and for Art-Net it means "show every entry received". Engine inputs and outputs are guaranteed visible in the monitor regardless of how tight the user pulls the filter, so a routing engine the operator has actively configured can never quietly disappear from the list. The dialog validates each field as the operator types and disables OK until both parse cleanly, with a per-field count shown underneath ("1024 universes selected", "No filter — show all received Art-Net", and so on); the toolbar button gains a trailing dot when either filter is active and its tooltip lists the current ranges so the operator can tell at a glance whether the monitor is showing a subset. The previous numeric cap saved as sACN/monitorRange migrates automatically on first launch to the new multi-range form (1-N, identical scope) so existing setups carry over without any operator action. Reported by SirDur (GitHub #34)

• Hovering or clicking a slot in the channel grid now also surfaces the patched fixture and channel name, so the operator can read off "Ch 47: 192 (75%) — 57 MAC Aura / Dimmer" instead of having to memorise which fixture sits at which absolute address while looking at raw DMX — the monitor pulls labels straight from the loaded MVR (or restored project patch), so every patched fixture in the show contributes to the readout, not just specific products: a moving head shows up as "Pan", "Tilt", "Dimmer", "Shutter"; a colour scroller shows up as "Color1"; a 16-bit Pan splits across two adjacent slots as "Pan" and "Pan (fine)", and the rare 24-bit / 32-bit channels extend the same pattern with "(ultra)" and "(uber)". Multi-cell containers (LED bars, pixel matrices) prefix the cell name with the parent so a click on a per-pixel Dimmer reads "57 LedBar / Cell 12 / Dimmer" rather than just "Dimmer", which is what the operator wanted to know — which pixel — when they clicked. The fixture's MVR ID is included in front of the name when one is present so labels match the operator's existing fixture sheet at a glance ("57 MAC Aura"), and the same label is forwarded into the oscilloscope's header underneath so the time-domain trace also identifies its source. Slots not covered by the patch (un-addressed gaps, fixtures imported from a Capture placeholder that hasn't been resolved yet) keep the legacy "Ch N only" form silently — there's no error overlay, just no extra subtitle. Editing the patch live updates the labels everywhere the operator can see them without a reselect. Suppressed in the Priority data view because per-channel sACN priority is set by the source, not the fixture, and grafting a fixture name onto a priority readout would be misleading

Fixture Patch

• Importing an MVR while a patch is already loaded now opens a small dialog asking whether to Replace the existing rig with the new MVR (the historical behaviour) or Merge the new MVR's fixtures into the existing patch alongside what's already there — until now, every Import MVR gesture was a destructive replace: bringing a second .mvr in dropped the first one entirely, which is right for the common case of starting fresh on a new show but wrong for the equally common case of building a combined rig from a console export plus a separate visualizer export, or stitching together an MA3 fixture sheet with a Vectorworks plot of a different department's gear, or adding a touring scenic-LED package on top of a venue's house-rig MVR for one show without losing either side. With Merge the operator picks a second .mvr and its fixtures, layer names, and addresses are appended to the current patch — fixture types shared between the two MVRs (the same Robe MAC Aura model patched in both) are deduplicated to one shared FixtureType so the rig doesn't carry two parallel copies of the same GDTF, and any manual GDTF assignments the operator had previously resolved on the first import continue to apply to incoming placeholder fixtures of the same model so they auto-resolve on the way in. Layer grouping is preserved per-source — fixtures from MVR A keep their original layer names and fixtures from MVR B keep theirs, so the patch tree visibly shows the two sides as distinct branches even after the merge. Merge can be invoked repeatedly: importing a third MVR while two are already merged stacks onto the combined patch the same way. Replace stays the default action of the dialog (so a muscle-memory Enter on Import MVR keeps the previous gesture) and Cancel aborts after the file picker without touching anything. With no patch loaded the dialog doesn't appear at all — the import goes straight through as before. Show metadata (project name, source MVR filename) belongs to the original import and isn't overwritten on subsequent merges, so the project file remains identifiable as "the original show, with these additions" rather than the most-recent fragment

• A new "Add MA2 Fixture…" entry in the patch toolbar's Add menu lets the operator manually patch fixtures from a grandMA2 .xml fixture library, using the same cascading manufacturer → model → mode picker as "Add Fixture Manually…" but reading definitions out of <Documents>/DMXRouter/MA2/ instead of the GDTF library — opens a path for fixtures that have no GDTF available, the canonical case being Robert Juliat's SpotMe trackers, which ship today only as MA2 .xml libraries pending the GDTF working group's standardisation of tracking devices, but the entry is generic and works with any MA2 fixture .xml dropped into the folder, from a moving head to a colour scroller. The dialog cascades manufacturer → model → mode just like the GDTF version, with quantity / FID start / universe / address / spill-to-next-universe controls and the same address-range preview before the operator commits, and a name template that gets a "#1, #2, …" suffix when quantity > 1. The dialog also has an "Add .xml to library…" button at the top that opens a file picker, copies the chosen .xml file(s) directly into the local MA2 library folder, and auto-selects the just-imported entry in the cascading combos as soon as the library finishes re-indexing — operators who get an .xml file from a manufacturer or extracted from a console backup can patch from it in one continuous flow without leaving DMXRouter to drag files around. Patched fixtures land in the "Manual" layer of the tree alongside any GDTF fixtures added the same way, with full channel labelling in the Universe Monitor (Pan, Tilt, Dimmer, Shutter, Pan (fine), and so on) and home/highlight values picked up from the MA2 file when present — for moving heads with a highlight_value declared (typically 100% on Dimmer, 0% on Shutter and Gobo to mean "open / no gobo"), the Highlight button drives the fixture as expected. MA2 fixtures with attribute codes that don't map cleanly to the GDTF taxonomy (mostly tracking-specific names like X Origin, Tracking Speed, A to B Distance) still appear in Fixture Check with their MA-defined names rather than as anonymous "Ch 1, Ch 2…" sliders, so the operator can identify what they're driving. Drop a fresh .xml into the folder while the dialog is open and the combos refresh automatically without having to dismiss and reopen. The folder is auto-created on first launch; if it's empty when the dialog opens, the warning text shows the exact path the operator needs to drop files into

• Auto-Next now starts a walk even when nothing — or only one fixture — is selected — pressing the Auto button used to silently snap back off unless the operator had pre-selected two or more fixtures in the patch tree, which forced a Select-All (or a multi-pick) before the auto-tour of the rig could begin, even though the manual Next/Previous buttons have always worked without a selection by stepping through the whole patch in tree order. From this version on, Auto behaves the same way: with no selection it tours the entire patch starting from the first fixture in tree order; with a single fixture selected it tours the patch starting from that fixture (the operator can scrub the walk position by clicking another fixture in the tree mid-walk and Auto continues from there); and with a multi-selection it walks just the selected group as before. The first fixture lights up immediately when Auto is pressed so the operator sees a head come up during the first interval rather than waiting a beat for the timer to fire, and Highlight propagation and Home-on-walk-away behave identically to the multi-selection path so moving heads stay parked between steps instead of racing back to th...

DMXRouter 1.10.0

Application

• DMXRouter can now be set to start automatically when the operating system starts — the typical kiosk / installation rig has DMXRouter running unattended on a dedicated machine, and the operator was previously responsible for either manually launching it after every boot or dropping a shortcut into the OS's startup folder by hand (which on Windows is hidden, on Linux requires writing an XDG .desktop file, and on macOS requires editing a launchd plist — three different procedures none of which DMXRouter helped with). A new "Start DMXRouter automatically with the operating system" toggle in the File menu, right next to "Auto-restore last config on startup", handles all three platforms transparently. On Windows it writes a per-user entry under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run; on Linux it drops a compliant XDG .desktop file into ~/.config/autostart/ (recognised by GNOME, KDE Plasma, XFCE, MATE, Cinnamon, and LXQt without further configuration); on macOS it creates a LaunchAgent plist in ~/Library/LaunchAgents/ with RunAtLoad set so the app launches at user login. All three are per-user — no admin rights or sudo needed to toggle, no installer rerun, and turning it off cleanly removes the entry. Pairs naturally with "Auto-restore last config on startup": both ticked equals an unattended boot of an installation rig straight to the running profile, which is exactly what most architectural / theme-park / venue installs actually want. The toggle's tooltip shows the exact path of the entry it created so an operator who wants to verify or remove it by hand can find it without reading the docs. The autostart entry also self-heals on launch: if the registered path no longer points at an existing file (the typical sequence is a reinstall into a different folder, an AppImage that's been moved on Linux, or a renamed binary), DMXRouter silently rewrites the entry to the current location of the running executable, so the operator's stated intent — "I want this app to start with the OS" — keeps working without needing to re-toggle the checkbox by hand

• Save now writes to the current configuration file instead of always prompting for a filename — when a profile or a JSON config was loaded, clicking Save (toolbar, File → Save Config, Ctrl+S, or the close-time "Unsaved changes" Save button) used to behave as if it were the first save: a file dialog would appear asking where to save, even though the user had loaded a named file moments earlier and just wanted to update it in place. From this version on, Save writes back to whichever file is open — a profile recalled from Profile Manager, a JSON loaded via File → Load Config, or the destination the user picked in a previous Save As. The window title shows the current file's name (the profile name for profiles, the file's own name for arbitrary JSONs) so it's always visible at a glance which file the next Save would target. A new "Save Config As..." entry has been added to the File menu (Ctrl+Shift+S) for the cases where the operator does want to redirect the save to a different location — the standard text-editor convention. The current-file association also survives a restart of DMXRouter, so closing the app while editing myshow.json and reopening it later keeps Save pointed at myshow.json rather than reverting to the file dialog. If the on-disk file has been moved or deleted between sessions DMXRouter falls back to a clean untitled state rather than silently writing somewhere unexpected

• The window title now shows a * when there are unsaved changes — same convention as most text editors and IDEs, so the operator knows at a glance whether the in-memory configuration matches what's on disk. A clean profile shows DMX Router — MyShow; the moment any change is made — adding a process engine, toggling an interface, editing a routing entry, importing an MVR, or editing a fixture's address or mode — the title becomes DMX Router — MyShow *. Saving (or loading a fresh config) clears the asterisk. Brand-new untitled sessions follow the same rule: DMX Router clean, DMX Router * modified. Particularly useful in installation rigs where the operator may want to verify that an unattended config matches the one saved on disk before walking away from the machine. The dirty-tracking now also covers fixture-patch edits — previously, importing an MVR or changing a fixture address could close the application without the unsaved-changes prompt firing, since only routing-table changes flagged the session as dirty; with this version every patch mutation counts as unsaved work and the close-time prompt behaves consistently across the whole UI

• PosiStageNet (PSN) viewer added — DMXRouter can now receive and display PSN multicast traffic from tracking systems (Robert Juliat Spotme, BlackTrax, Zactrack, MA Lighting's own Stage Marker streams, and any other server speaking the PSN v2.x protocol). A new "PSN Viewer" dock shows every active server on the network alongside its trackers in two views side-by-side: a flat table with one row per (server, tracker) pair listing position, velocity, orientation, validity and "last seen" age; and a 2D top-down map of the XZ plane with auto-fit bounds, a metre grid, a stage-origin crosshair, a scale legend, per-server colour coding, coordinate ruler labels at every gridline (X coordinates along the bottom, Z along the left edge — so the operator can read absolute positions directly off the map without mentally counting gridlines), and a small compass widget in the bottom-right corner with red +X and blue +Z arrows that stay fixed regardless of pan or zoom. Each tracker renders as a coloured dot with its ID and name, plus a short arrow showing the direction it'll be moving in over the next half-second when speed is non-zero. Validity dims the dot proportionally so the operator can spot uncertain trackers without scanning the table. The map is interactive: scroll the mouse wheel anywhere on it to zoom in or out (anchored on the cursor position, so the world point under the mouse stays put), drag with the left mouse button to pan, and click the "Fit View" toolbar button to snap back to the auto-fit framing of all current trackers — manual mode is preserved across snapshot updates so the view doesn't yank itself away from a region the operator has just zoomed into. The table has sortable Server / ID / Name columns (click a header to reorder, click again to flip direction; the numeric position / speed / orientation columns are intentionally NOT sortable since they change every frame and would make rows shuffle constantly), and each row shows a coloured swatch in the Server cell that matches the dot colour on the map — so the operator can visually link a row to its dot at a glance. Clicking any row paints a bright two-ring "reticule" halo on the corresponding dot in the map, kept in sync as long as the tracker stays alive (selection follows the tracker by identity, not by row index, so it survives sort changes and snapshot reshuffles). PSN reception is OFF by default — toggle it on from the dock's toolbar and the receiver joins the multicast group on every interface DMXRouter is currently using for Art-Net / sACN. Multicast address and port are editable in the toolbar for installations that have reconfigured their tracking server off the spec defaults; non-multicast addresses are rejected with an inline status message rather than silently failing. Multi-server is supported natively (Spotme's main + backup, MA's parallel sources, etc.) — every server gets its own colour and shows up on its own rows. Receive-only: DMXRouter does not emit PSN, so plugging it into an existing tracking network is a passive observation that can't disturb the live data path

• Test patterns can now be sent on demand from any process engine — the Routing Table toolbar gains a "Test…" button (also a "Test Output…" entry on the right-click menu) that opens a small non-modal dialog driving a manual test injector against every output of the selected engine(s). Seven patterns are available: Full (all 512 channels at 255 — the equivalent of the existing Full failsafe but on operator command rather than data loss), Blackout (all channels at 0), Ramp (every channel in lockstep fading 0 → 255 → 0 cyclically), Chase (a configurable group of consecutive channels at full stepping through the universe so the operator can identify which fixture lives at which address by counting steps until a fixture lights — set group size 3 for an RGB pixel strip, 4 for RGBW, etc.; group size 1 keeps the historical single-channel chase), Sinewave (synchronous — every channel oscillating in phase, smoother on the eye than Ramp for longer-duration verification), Sinewave (rolling — a continuous sine wave that crawls through the universe with every channel always showing a value, so you see multiple peaks at once and motion direction / speed are obvious at a glance; useful for verifying pixel-strip wiring direction and spotting dropped channels mid-strip that the synchronous Sinewave would mask), and Single Channel (one specific 1–512 channel held at a chosen 0–255 level with everything else at zero — the fixture-confidence test). For animated patterns (Ramp, Chase, both Sinewaves) the dialog has a Slow / Medium / Fast speed preset; Chase additionally has a Group Size spinner (1–16); Sinewave (rolling) has a Wavelength spinner (3–512 channels — controls how many peaks are visible at once); Single Channel has channel and value spinners. Duration is selectable from 10 s, 30 s, 1 min, or 5 min — the longest is a hard ceiling so a forgotten dialog cannot leave a venue at full overnight. Whichever pattern is chosen, the bytes that hit the wire are the pattern verbatim — channel patches and active fixture overrides are bypassed for the duration of the test, so the operator sees exactly what they asked for and not "what the engine...

DMXRouter 1.9.8

Fixture Patch

• Change Mode — switch the DMX mode of one or more fixtures without unassigning the GDTF first — until now, the only way to put a fixture on a different mode of its already-assigned GDTF was to clear the manual assignment, re-pick the same GDTF, and choose the new mode at the assignment dialog. That wiped the patch state for every fixture sharing the placeholder lineage and re-ran the resolver, which is overkill for the common case of "I want this group of Robe iFortes on 16-channel mode instead of 8-channel". The Patch tree's right-click menu now has a Change Mode… entry that operates per-instance: pick one or more fixtures of the same type, choose any of the modes the GDTF declares, and the selected fixtures (and only those) flip to the new mode. The dialog shows the type name, how many fixtures will be affected, the current mode, and a list of every available mode with its channel count next to the name. Start addresses are preserved across the switch — if the new mode's footprint is wider and now overlaps a neighbour, or extends past channel 512, the affected rows light up red in the patch tree (see below) so the operator can spot the collision and clean it up with Change Address. Active overrides on the affected fixtures are released automatically as part of the change, because a Pan override stamped at the old mode's channel layout would point at a different attribute (or none) under the new mode and silently drive the wrong slot. Multi-cell containers are excluded for now — re-moding a wall LED would have to rebuild the cell layout from the new GeometryReferences and isn't covered by this dialog yet; use Assign GDTF manually if you need to repatch a container

• DMX address overlap is now flagged in red on the patch tree, the same way the RDM device tree has always shown it — the Address column previously gave no indication that two fixtures had been patched onto channels that overlap each other. The operator could see the conflict only by mentally adding each fixture's footprint to its start channel and checking whether the resulting range intersected any neighbour, which is fine for a 12-fixture rig and impractical for anything bigger. The patch tree now sweeps each universe's occupants on every refresh, finds overlapping ranges, and tints the Address column of every row involved in a collision in the same red used by the RDM device tree's overlap painter. The tooltip on the tinted cell lists the offending neighbours with their ranges (e.g. "⚠ Overlaps with: Robe iForte 12 (U1/105–116)"), so the cause is visible without having to open another panel. Detection runs on every patch change — MVR import, manual add, Change Address, the new Change Mode, Resolve — so newly-introduced collisions surface immediately. Multi-cell containers participate as a single range covering the container's full footprint

• GDTF Share search now accepts multiple words in any order, instead of forcing the operator to type the whole manufacturer name before the fixture name — the search box previously matched the entire query as one string against each column. That worked for single words but broke as soon as the operator wanted to filter by both manufacturer and fixture together: typing "martin sceptron" matched nothing, because the Manufacturer column contains only "Martin" and the Fixture column contains only "Sceptron" — no individual column held the literal string "martin sceptron". The workaround was to drop the manufacturer entirely and search just "sceptron", which discovery-by-trial-and-error punished operators who didn't know the trick. The search now splits on whitespace and requires each word to appear in at least one column (Manufacturer, Fixture name, or UUID) — order doesn't matter and the words can land in different columns. "martin sceptron", "sceptron martin", "robe lighting iforte", and "iforte robe lighting" all return the expected fixtures. Single-word searches continue to behave exactly as before — typing "sceptron" alone still matches every Sceptron in the catalog regardless of manufacturer

Fixture Check

• Release All from the top toolbar (and from the web tablet view) now ends the walk properly, instead of leaving it ticking invisibly with no DMX going out — the panic-button Release All button at the top of the window did its primary job of clearing every override correctly, but it stopped there: the walk-the-rig state inside the Fixture Check tab kept running. The walk group highlight stayed painted in the Patch tree, the Auto-Next timer (if it was running) kept firing, and pressing the arrow keys to step Next or Previous still moved the active head around the group — except now no override frame was being stamped behind the move, so the rig stayed dark while the operator's selection cursor walked across fixtures that produced no light. The only Release All path that ended the walk cleanly was the dedicated FAB inside the Fixture Check tab itself; the global toolbar button and the web's release-all endpoint both left the walk in this half-alive state. All three surfaces now share the same teardown: Release All from anywhere stops Auto-Next if it was running, clears the walk group, removes the Patch tree group tint, and leaves the next arrow press to start a fresh walk from the current selection rather than continuing a ghost of the previous one

Networking

• Export the discovered RDM device list to CSV or to the clipboard for cross-checking between machines — operators running discovery from multiple DMXRouter machines on the same rig sometimes see different device counts, because RDM responses inside the protocol's 3-second window can collide and a busy fixture's reply lands at one machine but not the other. Until now there was no easy way to figure out which fixtures were missing on which machine — the operator had to read the tree on each screen and cross-reference manually, which doesn't scale past a handful of devices. The Discovery toolbar above the device tree now has an Export drop-down with two options: Save as CSV (UTF-8 with BOM, opens cleanly in Excel) and Copy to clipboard (TSV, paste straight into a spreadsheet). Both produce the same column set the tree shows on screen — Name, UID, DMX address, FID, Personality, Status, Last Seen, Manufacturer, Model, Software, Serial, Rental ID — so a diff between two machines' exports immediately surfaces fixtures that one saw and the other didn't. The output also walks every level of the tree (top-level entries plus any nested children), so multi-port layouts are exported in full instead of being collapsed.

• MA Lighting devices on the network now show up under the Discovery tab — operators running a mixed rig with grandMA2 or grandMA3 gear alongside DMXRouter previously had to keep a separate tool open (or read the IP off the console's display by hand) to know which MA stations were on the wire. A new "MA-Net Devices" section at the bottom of the Discovery panel — alongside the Art-Net / sACN node tree — lists every grandMA2 / grandMA3 console, processing unit, NPU, and node that's currently announcing itself, with the hostname the station broadcasts on MA-Net (e.g. "AA-Proart-L"), the name of the session it's currently joined to, the IP address, the protocol it's speaking (MA-Net2 or MA-Net3), and a "Last seen" relative timestamp that ticks forward so the operator can tell at a glance whether a device is still alive. The Session Name column drops to a dash when the station leaves its session, so an operator hitting End Session on a console will see the row update accordingly without having to refresh anything. Detection is purely passive — DMXRouter joins the multicast groups MA Lighting uses for session presence and listens on mDNS, but never emits a packet that could be mistaken for a real MA station joining a session. Devices stop showing 60 seconds after their last announcement, so unplugging a console clears the row on its own. Payload-level details — firmware versions, group names, VLAN consistency, full session topology — are intentionally out of scope for this view, since the MA-Net packet format itself isn't publicly documented

• VLANs can now be renamed after creation, and the friendly name appears next to every interface drop-down across the app — until now an operator who wanted to give a VLAN a meaningful label ("Lighting", "Backup Net", "Console World", etc.) had only one chance to set it: at the moment the VLAN was created. There was no way to change the name later, even though the table on the VLAN management tab clearly showed the field — typos, repurposed VLANs, and post-creation organisation all forced a destroy-and-recreate cycle just to update a label. A new "Rename" button now sits between Add and Remove on the VLAN tab, and double-clicking the Name cell of any row triggers the same rename dialog. The new name persists across the next save cycle and propagates immediately to every UI surface that displays interfaces — the Routing Table reroute combos (both the single-engine reroute and the multi-engine "Replace one interface with another across N engines" dialog, the latter of which had also been silently missing its VLAN colour coding for several versions and now has it back), the Process Engine editor's input/output/control-channel pickers, the Show Cue interface selector, the Add Process Engine dialog, and the Interface Selector cards on the Network panel — so an operator renaming "Backup Net" to "Cyc Wash" sees the change reflected everywhere on the next event-loop tick. The drop-downs render as "Cyc Wash · DMXRouter_VLAN300 — 10.0.3.5", with the friendly name first, the Luminex palette colour still applied to the row background, and the underlying adapter name and IP kept visible for troubleshooting. The OS adapter name itself (DMXRouter_VLAN) is unaffected — the rename is a label-only operation, so other tools or scripts that look up adapt...

DMXRouter 1.9.7

Fixture Patch

• Compact LED blinders and bare dimmer fixtures stop being mistaken for design-tool placeholders — GDTF detection used to flag any small fixture profile that had no Channel Set ranges and used only the Dimmer attribute as a placeholder, on the assumption that real manufacturer fixtures always declare ranges. That assumption broke down for legitimate compact fixtures: a 4-cell LED blinder with one Dimmer per cell, a generic 1-channel dimmer pack, anything in the 5–8 KB range with no fancy attributes — these were tagged as placeholders, which made the patch carry a "needs resolving" warning and made it impossible to clear that warning even after assigning a real GDTF library by hand: the assigned library was itself flagged the same way and the warning persisted with the fixture working but visually unresolved. Detection has been tightened to require the trait that actually identifies a placeholder export of this kind — a single DMX channel synthesised at offset 1 regardless of mode — so multi-channel fixtures (everything from 2-channel devices upward) are correctly recognised as real even when they're compact and Dimmer-only. Existing patches that previously had blinders or dimmer packs flagged as placeholders will load cleanly on the next start: the warning disappears, manual GDTF assignments complete without the residual flag, and the fixture's attributes show as fully resolved in Fixture Check

• The import warnings dialog now also surfaces GDTFs carrying the Capture Visualisation placeholder marker — until now, only WYSIWYG and Depence-style placeholder exports produced an explicit "Flagged as placeholder — consider replacing with a real manufacturer GDTF" entry in the import warnings list. Capture-marker placeholders were detected internally and treated correctly, but the user wasn't told why the fixture appeared as a generic Dimmer placeholder in the patch. The advisory entry is now consistent across all three placeholder fingerprints, so when an MVR is imported with a mix of placeholder origins it's clear which library to look for on gdtf-share.com

• GDTF Share browser now shows Created, Modified and Rating as sortable columns — when the catalog returns several revisions or uploads of the same fixture (a common situation for popular models that get re-uploaded as the manufacturer updates the GDTF), the browser previously surfaced only Manufacturer / Fixture / Revision / Uploader, leaving the operator to open the preview panel of every candidate to see which one was newest or had the highest rating. The three timestamps and the rating value have always been parsed from the gdtf-share.com API; they're now exposed as proper columns in the catalog table. Click the Modified header to sort by recency (most recent first or last); click Created to spot which entries are brand-new versus long-standing; click Rating to find the highest-scored variants. The columns sort numerically (epoch seconds for the dates, raw decimal for the rating) so missing values fall consistently to one end rather than shuffling around the alphabet. Note: the gdtf-share.com API currently returns 0 for the rating field on every entry — the rating shown on the website is computed by the website UI and not surfaced through the public API. The column shows an em-dash for those entries today and will populate automatically the day the API starts emitting real values

Fixture Check

• Manually-set slider values are now sticky across Highlight, Home, and walk-the-rig steps — moving heads have a recurring problem during commissioning: the operator selects a group, dials Pan and Tilt manually so all the heads point at a usable focus position they can actually see, and starts a walk to check each unit one by one. Until now, every walk step wiped that focus pose: Highlight on the new head reset everything to GDTF highlight values (Pan/Tilt typically centred, which on a moving head means aimed at the truss), Home on the head being walked away from did the same with the GDTF defaults, and the careful focus the operator had set at the start was destroyed by the second step of the walk. Any attribute the operator now writes via a slider (or the per-channel slider for placeholder fixtures) is marked as a manual override and preserved by every subsequent Highlight or Home call on that fixture. Highlight still applies its full-on-shutter-open intent to the rest of the attributes, Home still parks everything else at GDTF defaults — but Pan, Tilt, or any other slider the operator touched stays exactly where they left it. Walk a group of moving heads through Next / Previous / Auto and the entire group keeps the Pan/Tilt pose the operator set at the start; the walk now lights one head at a time without ever knocking the rig out of focus. The pin clears the moment the operator releases the fixture (or releases all) — Release is the explicit "hand control back to the show" gesture and intentionally wipes everything

• Change Address on a multi-selection of manual fixtures now renumbers consecutively, with optional spill to the next universe and configurable group order — until now, Change Address on a multi-selection always shifted every selected fixture by the same delta from the anchor, preserving the original spacing between them. That works perfectly for an MVR-imported rig where the spacing was deliberately set by the lighting designer, but it gets in the way of the typical workflow for hand-built patches: the operator added a batch of fixtures manually, the addresses ended up scattered across the universe as fixtures were inserted and removed during prep, and now they want to clean it up by renumbering everything contiguously starting from a chosen address. The Change Address dialog now offers two modes: the existing delta-shift (default when the selection contains MVR-imported fixtures) and a new "Renumber consecutively" mode (default when every selected fixture was added manually). In the new mode, fixtures are placed one after another starting at the address you set, each fixture's address chained to the previous one's footprint. A "Spill to next universe when full" checkbox (on by default) lets the chain continue at channel 1 of the next universe when the current one fills up, instead of failing with an overflow. When the selection contains more than one fixture type or mode (for example wash heads and spots, or two different modes of the same fixture), a reorderable group list appears in the dialog with Move Up / Move Down buttons so the operator can decide which type starts the chain — the live preview at the bottom of the dialog updates instantly and shows the first group, the total channels, and how many universes the chain will span. Single-select Change Address is unchanged

• Address column in the Fixture Patch tree (and the Fixture Check tablet view) now shows the on-wire range, not just the start channel — the Address column previously displayed only the start address (e.g. U3/40), forcing the operator to mentally add the footprint to figure out which channels each fixture actually occupied. The column now shows the full range (e.g. U3/40–58 for a 19-channel fixture), mirroring the convention used by the RDM device tree's DMX column. Single-channel fixtures (one DMX slot) still display as just U3/40 since the range would be redundant. The column auto-resizes to fit the wider text. Multi-cell containers continue to display the first-cell-to-last-cell range they always did, and unaddressed fixtures still show an em-dash. Identical change applied to the web Fixture Check view so tablet and desktop stay in sync

• Change Address on a multi-selection now respects click order, not tree order — when the operator ctrl-clicks several fixtures in the patch tree and opens Change Addresses, the chain order in the "Renumber consecutively" mode now follows the order in which the fixtures were clicked, not the order they happen to appear top-to-bottom in the tree. The first fixture clicked anchors the dialog (its current address pre-fills the start channel) and is also the first link of the chain; subsequent ctrl-clicks fall in behind in the order they were made. Right-clicking different rows to open the menu does not change the order — the right-click is just "open the menu" and the chain stays anchored on the first click. To override the order, use the group reorder list inside the dialog (which appears whenever the selection spans more than one fixture type or mode), or rebuild the selection with a different first click. Single-select Change Address and the delta-shift mode are unaffected (delta-shift doesn't care about order — every fixture moves by the same amount)

• Release All now sends an explicit blackout before closing the stream, so passive-engine setups go dark instead of holding the last override values — when the operator uses Fixture Check on a process engine that has no console feeding it (the typical "I just want to test outputs by overriding fixtures" workflow), Release All used to leave the rig lit on whatever the last override frame had stamped — Pan/Tilt at the focus position, Dimmer at whatever level, the lot. The stream-terminated packets that closed out the universe carried those last override values as their payload, sACN receivers correctly interpreted that as "source gone, hold last look" and held the override-stamped frame indefinitely. The output monitor showed the same thing: universe row turning grey but still displaying the override values, not zeros. Release All now dispatches one explicit zero-buffer frame as a normal packet first, so the receiver caches all-zeros as its last valid frame, and only then transmits the three stream-terminated packets that close the stream. The rig goes dark, the monitor shows zeros across the row before the universe drops to idle grey, and the panic-button intent of Release All is honoured. Engines that have a li...

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.

DMXRouter 1.9.5

Fixture Patch

• Auto-create Process Engines after MVR import (#31) — when you import an MVR file, DMXRouter now offers to create one Process Engine per referenced universe that doesn't already have one. A 20-universe rig that previously meant 20 minutes of manual PE setup is now a single dialog: choose protocol (sACN by default, matching MVR's universe convention), pick the output network interface, and decide whether to pre-configure a matching input source. Click Create. New PEs are grouped under "MVR Import" in the routing panel for easy management. If the chosen interface isn't enabled in the interface selector, it gets enabled automatically so packets actually flow. Skipped silently when every universe is already covered (re-importing the same MVR doesn't pester)

• Sliders show up correctly when adding more fixtures to an existing patch (#32) — when you already had fixtures patched (whether from MVR import, RDM discovery, or a prior manual addition) and you added more via Add Fixture Manually, the new fixtures opened in Fixture Check showing "Fixture not found" with no sliders, even though the patch tree showed them selected. Restarting DMXRouter "fixed" them, only for the next manually added fixture to hit the same problem. The cause was an internal lookup cache that was built once and never refreshed when fixtures were added or removed at runtime — the cache didn't know about the new entries, so it reported them as missing. The cache now refreshes on every patch mutation. Bonus: the same fix closes a latent crash risk in Remove Fixture, where the cache could end up pointing at moved positions in the fixture list after deletions

• Manually-added fixtures now actually output DMX — fixtures added through Add Fixture Manually appeared in the patch tree, opened in Fixture Check, sliders moved, the universe monitor showed activity, but no DMX bytes ever reached the wire. Root cause was an internal address-key mismatch with the GDTF spec default. The added fixture is now correctly addressable from the moment it lands in the patch — pull up the slider, the fixture moves

• RDM-discovered fixtures with a matching GDTF in your library output DMX correctly — same root cause as the manual fixtures bug above, but only triggered for RDM-discovered devices whose model matched a real GDTF in your library. RDM-only devices that fell back to generic synthesis (no GDTF match) happened to work by coincidence. If your rig had a mix and you were puzzled why some RDM heads responded to overrides while others didn't, this is why. All RDM-discovered fixtures, GDTF-matched or generic, now respond consistently

• Change Address works correctly on every fixture — Change Address (toolbar button and right-click menu, single-fixture and bulk multi-select) silently corrupted the address map for any fixture whose internal address sat under break key 1, including most MVR-imported fixtures and all manually-added fixtures from earlier patches. The dialog appeared to accept the new address, the patch tree updated to show it, but the fixture kept transmitting on the old channel. Now the address is updated under whichever break key the fixture actually uses — single-cell, multi-cell containers, their cells, and bulk moves all go through the same correct lookup. Fixtures that were "stuck" on a wrong address from a prior failed Change Address will move correctly the moment you set their address again

Process Engine

• Stop Output failsafe truly stops transmission now — when an engine entered Stop mode after losing its input, the engine itself stopped generating new packets, but the underlying rate limiter kept retransmitting the last value at the keep-alive cadence (every 850 ms). On sACN this could be partially masked by source priority on the receiver side; on Art-Net there's no stream-terminated semantic so the frozen last value just stayed on the wire indefinitely. The fix properly terminates every output stream the moment Stop kicks in — three stream-terminated packets where the protocol supports it (sACN per E1.31 §6.2.6), then full silence — so lower-priority sources on the same universe genuinely regain control as Stop was always meant to deliver. Resuming normal transmission when the input comes back works exactly as before

• Override-only universes go properly silent on release — when using a Process Engine in Forward mode whose input is invalid (a typical "I just want to check outputs by overriding fixtures" workflow), DMXRouter would keep transmitting the last override-stamped buffer at 44 Hz forever after the override was released — frozen DMX values, packet counter ticking up, monitor row showing as live, sACN receivers convinced the source was still healthy. Now releasing the last override on a universe sends three stream-terminated packets per E1.31 §6.2.6 and the universe goes quiet. Configs that genuinely have desk data flowing are left alone — they keep transmitting through their normal merge path. The Stop Output failsafe added in v1.9.4 is also honoured: if input is lost and the failsafe is set to Stop, an override release now restores the silence that Stop is meant to guarantee, instead of leaving the keep-alive cadence locked on the last override-stamped buffer

• Changing the failsafe mode while data loss is already active now takes effect immediately — if a Process Engine entered data loss with one failsafe (say, Hold) and you decided mid-emergency to switch it to Stop, the new mode used to wait for the next live → data loss cycle to engage. In practice that meant the universe kept transmitting the held value until the desk came back and dropped out again — which might never happen on a dark stage. Same problem in reverse: if Stop had silenced the universe and you switched to Hold or Zero hoping to restore something, the rate limiter stayed mute until live input returned. The failsafe change is now applied the moment you make it: switching to Stop sends the stream-terminated burst right away; switching from Stop to Hold reactivates transmission of the last known value; switching between Hold/Zero/Full/Scene swaps the output content immediately. The mode you pick is the mode you get, regardless of when you pick it

VLAN

• Hyper-V vSwitch traffic leak fixed in both directions — when a Hyper-V vSwitch was active for VLAN tagging, DMXRouter was silently using the vSwitch's hidden management adapter (the host's native/untagged VLAN port) as if it were another DMX interface. Two field-reported symptoms came from this: with everything unchecked the universe monitor still showed live levels, and with some VLANs enabled and others disabled, traffic from the disabled ones still surfaced when the underlying address ranges overlapped. But the leak went further than just the monitor — DMXRouter was also broadcasting Art-Net discovery and RDM packets out through the management adapter, so the operator's PC was announcing itself as a node and probing for fixtures on the native VLAN they hadn't selected. Discovered nodes from VLANs the operator hadn't enabled would appear in the Discovery panel, and RDM TOD requests went out to the wrong broadcast domains. The fix is a single change at the right level — DMXRouter no longer touches the management adapter at all. The vSwitch continues to route VLAN-tagged traffic correctly to per-VLAN adapters as before (that's the operating system's job, unaffected by this), but DMXRouter's input, output, and discovery now flow strictly through the VLANs the operator explicitly selected

RDM

• Thorough Discovery — new button next to Force Full Discovery in the RDM panel that runs three discovery passes back-to-back, accumulating any devices the gateway misses on a single sweep. The standard Force Full Discovery asks the Art-Net node to flush its TOD and rediscover the bus once; older nodes and lossy switches often return fewer fixtures than are actually patched because a single discovery pass can miss devices to RS-485 collisions or tight gateway timeouts. Thorough Discovery sends three flushes spaced apart — each pass picks up devices the previous one didn't see — without ever clearing the devices already known, so the rig count only grows. The button shows live progress ("Thorough … 2/3") during the run and a second click cancels mid-sweep. Useful when an old node or marginal switching reports something like 47 of 60 fixtures and you need the full count without rebooting hardware

• Configurable settling time between flush and TOD request — under View → Discovery settling time… you can now set how long the RDM panel waits between asking the gateway to flush its TOD and requesting the new device list, from 500 ms up to 5 seconds. Older Art-Net gateways need 1.5–3 seconds to complete their internal RDM bus sweep before they have a complete TOD to return; the previous fixed 500 ms was too tight for that hardware. The new default is 1500 ms and applies to both Force Full Discovery and the new Thorough Discovery. If your gateway is modern and you want quicker turnaround, lower the value; if you have an old node that still returns partial results, raise it

• More RDM tunables in the View menu — three new entries alongside the settling time: Thorough Discovery passes (1–10, default 3) lets you raise pass count without leaving the app for noisier setups; RDM transaction timeout (1–10 s, default 3 s) controls how long DMXRouter waits for any RDM response before retrying — useful for long RS-485 runs where responses occasionally arrive 4–5 s late; RDM transaction retries (0–10, default 2) is how many times to retry a failed transaction before giving up — raise it on noisy buses where one-off corruption causes SETs to fail silently. All four settings persist between sessions and apply on the next operati...

DMXRouter 1.9.4

Process Engine

• New failsafe mode: Stop Output — when every input to a Process Engine is lost, the engine can now cease transmitting packets entirely instead of holding, blacking out, or playing back a scene. This is the missing piece for touring setups where opening acts route their feeds through DMXRouter on a side VLAN and the main show should regain the rig the instant they disconnect: the engine goes silent on data loss, any other source on the same universe (typically the main show at a lower sACN priority) takes over automatically, and when the opening act's feed returns the engine picks back up without operator intervention. Selectable alongside Hold Last State / Blackout / Full On / Playback Scene in each Process Engine's failsafe configuration. The existing modes are unchanged

Fixture Check

• Walk-the-rig inside a multi-selection — select several fixtures and Next / Previous now step through them with wrap at the ends instead of escaping into the rest of the rig, matching how every lighting console handles a "selected group" walk. Only the active fixture gets the strong selection styling and has its channel sliders shown, so moving a slider during the walk only affects the one head you're looking at. The other group members stay visible in the Patch tree with a subtle tint so you can see the group membership at a glance. When Highlight is active on the selection, the first Next / Previous press anchors the walk at the primary (or last) fixture, releasing the others — so the first press doesn't visibly skip past your starting head. Subsequent presses then step normally through the group
• Auto-Next auto-walk — new ▶ toggle button next to Next in the Fixture Check toolbar, with a spinbox for the interval (0.1–30 seconds, remembered between sessions). Click the toggle and the walk runs automatically on the timer, cycling through the current selection with Highlight propagation like the manual walk. Ideal for hands-free focus checks and for verifying every head in a group without having to tap Next for each one. Stops automatically if you narrow the selection, hit Release All, or change the patch, so it can't keep stepping through a context that no longer exists
• Next / Previous follow the sort order of the Patch tree — when walking with no multi-selection, Next and Previous now step in the same order the fixtures appear in the Patch tree. Sort the tree by FID and the walk goes 1 → 2 → 3…; sort by Address and it goes U1/1 → U1/10 → U2/1…; switch back to MVR order and the walk follows that too. The walk always matches what you see on screen

Fixture Patch

• Sort the patch tree by column — click any column header (FID, Name, Type, Address, Mode) to sort within each layer group. Click the same column again for descending, and once more to return to the original MVR import order. Arrows ▲ / ▼ appear on the active column's header so the current sort is always visible. Sort applies within each layer group rather than across the whole tree, so groups stay organised by their MVR layer. Your preference is saved between sessions. Numeric columns (FID, Address) sort numerically so U2/1 comes before U10/1 as expected

GDTF Share

• Fixture preview panel in Browse GDTF Share — selecting any fixture in the browse dialog now shows an instant preview on the right-hand side: modes with their channel footprint, manufacturer, revision, GDTF version, file size, last-modified date, and the UUID (selectable for copying into a bug report or another tool). No need to download the file first to see whether it fits — if the mode you need is there with the expected channel count, you know before you commit. Fixtures you already have in your library are flagged with a green "In library" badge. The preview panel is collapsible if you prefer the old list-only view, and its width is remembered between sessions

RDM Transaction Log

• Separate PID number and PID name columns — the log now shows the hex PID (0xNNNN) in a dedicated column alongside the PID Name, matching the format used by the Slots and Status Messages tables elsewhere in the RDM panel. Easier to cross-reference with manufacturer documentation, easier to see at a glance what the transaction was. The search box now matches against the hex PID too, so typing "0x0060" or "SET_INFO" both find the same rows
• Export the transaction log — new Export button in the log toolbar with Save as CSV… and Copy to clipboard, mirrored as a right-click menu on the log table itself. Only visible rows are exported, so the active search and Failures-only filter control what ends up in the output — filter down to the problem fixture and export just its transactions for a bug report. The CSV is RFC 4180 with a UTF-8 BOM so Excel on Windows opens it correctly with non-ASCII device names intact; the clipboard copy is tab-separated for direct paste into Excel, Google Sheets, or a Slack code block

RDM Workflow

• Set address from patch — right-click any identified RDM device in the device tree and choose "Set Address From Patch…". A picker opens with every addressable fixture from the loaded MVR, grouped by layer, with the same FID / Name / Type / Address / Mode columns you already know from the Fixture Patch tree. The filter box is pre-filled with the RDM device's manufacturer and model so the likely candidates surface first; typing narrows the list live. Pick a fixture, hit Enter, and its DMX start address is pushed to the RDM device via SET_DMX_START_ADDRESS — no bouncing between the RDM panel and Fixture Check to look up the number. The typical workflow becomes: identify the head on the rig, right-click, pick its MVR entry, done
• Devices reconnect without re-fetching everything — when a device times out (cable pulled, switch reboot, gateway hiccup), DMXRouter now keeps the static info it already collected — manufacturer, model, personality list, slot map, boot software, language, presets, and so on. When the device reappears in a TOD, that info is restored instantly and only the DMX start address and active personality are re-queried (one PID, milliseconds), instead of running the full ~25-PID sweep again. On a rig of 20 heads coming back online after a brief disconnect that's the difference between a 30-second wait and an instant reconnection. The cache holds up to 2000 devices per session and is dropped on Force Discovery so a deliberate refresh is still genuinely fresh
• Quick-select mode — new "RDM quick-select (skip advanced info)" toggle in the View menu. When enabled, selecting an RDM device only fetches what you need to change channel and personality — basic info plus the personality list — instead of also pulling boot software, language, presets, curves, response time descriptions, and the rest. Cuts the wait between selecting a device and being able to act on it from a couple of seconds to nearly nothing. Advanced fields stay empty in the Info tab until you turn the toggle off and re-select, or use Fetch All to populate them. Default is off, so the existing behaviour (everything populated on selection) is unchanged unless you opt in

Mobile / Web

• Walk-the-rig from a tablet — the web Fixture Check tab now mirrors the desktop's walk-the-rig workflow. Tap any fixture to open its detail pane, then tap the new ▶ Walk button between Prev and Next: the rig starts cycling automatically from that fixture in the same order Prev / Next would step through, with Pause and End Walk available on the bar that appears at the top. For a curated subset rather than the whole rig, tap "Pick…" next to Walk — the list switches to checkbox mode, tap the fixtures you want included, hit Start Walk on the bar at the top. Both surfaces stay in sync: a Next from the tablet rotates the walk on the desktop, and vice-versa, so two operators can work the same rig together — one on the booth machine and one walking the truss — without stepping on each other
• Walk follows the desktop's sort — when the booth operator has the patch tree sorted by Address, FID, or Name, the walk on every connected tablet advances in that same order. The two surfaces stay coordinated regardless of what column the operator was sorting by, so the head lighting up next is always the one anyone would predict from looking at the desktop screen
• Sort the fixture list on the tablet — new "Sort: …" chip alongside the existing filters cycles through MVR / Address / FID / Name. Saved per browser so the tablet remembers your preferred view between sessions. Sort applies within each layer group, matching the desktop's sort behaviour
• Auto-Next from a tablet — the same ▶ toggle and interval input the desktop has appear in the walkbar when a walk is active. Tap the toggle and the walk runs on the timer; edit the interval and the change applies live (no stop-and-restart). State is shared, so pausing on the desktop pauses on every connected tablet too
• Set address from patch on a tablet — every RDM device row in the web RDM tab now has a "From Patch…" button next to the existing Set address button. Tap it to open the same fixture picker the desktop has, with the search pre-filled to the device's model so the right candidate surfaces first. Tap the fixture and the address is pushed. Same workflow as the desktop, available on whatever tablet the operator is carrying around the rig

Session Recovery

• Imported MVR survives a restart — closing DMXRouter with an MVR loaded but no Process Engine configured used to silently drop the patch on the next launch: every save path that touched disk (auto-save, the close-time session file, the close-time "save unsaved changes" prompt) had a guard that required at least one engine before writing anything, so MVR-only workflows (commissioning, addressing, fixture review) never persisted. Now the patch is preserved alongside engines, cues, and the rest of the session state ...