QLab 5
Preferences → Media Servers → QLab: connection, ports, and time display.
ShowRevue only supports QLab 5.
The Launch New Show wizard has a QLab step: pick QLab, enter its IP and ports, then run the Test step, which connects and checks the follow round-trip. The steps below are the same settings by hand.
QLab cues land in the playback cue list (Media tab) with their running times.
Setup
In QLab 5:
- Open Workspace Settings → Network → OSC Access.
- Turn on Allow OSC access.
- Set the OSC Port to match ShowRevue, usually
53000. - If the workspace uses an OSC passcode, enter the same passcode in ShowRevue → Preferences → Media Servers → QLab.
- If you want ShowRevue to fire cues back to QLab, make sure the OSC access level allows ShowRevue to control or fire cues.
- Set the destination IP to the Mac running ShowRevue.
- Confirm ShowRevue's Reply Port is available, usually
53001.
In ShowRevue:
- Open Preferences → Media Servers → QLab.
- Enter the QLab IP address.
- Confirm the QLab Port matches the QLab 5 workspace, usually
53000. - Confirm the Reply Port matches the port ShowRevue should listen on for QLab replies, usually
53001. - If QLab 5 has a passcode set for OSC access, enter the same value in Passcode.
- Confirm ShowRevue and QLab are on the same local network.
QLab cues appear in the Media tab.
During playback:
- Click the cannon icon on a QLab cue row to fire that cue again.
- Use FOLLOW to re-fire all recorded QLab cues at their original playback positions.
Follow mode and cue fireback should only be used when the workspace is ready to receive live commands.
Troubleshooting
The status line under Preferences → Media Servers → QLab says which of these you have.
"Waiting for QLab…" and the Live page shows Offline
ShowRevue is sending and QLab is not answering. Check, in this order:
- A workspace is open in QLab. QLab does not answer at all while it sits on the Launcher window, or while a dialog is waiting for an answer, such as the prompt asking whether to convert an older workspace.
- The QLab IP is right. For QLab on the same Mac this is
127.0.0.1. - The QLab port matches the workspace, usually
53000. - Both machines are on the same network and can see each other.
"QLab denied access"
QLab let ShowRevue connect but the workspace has not granted it any OSC rights, so every request after the connection is refused.
Open Workspace Settings → Network in QLab and allow OSC access. If you want ShowRevue to fire cues back, the access level needs to include control.
This one is easy to miss because the connection itself succeeds. QLab answers the version and workspace queries whatever the access setting is, and only refuses the requests that matter.
"Reply port 53001 in use"
Another application on the Mac holds the port ShowRevue listens on for QLab's replies. A second copy of ShowRevue is the usual cause. Quit the other application, or change the reply port in both places.
Keep the reply port at 53001 if you can. QLab 5.5 refuses the message that asks it to reply
somewhere else and answers on 53001 regardless, so a different port receives nothing.
A cue arrives with no name
QLab's running-cue list often leaves the name out, so a cue picked up when ShowRevue reconnects part-way through it would otherwise be recorded as a bare number. The name is fetched separately and filled in.
Reading the log
The log names what happened at each step. Find it at
~/Library/Application Support/ShowRevue/Logs/, or use
Preferences → Diagnostics → Save Bug Report to bundle it up for us.
A healthy connection looks like this:
qlab: Reply listener ready on 53001
qlab: Handshake sent to 127.0.0.1:53000 (attempt 1), awaiting /reply/workspaces on 53001
qlab: Workspace reply after 1 attempt(s): ShowRevueTest
qlab: Connected to ShowRevueTest, view + control
qlab: Cue start 14 14. Let's get physical.mp3
Repeated handshake attempts with no workspace reply mean QLab is not answering, which is the first section above.