BFS MiniMax H3 TARA - Native Temporal Alignment (Experimental)

What it is

TARA - Temporal-Aligned Reference Attention, in the author's framing - is a MODEL patch for MiniMax H3's native-reference motion transfer. The problem it targets is specific: when H3 has a source clip sitting in its conditioning as <Video 1>, nothing forces the frame it's generating at 5.0 seconds to consult the right moment of that clip. It can attend anywhere in the guide. Result: the performance drifts, timing slides, and a walk becomes a wobble.

The fix is a soft time penalty. At output time 5.0 s, guide content at 4.8–5.2 s is free; further away gets progressively suppressed, up to a cap. That's it. It's a preference, not a mask - distant moments are discouraged, never deleted.

It is not an identity knob, not an LoRA strength knob, and not a preset that makes bad output good. Read the author's own parameter guide before you start turning dials, because the most common disappointment here is someone raising strength to 10 hoping for a better likeness.

How it works

The node wraps the model function per-model - set_model_unet_function_wrapper, no global ComfyUI monkey patching, nothing loaded - and does two separate things:

1. Temporal RoPE alignment. It rewrites the rotary coordinates of the target video so its timeline sits on the same grid as the selected motion video. Images keep their native coordinates.
2. A soft attention bias on the edges from target-video queries to motion-video keys only:

score -= min(strength * (max(|t_target - t_guide| - window_seconds, 0) / falloff_seconds)^2, max_penalty)

Text, image references, target self-attention and reference audio keep normal behaviour. The docs are careful that the result is a relative key-weight multiplier before normalisation - not a probability, and not a measurement of whether your video came out right.

It requires a LoRA trained with the matching native_temporal_v1 contract (the author's ai-toolkit branch). It does not load that LoRA and does not encode video. In their own testing, an ordinary Add Guide-trained LoRA at step 10500 transferred surprisingly well, but they flag that as an observation, not a guarantee.

Inputs and outputs

Wire it after your LoRA loader, and route its MODEL output to the guider/scheduler. The motion video itself stays in MiniMax H3 Reference to Video's conditioning as a native video reference - this node never sees it, only its index.

• motion_video_index - which native <Video N> supplies the motion (default 1). Picture numbering is independent, so <Picture 1> and <Video 1> are unrelated slots.
• strength (2.0), window_seconds (0.2), falloff_seconds (0.25), max_penalty (6.0) - the training defaults. Change one at a time, with seed, LoRA, prompt and source fixed.
• attention_backend (optional) - flash partitions (no compile) is the default; flex (original) is the first implementation; comfy kitchen (experimental) uses an optional one-pass kernel when installed, otherwise a slower frame-wise path.

One output, MODEL. There's also an animated in-node parameter map (added in 1.115.23) that redraws the free window and capped penalty as you drag sliders - useful for understanding the shape of the bias, and explicitly not a preview of output quality.

What will break, and why it's usually your graph

This node refuses to run alongside the other ways of guiding H3. Add Guide, first-frame guides, VSA, SLA, or an unknown attention replacement all produce a clear error, because any of them changes the packed layout the patch reads. Pick one motion mechanism.

Guide and output must share a 24 fps temporal grid - 107 frames is the author's example of a valid count. Every conditioning branch the patched model evaluates needs the motion reference in it: an empty negative conditioning has no timeline for TARA to align against. Training preview uses CFG 1 for that reason.

And the trap worth taping to the monitor: strength = 0 is not TARA off. Zero strength or zero cap removes the bias; the RoPE alignment remains. To compare against plain native reference, bypass the whole node and route the original MODEL to both guider and scheduler.

Install

Manager → search ComfyUI-BFSNodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/alisson-anjos/ComfyUI-BFSNodes.git
cd ComfyUI-BFSNodes && pip install -r requirements.txt

Restart. No extra pip installs for the default backend - Flash Partitions uses native CUDA FlashAttention with log-sum-exp, so you need CUDA FP16/BF16 and PyTorch's LSE-capable path, and the node tells you if it can't find them. The Kitchen path (from 1.115.22) downloads a pinned one-pass extension into ComfyUI's user cache, matching your architecture - SM80/86/89/90/100/120 on Linux, SM86/89/120 on Windows - with a CUDA-13-capable driver. Confirm it actually activated by looking for Kitchen ONE-PASS dense kernel ACTIVE in the log; a successful render without that line means you got the slow compatibility path.

Honest limits

This is labelled experimental for real reasons. The pack's docs describe CPU-level layout/parity tests and some completed 5090 runs, and state plainly that full visual-quality validation is incomplete. Identity drift showed up in a fresh native-temporal LoRA checkpoint in early testing. Treat TARA as a way to tighten timing on a native-reference motion transfer - then check the ending and the fast actions, which is where any temporal bias shows its seams.