Network Time Code to Eos from QLab?

[John Huntington-Zircon]

There's been a desire over many years for a standardized way to send SMPTE-like time code over a network (in fact we did a whole "geekout" on this back in 2019 https://www.controlgeek.net/blog/2019/6/29/controlgeeknettimberspring-orlando-2019-time-code-geekout-wrapup) 

A bunch of work was done by a group of people (including Figure 53) on standardized ways to do this, but none of that has come to fruition yet in a standardized way.  

I'm doing a little live show control demo at USITT connecting QLab and Eos.  Right now for testing/demo I bought a couple little MIDI interfaces and am sending MTC since I don't have the ETC Response SMPTE Gateway.  

Have people found a solid way to send time code from QLab into Eos over the network without going to physical LTC or MTC?  RTP MIDI or something like that?

Thanks!

John

[Paul]

What's wrong with using the ETC Response gateway? (apart from the cost). Or using MIDI connection;  older and larger consoles have a MIDI port and on others you can use a suitable USB-MIDI adapter.

Because EOS runs on an embedded version of Windows it cannot support anything that doesn't have drivers build in by the manufacturer (including rtpMIDI). Unlikely that ETC would ever consider this as it would undermine its response gateway sales.

These days most people use OSC into EOS for time triggered cues; and it is much easier to adjust timing in QLab that in EOS Events.

[Richard Williamson]

I for one would love to see ETC/F53 impletement the artnet timecode spec - while not widely supported it looks like quite a simple solution to the problem

 

While it is true that it’s easy enough to get all the bits to make TC work, it is extra stuff, extra costs, extra connectors to not be plugged in etc etc. 

 

Richard 

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

--
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
TikTok: https://www.tiktok.com/@QLab.app
Bluesky: https://bsky.app/profile/qlab.app
---
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 visit https://groups.google.com/d/msgid/qlab/140a6a44-4969-4e29-8949-e4e1639061fen%40googlegroups.com.

[Paul]

While using timecode requires extra cables and set up, there can be some benefit in having distinct systems and cables - makes for easier diagnosis.

The feature request needs to go to ETC (this being a QLab forum) and it would be up to them to development the software.

Indeed you might observe ETC has already done the development! in as much as the Response Timecode gateway communicates to the desk via network.

 

Now it may be possible to hack that protocol and then write some software that generates the packets representing the timecode that EOS expects. It is probably fairly simple protocol, the only obstacle might be if there was some certificate/key EOS expects from the Gateway in the initialisation process, which could not be reproduced in other software. 

However doing this this would  probably be a breach of term of use and cause lawyers to get involved.  The problem is not a technical one but a commercial / legal one; ETC is a commercial company and while I'm sure their gateways are a small part of their sales they would not want to do it.

[John Huntington-Zircon]

On Saturday, February 28, 2026 at 6:56:02 AM UTC-5 Paul wrote:

What's wrong with using the ETC Response gateway? 

I'm just doing this for a test so I didn't want to spend $800 for a gateway :-)  For a show, absolutely.

John