FYI - new ATEM 4.2 crosspoint commands and status

15 posts / 0 new
Last post
Offline

Location

Sydney
Australia
Joined: 17/02/2013
Posts: 171
FYI - new ATEM 4.2 crosspoint commands and status

For those who dabble here are the new ATEM 4.2 crosspoint commands and status

http://www.lefflerpost.com.au/ATEM/new 4.2 xpoints.pdf

Contact me if you need more info

Baz

Where would I be without the 'undo' button

rcourtney's picture
Offline

Location

Eastern Iowa,
United States
Joined: 07/12/2011
Posts: 254
Qt Aux Control example

I'll look into my Qt example.  
Thanks.

Offline

Location

Sydney
Australia
Joined: 17/02/2013
Posts: 171
also note

Also note that the Aux xpoint command "CAuS" has changed from 4 bytes long to 8 bytes. The extra 4 bytes are needed, but atm don't do anything.

Where would I be without the 'undo' button

Offline

Location

Sydney
Australia
Joined: 17/02/2013
Posts: 171
MANY OTHER CHANGES

As I go thru my code I am finding more and more stuff they have changed like Supersource commands increasing by 16 bytes, keyer commands by 4, input names have 2 byte pointer rather than 1....

It really wouldn't have been that hard to implement these 'enhanced' protocols while maintaining backward compatibility but they just want to give us reverse engineering guys a hard time.

So far these are the things I have had to fix in my code...
Pgm xpoints and status
pvw xpoints and status
aux xpoints and status
Supersource xpoints and status
DVE xpoints and status
Upstream keyers xpoints and status
downstream keyers xpoints and status
Input names processing

things I still have to fix...
ALL audio controls including level, pan, ON/OFF, AFV
and all the other stuff I haven't yet discovered!

Where would I be without the 'undo' button

JohnBengston's picture
Offline

Location

London
United Kingdom
Joined: 14/01/2012
Posts: 1450
BMD actively trying to be annoying.... No..... Never.....
bazinoz wrote:

It really wouldn't have been that hard to implement these 'enhanced' protocols while maintaining backward compatibility but they just want to give us reverse engineering guys a hard time.

There is some historical precedence for this, I've written many times about the ATEMs SDK history, but the one that really stands out in my memory: Is when they changed their official Decklink Configuration Interfaces, I think it was at version 7.6. The crazy thing was; they allocated new GUIDs to all the old CONSTANTS, and new CONSTANTS to the old GUIDS. This meant the instant you recompiled your code, everything broke. It was an utter nightmare if you were on a deadline, and had to make a minor tweak to your code whilst keeping latest drivers and libraries for other reasons. So whenever that was, feels like a fair few years ago, made me very wary of updates from BMD, everyone loves an free update, but in the case of BMD, I always hold my breath after an update when checking my apps.

HOWEVER, to befair to BMD (ands it hurts to say that), I and I know for sure, some other developers, were told by BMDs OEM liaison, specifically not to develop against the UDP protocol, as BMD would, I quote, NEVER release the UDP protocol and be likely to change it. So this is not entirely unexpected.

Good luck with your changes, trust me, I know how you feel.

thos-berlin's picture
Offline

Location

berlin
Germany
Joined: 19/06/2012
Posts: 285
I hope Kasper will adapt his

I hope Kasper will adapt his arduino library soon ;-)

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

rcourtney's picture
Offline

Location

Eastern Iowa,
United States
Joined: 07/12/2011
Posts: 254
Keeping up with the Jones' (firmware versions)

I don't mind revising my code.  However, why is it BMD uses Qt for THEIR released software but force the rest of us to use Microsoft Visual C++/C#?

I admit that I may be biased because I love Qt and the ability to program for Macs, Linux, Android, and PCs using the same platform.
I do some projects in .NET just because.   

Other than the addition of audio back a few versions, there really has been no reason for me to upgrade BMD firmware.
Even then, My audio is mixed separately from the ATEM controller.  Thinking about  Software Audio Console in the future.

Good luck to those keeping up with the Jones'!

JohnBengston's picture
Offline

Location

London
United Kingdom
Joined: 14/01/2012
Posts: 1450
You are not forced to use

You are not forced to use Microsoft Visual C++/C#.

You can use pretty much any development tool you like. On Windows, anything that can import a Type Library from a DLL and implement COM will do the job, So GCC, PowerBasic, Delphi, FPC, Java, Lua, on Macs, pretty much anything that will compile a program will be able to load their APIs. They don't provide official SDKs for the other platforms you mention, their software may be using QT for visual components, but their App links to the exact same SDK interfaces they have exposed for users (pre 2.8 and post 3.5 anyway). Remove the SDK, see what happens.

Where the development language doesn't support COM directly, most have some kind of inter-op library interfaces.

I think there is plenty to knock BMD for, but I don't think their API/SDK policy is one of them at the moment. They've given us official and open access to almost the entire ATEM, and they haven't restricted the tools you can use, as you are suggesting.

Cheers

John

Offline

Location

Vanløse
Denmark
Joined: 08/10/2011
Posts: 62
I am working on an

I am working on an Arduino ATEM library update and have the basics in place currently. Should go to github in a few hours.

It's probably true that BMD has officially discouraged to code directly against the UDP protocol and if they maintained a library for Arduino or another MCU platform we would all just use that. But they don't and using Arduinos to control ATEM switchers has a lot of legitimate uses which could never be matched with a Mac or a PC and the official SDK. So I think it's a noble quest to keep reverse engineered implementations up-to-date and I still wish BMD would officially cheer the effort and provide help. I know from talks with high ranking BMD folks that they admire what we do. They definitely benefit.

A comment on the changes they made: I was actually very happy to discover that they finally cleaned up the numbers used for signal sources in the protocol. It was always a mess that the number for the color generator, media player etc. would change between models. So now I don't have to make my own abstraction but can simply enjoy theirs! Perfect. With regard to the other small changes: Well, we have seen many times before that small things change their place in the protocol but so far it was always easy to adapt to. This time it was just a big chunk, but definitely worth it.

- kasper

Offline

Location

Sydney
Australia
Joined: 17/02/2013
Posts: 171
yes but...

I agree with you Kasper, but you still have a few surprises that await you...

Especially when you get to the audio!

I have now completed all the required code adaptations for my full function 2 me panel
and tomorrow will do my other boxes including my dedicated TVS controller.

But I notice there is a new command code implemented which I think is the one I have been waiting for; full panel data.

I will strip it down next week and see what's in it

baz

Where would I be without the 'undo' button

Offline

Location

Vanløse
Denmark
Joined: 08/10/2011
Posts: 62
Great! You're right, I didn't

Great!

You're right, I didn't get to audio yet ;-) But it sounds like it's possible to figure out.

How did you come across the "full panel data" code, it sounds like something I have been waiting for very much, so please share a bit of info so I could help you to investigate it...

(What platform are you on, are you using the QT lib or a fork of my ATEM lib or something else?)

- kasper

Offline

Location

Sydney
Australia
Joined: 17/02/2013
Posts: 171
my atem history
kasper wrote:

Great!

You're right, I didn't get to audio yet ;-) But it sounds like it's possible to figure out.

How did you come across the "full panel data" code, it sounds like something I have been waiting for very much, so please share a bit of info so I could help you to investigate it...

(What platform are you on, are you using the QT lib or a fork of my ATEM lib or something else?)

- kasper

I began working on the ATEM interface as a request from one of my customers after doing them a Arduino BMD router controller.

I started off by analysing the UDP packages and writing trial and error code to duplicate it. This was a very long and tedious process.
Once I got the initial communications happening it was full steam ahead made easy by using 'device monitoring studio' which was a new program. It had bugs
and I helped the developer fix them but in the end it was worth it.

If you need any protocol help just ask.

Here is a list of the UDP data I have reverse engineered and am processing in my 2me controller -

"InPr"
"PrgI"
"PrvI"
"AuxS"
"SSBP"
"TlIn"
"TlSr"
"Time"
"TrPr"
"TrPs"
"TrSS"
"FtbS"
"FtbP"
"TMxP"
"DskS"
"KeOn"
"ColV"
"MPCE"
"RCPS"
"LKST"
"MPCF"
"FTDC"
"MPCS"
"MPSE"
"SSrc"
"TDpP"
"TWpP"
"TStP"
"TDvP"
"DskP"
"DskB"
"KeLm"
"KeDV"
"KeBP"
"KeCk"
"KePt"
"AMTl"
"AMIP"
"AMMO"
"Warn"
"_ver"
"_pin"
"VidM"
  
Here is a list of the UDP commands I have reverse engineered and am sending from my 2me controller -

"SCPS"
"MPSS"
"CKPt"
"CKCk"
"CKTp"
"SFKF"
"RFlK"
"KKFP"
"CKTp"
"CKDV"
"CKeF"
"CKeC"
"CKMs"
"CAMM”
"CAMI"
"CKLm"
"CTDv"
"CDsM"
"CDsG"
"CDsF"
"CDsC"
"CTSt"
"CTWp"
"CTDp"
"CPgI"
"CPvI"
"CAuS"
"CSBP"
"CSBP"
"CSSc"
"FtbA"
"CTMx"
"CDsR"
"FtbC"
"CTPr"
"CTTp"
"CKOn"
"CTTp"
"DCut"
"DAut"
"CDsL"
"CDsT"
"DDsA"
"CClV"
"CTPs"

I think thats all. Let me know if I have missed any.

Each one of these items had to ve detected, stripped down, analysed, trialled and errored etc etc so you can imagine my surprise when BMD change them!

Baz

Where would I be without the 'undo' button

Offline

Location

New York City
United States
Joined: 13/09/2013
Posts: 17
How's your progress Kasper?

Hi Kasper,

I've downloaded your preliminary updated library from Github. In looking at the cpp, I'm not 100% clear if the Downstream Key Related commands are 4.2 compliant. Is this the case? Thanks for your great work on this ongoing project. Btw, I left a note for you at Github regarding CDsR. I've found I use this one a lot.

 - Tom

 - Thomas Strausbaugh    Tomcat TV

Offline

Location

Vanløse
Denmark
Joined: 08/10/2011
Posts: 62
Hi Tom, I think most of the

Hi Tom,

I think most of the DSK things is compatible and thanks for the patch btw. Let me know if you find something which is not working. I'm busy with something and also planning a major clean-up of the library, so that's why I may be a bit relaxed about it all.

Offline

Location

New York City
United States
Joined: 13/09/2013
Posts: 17
Thank you

Thanks Kasper,

One more quick thing. Do you know what the returned strings are from getATEMmodel for the 4K models? I don't have access to any of these so I can't test.

Thanks again,
 - Tom

 - Thomas Strausbaugh    Tomcat TV