The problem virtual routing solves#
A broadcast device is rarely one routeable signal. A camera, replay server, feed, or production area can include video, audio, data, intercom, and other paths. The router exposes those paths as ports, but operators normally think in devices and production tasks:
Camera 1Replay AFeed 3PCR 1
Building every control panel and routing Preset directly from physical ports ties the operator controls to the current hardware design. Replacing a router, moving a device, or changing from SDI to IP can then require the same physical changes to be reproduced across panels, Presets, and operating procedures.
Virtual routing adds a logical routing layer between the operator's intent and the physical system. Engineering maps a logical object such as Camera 1 to its physical signals. Operators route the logical object. Buttons resolves that intent into routes on real ports.
This separation has two benefits:
- Operators work with names and groupings that match production operations.
- Engineering can replace or rearrange physical equipment by updating the mapping behind a virtual object, without redesigning every panel or routing Preset that uses it.
Virtual routing does not replace physical routing. Every virtual route must still resolve to valid, controllable ports.
A common division of responsibility is for technical staff to configure and maintain the physical-to-virtual mappings, while operators work only with virtual-to-virtual routes. This keeps hardware details out of normal operation without hiding them from the people responsible for engineering the system.
This first guide uses flat virtual Shapes. It does not use nested Shapes or reverse routing.
Example#
Assume the routing configuration contains:
- A physical source bundle named
Camera 1, with one video port and two audio ports. - A physical destination bundle named
Studio Monitor 1, with matching video and audio ports.
You will create:
- A source Virtual Bundle from
Camera 1. - A destination Virtual Bundle from
Studio Monitor 1. - A Matching Preset describing how their slots connect.
- A virtual-to-virtual route between them.
Warning
Use non-production ports for this example. Creating or changing a virtual mapping can complete an end-to-end path and cause Buttons to update a physical destination. Taking the final virtual route can change several physical destinations.
Create a source virtual from a physical bundle#
- Open Routing → Ports.
- Find the physical source bundle
Camera 1. - Right-click the bundle row and select Virtual → Create Virtual Bundle.
- Under Shape, leave Create New Shape selected.
- Set Shape Label to
Camera. - Under Bundle Labels, keep the physical bundle label or choose a suitable numbered label.
- Review the Shape Preview. Confirm that it contains the expected video and audio slots.
- Leave Strict Physical/Virtual Boundary off for this introductory example.
- Leave Route the incoming side or Route the outgoing side enabled, according to the side shown by Buttons.
- Leave the Hide and Lock options off during the initial setup.
- Select Create.
- Review the routing report, then use Go to bundles to open the new Virtual Bundle.
The dialog derives slots from the selected physical bundle's port types. If several selected physical bundles do not share a compatible port structure, Buttons cannot produce one useful Shape for all of them.
What you created#
The operation creates two related resources:
- The
Camera Shape describes the reusable structure: one video slot and the available audio slots. - The
Camera 1 Virtual Bundle is one logical device built from that Shape.
When Route the … side is enabled, it also creates mappings between the physical ports and the corresponding virtual slots. These mappings become the physical edge of routes that use the Virtual Bundle.
Use the source virtual#
Open Routing → Virtual → Bundles, then select Camera 1.
The bundle detail shows:
- The Shape used by the bundle.
- Incoming on the left and Outgoing on the right.
- One row for each slot.
- The physical or virtual routes currently touching each side.
At this point, Camera 1 can be selected as a logical source in routing interfaces that allow virtual resources. The operator no longer needs to select the camera's video and audio ports separately.
The Virtual Bundle is also the stable object that panels and saved routing Presets can refer to. If the physical camera is later connected through different hardware, update the physical mapping behind Camera 1. The operator-facing logical route can remain unchanged.
Hide or lock the implementation side#
A Virtual Bundle has separate Incoming and Outgoing sides. Often, one side exists only to connect the virtual to the physical system and should not be part of normal operator routing.
For a source virtual, engineering might map the physical source ports to the virtual's incoming side once. The incoming side can then be hidden so operators route only from the logical outgoing side.
For a destination virtual, the outgoing side can similarly hold the fixed mapping from the virtual to physical destination ports while operators route only to its logical incoming side.
Open the Virtual Bundle and use its side settings:
- Hidden removes that side's ports from routing interfaces.
- Locked keeps the side visible but prevents routing changes.
- Hidden and Locked together conceal the implementation mapping from routing interfaces and protect it from changes.
A useful setup sequence is:
- Leave the implementation side visible and unlocked while configuring it.
- Map every required physical port.
- Become familiar with the resulting route and its report.
- Turn on Hidden if operators should never select that side in routing interfaces.
- Turn on Locked if the mapping must not be changed during normal operation.
- Save the Virtual Bundle settings and confirm that the operator-facing side remains available.
The Create Virtual Bundle dialog also offers Hide the … side and Lock the … side. Use those options when the generated mapping is already understood. During the initial setup, leaving them off makes the mapping easier to inspect.
Understand the generated Shape#
A Shape is a reusable template for a kind of Virtual Bundle. It defines which signal positions are available and the bundle's main direction.
Open Routing → Virtual → Shapes, then select Camera.
The generated Shape contains:
- A Label identifying the device type.
- A Main Direction of Source because it was created from a physical source bundle.
- A list of Slots derived from the physical bundle.
- An icon, color, label, and data type for each slot.
- Visibility settings for the Shape's incoming and outgoing sides.
A slot is one routeable position in the logical device. The slot does not contain the physical port. It provides the stable logical position to which a physical or virtual port can be mapped.
For example, the Video slot remains the camera's logical video output even if the physical SDI connector or IP sender changes later.
How to make a Shape manually#
The port-config shortcut is useful when physical bundles already describe the required structure. You can also create the structure directly:
- Open Routing → Virtual → Shapes.
- Select + Shape.
- Change Label from
New Shape to the device type, such as Camera. - Set Main Direction to Source or Destination.
- Use + under Slots to add each signal position.
- Give every slot an operational label and the correct Data Type.
- Order the slots consistently.
- Leave Reverse Slots off for this flat Shape.
- Set Incoming Side and Outgoing Side visibility to Any context while configuring the Shape.
- Save the Shape.
Keep the first Shape flat and small. Use one slot for each signal that needs independent routing behavior. Do not add hierarchy merely to organize the display; nested Shapes affect matching and route expansion and are covered separately.
After creating a Shape, open Routing → Virtual → Bundles and select + Bundle to create instances from it. A Shape can be reused for many devices, such as Camera 1, Camera 2, and Camera 3.
Create a destination virtual from a physical bundle#
Create the destination in the same way:
- Return to Routing → Ports.
- Find the physical destination bundle
Studio Monitor 1. - Right-click it and select Virtual → Create Virtual Bundle.
- Leave Create New Shape selected.
- Set Shape Label to
Studio Monitor. - Review the preview and confirm that its slot types correspond to the source Shape.
- Leave the strict-boundary, hide, and lock options off during the initial setup.
- Leave Route the … side enabled.
- Select Create and review the routing report.
Buttons creates:
- A destination Shape named
Studio Monitor. - A destination Virtual Bundle named
Studio Monitor 1. - Mappings between the Virtual Bundle's slots and the selected physical destination ports.
Open both Shapes and compare their slots. The labels do not have to be identical, but the intended source and destination slots must have compatible directions and data types.
Create a Matching Preset#
A Matching Preset describes how slots from one Shape connect to slots in another Shape. It is different from a saved routing Preset, which stores routes for later recall.
- Open Routing → Virtual → Presets.
- Create a Matching Preset.
- Set Name to
Camera to Studio Monitor. - Set Source Shape to
Camera. - Set Destination Shape to
Studio Monitor. - Leave Reverse Routing off.
- Select Create.
- Review the generated Rules.
- Connect the camera video slot to the monitor video slot.
- Connect each audio source slot to the intended audio destination slot.
- Remove any incorrect rule.
- Leave Exclusive Destination off for this first example.
- Save the Matching Preset.
Buttons initially auto-matches compatible forward slots. Auto-match Forward Only can rebuild those rules, but the result still needs review. A Matching Preset expresses engineering intent; matching labels or data types alone do not prove that a route is operationally correct.
How the route is resolved#
The physical-to-virtual mappings and Matching Preset have different roles:
- The physical mappings connect physical source and destination ports to virtual slots.
- When a virtual-to-virtual route uses a Matching Preset, Buttons expands its rules into virtual slot-to-slot mappings.
- Buttons follows the resulting end-to-end paths from physical sources, through the virtual mappings, to physical destinations.
- For each physical destination that is not already on the resolved source, Buttons creates the physical route request required to satisfy that path.
The Matching Preset therefore determines which virtual slots connect and, together with the physical edge mappings, which physical route requests result. The routing report can contain both virtual mapping changes and actions sent to physical routing backends.
Route virtual to virtual#
- Open Routing → Execute.
- Select the virtual source
Camera 1. - Select the virtual destination
Studio Monitor 1. - In the staged bundle row, select
Camera to Studio Monitor as the Matching Preset. - Select the eye control to open Preview preset mapping.
- Confirm that every forward slot maps to the intended destination slot.
- Inspect the expanded mappings and the physical destination changes that Buttons plans to make.
- Select Take.
- Review the execution result and route state.
The operator chose one logical route: Camera 1 → Studio Monitor 1. Buttons expanded the Matching Preset into virtual slot mappings, resolved the complete paths through their physical edges, and sent the required physical route requests.
Why use this instead of physical routes everywhere?#
Virtual routing is most useful when the logical routing design should outlive the current infrastructure:
- Simpler operation: one device-wide selection can represent several related signals.
- Consistent panels: every panel can use the same logical names and groupings.
- Reusable routing intent: one Matching Preset can describe how every Camera bundle connects to every compatible Studio Monitor bundle.
- Hardware independence: replace a router port, gateway, sender, receiver, or complete device by updating the virtual-to-physical mapping.
- Safer maintenance: engineering changes remain behind the logical interface instead of being repeated in every operator panel and saved route.
- Scalable configuration: define the Shape once, then create many Virtual Bundles from it.
The abstraction depends on accurate physical mappings. After hardware changes, become familiar with the updated behavior before deploying it in production.
