沐阳 H3 · 准备进度（内部）

Generating a segment of MiniMax H3 video has a long dead zone at the front. Encoding prompts and reference images, building conditioning, staging weights - a minute or two of work with no sampling, and therefore no progress bar movement. Every long-video tool hits this and most of them handle it by showing you nothing until the sampler starts.

H3PrepareSignal is the pack's answer: a progress signal that fires on the real execution path before conditioning starts, so the Director's UI can say "preparing" and mean it.

Why that needs a node

You can't fake this from JavaScript. The frontend doesn't know when the backend has moved on to a stage; it just knows what it queued. The honest way to report progress is from inside the graph, at a point the engine will actually execute.

The pack's approach is a pass-through node with a side effect. It takes the job bundle, logs a line, and broadcasts an event over ComfyUI's websocket channel to the Director's panel. Because ComfyUI executes a node's function only when that node is reached, the event is real-time rather than a burst of optimism at queue time. The pack says as much in its own description of the sibling progress node: the function runs when ComfyUI actually gets there, so the events are live rather than a one-off flash while the graph is being built.

Inputs and output

Six required inputs, and they're all about being specific enough for a UI:

• h3 (MYANG_H3) - the job bundle, in and out.
• segment_index (INT, 1-999) and total_segments (INT, 1-999) - the pair that lets the panel say "segment 4 of 12". These are what make a long job legible instead of a spinner.
• run_id (STRING) and owner_id (STRING) - identifiers. The run ID distinguishes one queue from the next; the owner ID ties the event back to the specific Director instance that submitted it, which matters the moment you have two Director cards on one canvas or open two browser tabs. Without an owner, progress from one job can paint itself onto another job's panel.
• activity (STRING, default 准备提示词、素材与条件编码 - "preparing prompt, media and conditioning") - the human-readable line.

Output: h3, unchanged.

The event itself is small: run ID, owner ID, segment index, total, a stage of preparing, and the activity string. It's a status ping, not a data channel.

Like the pack's memory barriers, it forces a re-run. A progress signal that the cache skips is a progress signal that doesn't appear, and the whole point is that it appears every time.

What it's actually good for

Two things beyond the cosmetic. First, it tells you where a hang is. If the panel says "preparing" and never moves, you're stuck in conditioning - reference encoding, media loading, an LLM call - not in the sampler. That's a materially different debugging direction, and it's information you'd otherwise get by staring at a console log.

Second, it's a good example of doing UI from inside a graph at all, which is the general answer to "why is this nothing node in my workflow". Plenty of packs ship a cosmetic node like this; most of them are lying about when they fire. Node plumbing covers the always-rerun idiom that makes the honest version possible.

Category and install

沐阳 H3/内部 - internal. The Director's dynamic subgraph places it on the execution path in front of conditioning. You won't wire it by hand, and if you did, the placement rule is: it has to sit on the required path to conditioning, or it just won't be reached.

cd ComfyUI/custom_nodes
git clone https://github.com/civilcoco/ComfyUI-MiniMaxH3-Myang

Restart and hard-refresh the browser; category 沐阳 H3/内部. No Python dependencies - the pack declares an empty list, and the event send is an optional call into ComfyUI's own PromptServer.

The usual caveat applies: if you're loading the pack's example workflows, they've been sanitised, so select your own model names, media, prompts, output name and seed before queueing. An empty model selection looks exactly like a conditioning hang - and now you'll know which one it is, because the panel will be sitting on "preparing".