BrightAuthor: Super States and UDP control

Topic 1 of 13

#The whole idea in plain English

BrightAuthor:connected is where the presentation behaviour is built. BrightBridge distributes the finished published presentation. Companion then sends tiny network messages such as go_show to tell the running presentation what to do.

Thing	Think of it as	Example
State	One playable item or behaviour	Holding slide, opening video or sponsor loop
Event	A rule that listens for something	When go_show arrives, move to Show
Super State	A reusable folder containing its own states and rules	Everything used during the Show section
UDP message	A short one-way network cue	go_break
Companion button	The labelled button that sends the cue	BREAK

Signal path

Companion button
  -> UDP message: go_show
    -> BrightSign player UDP Input event
      -> transition into the Show Super State
        -> Show's initial state starts

Topic 2 of 13

#Before you build anything

BrightAuthor:connected is installed or open and the presentation can be edited.The presentation is Advanced or interactive rather than a simple non-interactive playlist.You know the test player's local IP address. Do not put a real address in presentation notes or screenshots used publicly.You know which computer runs Companion and that it can reach the player's network.You have one spare test player or an approved test window.A known-good presentation is available if the test needs to be rolled back.

Topic 3 of 13

#Create a Super State

Click-by-clickBuild one reusable presentation section

BrightAuthor:connectedEdit presentationZone Content

1
Add Super State
Drag a Super State onto the interactive playlist canvas.
2
Name
Use the job it performs, such as Holding, Show, Break or Emergency—not a temporary media filename.
3
Open it
Double-click the Super State to enter its internal playlist canvas.
4
Add states
Place the images, videos, lists or other states that belong to this section inside it.
5
Initial State
Choose the state that must play first whenever the Super State is entered.
6
Return
Use the breadcrumb above the canvas to return to the parent Zone Content canvas.

Put a cue on the Super State itself when it should be active while any state inside it is playing.
Put a cue on an individual internal state when it should work only from that state.
Use Super States to remove repeated global cues, not to hide an unexplained tangle of states.
Nested Super States work, but one level is easier for a first show file.

Topic 4 of 13

#Make UDP cues change Super States

A UDP Input event listens for an exact message. The message is just text: no quotation marks and no JSON are required for a simple cue.

Click-by-clickAdd one UDP transition

BrightAuthor:connectedZone ContentCurrent state or Super State

1
Select the start
Select the state or Super State that should listen for the cue.
2
Add event
Add a UDP Input event from that item.
3
Specify UDP input
Enter a short, unique message such as go_show. Use lowercase letters, digits and underscores to keep typing predictable.
4
Target
Connect the event to the destination Super State or state.
5
Optional exact landing
Open the event and use Specify next state only if the cue must enter a particular internal state instead of the Super State's initial state.
6
Save
Save the presentation, then repeat for the other required cues.

Beginner cue set

go_holding
go_show
go_break
go_emergency

Topic 5 of 13

#Worked example for a temporary event

Super State	Initial state inside it	Other states inside it
Holding	Holding Loop	Doors Open, Starting Soon
Show	Opening Video	Main Loop, Sponsor Sting
Break	Break Loop	Back in Five
Emergency	Safety Message	Blank Output

1
On the Holding Super State, add go_show to enter Show and go_emergency to enter Emergency.
2
On the Show Super State, add go_break to enter Break, go_holding to return to Holding and go_emergency to enter Emergency.
3
On the Break Super State, add go_show to return to Show, go_holding to return to Holding and go_emergency to enter Emergency.
4
On the Emergency Super State, add only the approved recovery cue, such as go_holding. Keeping recovery deliberate prevents an accidental show cue from clearing a safety screen.
5
Inside each Super State, add only the cues or Media End events needed by that particular internal sequence.

Cue sheet

HOLDING    go_holding
SHOW       go_show
BREAK      go_break
EMERGENCY  go_emergency

Topic 6 of 13

#Set the player's UDP receiver port

Click-by-clickCheck the incoming UDP port

BrightAuthor:connectedPresentation SettingsNetworkingUDP

1
UDP Receiver Port
Read the port the player will listen on. BrightAuthor:connected commonly defaults this to 5000.
2
Record it
Put the approved port in the private show network sheet. Companion must send to this same number.
3
Do not confuse ports
Receiver Port is for messages coming into the player. Destination Address and Destination Port are for UDP messages the presentation sends out.
4
Save
Save and republish if you changed the receiver port.

Topic 7 of 13

#Create the Companion buttons

Companion versions use slightly different wording, but the setup is the same: a Generic TCP/UDP connection sends raw UDP text to the BrightSign player's local address and receiver port.

Click-by-clickConnect Companion to one BrightSign player

CompanionConnectionsAdd connection

1
Connection type
Search for and add Generic TCP/UDP.
2
Protocol
Choose UDP rather than TCP.
3
Target host
Enter the test player's local IP address from the private network sheet.
4
Target port
Enter the BrightAuthor UDP Receiver Port—commonly 5000 unless the presentation uses another value.
5
Save
Give the connection a useful name such as BrightSign - Stage Left, then save it.

Click-by-clickMake one show-control button

CompanionButtonsChosen buttonActions

1
Button label
Name the outcome clearly, for example GO SHOW—not UDP 1.
2
Action
Add the send-data action from the Generic TCP/UDP connection.
3
Payload
Enter go_show as plain text, exactly as written in the BrightAuthor UDP Input event.
4
Line ending
Use no carriage return or line feed for this simple cue unless the BrightAuthor event was deliberately built to include one.
5
Save and copy
Test it, then duplicate the button and change both label and payload for Holding, Break and other approved cues.

Button text	UDP payload	Target
HOLDING	go_holding	Holding Super State
GO SHOW	go_show	Show Super State
BREAK	go_break	Break Super State
EMERGENCY	go_emergency	Emergency Super State

Topic 8 of 13

#Control more than one player

For predictable targeting, create one unicast connection per player and add all required send actions to the same Companion button.
Name every connection by physical outcome, such as Stage Left or Foyer—not only by IP address.
Keep cue payloads identical across players only when their deployed presentations interpret them the same way.
Network broadcasts may be blocked by VLANs, routers or Wi-Fi settings and can reach unintended players. Do not make broadcast the first show-critical design.
If players must change on the same video frame, plain independent UDP triggers are not a frame-accurate synchronisation system. Use an approved BrightSign synchronisation design instead.

Topic 9 of 13

#Optional: send a value instead of only a cue

A UDP Input event can assign incoming text to a BrightAuthor User Variable. This is useful for operator-supplied labels or simple values, but it is an advanced step after ordinary state cues work.

One variable

lowerthird:Welcome to the show

Several variables in one message

title:Welcome!!room:Main Stage!!session:Opening

Create the User Variable in the presentation before using it.
Configure the UDP Input event to assign the input to variables using the BrightAuthor variable-input option.
The name before the colon must match the variable name. Double exclamation marks separate multiple assignments.
Test punctuation and spaces with the actual receiving state before using the value on a live screen.
Never send passwords, tokens or personal data this way. Presentation User Variables are not a secret store.

Topic 10 of 13

#Publish it, then put it on the player

1
Save the BrightAuthor project and publish the complete presentation output using the approved publishing method.
2
In BrightBridge, open the Presentation library and upload the complete published output—not the BrightAuthor authoring project or a handful of media files.
3
Open Content releases, select only the test player, choose the new presentation and run a fresh dry run.
4
Apply the release once the preview is correct, then wait for the player to collect and start it.
5
Confirm the expected initial screen before sending any Companion cue.
6
Run the full cue test. Only then release the presentation to the remaining event players.

Topic 11 of 13

#Test every route before the event

Cold start or reboot lands on the intended presentation and initial state.Every Companion button has a plain outcome label and the correct raw payload.Every cue works from every Super State where operators may press it.Pressing the current-state cue again has an understood result; it does not unexpectedly restart an important video.Each target player responds, not only the easiest screen to see.The approved recovery cue returns to a safe known state.The control computer still reaches players after the real event switch, VLAN and Wi-Fi arrangement is in place.A known-good presentation and manual recovery method are available if control fails.

Topic 12 of 13

#If the button does nothing

What you see	Most likely cause	What to check
Nothing changes	Wrong address, port, payload or network path	Compare player IP, BrightAuthor Receiver Port and Companion target. Copy the cue text again.
Cue works from one screen only	Event is attached to one internal state	Move or add the global UDP event to the enclosing Super State.
It enters the wrong item	Wrong target or initial state	Check the event target, the Super State's Initial State and Specify next state.
One player changes	Only one connection/action worked	Inspect every Companion action and each player's address; test them separately.
Unexpected players change	Broadcast or reused target	Stop testing, confirm target addresses and change to explicit unicast connections.
Video restarts	The active cue targets the current state again	Decide whether repeat should restart, be ignored or target another state; test that design.
Variable stays unchanged	Assignment option or message format is wrong	Check variable name, colon, double-exclamation separators and the receiving event settings.
It worked yesterday	Presentation, player address or network changed	Confirm the player is running the expected published version and re-check the current network sheet.

1
Stop pressing the button repeatedly.
2
Confirm the correct presentation is visibly running on the correct player.
3
In Companion, read the exact target address, UDP port and payload.
4
In BrightAuthor, read the UDP Receiver Port and the event's Specify UDP input value.
5
Check whether the event is active from the state currently playing or from its enclosing Super State.
6
Test one simple cue on one player. If it still fails, record the time, player, current state, expected target and Companion action before escalating.

Topic 13 of 13

#Caveats and quick answers

Question	Short answer
Does Companion know the current BrightSign state?	Not from a simple outgoing UDP action. Add a deliberately designed feedback path if operators need trustworthy state feedback.
Is UDP guaranteed to arrive?	No. UDP does not provide delivery, ordering or acknowledgement. Use screen or player feedback to verify important cues.
Is port 5000 always correct?	No. It is a common BrightAuthor:connected default; the presentation's UDP Receiver Port is the source of truth.
Can one cue work from every item in a Super State?	Yes for suitable interactive events: place the event on the enclosing Super State. Keep state-specific events on the internal state.
Can a cue jump to an internal state?	Yes. Open the event and choose the desired internal target under Specify next state.
Can Super States be nested?	Yes, but entry and exit commands can run through each level. Keep the first version shallow and test command order.
Should we use the player's IP as a button label?	No. Label the physical outcome; keep addresses in the private network sheet and connection settings.
Can UDP come across the internet?	Do not expose this simple control receiver publicly. Use the organisation's approved secure network or remote-control design.
Do these labels match old BrightAuthor Classic exactly?	Not always. This guide follows BrightAuthor:connected; legacy BrightAuthor uses similar ideas but some screens and wording differ.