Skip to content
This repository was archived by the owner on Oct 16, 2026. It is now read-only.

DMXRouter 1.10.0

Choose a tag to compare

@fiverecords fiverecords released this 06 May 23:15
· 11 commits to main since this release
53d2695

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 would have output if it processed the pattern as live data". Tests work even on engines that are silent (no input ever received, or in data loss with the Stop failsafe selected) — DMXRouter feeds the test pattern at ~30 Hz on its own. The engine row in the Routing Table shows a red "TEST 23s" badge with a live countdown while a test is running on it, and the Universe Monitor shows the test pattern bytes (not whatever the merge would otherwise have computed) so the in-app monitor agrees with what's on the wire. Patterns can be changed live: switch from Full to Chase mid-test and the running test reconfigures on the spot without re-clicking Start. Multiple engines can be selected to run the same test across them simultaneously (useful for "send Full to FOH Wash + House Lights at the same time and see what doesn't come up"). Closing the dialog stops every test it has firing; the test also auto-stops on duration expiry, on the engine being edited / removed / disabled, and on profile load — there is no path that leaves a stale test running across configuration boundaries. Disabled engines are excluded automatically from the start; if the operator's selection contains some disabled engines they are listed in a one-shot information message before the dialog opens so it's clear what was skipped. Inspired by sACNView's Transmit Window and ChamSys MagicQ's per-universe Test button — operator workflows that DMXRouter now matches without needing a second app on the laptop

  • Startup buffer and failsafe scene can now be captured across many engines at once — a new "Snapshot…" button on the Routing Table toolbar (also a "Snapshot…" entry on the right-click menu) opens a multi-engine dialog that wraps the same Startup Buffer and Failsafe Scene operations the per-engine editor already had, but applied across every engine in the current selection in one pass. Setups with several engines used to mean opening the editor once per engine, scrolling to the Startup Buffer panel, clicking Capture Current, hitting OK, and repeating the process for the failsafe scene and again for the next engine — with a multi-universe rig that's a tedious sweep of dozens of editor sessions to capture a single show look. The bulk dialog replaces all of that with a single set of buttons: Capture Current Output → Startup Buffer (pulls each checked engine's live merged output and stores it as that engine's startup buffer, enabling the feature in the process), Record Current Output → Failsafe Scene (same idea for the failsafe), and an Import from File… variant of each that loads a single .dmx/.bin file and broadcasts it to every checked engine — handy when an installation rig should hold the same look on startup or fall back to the same emergency state across all of its universes. The same dialog also lets the operator pick the failsafe MODE for every checked engine in one step (Hold last values, Playback recorded scene, Stop transmission, All channels to zero, or All channels to full) and apply it via a single click — previously this required opening each engine's editor individually to flip a per-engine combobox, so an eight-engine rig meant eight round trips just to switch the whole rig from "Hold" to "Playback recorded scene"; now it's one selection and one Apply Mode button. The mode change takes effect immediately for engines that happen to be in data loss when the button is pressed (a Stop selection terminates their stream right away, a Playback Scene selection starts the recorded look on the wire), without disturbing engines that are receiving live input or running a manual test pattern at the same moment. The dialog opens with every engine the operator selected pre-checked and shows live annotations next to each row indicating what's already stored — "startup ✓" for engines with a captured startup buffer, "scene ✓" for engines with a recorded failsafe scene, and a compact "fs:stop" / "fs:zero" / "fs:full" / "fs:scene" tag whenever the engine's failsafe mode has been changed away from the Hold default — so the current state of the whole selection is visible before any change is made. Engines listed by their current name and primary output universe; the universe number honours the global Art-Net 0-based / 1-based display toggle, matching the rest of the routing table without surprising the operator with raw wire-level numbers. After each operation the annotations refresh in place, giving instant visual confirmation of which engines actually got data — an engine that hasn't produced output yet won't gain a "startup ✓" badge even if it was checked, and the status line spells out exactly how many succeeded versus how many were skipped silently, so the operator never has to dig through the editor to find out what didn't take. Each button click is its own undo-stack entry, so a four-engine bulk capture can be undone in one step rather than four. The dialog stays open between operations, so capturing startup buffer + recording failsafe + setting failsafe mode across the same selection is three clicks total, not three trips through the editor times N engines. Subject to the Show Mode "Destructive" gate like all other config-mutating operations — locked rigs cannot have their stored looks rewritten by accident

  • Right-click menus on the routing table have been reorganised — both the engine and group context menus had grown organically over the last several versions and the resulting order was a little chaotic (Rename buried between dialog-opening commands, Remove Group sitting in the second slot where an accidental click could happen). The engine menu is now grouped into five clean sections separated by visual dividers: identity edits at the top (Edit, Rename, Reroute), runtime control next (Switch Input where applicable, Test Output), then create / capture (Clone, Snapshot), then layout (Move Up, Move Down, Move to Group), with Remove sitting alone at the bottom. The group menu follows the same five-section logic — Rename Group at the top, runtime sweep ("Switch All Inputs") only when the group actually has Switch-mode engines in it, then Move Group Up / Down, then Group Color and Expand / Collapse, with Remove Group (keep engines) standalone at the bottom following the same destructive-action-last convention. Same actions, same handlers, same keyboard shortcuts — just laid out in an order an operator can scan and use without hunting


DMXRouter v1.10.0 — Built for the stage.