AD_Media_editor

If you open AD_Media_editor expecting a node that edits media, you'll be confused for about ten seconds, and then you'll get it. It has two text widgets, one optional media socket, and one media socket out. That's all. The actual editor - the thumbnails, the drag-and-drop tray, the per-shot prompt list - is drawn by the pack's frontend JavaScript on top of the node. The Python side is a pass-through: return (media,).

What it's for

It belongs to the Apt_Preset AD (MiniMax H3) branch of the pack. Those workflows ask the model to generate a clip in stages, where each stage can reference a different pile of material: a face for an identity, a costume image, a second angle, a music bed, a driving video. Without help, that means a media_1 … media_64 wall of sockets and a prompt that has to name each one by its socket index.

AD_Media_editor collapses that into two things a human can read. You attach your sources once - a small tray appears on the node - and you write one prompt per stage in a list, dropping in mentions of the attached material like Picture 1 or Video 2. The node hands the whole bundle downstream on one wire.

How the trick actually works

Two mechanisms, one on each side of the wire.

In the canvas, the node is a media hub (the same frontend module that powers basicIn_media, web/media_relay.js). Drag a wire from a Loader into its socket and the frontend stores that source in the node's own properties, drops the visible wire, and redraws the connection as a curve from the original node. A second and third source just extends the list, so the hub holds several references and feeds several consumers without dragging cords across your graph. Anything the hub is plugged into is deliberately ignored, so you can't chain hubs into a knot.

At execution, the prompt side is resolved by the backend. Your mentions are stored as placeholder tokens, and when a generate node runs a stage, the pack's resolver swaps each token for the tag (<Picture 1>, <Video 1>, <Audio 1>…) of the input it points at, checks each referenced material is actually connected, and hands the resulting text to the CLIP tokenizer. The stage list is authoritative in one direction only: if you write fewer prompts than stages, the last one repeats rather than erroring, because the scheduler's stage total is what the node trusts.

The inputs and outputs

prompt is the fallback text plus the single-stage prompt - leave it alone if you're using the editor, since the UI writes into it. stage_prompts is the multiline JSON list the UI maintains (default "[]"; entries are either a string or an object with a prompt and its own stage time), and hand-editing it is the fastest way to break a run. The optional media input is the tray's socket, and the single media output carries the same union value downstream - in practice, into the AD generate node or another hub. Don't expect it to convert anything: it is a relay, not a translator.

Installing it

It ships in ComfyUI-Apt_Preset, so you install the pack, not the node. ComfyUI Manager → search ComfyUI-Apt_Preset, or:

cd ComfyUI/custom_nodes
git clone https://github.com/cardenluo/ComfyUI-Apt_Preset

Then run the pack's install script (install-ComfyUI-Portable.bat for a portable install, the ...-aki.bat variant for the aki launcher) or just pip install -r requirements.txt, and restart ComfyUI. The requirements include opencv-python-headless, onnxruntime, transparent-background, scenedetect and gguf - the pack is a kitchen sink, and the AD nodes in particular import comfy_api.latest and comfy_extras.nodes_scail, so they need a recent ComfyUI. On an old build the whole module fails to import and you'll see the node as missing rather than broken.

Where people get stuck

The UI is the node. If the tray and prompt list don't render, nothing in the Python will tell you - the pack ships a web/ directory and the frontend loads it (WEB_DIRECTORY = "./web"), so a stale browser cache, a half-finished update, or a frontend that didn't pick up the extension leaves you with a bare text box. Hard-refresh before you go reading source.

Two error strings from the backend are worth recognising on sight. stage prompts are invalid or stage prompts must be a list means stage_prompts isn't parseable JSON - usually because it was edited by hand. material N is not connected means a prompt referenced something that isn't attached; fix it in the tray, not the text.

And because that tray list lives in the node's properties, it travels with the node when you copy/paste or export the workflow - and dies with the node if you delete it and add a fresh one.