OSC Inconsistently Fires - From ION to OSCRouter to QLab(s)

Just to clarify what you are after:

When Eos triggers a cue it triggers both the Sound and Video QLab systems which run on different computers with the same number as the firing eos cue?

If so I would expect OSC Router to look like this:

Although the loop back address works I would be more inclined to use the specific IP Address of the Audio Mac machine.

I'm sure you're aware of QLab being able to send OSC messages directly from within the application. I would do that to send Eos the OSC messages from the Video Computer rather than going unnecessarily through OSC Router.

Thank you very much for the response!

"When Eos triggers a cue it triggers both the Sound and Video QLab systems which run on different computers with the same number as the firing eos cue?"

Yes, and 98% of the time, this setup works.

To clarify, the issue is that OSC Router doesn't always see the the needed "eos/out/event/cue/xx/yy/*" from out of the Ion. So both Q Lab machines don't fire at all when this happens.

The extra loop backs are so that the either Q Lab machine can trigger the Eos if desired without needing to type the strings out or copy and pasting. I'm not the only one who uses this system (sometimes overhire, sometimes interns), so for ease of use this allows the user to use a standard Q Lab OSC cue, and only have to enter the number of the cue they wish to trigger.

Thanks for letting me clarify!

-Jeff

After a bunch of troubleshooting, I've come to the conclusion I was having UDP transmission loss. The string OSC Router was looking for was "eos/out/event/cue/xx/yy," and this would not always be received by OSC Router. As far as I know the Ion does not support TCP OSC transmission, which would allow us to use a TCP server approach to have error checking to our two Q-Lab Machines. Our work flow at our venue is not served by having Q-Lab as the MASTER, which would allow us to use OSC Router as a TCP server with the ION being RX TCP capable.

It seems with either v2.3 or v2.4 of the Eos Family upgrade you can add output strings and utilize the {*} and {%1} variables. Using this feature seems to have guaranteed the output of a predictable string on every "GO." Here are my settings;

/cue/%1/start

 

I've used this feature for several shows now, and it seems to have stabilized OSC. I still use OSC Router as an OSC Repeater given our multiple Q Lab Machines, but If you're only using a single Q Lab machine you shouldn't need OSC Router at all.

 

Hope this helps anyone with a similar problem!

Eos family does do OSC TCP. TCP port 3032 is the port for EOS TCP based OSC. There are settings in OSCRouter for TCP as well.

The literature on the Eos family I've read imply that this was for TX out of the Eos only. However as I write this down, and TCP being two way in nature, that logic of mine seems flawed. Thank you for pointing this out, I shall experiment further. When setting this up, do I use port 3032 for both transmit and recieve?

Best,

-Jeff

Jeff,

TCP does not need port settings in the Eos software. It is setup in the shell and is either OSC 1.0 or 1.1 which changes the encoding of the messages but not the port settings. TCP does not use multiple ports just the one. The port settings in the eos show control section are for UDP only.

Andrew,

Thanks for clarifying. I'm traveling until after the holidays, but will be sure to implement thesis changes to TCP. It was this portion that confused me in the "Eos Family Show Control User Manual."

From page 47

TCP

The preferred method for transmitting and receiving OSC packets is over a TCP connection. Eos will listen for incoming TCP connections on Port 3032. TCP communication still requires that {String RX} and {String TX} is enabled in the Show Control section of Setup.

In the ECU>Settings>Network>Interface Protocols, there is an option for changing the OSC TCP mode. By default, OSC 1.0 is selected. There are two TCP modes available – OSC 1.0 (packet-length headers) and OSC 1.1 (SLIP). Check the documentation for the OSC device you wish to use over a TCP connection to see which mode it supports.

 

It was the line "Eos will listen for incoming TCP connections on Port 3032," that threw me, because it doesn't list what port number is used for transmitting. Feeling foolish now, but at the time I took this to mean the EOS wasn't capable of transmitting TCP. I wish the line read "Eos will listen for incoming and transmit TCP connections on Port 3032."

Thank you for taking the extra time to explain this - lesson learned.

-Jeff

Eos acts only as a Server for TCP connections.

You can't establish a TCP connection from Eos, acting as a Client, meaning that Eos only listens and responds on the same port that a connection made to it. Transmit would infer a connection could be established via Eos.

Sam,

Thanks for responding. It may be still UDP, but for some reason the system has been much more stable using port 3032 to TX from the Eos. It has also been RX on 3032, from Q Lab via OSCRouter. I'll post my screenshot of OSCRouter later today.

I know this must feel like to you I'm coming at this a$$-backwards as I learn about different connections in the transport layer. However, learning more about networking has be a interesting and enlightening experience as I try to read and understand what's going on. Thank you for your patience.

-Jeff

I have another blog post coming out in the next week or two regarding UDP and TCP. Keep an eye out on the ETC Blog (https://blog.etcconnect.com/)

That post is now available here: blog.etcconnect.com/.../

Thanks! I'll check it out!