• Date
    Paul Toben
  • Date
  • Locked Locked
  • Replies 62 replies
  • Subscribers 99 subscribers
  • Views 166742 views
  • Users 0 members are here
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]
  • in reply to ldsfx

    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

  • in reply to Paul Toben
    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"?
  • in reply to ldsfx
    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.
  • 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!
  • Hey Paul,

    I'm just beginning with this, so I have a few basic questions.
    I've set up both machines as you specified in your post. When you have OSC/String enabled, does the cue automatically fire the OSC command to QLab? Basically, where do I type the OSC commands on the light board if I need to? Or does firing, say, Cue 2 on the Ion automatically fire Cue 2 on QLab with OSC/String enabled?
  • in reply to sprsndman

     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

  • in reply to Paul Toben

    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?

  • in reply to ayersjs

     There is a long list of OSC commands that the primary device on an Eos network will always output.  All of these implicit commands are all prefaced by "/eos/out/" and they are sent whenever String Tx is enabled.  So in your example, if your Ion is sitting in Cue 1, and you press [Go], it will automatically output an OSC command that looks like "/eos/out/event/cue/1/2/fire" (it will also output a whole bunch of other stuff too... you can see it all in the logs of OSCRouter).

    Since Qlab doesn't know what to do with "/eos/out/event/cue/1/2/fire", you need to use OSCRouter to translate "/eos/out/event/cue/1/2/fire" to "/cue/2/start".  That process is outlined in my first post.

    However, Eos is also capable of outputting *explicit* OSC commands.  If you don't want to mess around with OSCRouter, and you just need to trigger a handful of cues or commands in Qlab, you can do that by selecting an Eos cue and typing {Execute}{String} and typing "/cue/2/start".  Set your OSC Tx Port to 53000, and every time Eos plays back your cue, it will also send "/cue/2/start".

  • in reply to sprsndman

    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.

  • in reply to Paul Toben
    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
  • in reply to Paul Toben
    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!
  • in reply to sprsndman
    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?
  • in reply to miz

    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"

  • in reply to Paul Toben
    That right there would be absolutely superb, and cover both instances of the button usage.
  • in reply to sprsndman
    Got it Paul, updating the SCR...
Related

www.etcconnect.com