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 Reply Children
  • Change your incoming path to /eos/out/event/cue/1/*

    The * will match any event that starts with "/eos/out/event/cue/1/" so you don't need the "fire"

  • Got it, by leaving the incoming IP field blank. Looks like the app can't both receive and transmit with hard links to 127.0.0.1
  • That's likely a bug... we'll see what  says.  Leaving the IP field blank should do exactly the same thing as using the localhost IP address, yeah?

    ~P

  • Also it seems like the Router is preventing other messages from getting through (such as direct Qlab next cue/last cue controls) do I need to define each of those commands now that Router is in place?
  • Yeah what's happening is you are transmitting all of your OSC commands on port 5000 now, so everything is ending up in OSCRouter.  If OSCRouter doesn't know to forward something, the command just dies.

    Set up another line with empty paths, and OSCRouter will forward all incoming OSC packets to port 53000

    Here are some other examples that Chris made to show the things that OSCRouter can do:

  • Thank you both!  There was definitely a bug there on the Mac side.

    All fixed in v0.2:

    https://github.com/ElectronicTheatreControlsLabs/OSCRouter/releases/

  • Hmm okay so now have this up and running on a show, cues mapping fine, however now that I've created an OSCrouter hardlink for the "Panic" command for the light board op, OSCrouter double-receives every packet...is this bad?
  • Are you seeing double input in OSCRouter (light red text in the log), or double output to Qlab (green text in the log)?

    When I test this on my computer with a "Go" command from Eos, I see:

    The OSC Packet arriving:  [ 12:02:29 ]  IN  [10.0.1.101:8000] [OSC Packet] /eos/out/event/cue/1/2/fire
    The new OSC packet leaving: [ 12:02:29 ]  OUT [10.0.1.101:53000] [OSC Packet] /cue/1/start
    And a duplicate of the original command leaving: [ 12:02:29 ]  OUT [10.0.1.101:53000] [OSC Packet] /eos/out/event/cue/1/2/fire

    Of course I see a bunch of other stuff entering and leaving too... which I don't much care about since QLab will ignore any OSC commands it doesn't understand.

    EDIT: I should say, it's definitely a bad thing to be sending duplicate packets to QLab *if* those duplicate packets contain commands that QLab understands.  You don't want duplicate packets separated by a few milliseconds arriving in QLab, because you'll end up with stuttering video and audio, unnecessary resource usage on your QLab machine, and general unpredictability as QLab tries to trigger every action twice.

    Chris it might be worth thinking about a way to order and group rules together in OSCRouter so an incoming packet can only trigger the first rule in a group that the packet matches

  • I am away from the venue right now and forgot to copy the screenshot over last night. I was seeing double OSC packets arriving (light red text), since by adding the hardlink (in addition to the cue number re-route), I was opening another OSC socket into the App. Maybe this doesn't matter, but wondering if there is a more efficient way to conditionally route the OSC strings once they enter the router, more like "if/then" logic as opposed to multiple "ifs"?
  • Interesting. Yeah definitely post a screenshot when you are able. I'm not seeing that on my computer in my office now. Also post if you're using the new 0.2 version that Chris posted.
  • Hi Chris & Paul

    I used this today for the first.

    Chris brilliant as always with these bonus apps!

    Paul great post it took me less then a minute to setup.

    Thanks
Related