This article is about sending triggers from Eos to QLab. For the reverse scenario, see this article

• Qlab Figure 53
• Qlab Tutorial
• Qlab1

Description

R/qlab: QLab is audio, video, and MIDI/Show Control software produced by Figure53 for live events, theatre, and performance. For official product. Copyright © 2021 Asterian, LLC. ArgoLIMS Version 4.10.31 - 1852. Q-Lab's new, fully-equipped contract testing lab in Shanghai, is now ISO 17025 Accredited! Laboratory Testing is perfect for those interested in weathering or corrosion testing, but are not ready to. QLAB helps you easily access data to drive decisions influencing quality patient care. Enhance department workflow efficiency by viewing and analyzing data on or off-cart. QLab Remote is the official iOS companion app for remote control of QLab, the award-winning live show control software for macOS.

When playing back lighting and sound cues simultaneously, it is often desirable to have these execute at exactly the same time. This can be achieved using Open Sound Control (OSC), which allows sound to trigger lighting, or vice versa, using only a network connection between the devices - no additional hardware required. In this article, we will look at how to send triggers to the popular show control software QLab from an Eos family console.

This article is designed to get the new user up and running as fast as possible. There is also a series of articles on the et cetera blog which covers these topics in much more detail - these are linked in line, and in full at the end of the article.

What is OSC?

OSC is an open protocol which allows the sending and receiving of human-readable messages between sound, lighting and other entertainment technology systems. For example, Eos can understand commands like '/eos/chan/1/out', which would turn off channel 1, or '/eos/cue/1/fire' to run Cue 1. Other devices implement OSC in different ways; for example, QLab would understand the incoming command '/cue/1/start'.

Part of the trick in getting different devices to talk to each other is to have them speak each other's language. If the sound software can only output in the format '/cue/1/go', but the lighting console can only understand in the format '/lights/cue/1/fire', we have a problem. Luckily, both Eos and QLab are flexible enough to avoid this.

Formerly, the MIDI protocol was commonly used for this purpose. The advantage of OSC is that no additional MIDI hardware is required, as everything happens on the network, and that OSC is much more powerful. The trade-off is that OSC can be more time-consuming to set up.

For an in-depth look at how OSC is implemented in Eos, see p47 of this document (PDF).

Setting Everything Up

There are 3 main steps we need to take to successfully trigger QLab from Eos via OSC:

• Set up a working network connection between both devices
• Configure Eos correctly to send OSC to QLab
• Configure QLab correctly to receive OSC

The Network

A quick note on IP addresses

Each device on a network must have an IP address, which must be unique within that network. An IP address consists of 4 digits between 0 and 254 separated by decimal points. So with two Eos family consoles, one could have the address 10.101.100.20, and the other 10.101.90.101 - so far so simple.

But the IP addresses of two devices must be in the same subnet, if those devices want to talk to each other. Subnets are complex, but we can keep it simple for now:

• Set the Subnet Mask on every device to 255.255.0.0
• Consequently, for 2 devices to be on the same subnet, their first 2 numbers must be the same (10.101..), but the remaining numbers can be different (and at least one of them must be)

In the example above, the two Eos family consoles can talk to each other because they share the 10.101.. Another device with the IP address 192.168.1.55 could not talk to them.

This is all you need to know for a basic network setup between Eos and QLab - for more detail, see theet cetera blog post on IP addresses and subnets.

Cooperating with the Sound Department

ETC uses default IP addresses per product type, as detailed in this article. Consoles with 1 network port (Windows XP consoles and ETCnomad Puck) use a default IP address in the 10.101.x.x range. Consoles with 2 network ports (Windows 7 consoles) use the 192.168.x.x range for their second port by default.

If you have full control over all devices on the network (including the sound computer), or the sound department also use the 10.101.x.x range, it is easiest to stick with these defaults, and ensure the IP address of the QLab computer is in the same range.

But often, someone else is running sound, and they may have their own network, with their own IP address scheme. In that case, here are your options:

• If your console has 2 network ports (see below), use the second port to connect to the sound department, and choose an (unused!) IP address in the same subnet as their QLab computer.
• If your console has 1 network port, you will need to come to an arrangement so that the console and the QLab computer end up on the same subnet. This may depend who has the fewest devices to readdress! Of course, if you don't use your console's network port (because you use DMX only), you can follow option 1 above.

Eos Network settings

To edit the network settings on a console, exit to the shell, and go to Settings > Network.

The IP address for each port is set at the top of this window. If you need to change it from the default, do so - a reboot will be required.

Once this is set, scroll down to the Interface Protocols section. Ensure that UDP Strings & OSC is ticked for the port you want to use. Leave the OSC dropdown set as below.

If you're connecting to sound using your port 2, you may want to turn off sACN and Artnet for this port, to avoid spamming the sound network with level data.

For this article, we'll assume we're using Port 1 on an Eos Ti, with an IP address of 10.101.92.101.

That's everything set in the shell, so hit Accept and head back into Primary.

QLab Network Settings

QLab only runs on macOS, so head to the Apple menu (top left of the screen) > System Preferences > Network. Choose the relevant network interface from the list (usually either wired Ethernet or a Thunderbolt adapter) and assign and IP address and subnet mask. These are the settings we're using in this example:

Hit Apply and exit System Preferences

Configuring Eos to Send OSC

Now we need to check the settings within Eos. Press [Dispays] - {Setup}, choose System (rather than User or Device), and hit Show Control, then OSC.

The OSC options are divided into RX (receiving) on the left, and TX (transmitting) on the right. We're interested in TX, as Eos will be the transmitting device.

Set the following:

OSC TX: Enabled
OSC UDP TX Port: 53000 (this is the port QLab listens on)
OSC Cue Send String: leave blank for now, see below for details
OSC UDP TX IP Address: The IP address of the QLab Mac

Your window should now look something like this:

Eos is now set up to send OSC to IP address 10.101.155.1, port 53000. Now let's configure QLab.

Configuring QLab to Receive OSC

QLab just needs to be told to accept incoming OSC commands. Open up a QLab workspace, then click on the gear symbol (bottom right) for Workspace Preferences. Choose OSC in the left-hand menu, and ensure Use OSC Controls is ticked.

Hit Done.

Great! Now both devices have enough information to talk to each other.

Sending OSC Commands

There are several different ways you can send OSC cues to QLab

Sending an OSC string on a per-cue basis

If you only need to trigger a few QLab cues from Eos, it makes sense to send a specific OSC command from the relevant Eos cues.

Let's say you need to fire QLab cue 17 with Eos cue 5. To do this, type in:

[Cue] [5] {Execute} {More SK} {String} /cue/17/start [Enter]

Eos will send this string when Q5 is executed.

This is usually the best method for theatre shows where a couple of specific sound cues need to be triggered from Eos.

Sending QLab-readable OSC with every Eos cue

Eos outputs OSC natively every time it fires a cue, but not in a format that QLab understands. To get around this, we can use the OSC Cue Send String function in the Eos OSC Setup menu.

This allows you to send a custom string with a cue (or other) number as a variable. For example:

/cue/%1/start

would send that message with every cue, with the cue number in place of the %1 - which is the format that QLab understands.

There are 5 variables you can use in the string:

%1 - cue number
%2 - cuelist number
%3 - cue whole number only (i.e. if it's cue 17.5, send only 17)
%4 - cue point number only (i.e. if it's cue 17.5, send only 5)
%5 - cue label

This method works best when one person has control of the cue numbering of both Eos and QLab.

Other Methods

OSC is very flexible, and QLab's implementation has many options.

For example, you can send a simple /go which is the same as hitting the GO button on QLab itself. Normally sending a specific cue number is preferable, but it's good to know this is possible.

QLab can also accept custom commands for certain playback functions - for example, you could map the command /eos/says/GO to the Go button. This is done in the Workspace Preferences > OSC Controls section.

Turning OSC On and Off

At times you may want to turn the OSC link between lighting and sound off, especially during tech rehearsal. Rather than going into the Setup menu every time, you can create a pair of macros to enable and disable OSC TX, and put these on a magic sheet.

This is done half in live, and half in blind.

1. From Live, start recording a macro using [Learn] [Marco] [1] [Enter]
2. Hit [Displays] {Setup}, navigate back to the Show Control > OSC menu, and click on the OSC TX cell (it doesn't matter what state it's in)
3. Hit [Learn] to finish learning
4. Enter the macro list using [Macro] [Macro]
5. Your macro will contain several unwanted things. Hit {Edit}
6. Use the {Delete} softkey to remove all commands from the macro except OSC_TX and the final Enter (diamond)
7. Using the 'Common' tile in the CIA, insert the word 'Enable' after OSC_TX, before the Enter
8. Hit {Done} to finish editing your macro

The macro should now simply read OSC_TX Enable ♦

Within the macro list, copy this macro using [1] [CopyTo] [2], and edit the new macro to read OSC_TX Disable ♦

You can test these out from live, and create magic sheet objects to fire them.

It's Not Working!

If you followed the steps above, but the QLab cue won't fire, don't despair. There are many variables in a network system, and sometimes a little fault finding is required.

The Eos Diagnostics Tab

Eos has a built-in diagnostics tab, which shows you what's happening on the console in real time. To access it, hold down the [Tab] key, and type in 99, then release the [Tab] key. In the window at the top, you will see a live stream of events within Eos.

On the right-hand side, ensure the Outgoing OSC option is set to On. Now run an Eos cue that should send OSC to QLab. If the OSC is leaving Eos, you should see the following message (among a large number of other messages beginning with /eos)

This confirms that the OSC command was sent.

If you don't see this, the OSC message isn't being generated. Check your OSC String TX field, or the execute field of your cue, is correct. Check that OSC TX is turned on.

If you see this but nothing happens, check that there is a cue 2 in QLab.

If there is, check a few basics:

• Is the Eos OSC TX port set to 53000, and the TX IP Address set to that of the QLab Mac? You can check both these things in QLab Workspace Settings > OSC Controls
• Is 'Use OSC Controls' ticked in this window?
• Does Eos definitely think that the correct IP address is online? With an empty command line, press [About], and check that the expected IP appears here
  • This is especially important if running Eos on a laptop, which may have many network interfaces.

Network Connection Troubleshooting

If all of this is fine, we should confirm that the Mac and Eos can talk to each other at all. To do this, we will Ping the Eos from the Mac.

• Open the Terminal app on the Mac (Finder > Applications > Utilties > Terminal)
• Type in the following and hit Enter (with the IP address of your Eos):
  ping 10.101.92.101
• You should see the reply '64 bytes from 10.101.92.101'
• If not, you will get the failure message 'Request timeout for icmp_seq'

If your ping fails, investigate the cabling between your devices. Ensure both devices think the relevant network interface is online. If there's a switch in the mix, make sure it's happy (powered on, network lights blinking). If it's a managed switch, there may be settings preventing the message getting through. Managed switches are beyond the scope of this article; consult your favourite network expert.

If you're running Eos on a laptop, Windows or third-party firewall rules may be preventing the connection. Ensure that the Eos application is permitted free access to the relevant network interface.

If it still doesn't work, please contact ETC Technical Services in your region, who will be happy to help.

Notes and Additional Information

Now you have a basic overview of how to make Eos talk to QLab, and use OSC to fire a cue. There are other possibilities; most aspects of Eos control are exposed to OSC, so you could use QLab to raise a submaster, bring up a channel, or fire a macro. See the OSC section of the Eos Family Show Control User Guide (PDF) for details on how to access these functions.

Triggering other OSC Software from Eos

The same principles apply if you're sending OSC to a different program - simply set the correct IP address, port and string to send. You can use the OSC Cue Send String field in the same way as shown above.

For example, let's say we're using the fictional software 'Soundzz', which understands OSC, but only in the form '/soundzz/q/label/preshow/start'. We can use the label variable in the OSC Cue Send String field, and make sure the Eos and Soundzz cue labels match where necessary.

/soundzz/q/label/%5/start

Further Reading

As stated, this article is intended as a quick (ish) guide to get you up and running, using a common but simple scenario. We have barely scratched the surface of the concepts discussed here - OSC can do many more things than just trigger cues, and there is no limit to how large and complex a lighting network can be. See the following links for more information.

• The et cetera blog mentioned in the article, in full:

QLab is a cue-based, multimedia playback software for macOS, intended for use in theatre and live entertainment. It is developed by Figure 53, an American company based in Baltimore, Maryland.^[1]

History[edit]

Qlab Figure 53

Qlab Tutorial

QLab 1.3.10 was the first version of the software and was released on May 25, 2007.^[2] As of March 2020, the current version is 4.6.3.

Uses[edit]

Qlab1

Cues[edit]

In QLab, a cue is a marker for an action to take place in the program. When triggered, a cue executes an operation. The list of available cues in v4 is as follows:

• Audio
• Mic
• Video
• Camera
• Text
• Lights (Art-Net or DMX)
• Fade
• MIDI (voice messages, sysex, or MSC)
• MIDI File
• Timecode (MTC or LTC)
• Group
• Start
• Stop
• Pause
• Load
• Reset
• Devamp
• Goto
• Target
• Arm
• Disarm
• Wait
• Memo
• Scripts

Audio playback[edit]

QLab allows an end-user or designer to align audio files in a sequential order. Once the audio files are inserted into the cue list, the end-user can then manipulate it by looping it, changing the amplitude or volume, and adding fades in or out. Audio cues can also be placed into groups, so that multiple files can be triggered at one moment.^[3]

Video playback[edit]

The video capability of the software in its most recent version allows a designer to add video files to their cue lists, allowing them to be time aligned with other cues, including audio files. Video files can be altered in real time in QLab, by integrating a Quartz Composer file.^[4] The designer can also select on which video card or cards the video will play. It is useful to note that the speed of the computer processor and video card can affect the quality of video playback.

MIDI integration[edit]

QLab supports MIDI bi-directionally. QLab allows MIDI signals to be sent as a cue to trigger other devices, such as digital audio consoles. The software also accepts MIDI signals as triggers for its own cues. MIDI signals can be sent to QLab from other computers running QLab software, or any other MIDI capable device, using a MIDI Interface.^[5]

Live playback[edit]

A key software feature with QLab is its ease of use in live playback situations. The designer of a cue sheet can save their show file, and lock it, preventing any changes to the cues. After doing so, an untrained user can run the software in a playback situation. By default, a cue is triggered by clicking a large GO button on the screen, or by pressing the space bar.^[6]

References[edit]

1. ^Figure 53 | Company
2. ^Figure 53 | QLab | Download
3. ^Figure 53 | QLab | TourArchived February 4, 2011, at the Wayback Machine
4. ^Figure 53 | QLab | TourArchived February 4, 2011, at the Wayback Machine
5. ^Figure 53 | QLab | TourArchived February 4, 2011, at the Wayback Machine
6. ^Figure 53 | QLab | Documentation