Tally tells people and connected systems what is operationally important now: which source is on Program, which signal is on Preview, what is recording, or what a UMD should display.
Buttons does not treat tally as one fixed red or green light. It separates where state comes from, what that state means, where it applies, and what should happen because of it.
The operational model is:
Input state→ Provider→ Tally Channel on ports→ Consumer lookup→ Reaction
For example:
ATEM reports Input 2 on Program→ Input 2 Program Provider becomes active→ Program Channel becomes active on the Input 2 source port→ Consumer watching ME 1 Program follows its Active Source→ Consumer resolves Input 2, its label, and its Program Channel→ TSL reaction updates the UMD tile
A Tally Channel is a named category of operational state. Common examples include:
Program (PGM)
Preview (PVW)
Record (REC)
IMAG
Channels answer what the state means, not where it came from or what should react to it.
A Program Channel can be supplied by an ATEM feedback, an incoming TSL message, a variable, or another configured condition. Consumers can use that same Program meaning without needing to know which system supplied it.
A Channel has a label, short label, and color. The short label and color help present the state consistently in Buttons and compatible outputs.
Do not assume every active Channel means “on air.” Preview, Record, IMAG, confidence, and facility-specific meanings can coexist on the same port.
A Provider decides when one or more Tally Channels should become active and which ports should receive them.
A Provider has three essential parts:
Input Conditions: the state it evaluates.
Target Ports / Bundles: where the tally applies.
Tally Channels: the meanings it adds while active.
Provider inputs can include:
Connection feedbacks, such as ATEM Program or Preview state.
Connection, Position, or Workflow variables.
Incoming TSL state, from a TSL connection in Server (Listen) mode.
An explicit always-on condition.
GPI-based conditions are modeled but not yet configurable from this interface.
When several conditions are configured, Condition Mode controls whether All, Some, or None must be true. A Provider with no conditions is always active.
When the condition result becomes active, the Provider contributes its configured Channels to its resolved target ports. When it becomes inactive or stops, its contribution is removed. Other Providers may continue contributing Channels to the same ports.
Tip
Keep Providers focused on where state originates and Consumers focused on what should react. This makes it easier to inspect the source of an incorrect tally without also untangling output behavior.
The Provider's Target Ports / Bundles are its tally subjects. A subject can be a source port, destination port, source bundle, or destination bundle.
Its expansion determines whether tally applies only to the selected resource or follows routing:
Self applies tally to the selected port or the member ports of the selected bundle.
A source subject can apply tally to destinations it currently feeds.
A destination subject can apply tally to sources currently feeding it.
For a straightforward switcher setup, a Program Provider normally targets the relevant ATEM source port using Self. Buttons then records that the source itself has Program tally. Consumers can decide how to interpret that state relative to their own watched resources.
The Active view under Routing → Tally / UMD presents the tally state currently held on ports.
For each active port, it shows:
Active Channels: the tally meanings currently applied.
Responsible Providers: the Providers currently contributing them.
This view answers two useful questions:
Which Channels are active on this port?
Which Providers are responsible for that state?
It verifies the Provider side of the system. It does not prove that a Consumer resolved the intended relationship or that an external output received its message.
The Watch Item is not necessarily the port whose tally will be consumed. It is the point from which each lookup starts.
For example, a Consumer can watch the ME 1 Program destination while its lookup uses Active Source. If Input 2 is routed there, the Consumer reads the label and active Channels from Input 2, not from the destination itself.
This distinction allows a fixed UMD tile to follow changing routes without reconfiguring the Consumer every time the source changes.
Each Tally Lookup and Label Lookup chooses a routing relationship. Common choices include:
Selected Watch Item: use the Watch Item itself.
Active Source: use the source currently routed upstream to the watched destination.
Active Destination: use destinations currently fed by the watched source.
Upstream Related Source or Downstream Related Destination: trace the active routing chain to the Next Hop or Furthest related endpoint.
Upstream Virtual Bundle or Downstream Virtual Bundle: resolve Virtual Bundles encountered through the route, optionally restricted by Shape.
Route Request Source or Route Request Destination: use endpoints from relevant retained Route Requests.
The same Consumer can use one relationship for its label and another for its tally. For example, it could display the selected destination's label while showing Channels from its active source.
A Tally Lookup resolves one or more ports, reads their active Channels, and can filter the result.
Filters can require:
All selected Channels.
Some selected Channels.
None of the selected Channels.
No Channel filtering.
The lookup result can then drive a Reaction. For a UMD output, mappings decide which lookup controls the left, center, or right indication and which color to send.
A Label Lookup uses the chosen relationship and Label Strategy to resolve text. It can show a physical port label, an appropriate bundle label, or a Virtual Bundle label depending on the selected relationship and aggregation.
Label and tally resolution are separate because a display may need a label without a tally indication, a tally indication without changing its label, or both from different related resources.
TSL is an integration into the Tally system, not the complete model.
A TSL server connection listens for incoming TSL messages. A Provider can interpret an address and tally index from that connection and turn it into Buttons Tally Channels on configured subjects.
A TSL client connection sends to an external TSL server, such as a multiviewer or UMD display. A Consumer Reaction maps resolved labels and Channels to a TSL address, screen, text, and tally positions.
This separation allows incoming TSL state to be normalized into Channels, related to routing, and sent onward in a different form. Providers and Consumers can also operate without TSL when their inputs or Reactions use other supported systems.
Provider Test Mode forces that Provider active, applying its configured Channels to its resolved targets.
Consumer Test Mode forces selected Tally Lookups active and can replace resolved labels with explicit test values before running its Reactions.
Test Mode affects configured output behavior. A Consumer with a TSL Reaction can send test indications to the external display. Turn Test Mode off and save after setup work so temporary state is not mistaken for operational truth.
When tally is wrong, inspect the same sequence used by the model:
Is the real input state correct?
Is the expected Provider active?
Does Active show the expected Channel on the correct port?
Does the Consumer watch the correct item?
Do its Tally and Label Lookups resolve the intended relationship?
Does its Reaction target the correct action or TSL connection and mapping?
Does the external system use matching protocol and address settings?
If Active is wrong, investigate the Provider side first. If Active is correct but the result is wrong, investigate Consumer resolution and its Reaction.
