Audiovisual control · Practical guide
Q-SYS: prepare a UCI and separate emulation from real operation
A UCI (User Control Interface) can bring event content selection and equipment status together. It is useful when operators can distinguish what they requested from what the system has confirmed.
- Operator: content action
- UCI: requested action and visible state
- Control logic / intended Core
- AV device and output observation
Define an interface for one specific task
In this proposed application, an operator selects holding content or an opening video. Keep the requested content name separate from received status. If documented feedback is unavailable, display a condition to verify and agree on a manual observation.
Coordinate changes with the person responsible for the existing digital signal processing (DSP) design. This preparation covers UCI controls, text, and decisions; audio processing and routing require their own review.
Model, design, and licenses
Record the Core, Designer version, intended firmware, display device, and control components or plugins. The official FAQ states that supported Cores running 10.0 or later have scripting and UCI access without installing those licenses. For earlier versions, verify applicable rights without extrapolating this change. Check the other design features separately: opening or emulating a file does not confirm that the Core has all the required resources.
Check Design helps identify calculated design requirements and limits. Its documentation warns that it does not predict every scripting, plugin, or other environment-dependent load. Retain its report with the file revision.
What can be compared
| Item | In emulation | In an authorized real environment |
|---|---|---|
| UCI navigation | Review pages, text, and logic | Check presentation and operation on the selected panel |
| Equipment indicator | May lack physical data or show defaults | Compare with documented device status |
| Audio control | Does not demonstrate signal or DSP | Verify with the audio department |
| Core serial interface | Does not act as a physical port in emulation | Check interface, response, and output separately |
Do not assume a script’s network calls are isolated because of the mode name. Prepare the example without real destinations, credentials, or components that can communicate outside the review environment.
Prepare the review without deploying
- Keep a copy of the design and document the control to add or change.
- Write down the action, expected state, feedback source, and decision if confirmation is missing.
- Use fictional data to review names and logic, and record emulation observations separately.
- Keep emulation results, Core tests, and signal observations separate. Review text in a copy rather than saving over an active Core.
Three questions for the project discussion
- Is there an approved design? Its revision and owner define the change boundary.
- Will the UCI run on a PC, tablet, or Q-SYS panel? Confirm format, permissions, and licenses.
- What signal confirms the result? Define its source, freshness, and the operator’s action when it is missing.