This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

A guide to triggering Qlab cues from Eos over OSC

 This data is old - please refer to this support article: Triggering QLab from Eos using OSC - Electronic Theatre Controls Inc

With the release of 2.3, it is now possible to trigger Qlab cues using a protocol called OSC.  OSC is like MIDI Show control, except way more awesome, and it runs on modern networking protocols like TCP or UDP.  That means you can ditch the MIDI gear, and just connect your Qlab computer to your Eos lighting network.  

The only trick is, Eos and Qlab speak slightly different dialects of OSC.  Every time you take a cue on Eos, it will output a command that looks like "/eos/out/event/cue/1/2/fire", but Qlab is listening for a command that looks like "/cue/2/start".  So how do we get them to talk to each other? Here's how to get it working:

1) Make sure you're running Qlab 3 and Eos v2.3 or higher.

1a) Make sure that "UDP Strings & OSC" are enabled in the Eos shell settings (Exit to the shell, click "Setup", click "Network", scroll down to "Interface Protocols")

2) On Eos, navigate to Settings>Show Settings>Show Control, and configure your system so it matches these key settings:

For your Eos system to output OSC, String TX must be enabled, and you need to tell it what IP address you want it to send OSC commands to.  So under OSC TX IP Address, enter the IP address of the Qlab computer, and under OSC TX Port Number, enter 8000 (more on that later).

3) On the Qlab computer, download an application called OSCRouter (written by Eos developer, Chris Mizerak) from the ETC Labs Git Hub page:

github.com/.../OSCRouter

In OSCRouter, configure it to look like this:

That is telling your Qlab computer to listen for any OSC commands on port 8000 that look like /eos/out/event/cue/1/<cue number>/fire and then convert them to the format /cue/<cue number>/start, and then re-broadcast those commands to the localhost IP address (127.0.0.1) on port 53000 (which is the port that Qlab listens on).

Remember to click the Apply button

Check out the OSCRouter documentation for more amazing features, and for more information about why we use /eos/cue/out/event/1/* for the incoming path, and /cue/%6/start for the outgoing path.

4) In Qlab, make sure that your settings for your workspace look like this:

5) You should be all set!  When you fire a cue from Eos, double check that OSCRouter is making the conversion correctly.  It should look something like this:




[locked by: Seth Starr at 1:48 PM (GMT -5) on Tue, Jul 6 2021]
Parents
  • Question for the team, can oscrouter recognise wildcards at the beginning? */stop for example?
    Trying to setup qlab to panic the workspace when ion stop/back is pressed...

    Thanks!
  •  yes, OSCRouter does allow wildcards at the beginning.  I would use an incoming path of /eos/*/stop just to be safe, but */stop would work too.

    ~P

  • Thanks!
    I tried it, and wasn't successful, I think because EOS doesn't always send the same command when the stoo/back button is pushed... Any one have any thoughts on that?

  • Eos will always output "/eos/out/event/cue/-1/0/stop" when a cue is running and the [Stop/Back] button is pressed.  But in OSC terms, there is no difference between a backwards Go and a forwards Go.  Do you want the workspace to panic every time you back up a cue?  Or only when you Stop a running cue?

    Theoretically, it would be possible for Eos to output a command like "eos/out/event/cue/<cuelist number>/back", but that would be something that  and company would need to add.

  • Hi Guys,

    Thanks for the feedback; we will fix this :)

    RND 0031184: OSC - /eos/out/event/cue/<cue list number>/<cue number>/stop is reporting back as -1 instead of the cue number that is stopped
  • when the button is pushed, I'd think the console should output that the button was pushed, as well as, perhaps a second line, what actually occurred... but that's just me.

    what I'm trying to capture:
    cue 1 - lights up, projection go (5 sec fade)
    cue 2 - blackout, projection 2 go (0 sec fade)
    cue 3 - lights up, projection 3 go (5 sec fade)

    op double taps go, so we skip over cue 2, they back up... but projection can't follow, and we're looking at projection 3 possibly stacked on 2..

    ideally I'd panic the QLab workspace, to kill everything, then when cue 3 is fired again, we're back on track...

    I'm not sure if that's possible, but I'm trying to figure it out :-)

    Thanks for all the great stuff!
  • I suppose another way to put this... what happens if the cue is too short to stop? and is simply <back> is there both a <back> and a <stop> event generated for both events?
  • Hey Chris,

    It's sorta two separate issues.  First, when a cue list is stopped by pressing the [Stop/Back] button while one or more cues are running, Eos should probably send /eos/out/event/cue/<cue list number>/stop, and not send a cue number at all.  You're right that "-1" is definitely wrong!

    Second, a request:  When the [Stop/Back] button is pressed while a cue list is already Stopped, or when a cue list is not currently running a cue, could Eos send "/eos/out/event/cue/<cue list number>/back" in addition to "/eos/out/event/cue/<cue list number>/<cue number>/fire"

  • That right there would be absolutely superb, and cover both instances of the button usage.
Reply Children
Related