OSC issues

[Mike Post]

Hi again all,

I’m having an intermittent problem with OSC commands from an ETC Ion console triggering specific cues by number on QLab. It seems to work just fine for the most part but once in a while, a GO from the Ion will not trigger the cue on QLab. There’s much speculation about what may be causing this, maybe a specific cue, maybe a wiring problem… None of this is proving conclusive in my mind, so I wanted to ask here if anyone has run into this and has any idea what might cause a failed OSC GO.

I’ve looked at the console log but couldn’t see anything that jumped out to me as a problem at the time of the execution. Not that I’m an expert, but I would at least expect to see some sort of network error…? Yes?

The Ion is at the latest rev of the software and QLab is running at the latest version of 3 before V4 came out. Any comments would be appreciated.

Mike Post
mdp...@mac.com
http://mdpostdesign.com
(601) 307-8657

[Chris Ashworth]

Hi Mike,

As a debugging option, it might help to turn on some logging to look for confirmation that QLab believed the cues were triggered, and then compare that to what cues didn’t actually happen.

I don’t think you’re using v4 yet, but if you are, you can do that in the new status window by going to the logs tab and enabling logs for cue triggers.

Alternately, you can set log level 2 in the application preferences and it will log when cues start in the console logs.

If you see a cue show up in those logs that doesn’t fire, that would suggest to me that the message is getting lost somewhere in route, somehow….

-C

[Mike P]

Thanks Chris but I think that tests the wrong case. It's not QLab sending OSC. It's cues in QLab that are set to trigger off an OSC message from the Ion. I suspect the Ion is the culprit  but not sure what to look for. Is there an OSC sniffer for a Mac like I have for MIDI?

Sent from my iPhone

[richardm]

Hi Mike

I can't offer any great insight but i saw the exact same thing happen last night..This was an ETC Ti triggering QLab via OSC using numbered cues. I'd say of a couple of hundred cues fired, 2 did not reach Qlab.

I didnt have chance to really dig into the system set up but the OSC messages were passing through ETCs OSCRouter software on the QLab machine.  The OSCRouter log showed the cue arriving from the lighting console and being forwarded to Qlab. The console wasn't the problem i dont think (and the cues fired correctly after the show) so the packet seemed to get lost on a local socket .

This was an old version of QLab too - 3.1.2 i believe

Not much to go on i know but hope that's some use to you..I'm off the show now or i'd do some more digging..

 

richard 

[Mike Post]

Thanks Richard,

Actually, that gives me exactly what I need in the short term.  I don’t have there wherewithal to really diagnose this issue, but it does give me a means to test the overall reliability of the OSC link triggering QLab so I can decide what I’ll allow in our space.  I still feel confident from personal experience QLab triggering other devices via MIDI is quite reliable - been doing that for years.  But if I know there’s something intermittent in an OSC message successfully triggering QLab and can prove it, I can keep that scheme from messing up my shows.  Knowing about OSCRouter gives me that tool and I think I own just enough computer to mock it up without compromising my current show.  Thanks for that.

I don’t have much experience with QLab using OSC to trigger other devices but I know people who do and have never heard of any intermittent problems so I tend to think that’s a reliable scheme.  QLab seems to win out for reliability in most cases ;-)

The scenario you describe doesn’t point a finger at anything specific within the Mac for me.  We know it's received by the Mac, but once there I feel like the problem could be either in QLab or a failure in something low level between QLab and whatever the Mac does to pass OSC messages along.  I leave it to wiser heads than mine to figure out that puzzle...

Mike Post

mdp...@mac.com

http://mdpostdesign.com

(601) 307-8657

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/723a72ad-3442-41c6-b3fd-fab2cc4771b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Ashworth]

Hi Mike,

Ah, sorry to have misunderstood the direction messages were going.

I can't check just at this moment but I'm pretty sure log level 2 will log what incoming osc QLab sees into the console, and version 4 has a new built in OSC log for the same purpose.

Also worth mentioning at this juncture that since most OSC travels via UDP, and UDP is a protocol that is "fire and forget" that the design and construction of the network the messages are traveling over becomes more important --- I know you know that already but for the benefit of others reading, this is one of many reasons to build a dedicated show control network that's disconnected from other networks.

P.s.: "the best thing about a UDP joke is that I don't care if you get it"

(mobile)

[Mike Post]

Thanks Chris!

That does keep the net topology in mind.  It’s a closed system as you suggest, but it does rely on an older Apple hotspot as a hub which could also be the culprit.  The link between the machines is Cat5 through the hub - another point of failure.  I need a hotspot on the Ion for other reasons but I can use OSCRouter to check that out once this show comes down.

P.s.: "the best thing about a UDP joke is that I don't care if you get it"

Love it…  Reminds me of a professor I had who was on the original Unix team from Berkeley.  I said something about Unix being ‘user-hostile’ on the friendly scale.  She replied Unix was neither user-hostile nor user-friendly.  It’s user-apathetic.  It couldn’t care less if it had users.

:-)

Mike Post

mdp...@mac.com

http://mdpostdesign.com

(601) 307-8657

On Dec 10, 2016, at 7:55 AM, Christopher Ashworth <ch...@figure53.com> wrote:

Hi Mike,

Ah, sorry to have misunderstood the direction messages were going.

I can't check just at this moment but I'm pretty sure log level 2 will log what incoming osc QLab sees into the console, and version 4 has a new built in OSC log for the same purpose.

Also worth mentioning at this juncture that since most OSC travels via UDP, and UDP is a protocol that is "fire and forget" that the design and construction of the network the messages are traveling over becomes more important --- I know you know that already but for the benefit of others reading, this is one of many reasons to build a dedicated show control network that's disconnected from other networks.

[richardm]

..what i really wanted to try was OSC over a TCP connection between EOS & QLab,  probably would have needed OSCRouter to act as client to both ends. ETC certainly say they  'prefer' that protocol for OSC in their set-up guides, but press night seemed the wrong time to be mucking about with such things

I'm going to see if i can re-create the set-up if i get time next week but as the API's been updated a fair bit in v4 it probably makes more sense to start there..

r