Controlling ATEM

This is a thread to discuss ways to control the ATEM. I have had some success in controlling the ATEM TVS from a midi controller, using bome's midi translator to convert the midi data to keystrokes. Using a controller with light up pads such as the novation launchpad alongside bome's you can have a set of buttons which emulate a proper broadcast switcher fairly well. The major disadvantage to this method is that the ATEM software panel must be the active application on the computer with the midi controller attached. This means you have to dedicate an entire machine to control and cannot use it to playback content or edit titles. There are also some issues from the keystrokes that are assigned in the software, and the fact that your limited to input switching rather than having access to the media players and keyers. It's a fairly promising start though and perhaps shows a glimpse of what could be done in the future when the SDK allows a more direct control route.

I plan to use the x-keys

I plan to use the x-keys stick , its totally programable her the link

AppleScript to control auto-switching with caps-lock key status

Hi all,
I have been working on some AppleScript to automate the switching.
But because I don't have a ATEM Television Studio (it is on the wish list) I am wondering if you guys could test it.
Save this to ATEM_Switch_Automate.applescript on your desktop
tell application "System Events"
do shell script ("~/Desktop/GetCurrentKeyModifiers")
set n to result as number
set _capslocked to n
if _capslocked is 1024 then
tell application "ATEM Software Control" to activate
repeat until _capslocked is 0
keystroke "1"
delay 7
keystroke "2"
delay 7
keystroke "3"
delay 7
keystroke "4"
delay 10
do shell script ("~/Desktop/GetCurrentKeyModifiers")
set n to result as number
set _capslocked to n
end repeat
end if
return 1
end tell

The AppleScript call for a C script that must be made to read the status of the Capslock key.
Please save the underlinening code to GetCurrentKeyModifiers.c on your Desktop.
#include <Carbon/Carbon.h>
int main (int argc, const char * argv[]) {
unsigned int m = GetCurrentKeyModifiers();
printf("%u", m);
return 0;
You will have to "build" this using your computer (yeah your first build :) !), open "" and do the following.
cd ~/Desktop
gcc -framework Carbon -o GetCurrentKeyModifiers GetCurrentKeyModifiers.c

If you have done all the above and than run the ATEM_Switch_Automate.applescript file you would be able to do automated switching if you start with the caps-lock key on. If you switch the caps-lock status to off then the auto switching will end.
I hope this works. If you want to change the video inputs or time delays then you can edit the ATEM_Switch_Automate.applescript file to your liking. Also the location of the GetCurrentKeyModifiers file can be changed there.

Follow me @Kjeld
Small screens big opportunities!

That apple script is very

That apple script is very interesting, i'll certainly test it for you in the week.

I've found an interesting option for control from an ipad / iphone which i will also try and get working in the next couple of days.

I have an interface working

I have an interface working on the iPhone to control the ATEM software, it can select inputs on both buses, cut and auto take. With some minor windows configuration I have got it to select the correct US keyboard layout so the shortcuts work properly.

It works, but i'm not sure i would want to use it on a real show, touch screens are not ideal for controlling video!

You can see the interface here

Code sharing

Hi Tom,

Any code you can share for this?

Follow me @Kjeld
Small screens big opportunities!

i'm using an app called

i'm using an app called hipporemote pro - i've created a custom profile for the atem software.

i will release my custom profile for people to use if they want. i need to tidy it up a bit and write a help file to explain how to set things up.

Very interested in this! A

Very interested in this!

A SDK or applescript would be great. I have background in both component level electronics and software development. A control surface of sorts that interface with software would be fairly easy. It would allow me to make a temporary (cheap) version of the broadcast panel.

If you look at the components in the broadcast panel, it's well worth the money. You actually would't save too much and it would be a beast to design. If you were willing to cut back on button quality, then you might be better off. Mainly, I would LOVE the ability to setup other keyboard shortcuts for other things. Effects, keyers, transitions, etc.

could >1 panel control 1 TVS in parallel?

first thing that came to my mind:

adding a dedicated controller box via LAN (once the SDK arrives, or at least the according protocol is made public), that has only a small set of most demanded hardware controls-
to give you immediate access where it is critical.

All the rest of the panel functions would remain with the software emulation, which I´d prefer to have on the ipad.

Yes, with the IP based

Yes, with the IP based control system there is no reason why you could not have multiple control solutions running in parallel, in actual fact this is already working, you can use mutliple computers running the software panel and they all keep in sync with the hardware.

Not sure if there will be in iOS version of the full control software, this is down to BMD. AFAIK the current plan is for the SDK to have a limited set of control commands initially, so 3rd parties would not be able to write an iOS app that allowed full control over all the settings.

utilizing MIDI controllers as directly as possible

suppose someone designed a converter box turning MIDI control messages into a set of LAN based commands for the ATEMs.

This imaginary box would also employ a return channel for status updates.
Just a guess... maybe the Mackie HUI protocol would serve well for this purpose?

Wouldn´t that be an efficient concept
+ well... relatively.... easy to design?

yes that would be nice. it's

yes that would be nice.

it's possible to do this on the Arduino platform.

Tom, do you think we could

Tom, do you think we could find + encourage that certain someone - or a collaborative bunch of them- right here in the forum?

As I have no idea at all about the LAN part-
Do you think one could obtain documentation about the communication between panel and processor?

(The above might be a stupid question, because a: the protocol is obvious for anyone with more understanding than I have, or b: BMD is crippling the SDK just to let nobody know...)

Yes I'm sure that

Yes I'm sure that collectively we have the skills to do some very interesting things with the ATEM range. What we currently lack is the details of the protocol used to control the ATEM. BMD have promised that their will be a documented SDK of some kind or other, and when this appears then we should be able to make fairly rapid progress.

I don't doubt that someone could reverse engineer the protocol, even without any info from BMD it could be possible to work out how to control functions on the switchers. However I'm sure the BMD will eventually release an SDK with details of the control protocol, and so I haven't really tried to hack about and work it out for myself.

I'm hoping to develop some computer based control systems once i have details of the protocol, using a system such as Max/MSP or Quartz Composer we should be able to get some interesting stuff working very quickly. I've done this with other video hardware in the past and some of what i've developed has been taken on by others (notably the imixhd software which controls TVOne hardware which was initially based on a quartz composer patch that I developed)

a genuine hardware controller based on something such as arduino should be relatively simple too and I suspect we will see the protocol supported by existing hardware integration / automation products such as those made by Crestron / AMX.

However all this may be some way away. BMD have a lot of work to do to get the currently released hardware fully working with all the promised functionality, never mind the 2M/E switcher which still isn't released.

So the future is bright, yet somewhat distant! However i'm confident that BMD have our interests at heart, they seem to listen to what users have to say, it would be inconceivable for the CEO of Sony to be chatting to users on a independent forum, yet Grant Petty (BMD owner) is a member of this forum, and has been joining in with some of the discussions.

AppleScript testing

Hi Tom,

Have you had time to do some testing?
If so, did it work?

About controlling the ATEM TVS via IP:
I would love to build systems/interfaces that could control the thing.
I am thinking of iPad control pannel, if it is on the same subnet as the controller it should be easy to do if we have the control commands.
And webbased switching for fun. And interface that let people switch the ATEM via a website. So that the users can pick a viewing angle.
That would be fun in a "bigbrother" situation.

I wish I had an ATEM TVS to do all kinds of hacking on to make product for the community... hint hint to BMD ;)
The thing is cool, but it is not my core business so investing money to buy one is to much for just fun.

Follow me @Kjeld
Small screens big opportunities!

Hi sorry i've not had the

Hi sorry i've not had the time to test this - my mac screen is smashed and so it's been sat at home waiting to go to the doctor.

Protocol reverse engineering

I just worked a little on the protocol.

What i can do so far is to switch the program and preview.
There is lot of stuff exchanged in the connection phase i don't unterstand
totally. So i'm a bit careful, smashing udp packet's to my 1 M/E :)
As soon as i'm back home, i will upload the perl scripts
and my notes about the protocol.



Great job ratte

Cool Ratte,

Please post your findings, looking forward to hacking something up.

Follow me @Kjeld
Small screens big opportunities!

Beautiful Ratte!! I'll check

Beautiful Ratte!!

I'll check in here daily for news, and contribute if I can.

Perl Script controlling Atem 1/ME

As promised my crappy perl script to fiddle around with the 1M/E.

If I've some more spare time, i will rework this a little.
But my real plan is to write a C-Library to talk to the Switcher.
Of course I could not reveal all protocol parameters, etc. Still working on it.

ATM the talks to the switcher and play's blinkenlights with
PGM, PVW, Keyer and Transition (line 95-99 is doing this stuff). is a script which tries to emulate the atem for use with
the software control panel. When playing around, I crashed my 1M/E
more than once, so i decided to start first with this emulation to understand
the protocol a bit more.

If there are any questions, don't hesitate to write them down here.

Have fun!

P.S.: It would be so nice, just to get the protocol-information from BMD :>
I hope the developers are fulfilling this dream when releasing the SDK.

Midi control


I am trying to develop a midi control for doing the fading (and probably some more stuff) from a hardware midi controler (Korg nano kontrol).

I have ported your code to python, and managed to write the fader value to the mixer.

The code is at . Tell me if you want commit access.

Maybe in the future (most likely next year) i'll make something a bit more pretty and complete.

Your Perl Script

Hi Ratte,

I have been looking at your script and learning a little. I was wondering if you could post for us what you have discovered in your communication attempts with the ATEM 1M/E. For instance, I notice from your code that the switcher uses port 9910 to communicate. Does every device that communicates with the switcher chassis use this same port? What is the data structure of the communication from panel to the switcher? What is the data structure from switcher to the panel? I appreciate what you have done but perl is foreign to me. I use Delphi which is a Pascal derivative. Just posting plain english descriptions of all you have discovered and fully commenting your source code would be most helpful.


ATEM Protocol

Hi Tony,

being ill the last two weeks, i could not go further into my atem.
What i can tell you about the communication between Panel <-> ATEM:

- Yes, every ATEM switcher listens on UDP Port 9910, so the hardware
panel, the software panel(s) and later on the Tally Interfaces connect to this port.

The packets are structured as following - [] represents 1 byte:
[CCCCCLLL][LLLLLLLL][UH][UL][JH][JL][?][?][?][?][KH][KL] ... [VH][VL][P1]-[Pn]

C are command bits:
bit 8 means: send ACK for (packet with bit 4 and Counter 'K' set)
- fill counter 'J' with value of counter 'K'
bit 7 means: no idea at all
bit 6 means: this is an resend packet
bit 5 means: this is an hello packet
bit 4 means: request acknowledge for this packet, fill counter 'K' with incremental packet number

L is the lenght, as you can see, it's 11 bits, the 3 higher bits are stored in the command byte.

U is the uid, when connecting to the atem, you choose a random one (afaik).
After successfull hello, the mixer answers with his configuration and your "new" uid.
Do not ack the configuration packets until their payload is 0 (means L is 12 decimal).

J and K are counters. The atem and the control panel use, let's call it communication channels,
using the command bits 8 and 4 and incrementing these counter's resp. acking the packet of the opposite site.

The part's with [?] i don't know anything about :)

The payload is, as described above just 2 byte length and then the payload (the 2 bytes len are included in the length calculation). So if you get a packet, check for L, and if it's greater than 12 dec, read ahead the next 2 bytes, read the payload and so on...

To change the preview bus to Input 3 you send (this is hex notation, of course you send bytes):

08 = bit4 set - packet from me, ack please
18 = len of 24 bytes
8001 = my uid
0000 =
0000 =
0000 =
002e = my incremental packet counter
000c = payload len of 12 bytes (resp. 10 bytes, because of len - 2 bytes header)
3e74 = , can be 0000
43507649 = command "CPvI" - means Change Preview
0004 = value 4 - means switch to input 4
c0d5 = , can be 0000

To change the Program input, you send "CPgI" (43506749).

The mixer responds with:

Bit 8 is set, so he want's an ACK for counter 0023.
Bit 4 is set, so this is an ACK to our packet 002e.

0014 = payload of 20 bytes
0000 =
546c496e = "TlIn" - this is a tally message
0008 = 8 tally inputs(?)
01000002000000 = Input 1 - 8 -> 01 means INPUT1 is PGM, 02 means INPUT4 is PVW
0000 =
000c = payload of 12 bytes
0000 =
50727649 = "PrvI" - show's the selected preview
0004 = INPUT4 is Preview
0000 =

If you change Program, then mixer sends 50726749 and the 2 bytes after indicate what
program is choosen.

That's the trick, why you can use more than one control with this mixer,
he tells all connected controls, what has changed :)

I'm trying to get some more useful stuff out of the protocol as soon as i get healty again :)

In the meanwhile, i can recommend that you use wireshare to get a little closer to the
packets. Most of the payload is something like "cleartext", and not so hard to understand.

Kind regards,


Coming Right Along

Hi ratte,

I'm sorry you have been ill, hope you are better than ever real soon!

I want to thank you for your documentation of your ATEM findings. This is helping me a lot!
I have some controls working in Delphi now. I think I will make a module specifically with all
the ATEM features you have uncovered and then be able to use it in whatever I program I develop.

I am working on a media player for the ATEM that will be able to read the state of the switcher and play when a selected input is taken live.

I have also written an autoswitcher for the ATEM but as of now it feeds keystrokes to a software control panel. Making it communicate directly with the switcher chassis will be very cool!

Thanks again for your efforts and sharing this with us. I will be sharing whatever I come up with the users on here as well.


Michael, Thanks so much for


Thanks so much for the write up. I have some ATEM TV Studio control based on that.

Couple of things I found that are key - if you're trying to implement, add these details to Ratte's post:

You must respond to the 'hello response' (0x03) and other packets as requested, or the Atem won't correctly communicate with you.

You must listen for when the Atem starts to use an new 'UUID' or session ID, and start using that when sending commands.

Still picking out more commands, some are obvious, some less so.

Willing to help if people have trouble, I did a test in RealBasic, but I normally work in C++. I had trouble getting through the python examples, myself.


Excellent thread guys - many

Excellent thread guys - many thanks for the good work. I will be digging through your examples and share what I find.


Hey Tom,

Would love to try out your profile on Hipporemote.

I cant find th profile..did you release it in the end?


i never got round to it. I'll

i never got round to it. I'll find it and put it up on the site tomorrow for you.

TBH it's not very good, or very complex. Mixing video from a touch screen interface without any status feedback from the mixer is horrible and basically not worth investigating further.

But I will try and put the files up anyway so others can evaluate them.

You may download the

You may download the hipporemote patch here

Many thanks Tom, I shall have

Many thanks Tom,

I shall have a play, but agree with your thoughts on touch screens and switcher response.

Custom Control Pad

Hey Proteous the X Keys link you posted looks good. with the keys programmable too.
I had thought of utilizing a numeric keypad but there are no keys for "Cut" or "Hot Switch", all the others are there.
As an TVS user into recording lectures etc this could make a good cut down control system that could be used by camera operator to control vision. Just need to have a laptop to record and small audio mixer to input sound. Could be very light on equipment for that small shoot.
Anybody know if when we might get an update with additional shortcut keys ?
John Fickling

*Appleboy *
End Time Videos
New Zealand

ATEM Television Studio
3 x JVC  GY-HM650 cameras with 663/0/P2 7" monitors
1 x JVC  GC-PX100 camera with Nyrius Pro (50m) video transmitter
OB van with Datavideo OBV 2800 style console

Suggestions for shortcuts

I think it’s a pity that there is no small, simple and cheap hardware control panel available (or in development?!?) to operate the simple mixer functions like PGM & PRE-rows, cut, auto, FTB, keying (on/off/auto/tie) and maybe a simple T-bar. Buying the 5000$ 1ME-Panel for the TVS would be over the top for most of the TVS-user’s needs I think.

Obviously the TVS is meant to be operated via software, but in this case there are far too little keyboard shortcuts. Operating fast switches by mouse is just awful. So I’m missing shortcuts especially for the keying section (at least on/off or auto) and the selection of the media players for PGM. Configuring the settings in the menue by mouse is not a problem, even more comfortable compared to old vision switchers. But having to think about which important button I’m able to “press” by keyboard and which are mouse-only, lags fast operations. Hopefully this will be implemented by some of the SDK-developers after BMD releasing it.

web-based hotkeys

A big shout out to the guys on the forum for some initial guidance; however, because the UDP protocol is not officially documented nor supported, I could not afford to commit to a spec that might change in a minor software update.

That said, my C# wrapper around the messaging protocol is mostly done, with some handshaking related issues.

For those curious, instead I wrote a custom HTTP server app that runs on a system alongside the ATEM Software Controller. It serves up HTML5 web-pages that remotely trigger ATEM keyboard shortcuts. Includes safety checks to auto-launch the app in case it is accidentally closed and other security features.

Bonus: iOS / Android friendly.


(Un)official API


Have anyone else than me noticed that when installing the ATEM software you get a file in the software folder called "AtemSwitcherAPI.dll"? It seems to be a type library which contains most (if not all) functions of the ATEM switcher, and to me it looks like it might very well be the base of the official SDK.

Anyone from Blackmagic who can confirm/deny this? Or anyone that has tried using the file, that can share some findings?

If not, I will for sure give it a try when I get back to my mixer in a week or so.



I can now confirm that the "AtemSwitcherAPI.dll" file (which is installed together with the BMD application at least from version 2.7.2) is an COM object that contains all you need to control the ATEM switchers. I have only tested on ATEM 1-ME, but I am quite sure it will work with the other models as well. Would be VERY surprised if this doesnt sooner or later ends up as the official SDK...

For those who has tried the TCP protocol I strongly recommend looking into this solution: It took me 10 minutes to be up and running with a working control software.

The library is for PC only, but maybe someone with a Mac installation can tell if there is a similar library available in that installation?


You are right, it is even in

You are right, it is even in there when disassembled with PE explorer:

10024B28 4174656D537769746368+ db 'AtemSwitcher API, Blackmagic Design',0

Can you give an example how to use it for novice programmers?

The Mac installation does

The Mac installation does include a library, /Library/Application Support/Blackmagic Design/Switchers/SwitcherAPI.bundle/Contents/MacOS/AtemSwitcherAPI

Unfortunately it seems to be a C++ library, of course without a header, so I'm not sure how easy it would be to actually link against it.

Very Good News

The next version of the ATEM Software includes a basic SDK for controlling the switcher. This should allow a wide range of developments for different control options.

Yea, I've been waiting for

Yea, I've been waiting for the SDK to be released for a while now. I would definitely start working on a native client. Win-Win really, I'm happy having a native client, and BMD wins because other people purchase the ATEMs after seeing the nice native clients. :)

Yes well the SDK looks very

Yes well the SDK looks very promising, they have included a simple demo app which has basic control for the switcher. My programming skills are not up to doing anything useful with it unfortunately. I'm hopeful someone will be interested in developing an app to allow remote control using MIDI or OpenSoundControl (DMX would also be useful).

Porting the SDK to the Arduino platform would be really great as people could then build DIY hardware interfaces easily.

And when can we expect to

And when can we expect to download it?

err "very soon" apparently.

err "very soon" apparently.

I do have (thankfully)

I do have (thankfully) experience, working on two live production applications for OSX, and would love to add this third.

I would start with accepting external commands as part of the plan, but first implement it without. But MIDI would probably come very soon after that. DMX is a little more difficult, as there are so many different widgets, though the backend of one of those other two apps would prove to be helpful here.

(Although I laughing now, I'm kinda scared to actually hear someone showing me their DMX board saying "these are my intels, these are the LED strips, got a fog machine controlled here, and these pots control our video switcher")

I'm slightly jealous you already have the SDK, but hopefully the rest of us will have it soon. :)

Great, I'd love to help you

Great, I'd love to help you however I can. I'd be more than happy to test things and chip in ideas for functionality.

In an ideal world someone would turn the SDK into an OpenFrameworks addon, this would allow easier use for less technically able programmers (such as myself!)

ATEM Library for Arduino

Hi guys,

Finally no more talk. Here is the beginning (!) of a library for Arduino, talking to the ATEM switchers. Works with selecting the busses and cutting. There are a few more things in the protocol which is easy to extract, but I gave a go at configuring a DVE and that was not so intuitive...

Tomorrow I will post a video on YouTube showing what I have made with the API so far.

The code is on github, it's Open Source under GPL. Play nice, be social, share your inventions and let the good times roll! Blackmagic is hopefully gonna pick up the spirit and support these initiatives. (... although their 500$ Tally / GPI interface can now be made with a 50$ Arduino Ethernet model more or less out of the box... :-)

- kasper

YouTube demonstration of Arduino library

Here it is, demoing the Arduino library:

See video

- k


Very very nice work Kasper.

And yes, it will be very usefull !!

Wherever I can help you tell me. I have quite some programming skills and experience with software development. With help of each other here this is a very promising start. Great job!! Great Forum!!


Ow, and my first feature that I would like to add..:-) As well a tally LED per channel indicating that the channel is in preview. But that's of later concern.

just wanted to applaud. Thank

just wanted to applaud. Thank you so much for sharing, Kasper!



I too have a significant software background, along with hobby-level experience with electronics. Wouldn't mind pitching in.

I want to congratulate you

I want to congratulate you guys for starting to work out a hardware solution. I might have to look into building the tally lights myself. :)

Now if only I had my hands on the SDK (or a better write up of the protocol…), I'm salivating thinking about writing something for this!

Collaboration on ATEM Arduino Library

Hi Guys,

Thanks for your comments! I put the project on GitHub so I guess you can just make a fork there and do some work as you like, then make a pull-request to me. However, I'm not sure if this is the way to collaborate best or if I should add you as committers on my branch. I haven't used GitHub before so I'm not sure about the best way/practice around that.

But lets say for now that you are invited to improve the library and when you have some actual code to commit, let me know and we will deal with it then.

Maybe we should also have a wiki for documentation of the ATEM Protocol?


How GitHub normally works is

How GitHub normally works is that you fork and merge back in. Adding commiters on repos is really only for private repos and in organizations.

Think about using following

Think about using following tools in chain

TouchOSC builds custom dashboard on iOS
Osculator receives inputs and sends key presses to control software and I use abler on live for mixer
Osculator sends she'll commands to a tellus USB stick that switches power plugs by radio
Those are connected with lights on my camera

I've done a video in German thats not online yet
If you are interested, let me know

Solution takes less than 30m and 120€

Think about using following

Think about using following tools in chain

TouchOSC builds custom dashboard on iOS or simply use a Wii mote
Osculator receives inputs and sends key presses to control software and I use abler on live for mixer
Osculator sends she'll commands to a tellus USB stick that switches power plugs by radio
Those are connected with lights on my camera

I've done a video in German thats not online yet
If you are interested, let me know

Solution takes less than 30m and 120€

Tally lights build

Yes Terinjokes
I would love to get building a tally box. The BDM tally is half the cost of of my TVS !!! $750 in local currency. I just want to run a LED in the camera monitor to alert the cameraman that camera it's live.

Unfortunately I don't have the computer skills to be of assistance, all my experience is with using cameras and other tv equipment, repairs etc so could build up circuit board etc.

If the tally controlling was done by the computer controlling the switcher that would be a very neat arrangement?

*Appleboy *
End Time Videos
New Zealand

ATEM Television Studio
3 x JVC  GY-HM650 cameras with 663/0/P2 7" monitors
1 x JVC  GC-PX100 camera with Nyrius Pro (50m) video transmitter
OB van with Datavideo OBV 2800 style console

If someone designs a tally "kit"

If someone designs a tally "kit" I would recommend using a rotary dip switch
to select which camera to indicate.

If I had the time I would layout a circuit card but my uP frontend choice is
MicroChip's ENC28J60

One thing I haven't looked at is if preview and program info is being sent so
one could use a two color LED (red/green) for tally.

Great work!

i've been thinking about a

i've been thinking about a tally system over the weekend.

I've come up with some plans for a number of different solutions. Using the arduino it will be simple to create a workable tally system. For people using proper camera systems then a traditional close contact tally will be easily accomplished with a set of relays controlled by the arduino.

For people with small cameras which have no external tally facility then it is easy to make a small box with leds - this could be done to work with close contact tallys (and thus be compatible with other switchers) Or you could do ethernet tallies where you'd need one arduino per camera.

It should also be possible to make a wifi tally system using an arduino and wifi shield on each camera (gets expensive!)

Two colour tallies are no problem as the Atem sends this info out on the ethernet

hopefully my ethernet shield will arrive tomorrow and i can get testing...

I can probably build a

I can probably build a non-traditional ethernet two color tallies this week or weekend and post how I've done it.

I'll be a little hesitant for using wifi, but that's a personal issue.

Arduino shield ideas

Hi Tom,

Thanks for commenting.

I have made some ideas for arduino shields:

The Pro shield is basically 100% compatible with BMDs "GPI and Tally Interface" box. It has a DB25 header and uses the same components in the I/O. In addition it has screw terminals (does that make sense?) just doubling the I/O pins from the DB-25 header. I thought it would be cool to have indicator LEDs on board so you can get a visual feedback on both an outgoing and incoming signal. This will help debugging.

The Indie shield is for the rest of us :-) Or basically, it is aimed at those who wants to connect their Two-color LEDs to the board. So it will not have optocouplers and the output of the screw terminals will allow you to just screw in a LED directly! Then you can extend that with wire as you like. Question is if there should be some other pin-based headers so you don't have to always screw cables in. Also this print has LEDs, but this time, two LEDs for each output tally since we will allow both a Program and Preview tally LED.

The nice thing is that such two shields could be stacked on top of each other on the arduino main board and thus allow you to mix as you please with the same base-Arduino.

As for configuration, I don't intend to add switches on the shields. Rather, I would based the config on having a neatly documented Arduino sketch. People need to configure the IP address of the board anyway, so there is no way around downloading the Arduino IDE and compile stuff. But hey, that is SO easy that it's hardly a problem if a sufficiently nice tutorial is also made available. This way you can configure any outputs as you like.

On issue I'm gonna face is probably how to fit all this onto the shields if there should be room for screw terminals and LEDs. We might also consider if maybe the tally shields should include only 4 channels instead - and then expand to 8, 12, 16 channels by simply buying more shields (which will be 1/2 price for half # channels anyway) and stack them! Mix and match.

If we can elaborate a functional description of such shields - or even split the products up into more shields if needed - I would go for implementing these and having them produced for sale online.

PS: I was considering a "yellow tally" as well; when your input is used in a keyed, for instance to create a PIP effect with the DVE... makes sense? Now, that could always be implemented in the code using a free tally output channel...

Yeah, nice idea of putting it

Yeah, nice idea of putting it on a shield.

I've been thinking about the programming aspect and am leaning towards a solution with an XML file stored on the SD card of the ethernet board. This would allow user customisation of IP addresses (both of the switcher and the arduino) as well as mapping tally outputs to specific mixer functions. It allows for an easy to use system based on the arduino ethernet board (the ethernet arduino is a pain to program via usb, as you need to access the arduinos headers)..

One idea which would be a pretty neat tally solution would be to make a small box with an arduino mini - it would have a switch to select which input it was responding to, with an led segment display of the camera number, and program / preview tallies for the selected camera channel. Using a PoE ethernet module would allow you to run a single cat5 to each camera from a PoE ethernet switch connected to the atem. Whilst being more costly than a solution using a single arduino it offers the advantage of avoiding any custom cabling to the cameras.

Hopefully my ethernet shield will arrive tomorrow (post has been very slow after christmas) and I can start putting some of these ideas into practice.

Nice ideas

I like the ideas of the SD card and I will look into the Mini idea as well. I'll be on vacation a few weeks, when I get back I'll elaborate more on it. Looking forward to hearing about your experiences with my code by then. Hopefully there will be some people who can help to extend the protocol support in my code. later...

Simple Tally for small camera

Thanks Tom for your helpful deliberations.

For my application with TVS and four small 3 chip cameras it would be great to have the 2 colour LED system mounted on camera. To cut down wiring a 2 wire system would be the simplest, unless you were to incorporate intercom to the camera too !!!!

*Appleboy *
End Time Videos
New Zealand

ATEM Television Studio
3 x JVC  GY-HM650 cameras with 663/0/P2 7" monitors
1 x JVC  GC-PX100 camera with Nyrius Pro (50m) video transmitter
OB van with Datavideo OBV 2800 style console

Looks really interesting. I'm

Looks really interesting.

I'm a little challenged and feel myself going a bit glazy eyed when I read the programming side of things. However, I'm handy with a soldering iron.

I'm going to need a very simple tally box with up to 6 outputs to tell the camera ops when they're live. I don't need yellow tallies - I switch the cams on the main bus and rarely use the preview bus.

I could go for the BMD Tally/GPI unit (if it's actually available - I'm never quite sure with BMD) or preferably save some money and build my own.

The bit I don't get is the deciphering of the serial info from the Ethernet port and translating that into relay actuations. Is that simple enough to get my (small) brain around?

Alternatively, I might be your first customer, Sysopstv, for a custom built box.

Thanks in advance,


Ben Giles

The GPI /TALLY box actual

The GPI /TALLY box actual does exist ;-) I took it apart the other night to look at what they used inside of components. Also, I am going to compare it's use of the protocol to that of the Broadcast Panel and the laptop software - maybe that will expose some more details.

Anyway, could people please comment on their primary needs for a tally device? Take a look at my suggestion for two Arduino shields, one "pro" and one "Indie" and let me know if they fit your needs. If you have more ideas and needs for a tally device, please post them so we can integrate it into the design.


I would be very interested to see a picture of the inside of the GPI/Tally box

Extra board or not

My Arduino (Mega) board with Ethernet Shield and software works perfectly fine! Excellent! I played around using a preview button and a separate program button per channel. Will test it better with some extensions in the software this weekend.

The tally connection done with an extra Arduino shield would indeed be the simplest. But still my preference would be to put a self made circuit board in between: The Arduino, the panel switches and panel LED's (Or some fancy illuminated buttons), and some dedicated connectors to the backside of the panel.

In my tally goes via the intercom and I need/will use 2 dedicated 15pins sub D connectors (2 times 4 camera's). I know other people need different connectors so that would indeed mean people have to solder some wires between the self made circuit board and their type of output connector.
As in earlier posts mentioned, having the advantage that they can decide at that stage if they use 1 or 2 led colours per channel. I realize that soldering is maybe not too nice/handy for everybody but even though its a self made panel, I think everybody needs a panel that you can trust for 100%. Therefore I prefer some robust connections especially to the outside world. Does not cost a lot, it does imply the chassis part of the connector at panel side is not soldered onto a circuit board but wired to a circuit board. So connecting/disconnecting cables is not accidentally a cause of failure internally.

Secondly the stack of boards becomes relatively high with a third. I would like the panel to fit in a drawer of maximum 2 height units high, but rather in 1.

Just for the idea a first quick search to a panel box gave me:

Idea/Question: With a simple fader (slider) one could easily create a T-bar. Use an analog input and the software for reading the value is easy. But do we know the command description (and its header) that has to be send?

Yes, you could create a T-bar

Yes, you could create a T-bar with the analogue Arduino inputs. Protocol-wise you simply have to send a series of commands for each step of the dissolve from one input to another. I haven't fully investigated it, but for a 1 second transition it seems that the ATEM Software sends some 20 or 30 requests to the switcher.

Nice boxes!

Ah, the pictures of the inside of GPI/Tally box asked for is here:

Some thoughts

I like the appearance of the sloped boxes you found. Half of anything one
puts into a system is the "wow factor".

The T-bar is another area and I am sure a fair amount of money would be
spent in custom milling the parts for the handle and linkage to the position
pot. You would need stable pots or have at least a calibrate function to
tell the Arduino the range from full up to full down.

GPI and GPO has many uses in production. An example is a playout device.
When a input is taken to program, the edge transition would start the playout.
Where is the GPI used on products. BMD's documentation is so limited.

GPI could be used for example

GPI could be used for example to trigger auto transistions or to trigger key transistions (we use it a lot in OB trucks to let the graphic operator turn on and off his keyer),

But I dont know if the GPI in ATEM is actually implemented, cause I have not seen any reference to them (but have not looked either).


I'm using this as a hardware

I'm using this as a hardware control:

I just need a few more hot keys implemented, and it'll work just fine.

There is also the X Keys

There is also the X Keys range:


and the rather groovy looking:

However, all these peripheral control surfaces depend on a PC or Mac as the controller/UI. I'm looking forward to seeing what some of our super-sized brain colleagues on here can cook up regarding a standalone hardware controller.

I like the BDM control panel - but I could actually do with something more like the size of the X Keys units above. I'm going to take a look at the new SDK - it's not something I've ever done before. How much programming knowledge do I need? How long is a piece of string... :-)


Ben Giles

What laptop to use for Atem built-in scope?


I would like to get a better insight in the light and colour qualities of the images coming from my cameras, and I think that the built-in scope might be very useful. Unfortunately, this only seems to work on Windows computers.
Blackmagic has some recommendations for motherboards, and some tested systems, but laptops are not included in the list.

Who can share some experiences with the Ultrascope, and who can recommend a windows laptop for this use?


Sorry, this was supposed to be a new topic.
I moved this to a new thread:

Gerbrand Oudenaarden
Engage! Tactical Media -
webcasting & multicam

SDK not Standalone Friendly

To throw in my 2-cents, he's what I'm hoping to use as the controller:


sitting along side a


Both are midi devices, which would have to be tethered to a Mac/PC. I'm also 75% through the construction of control surface with an Arduino Mega brain. So, a standalone device is my long-term goal.

I have some programming experience, and I've looked through the SDK. What's been released, so far, depends on linking against their dynamic library. Which means the code must be run under Windows or Mac (no Linux). This limits the ability to make the device standalone. I was kinda hoping the SDK would expand on the networking protocol you all have impressively deciphered.

I guess the best hope

I guess the best hope currently is the option to use the sdk to make an app to help understand the UDP commands further. By having the ability to programatically manipulate the ATEM library it should be possible (i guess) to make an app which sends specific commands and spies on the UDP traffic which they generate. I'm not a programmer so i haven't the skills to do this, but it would seem to be possible at least.

It is somewhat disappointing that BMD haven't published at least some of the UDP protocol, having a high level SDK is great for windows / mac apps but does nothing for people making hardware control options. This really limits the ATEM considerably as not only DIY arduino type solutions are excluded, professional control system integrators such as AMX are also unable to make solutions for ATEM integration. Hopefully BMD will release more low level details of the UDP protocol, until then we will have to keep hacking away :)

Control ATEM software via "Keysonic" programmable keyboard

A good solution is the fully programmable USB-keyboard Keysonic KSK 8003 UX (I don't know if it's available worldwide). It is also very easy to change the key-covers to create a "PVW-row" with the numpad-buttons.

I do hope that BMD will shortly include keyboard-shortkeys for the keyers and other functions so that it will be possible to control the standard-switcher-operations by keyboard only.

keyboard shortcuts for AUX bus(es)

We also need some shortcuts setting the input to the AUX bus(es).
Currently it takes to many to change the input.

tally on keyer fill source

I've been experimenting with the arduino examples and i am able to build a simple tally interface on the breadboard i have connected to the arduino while recycling the code and wiring of the example.
But, when i select a camera imput to a keyer source and put that to program, the tally won't react as i already had suspected.
But it would be a great option to have it do that. Any ideas how to accomplish it?
On the multiviewer, the red border is there when i do the same.


I have not looked into the actual code, but could it be that what your code is doing is to read the input on the PGM bus? If so you should also not get tally during an dissolve (the camera you dissolve to wont get tally until the dissolve is complete).

Maybe there is a way of reading the actual tally state for each input - after all that would be the best way for BMD to use their own tally box as well. If not you have to calculate your own tally, based on:

- If the input is selected on the PGM bus
- If the input is selected on the PST bus AND an transition between PGM and PST is in progress
- If the input is selected as key or fill source in any keyer AND that keyer is ON or in fade progress
- The fade to black is NOT completley turned on

There are quite some values to read in order to get a true tally status, so I would start by trying to see if there is a tally message being sent on the network (keep in mind that the above calculation becomes much more complex on a 2 ME system, so it would be strange if the BMD tally box had to do all of that).


Tally calculations

I agree with Jonas. Currently, tally is just based on what is on PGM input in the library. I didn't yet look closer whether tally information is calculated from the switcher directly, but if it is I think it might be pretty easy to decode and implement. Surely, if someone would like to help out, I already put the code on GitHub and everyone with a clue is invited to help improve it.

Ok, clear. I'll also do some

Ok, clear. I'll also do some wireshark analysing and hope I can figure it out. ;-)

Tally info in protocol

Hi folks,

I woke up this morning and somehow my brain had come to think of a value in the standard response and update information coming from the ATEM switcher upon a change of Preview or Program input. So I think I have solved it although I haven't actually added this to the Arduino library yet.

However, I think we should move technical discussions of the protocol internals to a new thread I have created:

Microchip based controller

I managed to get the ATEM working with a Microchip dev board (PICDEM.NET 2) and wired up external interface for doing preview override. Works great but have noticed that after a few hours the inteface crashes/locks up. Doesn't seem to be the ATEM so i'm thinking its something in the UDP protocol.

Has anyone seen anything like that?
Does it just occasionally change uid/session id after a certain time?

I can post code etc if that is of any use to anybody for their projects, its written in C for the C18 compiler.



Re: Microchip based controller

As written in this post: it looks like the ATEM might change UID and/or session ID while running. I have seen similar things when monitoring my network traffic, but since I have been controlling my ATEM over a wireless network I cannot be sure if the new ID's has been given due to a short loss of communication or due to system design.

What concerns me most is that BMD has choosen (so far) not to release the protocol. As it is right now any future update could make any applications built on the network protocol unstable or even unusable. Since all their own products can be updated over usb it is fairly simple for them to make a protocol modification, that then needs to be reversed engineered again... Anyone with any contact at BMD who might be able to tell what the future might show?

At the same time the released API is very crippled compared to the unofficial one that was delivered with version 2.7...


Hi Jonas, I agree that BMD

Hi Jonas,

I agree that BMD could change the protocol anytime and they could potentially make it very difficult to figure out - for instance crypt all data. The real question is if they have such hostile intentions. I actually don't think so if they are just a bit aware of the wave of user driven innovation in recent times. Innovation management people like to put it this way, that "the smartest people are almost definitely not employed by you" - the point being that invitations to the surrounding world to contribute and innovate with your product is likely to reach some talent you would otherwise never encounter. And that innovation will give BMD more back for free than it takes away. Lets say that some third-party hardware based on a hacked protocol might take away the sale of 100 GPI & Tally devices in total - isn't it likely that it on the other hand would create increased loyalty and customer base of a far larger value to BMD when people realise that BMD are supportive of such "indie-development" taking place? Not to mention all the ideas and direct insight into their users own perception of needs?
I would most of all like BMD to state their commitment to supporting "indie-development" for the ATEM range of products, which in the most basic form is to say they will not try to take countermeasures and in a more active form would be to actually publish details of the protocol - or just share their SDK libraries in source form so we can peak at the internals. It should be pretty easy to just make such a principal statement.
They are smart and friendly people so they probably just need to be asked.

Gpad on Android via WiFi

Gpad for simple setups..

It is possible to create a simple wireless remote for the Atem panel via Gpad app on Android phones and tablets. The space for creating buttons is limited, so I have just set it up direct to program camera switching and a fade (enter) button.

Android market:


Lars, first post :-D

Updated Arduino library

Hi folks,

I have updated the arduino library. Check the small change log if you intend to upgrade to it.
Short summary is:
* Tally correctly supported now
* All "switcher-interface" functions implemented, some configuration from the palettes as well (such as selecting media for the media banks.)

It's still beta and will remain that way for a few more months.


Before I got the TVS I was using MIDI and Applescript for switching, works perfectly apart from the fact all the video is going through CamTwist software. Is there any scope for using the Arduino code with a MIDI input to map to the Ethernet out?
I have no experience of Arduino at all, but am willing to put some time in to help make it a reality.


MIDI with Arduino

Well, yes, I just need to know how to interface with a midi controller.

I remember in the 80's there were like DIN plugs on the midi synths. Is that still it? Or is it "USB-MIDI"? Regardless, I need to either find an arduino shield which does the interfacing or know how otherwise to communicate with such a device.

Basically; Anything that you can read from an arduino can be used to control the ATEM by sending the preferred commands in response to the input.

Tally info

Thank you for the big update of the library.

I have been playing with it, to make a tally interface working.
I did expand the tally section of the control example and stripped the control parts to get a basic tally interface going with an 8 relay board that costs 8 euro on ebay with free shipping.
It is working, but sometimes things go wrong.
When that happens, the tally status is not updated and i get a bunch of packet size mismatches on the serial monitor:

ERROR: Packet size mismatch: 112 != 92
ERROR: Packet size mismatch: 112 != 92
ERROR: Packet size mismatch: 112 != 92
ERROR: Packet size mismatch: 112 != 92
ERROR: Packet size mismatch: 112 != 92
ERROR: Packet size mismatch: 112 != 92
ERROR: Packet size mismatch: 112 != 92
ERROR: Packet size mismatch: 112 != 92
ERROR: Packet size mismatch: 112 != 92

Do you have any idea what causes this?

Also, when i let a DVE run to a keyframe, the arduino crashes with the follwing showing up on the serial monitor:

???? Unknown token: KeFS : 0 0 1 0 4 5 1 EE
ACK, rpID: 25
???? Unknown token: KeDV : 0 0 1 0 0 0 2 DF 0 0 2 DF 0 0 15 E 0 0 0 0 0 0 0 0 1 0 1 1 0 32 0 32 0 0 0 32 64 C 0 0 0 0 3 E8 1 68 19 1 0 0 0 0 D DE D DE 19 2 0 6E
???? Unknown token: KeFS : 0 0 1 0 4 5 0 1
ACK, rpID: 26
ERROR: Packet size mismatch: 2040 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 592 != 92
ERROR: Packet size mismatch: 692 != 92
ERROR: Packet size mismatch: 592 != 92
ERROR: Packet size mismatch: 592 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 692 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 692 != 92
ERROR: Packet size mismatch: 692 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Packet size mismatch: 592 != 92
ERROR: Packet size mismatch: 392 != 92
ERROR: Packet size mismatch: 492 != 92
ERROR: Command Size mismatch: 0ERROR: Command Size mismatch: 0

What you experience with

What you experience with Packet and Command size mismatches are a still unsolved problem which I'm not entirely sure about, but I have some reasons to believe that they are caused by a bug in the EthernetUDP library. The more general problem is that the Arduino might sometimes receive information from the ATEM Switcher quicker than it can process it and empty the in-buffer for the next packet. But after the initial handshaking this problem should be quite small and not make it crash.

Generally, we have to face the fact that Arduino is relatively slow and our ways to implement the ATEM library can greatly affect how well it works (eg. if it doesn't have time to process and respond to packets from the switcher). Actually, as a quick suggestion to you: Comment out the line AtemSwitcher.serialOutput(true); - so you DON'T get serial output - because it takes cycles to send those slow serial commands. That might on the short term solve your problem ;-)

- kasper

GPI/Tally interface from BMD

BTW, did anyone actually use BMDs GPI/Tally box? I tested it the other day and could make the GPO pins work (relays for tally lamps). But the GPI inputs didn't do anything whatsoever. No packets on the wire at all. Reading in the ATEM manual you begin to suspect that they didn't yet implement support for GPI since there is no discussion about where GPI signals will end up... typical, hrmf.

Can someone confirm this?

When I disabled the serial

When I disabled the serial output, it doesn't crash anymore when I let the dve run to a certain setpoint, but I still get the bug that it won't respond sometimes. The next package that has tally info will be picked up right after that, and it will keep running.

After reading Some

After reading Some information about the Ardiuno setup. I decided that i woud change the way i want to control the Atem.

We ordered an Ardiuno mega version 54 I/O's if im not mistaking.
Ethershield for it.

I will wire up a old rmc90 from datavideo as button and T bar for testing purposes.

Make a tally output in it and light control for the buttons.

What do you guys think are the most needed functions on a basic controller?
Pgm bus. Prev bus. T-bar. Take button. ? Maybe some control for key?

Greatings Daniel Wittenaar
Xtreemtec Media Productions

Daniel Wittenaar

Xtreemtec Media Productions

The Willows Developments

That will be a nice project.

That will be a nice project. I was thinking about the same, but at the moment i'm just using what i have laying around to create a simple tally box.
With that i'm already getting problems that make it unsuitable for production at the moment.
So don't get your exepectations up too high. It will work and let you control the atem with it, but you will experience it not responding from time to time having to press a button twice when I look at my experiment with it.

Because you will be wiring up an existing panel, just wire up all the pushbuttons, you can 'assign' the buttons later in your software. When you use more than one mega, you can also make the button lights work with the tally info.
When i would wire something up like that or design a panel of my own, i would just put a preview and program rail on it, including keying and maybe an aux rail, plus the transition buttons.
The setup of the keyers and other advanced functions, i would do in the software panel.

When you play around with the BM panel, the upper rail changes with the function you select.
It works really nice and I think it's really worth the money, not easy to imitate that with an arduino.
But a simple board should be really possible.

I like to play around, but I'm definitely getting the real thing when I made the money with the atem. ;)

smart control panel to control ATEM aux sources


I've been thinking about using a smart control panel from blackmagic (2 x 40 buttons, normally used for controlling matrix routers) as a control interface to select the sources for aux outputs of the ATEM. An Arduino with an Ethernet shield could probably be used as a protocol converter.


Gerbrand Oudenaarden
Engage! Tactical Media -
webcasting & multicam

Applescript a possibility?

I know ATEM Software control is both platforms, but does anyone know if there are plans to activate Applescript for the OS X side?
It would seem to be a trivial matter to just enable Applescript in the info.plist - indeed I have tried but permissions wont allow.
That way at least we could send it key commands on a very basic level.

AppleScript Interface

Nick, Mac apps that don't provide an applescript interface, can sometimes still be controlled by sending "System Events". Here's some good info on doing so:

Hi Fdrlive, thanks for the

Hi Fdrlive, thanks for the tip - I have got that working, though I would love to have some more key commands available to control - DSK live togle etc - or any other buttons would be a great help. But I have something working with the System Events.


Atem Protocol

Would it be nice to open a seperated topic for all communication digging of the ATEM?

So we have that bundled in 1 topic. I think this topic is to common.. Controlling atem is about more than coding.

And also with that info bundled we can more easily adapt the protocol and rewrite the software to expand the functions.

I guess if Kasper would start it. He has the most information of the protocol as far as i know..
I could bundle the info that i have read here.

Daniel Wittenaar

Xtreemtec Media Productions

The Willows Developments

Got a working tallybox

After some changing in the used libs, I got the endresult stable. In w5100.h i set:
#define MAX_SOCK_NUM 1
In w5100.ccp:
#define TX_RX_MAX_BUF_SIZE 8192
Just multiplied that by 4.

I tested that, was way more stable but sometimes on take it would still bork sometimes and throw me a cmdlength error.
So I upped the max cmdLength from 96 to 384 in ATEM.cpp. Didn't know where to go with it so multiplied it by 4 too.
Also upped the buffer flush to 384 of course.

When testing this again, it didn't give any bad results anymore while doing takes and cuts with 2 keyers enabled, doing dve go to setpoints etc.
I could still make the arduino crash by keeping the enter button pressed. Then I disabled the serial output again, and voila!
Sigar time!

My programming skills are quite basic, but it seems the max buffer size of 96 is too small. Because of what reason did you choose that value?

Working Tallybox Congrats

Mathijs that's great news, well worth the effort you put in persisting with the challenge.

Great stuff

*Appleboy *
End Time Videos
New Zealand

ATEM Television Studio
3 x JVC  GY-HM650 cameras with 663/0/P2 7" monitors
1 x JVC  GC-PX100 camera with Nyrius Pro (50m) video transmitter
OB van with Datavideo OBV 2800 style console

Atem Protocol

I already started such a tread for discussing the protocol.

My suggestion there was to use the wiki at github related to the ATEM Library. I wanted to start that myself, but didn't because I realised that my Arduino code would basically reflect all the knowledge acquired. So for now I'm just documenting the protocol in the library. I think it has to take someone else (and hopefully a collaborative effort) to put it on the wiki or in some other form independent of my library.

Good work, mathijs! I never

Good work, mathijs!

I never tried changing the buffer settings myself but thought that would be a last resort if nothing else would work for me. It's good to know that it can solve some problems. Preferably we make it work with the default settings because your changes are (as far as I can tell) changes to the Arduino installation - which is not so user friendly to suggest to other people ;-)

Some history:
My first implementation instantly read the whole UDP packet to Arduino memory. But I was very soon out of memory! So, my second attempt involved reading the packet and part lengths and parse it little by little. For this I still needed a max buffer size, but instead of 1400 bytes it became 96. That number was based on analysis of the initial information payload from the Atem switcher where I didn't encounter any parts longer than that. But your findings suggest I was wrong. I will look into that.
My aim was that the library could run on a basic arduino with 2K memory and an ethernet shield (or my own favourite which is the Arduino Ethernet board which has it all - just need a special USB cable for programming it).

I will test your findings myself and make some adjustments later. I will also check up on the issues with the Ethernet UDP library which I found a discussion about on the Arduino development lists - that might play a role as well.

Thanks for sharing your findings and help improving the library!

I agree it would be better if

I agree it would be better if it would run on standard arduino installation.
It could be that it will run on it, because I first tried to lower the sockets and made the window bigger, which did not resolve the entire issue until I made the buffer bigger on the ATEM library.
It did improve things though, just not all the way.
So I will give it a try using the standard arduino installation when I get some time and keep you posted.

Anyway, this will give Xtreemtec's project a bigger chance to be usable in a production environment, which I would like to see happen of course. ;)



Touchscreen pc - works great

I am using an Acer touchscreen PC to control my ATEM. I purchased it new for $1000 - so certainly a lot cheaper than the $5000 asking price for the BMD controller. Here are a couple of videos I made recently of progress in my webTV studio (or "money pit" as it is sometimes referred to :) ).

See video See video

A lot of us are using a

A lot of us are using a touchscreen to control the ATEM, it works but it is not as direct as pressing a button. While having a touchscreen I work more on the keyboard than using it to be fair.
It is a cheap solution though, yours is even expensive to be fair. A touch monitor costs 150 euro and can be used with any windows 7 PC.

how to install it

Thank you for the patch of hipporemote
But how to install it?
I'd like to have a test
Thank You


It's OK
Need to do an zip file of all files

Request for VB example

Hi there,

I can't afford a tally system in my very underfunded studio, but what I would like to do is display an arrow on a monitor that points to what camera is currently live. I have some decent VB.NET skills, but not deep enough to know how to parse through the C# examples in the SDK to do what I want which is two basic things:

1. Connect to the switcher
2. return what camera is currently active so I can update what's shown on the monitor. (It also shows a countdown timer and gives me a space to send messages to the talent.)

Can someone give me a decent example of connecting to the switcher and monitoring which camera is active in VB? I've added the BMDSwitcherAPI and the DecklinkPublicLib references to my project, but not sure exactly where to go from there. (Yeah, I know that was the easy part.)


Visual Basic Example

A tall order....

Just to clarify your project. You want to use an output port (which card and port)
on your Decklink card to overlay:

1. The number of current active camera taken from the data packet. (IE:1-8)
2. Countdown (program remaining?)
3. Text message

All cameras will have a program out confidence monitor with the above text overlayed.

VB Example

Hi - Sorry to be confusing. I have already built an application that will display a countdown timer, and messages, on a secondary monitor to help keep the talent on track. So, all I need is an example of connecting to the ATEM Production Switcher (1 M/E in my case) and keeping track of which camera is active - in VB. That way I can put a directional arrow on the same display to point to the active camera. I don't have a Decklink card and I probably confused things by including the decklink api in my previous post.

I really need to update my skills to C#, finding VB examples for anything these days is pretty difficult.


Software controlled VGA switcher

Perhaps this should be a thread of its own.

For your application how about one of these:
controlled by your VB program. Read the tally lan packet and
send a serial command to the VGA switcher showing your
computer's screen on the appropriate monitor.
I think serial communications and reading LAN packets comes standard in VB 6 (winsock).

Another method, I thought you were referring to, was taking program out from the ATEM
into a Decklink card and overlaying the timer and message to talent, then feeding that
signal to the ATEM Studio Convertor (or a HDMI splitter) to all monitors.

As I posted elsewhere, I have

As I posted elsewhere, I have a simple app that sends UDP tally data for the program/preview bus.  It supports dual-program tally for transitions, but is currently restricted to the first M/E and does not take into account keys or AUXs.

I have it talking to an Arduino which is simply sending digital pins high/low depending on which should have tally.  It's nowhere near as elegant or feature-filled as the full-blown Arduino solution (much respect guys - that protocol is a bit of a nightmare), but it's stable and easy to get all manner of things to work with.

ATEM / Arduino Library Update announcement

Hi folks,

Old thread, but so many people potentially interested:

Just wanted to bring your attention the the latests update of the ATEM Arduino Library. It now supports (and maybe requires) Arduino 1.0.1 released in may. The UDP problems seems to be gone now.

Also, if you are interested in development ATEM hardware on this platform I have made some DIY components ready for sale and/or DIY at

Finally you will find a lot of new case stories at this YouTube channel.

Have a nice weekend!

- kasper

MIDI to Atem 1


I'm looking for a driver to convert incoming MIDI signals and output the LAN information for the atem.

Do you know such program?


MIDI controller-->Arduino---> ATEM

Hello all ,
Sort of what Peter was asking....

I was curious if it would be possible to use a MIDI controller to control an ATEM directly with just an Arduino and no extra computer?

I know that people have built MIDI controllers with Arduino's, just not sure it would work with an ATEM + Kaspers library.

So the code for  both exist for Arduino, should just be a matter of putting both of them together right?

It would be best if it had some sort of mapping functionality via LCD display. That way you could use any MIDI controller and map it to your arduino controlled ATEM.


Peter wrote:


I'm looking for a driver to convert incoming MIDI signals and output the LAN information for the atem.

Do you know such program?


We're about to build exactly that.

Our goal is to allow any (windows-based, at the moment) show-control system that supports MSC to control an ATEM.
Our current focus is SFX, but I'd like the solution to be generally useful.

In an attempt to not reinvent the wheel, I'd like to know if there has emerged a "community standard" for MSC to UDP mapping, or we should just choose our own.
Are there any projects that would be an obvious starting point? I know about Kaspars arduino libraries and Joys dll, but if someone had a partial solution that could be easily extended it would save us some time.  

Best regards



MSC is kind of a stange out branch of MIDI. It's poorly supported by hardware and wouldn't be the most useful way of controlling ATEM for MIDI users.

IMHO the best method to use would be a freely mappable MIDI system, where Note-on and CC messages could be mapped to specific ATEM commands.

This would allow for control from affordable midi hardware such as the novation launch pad. For the best user experiance the MIDI protocol should be bi-directional - providing feedback from the ATEM via MIDI (note / CC) to allow for hardware controllers which have lights to indicate the ATEM status.

This would work well for all the popular show control solutions too - SFX can happily send MIDI (note / CC) Cues without needing to use the MSC extensions of MIDI which do not play well with hardware controllers.



Hi Tom

I'll have to use MSC for triggering a grandma anyway, so I've got no problem with sysex. As it has a subclass for video devices, it just seemed "the right way" to go.

I hadn't thought of the two-way communication, but it makes perfectly sense... Since I'm using a programmable USB keyboard (like those for cash-registers) as interface, I don't have any light-indicators, but we might as well support it.
Would you have any pointers to documentation of how this works (returning values to a controller)?

As for the freely mappable MIDI commands, I think it would be leaner to leave that to an external tool.
Maybe I don't understand how others would use this, but I'd be connecting it through midi-ox, which already has a mapping function. That way, different controllers could easily be supported by different midi-ox map-files.

Am I making sense, or am I hampered by a limited view of usage scenarios?


The trouble is that MSC is

The trouble is that MSC is not really implemented on any common midi hardware. And its considerably more complex than is needed for basic control.

There is no point in an app which needs MIDIOX to work. The app should take input from standard MIDI controllers and directly control the software. Mapping the MIDI controls to the ATEM functions should be a core part of the app - not something to pass onto MIDIOX.

I would go and buy a Novation Launch Pad this is a great controller with light up buttons and a fairly standard MIDI map. (no 2 controllers have the same MIDI implementation and the trend these days is for fixed MIDI assignment in the hardware as pretty much all music software has freely assignable controls - this is a very important thing to note if your interested in wide compatibility it is essential to allow users to map the midi in your software - fixed assignments are a thing that most music apps left behind in the 90's!) 

It is little to no work to allow for free MIDI assignment - having it will greatly improve the appeal of your app and make it easy to use without needing to rely on 3rd party MIDI translators which add a layer of instability and latency into the system. 


Don't you need some sort of midi loopback if you don't have (or need) a hardware midi interface in the PC?
That's why I initially used midiox. But then again, I never had a hardware midi control surface.

I guess my unix upbringing shows; having small programs each doing one thing well, and then stack them as needed.
But your point is taken. If the general usage scenario doesn't need midiox or equivalent, then the mapping functionality should probably be moved (or in my usage scenario, duplicated) into the app.

Yeah i can see from a unix

Yeah i can see from a unix point of view that you would keep everything "lean" and then end up running a load of little apps which each did a specific task. Windows sucks though and you get lots of timing issues when your running multiple apps as so much depends on the dynamic resource allocation which is not well managed by the OS. 

MIDI loopback is needed if your sending MIDI commands from one app to another. A MIDI (hardware) interface is needed if your connecting hardware devices, though most hardware these days contains a USB MIDI interface - so you can just plug and play via USB with the hardware appearing as a MIDI In/Out device in device manager.

I totally recommend getting some kind of MIDI hardware just to see how these devices work, if you don't want to drop the cash for a novation launchpad then i would take a look at the Korg Nano range these cost less than a decent meal in a restaurant and are as such very popular controllers.

Try using the controller with a demo version of Abelton Live - seeing how midi is handled in such a popular music app will be a great help when you try to make it work in your own app.

I created my own experimental tally box - but I have a problem

This weekend I started creating my own experimental arduino-based tally box. I use a sainsmart mega with sainsmart ethernet shield, both compatible to arduino.

I also used Kaspars atem library and the tally-example. The ATEM is a TVS with actual firmware.

All works fine, but:

1.) The tally starts working, when choosing a not selected source on control-Software. Before, there is no visible tally. What could be the problem ?

2.)  During a dissolve (or wipe), the tally shows correctly two program-out, but also additionally the "old" previev. After ending the transition, the tally freezes for 7 seconds. During this time, no changes on program or previev are displayed. (But the control software does). After 7 Seconds, the tally respond only to new changes. It don't show the current status.

Could someone help me ?

Thank you.

Thomas  S e e w a l d - thos-berlin (amateur)

Missing TlIn during initialization

thos-berlin wrote:

This weekend I started creating my own experimental arduino-based tally box. I use a sainsmart mega with sainsmart ethernet shield, both compatible to arduino.

I also used Kaspars atem library and the tally-example. The ATEM is a TVS with actual firmware.

All works fine, but:

1.) The tally starts working, when choosing a not selected source on control-Software. Before, there is no visible tally. What could be the problem ?

2.)  During a dissolve (or wipe), the tally shows correctly two program-out, but also additionally the "old" previev. After ending the transition, the tally freezes for 7 seconds. During this time, no changes on program or previev are displayed. (But the control software does). After 7 Seconds, the tally respond only to new changes. It don't show the current status.

Could someone help me ?

Thank you.

I think you are missing the TIIn packet that is received before InCm incoming packet.  (In)itialization(C)o(m)plete.
Kaspars initial code only looked for a change in packet length to signal initialization complete.

During a dissolve the tally bits will change from only one bit to both bits to finally the other bit.  (2 bits of 8 per tally)
I am not sure the of the 7 second  freeze unless your device fails to respond and in time and eventually is
disconnected.  It reconnects and catches up.

It my be, that the Arduino

It my be, that the Arduino looses control for 7 seconds. The result is the same as, when starting the Arduino - no actual state is displayed.

Kasper, how did you solved the problem ? Has any other any idea ?

Thomas  S e e w a l d - thos-berlin (amateur)

The 7 second control loss

The 7 second control loss sounds like the ATEM looses connection to the Arduino, then after some seconds the arduino re-initializes and is back. Why this happens is difficult to say, in my setups it doesn't. Could be hardware, could also be software (if you changed my sketches much - for instance, don't implement normal delays!)

The state issue is unfortunately unsolved. It relates to the fact that the ATEM switcher originally sends around 15-20kb information to the client (the Arduino) but so fast that the ethernet buffer cannot be processed before the next packet arrives. I haven't been able to solve this issue yet. It means that some state information is missing upon reset/boot. However, it comes as soon as something changes. So, in the cases where the ARduino does not pick up Tally info during boot it will get it as soon as someone changes inputs.

There are three possible outcomes of this issue:
- Either we/I manage to figure how the arduino can process the incoming packets fast enough. Could be changes to the buffer numbers and size, could be something else. Any help is welcome.
- Or we/I manage to figure out how to specifically _ask_ for state information that we like to know about. Or to ask the ATEM to resent a packet which we missed. This is going to be guess work though since I haven't observed that behaviour on the network between atem units.
- We find a faster platform than the arduino, could be a raspberry pi. But that's a lot of work and something entirely different anyway.
- We don't solve the issue; we learn to live with a work-around where the arduino has to indirectly get the information it needs by making tactical changes to the registers in the ATEM switcher so that it will send state information back.

Thanks Kasper

Hi Kasper,

thank you for your response. The sketches were modified, but smaller ;-)

May be I'll try an original Arduino, because i recently use a compatible called "Sainsmart". I'm wondering, why the connection will be lost during an autotake (dissolve), but it seems really to be a lost connection.

"- Either we/I manage to figure how the arduino can process the incoming packets fast enough. Could be changes to the buffer numbers and size, could be something else. Any help is welcome."

Sorry, I have not enough knowledge to help.

"- Or we/I manage to figure out how to specifically _ask_ for state information that we like to know about. Or to ask the ATEM to resent a packet which we missed. This is going to be guess work though since I haven't observed that behaviour on the network between atem units."

"- We find a faster platform than the arduino, could be a raspberry pi. But that's a lot of work and something entirely different anyway."

I hope, this isn't necessary.
"- We don't solve the issue; we learn to live with a work-around where the arduino has to indirectly get the information it needs by making tactical changes to the registers in the ATEM switcher so that it will send state information back."

This could be a good workaround.

Thomas  S e e w a l d - thos-berlin (amateur)

An autotake is a good example

An autotake is a good example of something that might throw you off - because a lot of packets are passed (maybe 60 per second) and must be responded to - and if the arduino doesn't do that, the ATEM switcher gives up on it.

However, trying another Arduino might be a good idea since at least my experience is that it normally does not loose connection under these circumstances.

That being said there are probably optimizations to be done to my work.

Are you using a fast or slow switch on the network? I'm not sure how much it would matter, but maybe there is a difference whther you use a gigabit switch or a slow hub.

Soekris Engineering

These are probably in most hobbyist opinions an overkill,

They do have a GPIO that could be used for tally.  

I have used these for wifi hotspots in the past.

AtemSwitcher.changeTransitionPositionDone() forces tally display

I tried a call of "  AtemSwitcher.changeTransitionPositionDone();" as "tactical change" in the setup-function.  It forced a correct tally-display when starting.  Curiously, since this time, the disconnects are less (it seems so)....But maybe I had network problems, because I develop in my living room and the atem ist in my "office". In between there are two GBit swiches (netgear) in a chain.

Thomas  S e e w a l d - thos-berlin (amateur)

Hi Kjeld, nice little script,

Hi Kjeld,

nice little script, as far as I could judge it with my basic turbo pascal knowledge ;-)

If I do the terminal input on my macbookpro :
cd ~/Desktop
gcc -framework Carbon -o GetCurrentKeyModifiers GetCurrentKeyModifiers.c

the gcc command is not found.

Is this the right command?

I would like to try the routine on our blackmagic TV Studio to have automated camera selection. Is there also a way to do random selection with random times?

Many Thanks for your help


Control and tally

In a few posts, there would be said: "Why don't we use two arduinos for complex themes, one for control and one for tally ?" This is not nessessary, when the control unit has illuminated buttons. This is tally. You only has to breakout the signal for the LEDs in the program bus buttons to relays. There is an relay-unit for arduiono. When arduino's output has not enough power to drive both, maybe a simple driver IC or transistor can do the job.

Thomas  S e e w a l d - thos-berlin (amateur)

Hi Kjeld, testted the script

Hi Kjeld,

testted the script on a TVS: Works nicely.
Instead of
keystroke "1"
you should use
keystroke "1" using control down

to control the program switching, otherwise you just switch the preview as the keyboard shortcut is ctrl+1 fro channel1 on program.

thanks nice work.


Control Surface

Hi everyone,

I am still waiting for my 1 M/E to arrive and I'm really excited. I have been looking at alternate ways to control it. One has been x-keys, the other a unit like this:

Novation - Zero-SL-MKII.

Just wondering if a device like this would be hard to map or would it be the same procedure as the x-keys?


Header bit 7

I'm not sure if anyone has filled this in yet, but I believe bit 7 of the header is transmitted from the ATEM when a message has been skipped. For example, if it recieves counter K value 0x00,0x01 and the next message it recieves is 0x00,0x03, it will respond with bit 7 in the header, asking what message 0x00,0x02 was supposed to be. The message counter it is looking for appears to be bytes 7 & 8 in the message, followed by 0x01,0x7B,0x00,0x00. The example return is: 0x40,0x0C,UH,LH,0x00,0x00,0x00,0x02,0x01,0x7B,0x00,0x00.

Hope that helps,


ATEM 1M/E 4k

Does anyone know if the 1M/E 4k uses the same protocol ?
(of course again with modified source IDs)


ATEM Protocol

Hi all,

this post from Ratte is a very interesting and useful post.

In my application I am now able to connect to Atem and deal with it but need to keep the connection active and select the preview input and Cut. No need to manage the status and parse the responses, just to select preview and CUT.

Can you show me a very simple connection sample even with no ACK?


Thank you very much

Fabrizio Lorenzini - Intermark Sistemi -


what OS platform?


Perhaps a separate thread?

I have code for Linux and Android. Can be used on most machines as written using Qt.


ATEM Protocol study

ATEM protocol document is not released  yet (since years), and it seems
The main problem for me is to understand the meaning of byte position #10 inside the hexadecimal 80 0c message.
Explaining a little better .... I am sniffing packets between ATEM Software Control and ATEM Television Studio

ATEM SOFT.CONTROL -> 10 14 2e 07 00 00 00 00  00 ec 00 00 01 00 00 00 00 00 00 00 (HELLO)
ATEM TVS -> 10 14 2e 07 00 00 00 00  00 20 00 00 02 00 00 33 00 00 00 00 (HELLO RESPONSE: yes, tell me more)
ATEM SOFT.CONTROL -> 80 0c 2e 07 00 00 00 00  00 ab 00 00 (STARTING DIALOG:I am here - PLEASE LOOK AT THE ab)
ATEM TVS -> 30 14 2e 07 00 00 00 00  00 20 00 00 02 00 00 33 00 00 00 00 (HELLO RESPONSE: yes, tell me more - SECOND REQUEST)
ATEM SOFT.CONTROL -> 80 0c 2e 07 00 00 00 00  00 f9 00 00 (STARTING DIALOG:I am here - PLEASE LOOK AT THE f9)
..... ATEM Software and ATEM TVS exchanges data .....
It seems that  ab and f9 are strictly depending on the uuid 2e 07

So, what does that byte means? and how can I calculate if the uuid is different ?

Thank you very much
Fabrizio Lorenzini


You should direct your

You should direct your attention at this topic:

Which links to Kaspar's work decoding the entire protocol which he published here:



Thanks John,   In fact, our

Thanks John,


In fact, our page only describes the individual commands for getting and setting values, none of the handshaking is really documented there, but if you look inside our implementation or the one from Peter Simonsen (QT lib), you can kinda see how much we know. But in any case it seems irrelevant what that byte does. It may even mean nothing at all. For all practical purposes it doesn't matter unless you see it in our implementations.

On the other hand, the first byte which is "01": For this, the second bit which is set in the second response ("03") means "resend" as far as I remember and you'll see the ATEM switcher respond with a resend message if you are not fast enough to respond to it. I always interpreted this "extra" package in the handshake as... well redundant. I think if you just send the first "Hello" you may see the switcher issue a few more of these...


Let us know if you think it's important in some way to understand further.


- kasper

I need to further understand

Thanks John, thank Kasper,

yes I need to understand further, as I must control ATEM Television Studio, even in a minimal way, and can't fail.

I need to keep the dialog active and select the camera preview and cutting. I don't need to know the TVS status.

I already know the commands to select preview and command for cutting.

So, for me it is very important to go onwards and succed in keeping the dialog active.

After receiving a ping response from TVS

0x10 0x14 uuid_high uuid_low  ....

0x30 0x14 uuid_high uuid_low  ....

I reply with

0x80 0x0c uuid_high uuid_low .... (same message twice)

I receive hundreds and hundreds of data bytes information but after a minute I receive

0x10 0x14 (uuid_high-0x80) uuid_low  ....

0x30 0x14 (uuid_high-0x80) uuid_low  ....

Even if I reply with the same 0x80 0x0c messages above and with uuid_high-0x80 the TVS does not respond as previously

I will do some other attempts for the whole day today

Please, help me.

Thank you


Protocol Loop

See my post about the protocol:

1) You need to keep the connection alive, reconnecting too many times to the ATEM makes him dizzy.
I found that out the hard way during a job ;-)

2) Have a look at my

There's all about the ACK and ACK REQUEST documented.


which hardware platform


If you tell us the platform and software language we can send you a working example.

I have got success

Hi all,

I have got success, now I get a stable connection with Atem TVS.

The control system is AMX.

Ratte, your post about protocol was very important for me

Thank you very much