Macro recording bug

Hi all, I have found a bug in macros. It concerns all ATEMs, as it originates from fact,
that developers probably omitted to save concurrent use of NextTransition Buttons.

Do this:
Start ATEM. NextTransition is Background.
Record macro A: Add Key1 to NextTransition (both Background and Key1 light up).
Record macro B: Remove Key1 from NextTransition.
Record macro C: Add Key1 to NextTransition and remove Background.
Record macro D: Remove Key1 from NextTransition and add Background back.
Run all macros, they work well.
Actually B=D.
Save macros.
Restore macros.

Now A does not work,
due to that it has no record in xml file.

It is because these lines in xml file
<Op id="TransitionSource" mixEffectBlockIndex="0" source="Key1"/>
<Op id="TransitionSource" mixEffectBlockIndex="0" source="Background"/>
works as a switch, not as a add/remove selection to button,
so for macro A was no information saved
(we added Key1, but Background remained).

Can this be fixed?

Regards,
Karel Holubicka

This is simply due to the difference between the Software Mix/Effect representation and a real control surface.

On a real control surface - including the BMD Panels, in order to select background and Key1 into the next transition, you'd push the two button simultaneously, the buttons are not toggle in and out as they are on the software.

Hence when recording a macro from a control surface your first and second step are a single action "pushing Background and Key1 with two fingers at the same time". Thus if recording your macro from the panel, it would work correctly and exactly as expected. Because you are trying to record from the software, you need to be extra careful to ensure you are setting up your initial state going into the sequence, and normally you'll have to manually edit the sequence, or at least restore a preset / snapshot at the start of your sequence.

This is not a bug in the BMD Macros system, it's a mindset thing, for example if your transition mode was set to DVE and USK1 was set with a Fly position, your macro also would not work. You need to ensure macros FULLY and effectively set their initial stating state.

Good Luck and please consider reading this:

http://www.atemuser.com/forums/atem-vision-mixers/blackmagic-atems/just-macros/atem-macros-justmacros

Hi John,
thanks for the reply.
I understand your point, however,
I maybe did not describe the problem simply enough:

1/ I record macro succesfully and it works.
2/ After save-reload, it does not work, even from THE SAME initial state.
This is unexpected behaviour.

Given the same initial state,
macro should work regardless if it is recorded
just from the surface,
or recorded from surface&saved&reloaded.

I am not mentioning here creating macros with help of other SW,
details of XML I provided just in belief that I am able to track where are roots of the problem.

Have a nice day,
Karel

You are going to have to post the XML that you've saved to explain this further mate.

Try mine:

http://www.justmacros.tv/downloads/other/KarelTest_All_4_Macros.zip

This basically is a re-creation of your report, except..... I added a USERWAIT at the beginning of Macros A,B and C, and to prove that wasn't the difference, on D I didn't include the user wait.

I then deleted the macros and restored them from the XML - Several times. Everything works just as expected.

I maintain this probably isn't a bug in the BMD Macros system, but if a command is missing from the XML, it is because you didn't record it correctly, and I urge you to think again about your initial states when recording. I often add lots of USERWAITs into sequences when designing, so that I can be sure of what is happening when. Only when I am sure it's correct do I remove the USERWAITs or replace with SLEEPs - You'll probably need to switch to XML editing for this.

Maybe give this a try...

Hi John,
thanks for your interest.

>>it is because you didn't record it correctly
I will repeat myself - once recorded, works FINE.
Do do not mean "while recording", i mean
"played recorded macro using macro play button" is fine.
But,
after save and reload,
it does not work, even from with then same condition.

I downloaded your test and will test it later.
BUT,
I will get to work with this ATEM1 no sooner than in January, so until now - Marry Xmas

Have a nice day,
Karel

I do understand what you are saying, and in "the nicest possible way" : I simply cannot re-produce what it is you are saying, since I totally depend on this functionality working, I would be super-worried if Macros started losing commands when they are re-loaded.

Perhaps you are including a step not covered in your description that prevents anyone from re-producing the problem.

Perhaps your mixer is faulty. or needs a downgrade and re-upgrade.

I don't know how I can be any clearer, what you are describing is unique to you, tested on multiple mixers - 2ME / 1ME, 4K and original types. Are you using TVS?

If you publish an XML file containing macros that don't get reloaded properly then other users (on-a-peer-to-peer-forum) might be able to recreate and therefore help you track your problem.

hope you have good holiday period too!!

Ahh, now I see how important it may be to you too.

I did all this on ATEM-1 with 6.4 drivers, in May.
I should be doing the same thing with the same ATEM-1 in February 2016.
I believe this ATEM is still kept at 6.4,
so I will try to reproduce the problem and record it to a videocamera,
and see, if problem survives upgrade to 6.6
(in case if ATEM-1 owner decides for upgrade.)

Have a nice day,
Karel

Problem solved.
After upgrading to 6.6.1,
saved macro lines behave fully as status lines,
and proper status line is also recorded for Macro A from my example.
(resp. for it's result)

<Op id="TransitionSource" mixEffectBlockIndex="0" source="Background, Key1"/>

So John, you were right,
at the time you have found my May's post
it was probably already fixed.

Have a nice day,
Karel