Read Tally Status with an Arduino

[Wilts01]

Is there a way of reading the Tally Status from atemOSC using an Arduino? It would seem possible to do this via the /atem/send-status/mix-effect-block command but being a real novice on OSC I am failing to work out how do this. Are there any pointers on how to do it? I have so far failed to work out how to even read the return from that command from a proper computer, let alone an Arduino.

In terms of background, I have been using this code to read the tally status https://oneguyoneblog.com/2020/06/13/tally-light-esp32-for-blackmagic-atem-switcher/

it works fine on our ATEM Television Studio HD but we have just got an ATEM Television Studio Pro 4K and I'm guessing that the SKAARHOJ Arduino libraries are out of date. Hence noting that there are OSC libraries for the Arduino, I figured that I could use atemOSC instead.

So pointers to some helpful information would be greatly appreciated.

Thanks

Paul

[ruebyi]

Hmm, I’m using tally arbiter for that. this one fetches the tally status and sends back an OSC Command to my midi mixer in Osculator and sends out the tally status to my m5Stick C for tally arbiter.

i Hope this is helpful for you

[SteffeyDev]

@Wilts01 If you enter the IP address of your Arduino as the OSC Out IP Address and listen on the OSC outgoing port, you will receive a message every time the program is changed. The message will have an address of /atem/program and an integer value that is the camera number that is now live. You will also receive a message in the form /atem/program/#, where # is camera number (in case this format is easier to parse).

[Wilts01]

Thanks. That's really helpful. Can you get the preview information in the same fashion?

[SteffeyDev]

Yep, it's identical to program except with the address /atem/preview

[SteffeyDev]

Though now that I'm looking at the code, there seems to be a bug. Oops! So for now, every time the program changes, you'll receive two messages per input. The first will be /atem/program/# (where # is the camera number) with a float value of either 1.0 (meaning the camera is live), or 0.0 (camera not live). Use that message for tally lights. The second message message will just be /atem/program with the camera number in the value, but no indication of whether that camera is live! Ignore those messages until I fix that bug, it should somehow indicate which camera is live in that format as well but doesn't right now.

[Wilts01]

Thanks again for the updates. I've implemented some code using CNMAT/OSC on an ESP32 to get the the /atem/program/# messages from atemOSC as UDP messages and have successfully parsed the program status for my Tally Lights. The problem I have is that my software does not appear to be able to keep up with the flood of 96 UDP packets that appear every time I press cut on my ATEM TV Studio HD. I did look at using the /atem/send-status/mix-effect-block function but atemOSC says "OSC endpoint not implemented for /mix-effect-block". Suggestions as to how I might speed things up would be appreciated! Thanks

[SteffeyDev]

That's strange, what do you mean by "not able to keep up with the flood"? What are you seeing? Given how fast networks and systems are these days, I'd be surprised if it can't handle 100 of anything relatively quickly. But then again, I'm not sure what kind of specs you are working with.

[Wilts01]

Thanks a lot for your quick response. I'm using an ESP32 board programmed using the Arduino library over WiFi. I've tried a couple of different OSC libraries now and get similar results - basically it ends up missing some of the UDP packets. I've also looked at some different solutions and I think I am going to use atemOSC to control the ATEM but use Tally Arbiter to produce OSC message just on the status of the few inputs I am interested in. A quick experiment shows that this works well for me with no missed transitions.
Thanks again for your support - all the best for 2021.

[SteffeyDev]

Ah missed packets, I see. I wonder why you are getting 96 packets, it should only be sending 2 packets per input. How many inputs do you have? I'll definitely keep that in mind, and maybe have an option in future versions to send fewer packets if you don't want TouchOSC support.

[SteffeyDev]

Another thing I've done the in the past is deliberately spacing out the packets by putting in an artificial delay, I could try to do that more conservatively for the program/preview status messages and I bet it would fix the issues.

[Wilts01]

I used WireShark to inspect what was going on. Basically every time I press either Cut or Auto I get packets from every single possible input on the ATEM first at program and then as preview. For example Packet# Message 1 Message: /atem/program/0 ,f 2 Message: /atem/program ,i 3 Message: /atem/program/1 ,f 4 Message: /atem/program ,i 5 Message: /atem/program/2 ,f 6 Message: /atem/program ,i 7 Message: /atem/program/3 ,f ....... 19 Message: /atem/program/1000 ,f 20 Message: /atem/program ,i 21 Message: /atem/program/2001 ,f 22 Message: /atem/program ,i 23 Message: /atem/program/2002 ,f ..... 49 Message: /atem/preview/0 ,f 50 Message: /atem/preview ,i 51 Message: /atem/preview/1 ,f ...... 95 Message: /atem/preview/10011 ,f 96 Message: /atem/preview ,i

As you can see, a fair number of them!
Yes a delay would probably help but then having less of them would also be good! I typically found that my tally lights could keep up with switching between inputs 1 and 2 but would struggle with input 3 implying some packet's going astray.

Hopes this helps

[SteffeyDev]

This is really good info, thanks! I forgot that the media players are considered inputs, and that we send both program and preview. Obviously there is still the bug where it sends a bunch of useless messages that is not helping. What is the minimum number of packets you would need for a tally system? If I implemented a feature that sent out messages only for tally purposes, what messages would you want for each change?

[Wilts01]

In an ideal world, one packet for the input on programme and one for the input on preview. So perhaps something like: /atem/programtally, int where the int would be the number of the input on programme /atem/previewtally, int where the int would be the number of the input on preview

Ideally this would could change on either cut, auto or if the preview input was updated. Clearly this is just an option but hopefully you get the drift. If you want it simpler then just considering the 8 real inputs would be sufficient - you are unlikely to put a tally light on a media player for example.

[Wilts01]

It would also be helpful it these packets went to a different port so that the Arduino can ignore them.

[sneat]

It’s worth noting that you can have multiple inputs live (or in preview) at the same time. For instance with a DSK or USK etc. So a single value send won’t be enough.

[Wilts01]

Thanks - wasn't aware of that. However, for discrete tally lights that would end up on cameras, I would have thought that just know the status of the 8 real inputs would be enough.

[sneat]

Yeh, the difficulty is what should you send if you are showing picture in picture of two cameras?

[Wilts01]

Ooh, interesting corner case! I can see the problem clearly now. Perhaps the message should be a list of camera numbers then. Processing one longer message is a lot easier than processing many of them.

[SteffeyDev]

Ok, I think you are right, a single OSC message with the address of /atem/preview and value of a list of integers, one for each active camera & USK seems the best option for me. Same for preview. Then, I can just allow you to toggle off the TouchOSC-style output messages and you should be able to get the tally messages consistently

[jeffreylsoffer]

Definitely interested in this! I think one option would be to have an option to change atemOSC's output to match what Tally Arbiter's OSC input is expecting. That way, the arduino M5StickC implementation is already done. However, a more custom program that accepts the simple /atem/program integer value could also work.

[Christoph111]

hi there, would be great to have osc messages to feed tallyArbiter since i don´t like another device/app block one of the only 5 connections of the atem mini. actually i programmed an m5 atom matrix to listen to OSC commands for tally lights, in this case you would not even need tallyArbiter. if someone can develop atemOSC for tally this would be great, at this point if you don´t cut but make a eg. 1sec transition, no tally change is sent out (only that t-bar is moving), so using the the bmd tally logic would be necessary. for me i don´t need any feedback coming back from the tally light, so using .255 for broadcasting is just fine.

tally arbiter OSC expects: /tally/preview_on <#input number> /tally/preview_off <#input number> /tally/program_on <#input number> /tally/program_off <#input number>

also possible (but really necessary?): /tally/previewprogram_on <#input number> /tally/previewprogram_off <#input number>

i tried to do this with osculator, but it´s really not working since so many commands are sent....

[Christoph111]

any news on that? if someone can give me some tips where to edit code i really would love to try to contribute. since this project is way bigger than usual, it might be beyond my skills but i would give it a try may be you can use code from here: https://github.com/scebbers/ATEM-WebTally/blob/master/ATEM%20WebTally/switcherCallbacks.cs

[SteffeyDev]

@Christoph111 if you are up for it, feel free to try to implement and reach out if you need some help. I have a lot going on in my life right now so don't have time to work on this project unfortunately, but could probably point you in the right direction if you get stuck. Would love to see some people who use atemOSC on a regular basis be able to contribute and keep things going.

[SteffeyDev]

I've released a new major version, which should fix the sending useless messages bug. If there's still more needed for any of this, open a support request at www.atemosc.com/support and we can discuss it more over email.