Hey all,
I'm having a issue where OSC works inconsistently. From time to time, OSCRouter doesn't get the string it's looking for (the crucial "eos/out/event/cue/xx/yy). The best we've been able to reproduce this is by waiting longer than 5 minutes before firing the next light cues, causing the next OSC lined cue to not fire (lights fire, but Q Lab doesn't fire). Even this is not consistent.
I've attached a log file from OSCRouter, and scroll all the way to the bottom. The time code 21:15:54 is where OSCRouter failed to receive cue 7 in this case
Cue 7 didn't fire.txt
A bit about our system. We're a small performing arts center, and this is in our main theatre.
The OSC Signal path is;
ION -> Q Lab Audio Computer - > Q Lab Video Computer
I'm using OSCRouter on both Macs, running Sierra and Q Lab 3.2.9, as OSC Translation. I've attached Screen shots of both OSC router setups.
All of these devices are on a stand-alone network dubbed "ShowNet." It is managed by a Luxul XWR1750 gigabyte wireless Router, but all the lines are cat5e with a 16 port gigabyte network switch. The wireless is for our iPad only.
ShowNet has all of our show related computers, lighting gear (Console, DMX nodes, & Dimmer Racks), Network Switches and 5 Projectors. Its about +25 devices on the network.
My working theory is that we have too many devices on ShowNet, and it is causing issues with UDP transmission. I would hate for this theory to be true, since it's fantastic to have all our devices on ShowNet.
Thank you all for any help or ideas you may have.
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.
In reply to Sammy:
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!
In reply to dorfman2:
In reply to Druuka:
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.
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