Pathway Connectivity
DMX-to-network gateways and entertainment switching under one configuration tool, strongest where protocol conversion and RDM carry the design.
What it is
Pathway Connectivity covers two related jobs: gateways and switching. Pathport gateways convert between DMX512 and the Ethernet protocols a show network carries, principally Art-Net and sACN, with per-port patching, merging and priority handling, and substantial RDM support back down the DMX line. The VIA series are managed Ethernet switches intended for entertainment networks, with multicast handling and lighting-oriented defaults rather than office defaults. Both are configured from Pathscape, one application that discovers devices on the network, holds their configuration, and can back it up and restore it. Gateway form factors include rack, wall-mount, portable and DIN-rail variants, so conversion capacity can sit where the DMX actually terminates instead of being concentrated in a single rack position.
How we work with it
We reach for Pathway when the hard part of a design is the edge rather than the core: many DMX termination points, mixed protocols, real merge and priority logic, and fixtures that should be addressable over RDM rather than by hand. Specification starts with a patch strategy, written down before any hardware is ordered, that says which source owns which universe and what happens when a source disappears. Merging gets used where it is genuinely the right answer and refused where it is papering over a control design problem. We commission with Pathscape holding the authoritative configuration, export and archive it so a dead gateway is a swap rather than a rebuild, and verify priority failover by killing sources rather than reading a datasheet. Firmware gets standardized across the fleet before anything ships.
Pathport gateways handle DMX, Art-Net and sACN conversion with per-port patching, merging and priority, plus RDM.
Switches and gateways share one configuration tool, so the core and the edge get documented together.
Rack, wall, portable and DIN form factors let conversion sit where the DMX cable actually ends.
Configurations can be exported and restored, which turns a failed gateway into a swap instead of a rebuild.
Right when
- The design is gateway-heavy: many DMX termination points, mixed protocols, and merging or priority logic that has to be right.
- RDM matters and you want addressing and fixture feedback over the same infrastructure rather than a parallel path.
- You want a single tool holding switch and gateway configuration for backup, restore and handover to the next crew.
Look elsewhere when
- The show is effectively all network and almost no DMX: sACN straight to fixtures, media servers and consoles, with a handful of nodes at most. Then you are buying an ecosystem for its switching alone, and that is the weaker half of the argument. Other vendors offer more switch per dollar, or better fleet monitoring, and the gateway strength you paid for never gets used.
- The console or fixture vendor's own nodes are already the standard on the rig, with spares, crew familiarity and a firmware track behind them. Introducing a second gateway platform adds another configuration store, another firmware matrix and another spares pool for no operational gain. Consistency across an unfamiliar crew is worth more than a marginally better gateway.
Is merging at the gateway a good idea?
Sometimes. Merging is correct when two sources are genuinely meant to share control of a universe, such as a house system and a visiting console, and the behavior on loss of either is defined. It is the wrong tool when it is being used to hide an unresolved question about who owns a fixture. If nobody can state the intended result when both sources are live, fix the control design first.
Do we still need managed switching if the gateways are doing the conversion?
Yes. Gateways decide what happens at the DMX boundary; they do not decide how multicast propagates across the network in between. Unmanaged switching with meaningful sACN universe counts floods traffic to every port, and the symptom shows up as unrelated devices misbehaving under load. The switching layer needs its own design regardless of how good the edge conversion is.