TCP to Eos

95 views
Skip to first unread message

Brendan

unread,
Jun 28, 2024, 7:35:53 PM (6 days ago) Jun 28
to QLab
I'm curious if anything has changed in the last 18 months allowing Qlab to initiate a TCP connection to ETC Eos software.

The last time I tried to trigger an Eos with OSC I had a lot of trouble with intermittent missed cues, and it seemed like the source of this was occasionally dropped UDP packets. At the time, though both platforms supported TCP, the official documentation from ETC stated to use UDP as "neither platform can initiate the TCP connection."

I am working on a project now where I'm being told TCP now works, but I can't find anything in a Qlab changelog or ETC documentation that would indicate so I'm skeptical. What are folks' experience these days?

Richard Williamson

unread,
Jun 28, 2024, 8:11:33 PM (6 days ago) Jun 28
to ql...@googlegroups.com
Sadly - unless heads have been banged together - neither etc or qlab have built the capacity to connect to another TCP server (both are always servers), ideally qlab or etc would offer the ability to act as a tcp client which would solve this pain 

Sent from my iPhone

On 29 Jun 2024, at 08:35, Brendan <baa...@gmail.com> wrote:

I'm curious if anything has changed in the last 18 months allowing Qlab to initiate a TCP connection to ETC Eos software.

The last time I tried to trigger an Eos with OSC I had a lot of trouble with intermittent missed cues, and it seemed like the source of this was occasionally dropped UDP packets. At the time, though both platforms supported TCP, the official documentation from ETC stated to use UDP as "neither platform can initiate the TCP connection."

I am working on a project now where I'm being told TCP now works, but I can't find anything in a Qlab changelog or ETC documentation that would indicate so I'm skeptical. What are folks' experience these days?

--
Contact support anytime: sup...@figure53.com
Follow QLab on Threads: https://threads.net/@QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
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/76acd6e2-5bfb-4e0b-a813-965f5445b2b6n%40googlegroups.com.

Ethan White

unread,
Jun 29, 2024, 12:48:28 AM (6 days ago) Jun 29
to QLab
Hi Brendan,

Yes! QLab 5 can act as a TCP client to connect out to an Eos console to trigger it via OSC. On the QLab side, all you need to do is set up a network patch with the "ETC Eos family" type and select TCP. I've attached a photo for your reference. You will then need to configure your Eos console to accept TCP OSC on that port. At this time Eos still is only a TCP server so the other direction (Eos triggering QLab over TCP) still requires some additional setup.

Thanks,
Ethan
QLab Developer
QLabTriggerEosOSC.png

Richard Williamson

unread,
Jun 29, 2024, 2:32:41 AM (6 days ago) Jun 29
to QLab
Ah apologies - I realised the issue I have previously faced (which still appears to be there) is that while QLab acts as a client and connects to Eos, it does not then act on the OSC received through that network patch. Although ETC is sending the requested data out via TCP there still appears to be no way to control QLab from Eos via TCP OSC without using some kind of middle-ware. Which to my mind is really silly and (since the TCP functionality is now there) also massively frustrating. 

Since this is something that is so massively used in the industry, and UDP has caused many significant issues in shows I do feel that ETC and F53 need to sort this out somehow. At the least QLab should have the option to accept incoming commands from a network patch which would solve the problem straight away.

--

Brendan Aanes

unread,
Jun 29, 2024, 7:08:26 AM (6 days ago) Jun 29
to ql...@googlegroups.com
Thanks Ethan! That is very helpful and now I understand the confusion around this issue. 

Brendan Aanes

unread,
Jun 29, 2024, 8:52:59 AM (6 days ago) Jun 29
to ql...@googlegroups.com
One other question- are outgoing messages over TCP using OSC 1.1 or 1.0?

Chris Ashworth

unread,
Jun 29, 2024, 9:05:16 AM (6 days ago) Jun 29
to Brendan Aanes, ql...@googlegroups.com
v5 offers some OSC 1.1 arguments:

\T is a boolean true.
\F is a boolean false.
\I is an impulse.
\N is a Null.

Christopher Ashworth

unread,
Jun 29, 2024, 11:00:38 AM (6 days ago) Jun 29
to ql...@googlegroups.com
Hi Richard,

At present QLab closes the TCP connection it establishes shortly after it no longer has more messages to send, although this is certainly something that could be adjusted.

Can you say more about what messages you expect ETC to be sending on a new client connection and how you expect QLab to react to those messages?

C

(mobile)

On Jun 29, 2024, at 2:32 AM, Richard Williamson <ric...@theatre.support> wrote:



Richard Williamson

unread,
Jun 29, 2024, 12:21:49 PM (6 days ago) Jun 29
to ql...@googlegroups.com
A (very) common use case is for Eos to fire qlab, eos has the ‘send string’ feature which allows you to define a dynamic osc message to send on every go. So generally people set it to /cue/%1/go which replaces the %1 with the cue number fired, meaning you can very quickly programme qlab to follow along to eos with little faff. 

At the moment this only however works with UDP - which can be unreliable (a problem which has been discussed much before) and so there is a danger of cues being lost - I’ve had this happen mid show more than once 

Currently the fix is to put oscRouter or similar in the middle - this then acts as a TCP client to both qlab and eos and bounces messages between the two. But adds more complexity and another point of failure to the mix 

Ideally between f53 and ETC a decent solution would be agreed that avoided middleware and allowed TCP to be the communication format 

Sent from my iPhone

On 30 Jun 2024, at 00:00, Christopher Ashworth <ch...@figure53.com> wrote:

Hi Richard,
--
Contact support anytime: sup...@figure53.com
Follow QLab on Threads: https://threads.net/@QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
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.

Christopher Ashworth

unread,
Jun 29, 2024, 12:57:15 PM (6 days ago) Jun 29
to ql...@googlegroups.com
Makes sense! 

Although that sounds like something I would expect to be configured on the EOS side, as the UDP version is, so the sender knows to whom and how it is sending messages, rather than just sending messages to any anonymous clients if they happen to connect. Seems like a feature request to ETC.

(mobile)

On Jun 29, 2024, at 12:21 PM, Richard Williamson <ric...@theatre.support> wrote:

A (very) common use case is for Eos to fire qlab, eos has the ‘send string’ feature which allows you to define a dynamic osc message to send on every go. So generally people set it to /cue/%1/go which replaces the %1 with the cue number fired, meaning you can very quickly programme qlab to follow along to eos with little faff. 

Mike Post

unread,
Jun 29, 2024, 1:11:03 PM (6 days ago) Jun 29
to 'Rich Walsh' via QLab
EOS software lets you configure to either TCP/IP or UDP but like Richard, I’ve never managed to get the TCP link to work.  I always assumed it was something on ETC’s end. 

Sam’s solution to get EOS to shut up sending random OSC messages all the time seems to have helped with UDP, but it’s always a “wait and see” game.

--
Contact support anytime: sup...@figure53.com
Follow QLab on Threads: https://threads.net/@QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
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.
Reply all
Reply to author
Forward
0 new messages