OSC "Tally lights" feature

[Marcel Gavalier]

Please add "tally lights" broadcasting over OSC, if its is possible.

I wrote and build HW tally lights on arduino, and its works on blackmagic atems, but new "overview screen" in OBS is last thing what i missing to use OBS like stand alone mixing console.

So, i think, when you add broadcast OSC messages for tally purpose, i think i can build HW lights using OBS studio.

Thank you for you work!

 

[superlou]

I was looking to build a portable tally light system using inexpensive WiFi devices. The functionality needed on the OBS side can be implemented via the Lua scripting interface. It provides all of the hooks needed to recognize which sources are active.

 

[Marcel Gavalier]

Industry standard is UDP stream to broadcast all devices in network. Most popular manufacturers use their own protocol (like blackmagic) but using OSC protocol is opensource and easy to implement. All of needed is implement UDP broadcting with message like "/Sources/1-8/Tally/0-2" (0 off, 1 green, 2 red)

 

[superlou]

Are you referring to Open Sound Control? I'm not familiar with it but that seems like a reasonable protocol. Essentially, each tally light is a basic HTTP server that can accept UDP messages? Does the protocol cover a handshake to make sure that the UDP message is received? Can you link that part of the spec that covers tally messages?

So on the OBS side, it would need to know the IP of each tally light, and which OBS source maps to which tally light ID?

 

[Marcel Gavalier]

Are you referring to Open Sound Control? I'm not familiar with it but that seems like a reasonable protocol

Yes Open Sound Control. It is very easy to use and simpy to understand, use google to handle it.

Essentially, each tally light is a basic HTTP server that can accept UDP messages? Does the protocol cover a handshake to make sure that the UDP message is received? Can you link that part of the spec that covers tally messages?

OSC is so simply that handshake is not necessary. But in general some "formal" handshakes are used in many cases. If you thinking about http clients than yes, you can use any http client to handle udp messages, server is needed only one. You can imagine this: you have one server (simple http or apache or nginx or whatever) and clients like internet browsers and you can handle everithing. I wrote in past some mobile friendly webapps to handle tally on smartphone (open safari, type ip address of server and woala)

So on the OBS side, it would need to know the IP of each tally light, and which OBS source maps to which tally light ID?

No UDP is unicast, so everthink on network can recieve messages, OBS send messages blind. No answer is needed. And clients who listnen on defined UDP port catch theese messages and decide what is to do with this message.

 

[superlou]

Marcel, do you mean UDP "broadcast?"

It does not look like the OSC protocol has been maintained since 2009, and the "most accurate document" describing version 1.1 is a broken link. I'm not sure that UDP is a great solution where messages need to be delivered reliably. For something like a tally light, you don't need high bandwidth, but you do need to guarantee that the message is received. I don't believe the additional TCP overhead will be significant on a local network. Alternatively, you could continuously send messages which might be useful anyway so that the remote tallys can indicate if they've lost communication with the OBS system.

 

[Marcel Gavalier]

Superlou,

When you send message to one exact IP it is unicast, when you send to more IPs, its mutlicast and wher u use 255 as end of IP, this means broadcast.

In general mutlicast is used as well, (yes some formal handshaking to server ip like "Are you there? Send me your ID") and when server respond with message "My id is 123123213213" this means "very easy handshaking". Server store IP on "client list" and Client send every few seconds "handshake" message to determine working conecction.

OSC is not "industry standard" OSC was designed as userfriendly quick to understand and quick to implement "comunication" protocol, as new level of MIDI.

Many manufacturers use OSC to "remote apps" or remote controling, or messaging, (see touchOSC). We have DIGICO S21 mixing console and she use OSC to surface control (OSC over UDP, multicast).

We have many devices from Blackmagic design (industry standard video hw) like ATEMs. But atems use their own protocol (custom messages over UDP, multicast).

When OSC use own custom UDP messages, nothing worng. Every udp client can read it (when protocol will be documented and public), or OBS can use osc messaging to "cominiation" and YOU and ME and EVERY(dummy)BODY can use simple OSC client (like touch osc). And create tally lights will be super easy and fast to implement (for me, you and every clients).

My own tally client based on arduino works very well for 2 years! Without any troubles or glitch! Is used on live production for 8 cameras and it is udp multicast.

Can you use DMX (light protocol). This is blind protocol too, no returns, server have no idea what happens with message. In header on message is described for which client was this message sended. (DMX address) and every in a network who have this dmx address can act as one.

 

[Marcel Gavalier]

http://tally.gavalier.sk/

 

[darioluzuriaga]

Almost one year later, was anybody able to create a Lua script that sends some signal when a particular scene is in the program output? Thanks.