AV show control
Show control messages: OSC, MIDI notes, and MSC
Before choosing a protocol, describe the intended action: select a specific cue, advance a list, or adjust a value. Two systems may support the same protocol while assigning different meanings to messages.
OSC: address, type, and value
OSC 1.0 structures a message with an address, types, and arguments. The application defines what an address means. Feedback or acknowledgment must be documented by the destination.
Fictional message example: /demo/cue/select, type tag ,s, argument Q010. This shows how a text identifier can be expressed. To use a message with a product, you need the address, data type, range, and behavior documented by its manufacturer.
What to ask about feedback
Where supported, request a response that distinguishes receipt, acceptance, and resulting state. If only connection status is available, document that limit and agree on an operator observation. A bundle does not establish alignment of physical outputs.
Record whether feedback uses polling or a subscription, when it becomes stale, and how it relates to the cue. Do not blindly resend an advance when feedback is missing: the first command may have taken effect.
MIDI notes and MSC: choose by intent
In MIDI 1.0, Note On carries a note number and velocity; Program Change carries a program number. Their show functions require explicit mapping. MSC provides show commands such as GO, STOP, and RESUME.
Before choosing MSC, confirm both implementations and versions, Device ID, command format, and supported cue/list fields. Do not confuse Device ID with a note’s MIDI channel. For notes, record channel, numeric note number, velocity, and the event that permits triggering; octave names may differ between programs.
| Need | Option to review | Decisive question |
|---|---|---|
| Select a named cue | OSC supported by the destination | Does it accept the identifier and confirm selection? |
| A mapped trigger | MIDI note | Does it trigger on press, on release, or only when a filter condition is met? |
| Show commands between compatible systems | MSC | Which commands and fields does each endpoint interpret? |
Duplicate triggers: identity and repetition
For filter design, distinguish cue ID, execution ID, and attempt number. Running Q010 in another performance may be legitimate; receiving the same execution twice requires a different decision. Document the duplicate history’s scope and retention if the platform supports implementing it.
Conceptual proposal: session S-A / execution E-010 / destination VIDEO-A identifies one intent. A second arrival with that combination is logged as a duplicate without retriggering, but only if the implemented logic retains that record. A new execution E-011 requires an explicit GO.
After a restart or when the history expires, that protection may no longer apply. Agree on checking state and recovering manually before resending. A filter based only on timing might also suppress a valid second GO. Review the rule with the operator and check what the platform supports; the filter does not guarantee exactly-once execution under all conditions.
| Proposed situation | Design decision to review |
|---|---|
| Same execution received twice | Log repetition and check the deduplication rule |
| Legitimate new GO for the same cue | New execution identity; verify it is permitted |
| No response and unknown outcome | Do not blindly retry an advance; observe/query and decide |
| Controller restarted | Reconcile state and review retained history |
Prepare a message record
The existing QL, Companion, and Lightkey guide covers their configuration and troubleshooting. Use it for that case; this record organizes the agreement between departments.
- Record each product, version/build, and manual. Confirm transport, direction, and port naming with the technical lead.
- For each cue, record intent, documented message, types/values, destination, and previous state.
- Add expected feedback, an agreed waiting limit, and the operator’s decision if unconfirmed.
- Prepare a test in an isolated copy first. Then arrange an authorized test that includes observing the actual output and recording which message arrived and what happened.
Sources and manuals
Review how your systems communicate
Share a system diagram, photos of the connections, or a preliminary cue list. GLMedia can help identify which interfaces to evaluate and what technical support or additional equipment the workflow may need.
Review how your systems communicate