ATEM Software Control overriding aperture/shutter settings

Hi everyone,

Is there any way to stop the ATEM Software control to override aperture and shutter settings on the Micro Studio Cameras (and possibly the other studio cameras as well)

Here's the problem. We made a custom iPad app to control our setup of five micro studio cameras.
It all works nicely, but as soon as the ATEM Software Control logs in, it overrides the aperture and shutter settings to what is set on the ATEM Software Control (overriding aperture settings on our app and also settings changed on the camera itself)
It does so only with aperture and shutter. White balance, gain and focus for instance sync nicely (meaning if we change the setting on the app, it changes in the ATEM Software Control automatically and vice versa).

I know this is supposed to be a feature as it is documented in the manual.
But is there any way to turn this off? Ideally having the settings sync just like it works now witch gain, white balance and focus. Perhaps adding a toggle to turn the ATEM Software Control override on/off?

I need to be able to use the ATEM Software Control alongside our app. Right now this is not possible.

I imagine this to be an issue with JustMacros or the Skarhoj hardware solutions as well. How did you guys solve that?

Any help would be much appreciated.

Cheers,

Daniel

Just a guess, but if the lens doesn't return a value for aperture/shutter, there's no way for the software to "know" where it is. Someone has to be a hard "master" in that case. What lens are you using?

-Evan

Thanks for the input Evan, but i don't think the lenses are to blame. The lenses do return the aperture value, it is visible in the status overlays that you can turn on for the HDMI out. Since the aperture on the MFT and EF lenses I use are only controllable through the camera, I can't imagine how this value should not be readable from the camera. I will check back with our app developer though and ask if the current aperture value can be read from the camera.

I tried with these lenses:
Panasonic Lumix G 25mm/1.7 MFT
Panasonic Lumix G 20mm/1.7 MFT
And a Sigma 17-50mm, f2.8 EF (w/ Metabones Speedbooster BMPCC)

Actually, I would be fine with the ATEM software control not showing the change of value if done manually on the camera or with another app. My issue is, that the ATEM software control keeps sending it's own aperture and shutter values, thereby overriding any other setting.

Cheers,
Daniel

Actually, I would be fine with the ATEM software control not showing the change of value if done manually on the camera or with another app. My issue is, that the ATEM software control keeps sending it's own aperture and shutter values, thereby overriding any other setting.

What...... No....... This must be a joke, as what you are saying is running the BMD ATEM control software within your live environment in a risk.

Oh Yeah, I've been saying that for years......

This is not a surprise, not a shock, not new news, just another reason to ban it's use within your live environment, or live with its shortcomings & risk.

Just like you cannot connect a MIDI device to a computer running the BMD software unless you intend to use it in Mackie mode to manage the embedded audio mixer, you have defined another use-case whereby you cannot run the software. If you want to use the CCU in a meaningful way - DO NOT RUN the BMD software.

Sorry to be slightly coarse, but seriously......

Hi John. Thanks for your uplifting input
Well, eliminating the use of the BMD Software Control from critical live applications is exactly what we are working on. We are a young company in the process of building a most mobile light weight live-production setup that can be operated by a small team.

For the Switching part we are already using a Xkeys/JustMacros Setup that works nicely and so far reliably.
As we got several Micro Studio Cams recently we are now trying to get a similar thing going with the CCU.

Unfortunately, as far as I can see, there are no proper BMD CCU hardware solutions on the market currently (Skarhoj seems to have something promising in the works though). I find the BMD ATEM Software Control totally useless to actually control a camera. (I dare everyone to try getting anything in focus with that "focus wheel". Does anyone actually work with this?) So we decided to make an ipad app to change settings on the Micro Studio 4Ks and to make the CCU (especially pulling focus) somewhat usable as an intermediate solution until the Arduino shield arrives and we can get or make our own real hardware solution.
The only issue is, that our app does not cover everything yet (we did not implement the whole davinci color wheels part and we still use the ATEM Software Control for loading gfx into the ATEM or changing settings).

I'm fine with the BMD Software Control not being useful for our use case. I just wish it would not sabotage us . Having their own software overriding any other applications kind of defeats the whole idea of providing an SDK for the CCU in the first place.

Would be great if someone from BMD could explain that design decision. I'm referring to this part in the ATEM manual, page 54, "Using ATEM Software Control"

Synchronizing Settings
When connected, camera control signals are sent from your ATEM switcher to the Blackmagic Studio Camera. If a setting is accidentally adjusted from the Studio Camera, camera control will automatically reset that setting to maintain synchronization.

Cheers,
Daniel

Sorry if my sarcasm was offensive.

But when you've been telling people to NOT use the BMD software in mission critical scenarios for as long and I have, your surprise you were having problems, is fairly surprising.

You can try reporting the problem directly to BMD via their support services, and I wish you luck with that. Perhaps they will resolve, perhaps they will not.

I'll say I would be willing to bet they won't comment here, and that may itself help you, as they do love to be contrary. But peer to peer and all that, you mentioned JustMacros, so that was an invite for me to reiterate my point.

I've told the story many times, Stage blacked out on ATEM Audio transition at start of show, as someone had hooked up a DMX desk via MIDI in order to program lighting sequences on the same computer they were running the BMD software on (for no reason) after being told under no circumstances to run the BMD app once the show was started. And if you think I was too nice to say "I told you so" to the Muppet involved, you would be very mistaken.

There are plenty of other things wrong with the BMD ATEM app, such as it's un-configurable desire to download every media pool item you upload. Try putting 10 mixers on your network, and uploading stills continuously to them all, see what effect running 10 instances of the BMD app "for monitoring" does to your upload performance..... and so on.

I wish you good luck with your system integration, I want to see as many 3rd party tools for the ATEM available as is feasible and possible. So this issue should provide additional pressure for you and your guys to get it done.

I promise the BMD app isn't trying to sabotage you, it just doesn't care what you want to do. It's only purpose is to expose the features of the ATEM to a user in a pretty way. For many that is fine, but users cannot really complain when it does unexpected or undesirable things to their shows.

If using the BMD app, test test test and then test some more - which is never bad advice anyway!! Don't waste time and energy worrying about the BMD app, just get on with building your system, and give the BMD app the attention it deserves - None.

Once again wishing you Luck & Success with your project.

John

Thank you very much, John

Absolutely no offense taken, advice from experienced colleagues is always much appreciated. And I don't mind sarcasm at all.

Don't worry, we don't do our testing at our live shows. The CCU setup is still in in-house testing stage and will only make it to critical live use once we have a stable and reliable solution.

Looks like we still have quite a bit of more work ahead of us to get to that solution.

Thanks for all the other insights, good to know what to avoid.

Cheers,
Daniel

We found a solution!

Just for reference: page 37 studio camera manual: "developer information":
There are 3 ways the SDK allows to send aperture values:
1. The f-stop value itself (actually an aperture value (AV) which calculates fstopvalue=sqrt(2^AV)
2. A normalised value (basically a percentage points value for which 0% is aperture wide open and 100% is totally closed)
3. Aperture (ordinal).. a value 0,1,2,3,4... to n where each value represents one stop.

The ATEM software control uses the normalised value (and we had used the ordinal value) - therefor the two did not communicate. I get it why they use the normalised value as the number of f-stops differs depending on the lens used. But still: Lazy programming on BMDs side for not reading the ordinal values from the ATEM as well. We changed our app to send the normalised values as well and now they communicate properly. It sucks though since we want actual f-stop values to be shown in our app, because now we need to build a complicated calculation to transform meaningless percentage values into accurate f-stops (and differently so for each lens we use).
Btw. Using the F-stop value seems broken in either the camera firmware or the ATEM firmware. If I send the AV value 4.0 which should translate into f4.0 as well - the camera jumps to f4.0 but shows f16 (100% shut) in the overlay and the ATEM software control.

The same is true for shutter (exposure). You have to send the exposure values in microseconds (1.5) and not the ordinal (1.6) to make it talk to the ATEM Software Control.

So, here are the IDs BMD seems to be using in their software control and that work to keep it in sync:
Aperture (normalised): 0.3
Shutter/Exposure (us): 1.5
WhiteBalance: 1.2
SensorGain: 1.1

Maybe it helps someone.
Cheers
Daniel

Awesome find Daniel! I've been experiencing an issue with aperture not being saved and loaded in ATEM and my previous workaround was to manually change the fstop value parameter in the XML file.

However, now the software doesn't seem to be referencing the fstop value itself, only the normalized value (strange call to make in my opinion). I only see two parameters pertaining to aperture in the XML and treating the first fstop parameter as fstop or ordinal didn't seem to make a difference. After typing in a number for the normalized fstop value parameter between 0-1 (0 being 0% and 1 being 100%) I was able to at least restore relatively consistent fstop values on my Blackmagic Studio 4K Pros with Lumix lenses day-to-day.

If anyone knows how to force fstop values in ATEM by saving and restoring XML files please let me know! This is as far as I could get on my own.