🌿 New sprout. This tool is freshly built and still being tested against real ATEM exports — double-check anything that looks off before relying on it.
Reading ATEM macro exports in plain language #
ATEM Software Control can export a macro pool as XML, but the raw file is close to unreadable — a single macro can run 250+ lines, because the macro recorder dumps the whole state of a keyer or SuperSource box even when only one thing changed. This tool loads that export and turns each macro into something you can read.
Drag a macro-export (or full config) file onto the row above, click Code to paste XML directly, or pick up a config you loaded here recently. Once it's loaded the loader collapses to a single line, and the panel on the left offers four ways into the pool.
Load a full config, not just the macro pool
Everything below works better — and some of it only works at all — with a full config export rather than a macro-pool-only one. A full export carries the switcher's own naming tables and its captured state, which is what lets the tool say "fill from 5 - PCAM 5" instead of "fill from Camera5", and draw a macro in context instead of in a vacuum.
Finding a macro
- List — every macro by slot and name, filtered by name or description.
j/k(or the arrow keys) step through the list,/jumps to the filter,Escclears it. - Pool — the macro pool as a grid of slots. Macro indices are sparse in practice (0, 1, 2, 4, 5, 18, 19, 24…) because the pool is slot-addressed: that number is what a panel button or a Companion action fires. The grid shows which slots are taken and which are free.
- Usage — the pool read backwards. Pick a target (ME1 Key2, SuperSource 1 Box 3) or a source (a camera, a media player) and see every macro that touches it, and how many Ops each one spends on it. This is the "if I re-patch camera 25, what breaks?" view.
- Diff — compare this config's macro pool against another one you've loaded recently. It compares meaning rather than text, so it reports "SuperSource 1 Box 1 · source: 5 - Wide → 20 - Player PIP" instead of a wall of moved lines.
Whichever you use, the selected macro goes in the address bar (?macro=24), so a particular macro can be linked to or survive a reload.
Reading a macro
A macro is a sequence, so it's shown as one: a numbered list of steps in execution order, each naming the target it acts on and what it does there in plain language. A run of Ops on one target collapses into one step; a target the macro comes back to later gets its own step, which is exactly the detail a per-target summary loses.
Three reading levels:
- Summary — the steps that actually do something. If steps are left out, it says how many and why.
- All changes — every step, geometry and cosmetics included.
- Raw Ops — the complete list, exactly as ATEM exported it.
Clicking a step's target chip folds out the raw Ops behind that one step. With a full config loaded, Ops that set a value the switcher already had are dimmed, and the card says how many there were — that's measured against this switcher's own state, not guessed from what defaults usually look like.
Copy as Markdown turns a macro (or the whole pool) into a table you can paste into a wiki, a handover doc or a show binder. Printing gives the selected macro the page on its own.
Show Layout
A macro is a patch, not a picture. A macro whose only Op is DVEAndFlyKeyXPosition says nothing about that key's size, fill or on-air state — so drawing "the macro's layout" from its Ops alone is either empty or quietly misleading.
The layout is therefore always drawn as a base plus this macro, and you choose the base:
- Switcher state from this config — the state captured in the export, which is what makes a one-Op macro readable at all.
- After macro #N — the state once another macro has run, since that's how macros actually stack at showtime.
- No base — this macro's Ops alone.
Three kinds of fact are drawn differently rather than flattened together: what the macro set is solid and accented, what it inherited from the captured state is dimmed, and what nobody stated anywhere is dashed and never filled in with a guess. Hover any element to see which of its numbers came from where. Because a macro is a change, the drawing shows one — the element's position before the macro ran, as a ghost outline with an arrow to where it ends up.
The frame is drawn with a gutter around it, so something parked outside it (a "hide the PIP" macro moving a key to x=30) is pulled back to the edge and labelled off frame rather than clipped away. A keyer whose DVE geometry isn't live — not a DVE key, fly disabled — is marked as such instead of being drawn like an on-air PIP.
What the drawing does not claim
The coordinate system is inferred from mask boundary values in real exports (a 32 × 18 frame centred on the origin), not documented by Blackmagic, and has not been checked against a live multiviewer. Crop is listed per element but deliberately not applied to the drawing, because whether it scales with the box is unverified. The number of Ops that change things a layout can't show — key tuning, borders, transitions — is stated under the drawing, so the picture never implies it covers the whole macro.
A note on defaults and unknowns
There's no official documentation of this XML format from Blackmagic — only the separate Streaming XML format (for RTMP providers) is documented. Everything the tool knows about Op names, default values, source-id ranges and the shape of the captured state was built empirically from real export files, and deliberately conservatively: a value is only treated as a default when sample exports agreed on it almost unanimously. Anything unrecognised is shown as-is rather than guessed away, and a source name the tool can't place in the id space is printed exactly as the file wrote it.