Once a node is adopted, a few settings decide how its endpoints are reached, how its ports are organized for routing, and how Buttons reacts to the sender and receiver state the node reports. Getting these right is what turns a working connection into one that behaves the way your facility actually needs.
Before you begin#
You need:
Review the node's endpoints#
Open the node in Connection → NMOS and select its Node tab.
- Api Version selects the IS-04 version Buttons uses when talking to this node: leave it at Auto unless the node needs a specific supported version. This is fixed to the discovered value for a peer-to-peer node under active discovery.
- Node endpoints lists the addresses Buttons tries to reach this node's API on, in order: the lowest-priority endpoint is tried first, and Buttons moves to the next one if it's unreachable. This mirrors how Registry endpoints work on a Registry connection.
- Polling controls how often Buttons independently checks the node's status, SDPs, and active flows, as a fallback for when mDNS isn't operating normally. It's off unless you turn it on and choose an interval from five seconds up to an hour.
- Address Substitution is for advanced cases only: when a node's own address isn't reachable as advertised, such as across network boundaries, this substitutes the addresses Buttons uses to reach it.
Ongoing changes on the node#
A node's senders and receivers aren't fixed at adoption time. If the node later adds or removes a sender/receiver, or a receiver's subscription changes from elsewhere, Buttons picks that up on its own (through the node's mDNS announcements for a peer-to-peer connection, or through the Registry's own update stream for a Registry-adopted one) without needing to re-adopt the node. Ports and Bundles and Active update to match once the change has been processed.
Choose how the node's ports become routing bundles#
Still on the Node tab, Group Mode decides how this node's Senders and Receivers are organized into the bundles you see under Ports and Bundles:
- All ports as one bundle for this node: every port on the node in a single bundle.
- All ports on one device as one bundle: one bundle per Device the node hosts.
- Use group hints as bundles: follow grouping hints the node itself provides.
- One to one: each port becomes its own bundle.
Warning
Changing Group Mode adds or removes bundles on this node and resets their tags and labels. Confirm any panels or Presets built from this node's current bundles before changing it.
Multi-channel audio senders and receivers#
An IS-04 audio sender that reports a source.channels list publishes one essence per channel (an 8-channel sender is 8 separate Audio essences), while an IS-04 receiver never reports a channel list, so Buttons treats it as a single flexible essence that can accept any number of channels. This asymmetry is expected and doesn't block routing: a route from a multi-channel sender straight to a receiver is a normal take, and a receiver routed into a fan-in/fan-out mux (an SDI input carrying embedded audio, for example) has its one essence matched against every channel on the other side rather than needing a one-to-one channel count.
NMOS Controller Behavior#
Four behaviors, available system-wide at Settings → NMOS and overridable per Registry connection or per node, shape how Buttons reacts to what a sender or receiver reports:
- Ignore Reported Active Sender: ignore the active sender IDs a destination port reports, useful when a device doesn't reliably update its own reported active sender after being routed elsewhere. Applies to destination ports only.
- Reconnect on SDP Change (Experimental): automatically re-route a destination when its connected sender's SDP changes, such as a resolution, framerate, or multicast address change. Applies to destination ports only.
- Activate Sender when SDP Present: automatically activate a sender once its SDP is successfully fetched, if it isn't already active. Applies to source ports only.
- Auto-Assign Multicast Address: automatically assign a sender a multicast address from a configured profile. Covered in full in Manage NMOS multicast addresses.
Behaviors cascade from system scope down through Registry and connection scope to individual ports. A Registry connection's or a node's own Behaviors tab has an Inherit behaviors switch: leave it on to follow the parent scope's configuration (shown with a badge such as From Registry), or turn it off to configure different behaviors at this specific level.
Verify a route#
The settings above become visible the moment you actually route through this node.
- Open Routing → Execute.
- Select the adopted node's connection as both Sources and Destinations, or the appropriate pair of connections if the sender and receiver belong to different nodes.
- Select the source and destination bundles.
- Select Take.
A successful request reports Routes executed successfully, and the destination's active-source display updates from the state the NMOS receiver reports. If Activate Sender when SDP Present is on, watch for the source activating on its own once its SDP becomes available, rather than needing an explicit action. If Reconnect on SDP Change is on and the sender's transport changes later, the destination should re-route to follow it without a new manual request.
If you get stuck#
What you see | What to try |
|---|
Bundles for a node look wrong, or tags and labels disappeared. | Check Group Mode: changing it resets bundles, tags, and labels for that node. |
A route succeeds, but the destination's active-source display doesn't match what you expect. | Check Ignore Reported Active Sender: with it off, a device that doesn't update its own reported sender can make Buttons show a stale result. |
A sender never becomes active on its own. | Confirm Activate Sender when SDP Present is enabled and that the sender's SDP is actually fetchable: see Diagnose NMOS problems. |
A node keeps losing track of live status. | Turn on Polling as a fallback, especially if mDNS isn't reliable on this network. |
Where to go next#
