Pianosequenza-True_long · Pack PSkf

The pack's naming is doing a lot of work here, so let's translate. "PSkf" is a Pianosequenza State Keyframe - a snapshot of the joint H3 video-plus-audio latent at a point you've decided is good. Pack PSkf is the node that builds that snapshot in memory. It's a two-output utility, no GPU work, and it's the difference between a sequence you can extend and one you have to regenerate from scratch.

Why you'd reach for it

H3's native output sits in a 4-15 second window. Every long-form workflow worth using is therefore a stitching problem, and stitching problems live or die on what the seam carries. Most long-video tricks hand the next chunk a decoded video frame or two and hope. This one hands it the whole AV latent plus the boundary analysis metadata - picture and sound, undecoded, at latent resolution.

So Pack PSkf is the moment where you say: this take is accepted, freeze its state. Everything downstream - save to disk, continue from it, retry the next shot - reads from that frozen state.

If you want the honest context: the "Pianosequenza-True_long" name is IAMCCS's own; searching for it in community threads turns up nothing, because it's one author's internal vocabulary rather than a technique the wider scene has adopted. That's neither a knock nor a badge. It does mean the docs here matter more than vibes from Reddit.

Inputs that matter

latent is the one that counts - the complete accepted H3 video+audio sampler latent. Not a video-only latent. The node internally splits the nested tensor into video and audio streams and derives the pixel frame count from the video stream's shape, so feeding it something that isn't the joint AV payload either fails or produces nonsense bookkeeping.

Then three bookkeeping fields, which are where the real decisions live:

• clip_index - the slot number for this keyframe. It's what Load PSkf later matches against, so keep a numbering scheme. Defaults to 1.
• head_context_frames - how many leading frames are treated as context rather than as visible action. Default 0, which is right unless you deliberately generated with a context head.
• visible_frame_count - how many frames are the actual shot. Leave it at 0 and it derives the visible interval from the latent, which is what you want in the normal case.
• source_id - optional free-text lineage tag, project or shot name. Costs nothing, and you'll thank yourself at clip 40.

There's also an optional handover input, the freeze-analysis metadata that the continuation engine produces. Wire it if you have it: it's what makes the automatic handover mode in the Extend node possible instead of you hand-dialling a tail length.

Two outputs: pskf (the state, into Save or Extend) and state_info, a one-line string printing clip index, technical frame count, visible frames, head context and technical padding. Read it once per run. It catches almost every misconfiguration before it reaches disk.

How it works

The arithmetic is straightforward once you see it. Take the technical latent length, subtract head_context_frames, subtract visible_frame_count, and the remainder is technical_padding_frames. If head context plus visible frames exceeds the latent, the node raises rather than silently clipping - "head context + visible frames exceeds the technical latent" is a message you'll see exactly once before you fix your numbers.

It also normalises the handover block: if the analysis was computed over the visible interval rather than the full technical latent, every frame coordinate in it gets shifted by the head context so the numbers still point at the right place. That's the kind of detail that either works invisibly or produces a seam that jumps two frames, and I'd rather it be handled in a pack than in my head.

To be clear about what this node does not do: it doesn't sample, doesn't decode, and doesn't write anything to disk. It builds a dict. The save is a separate node, which is a good split - you can pack and continue without ever touching the filesystem, or pack, save, and resume tomorrow.

Install

Part of IAMCCS-nodes. ComfyUI Manager → search IAMCCS Nodes → install → restart → hard-refresh. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart ComfyUI. One copy only in custom_nodes - the README calls out duplicates as a cause of stale node definitions, and it's a real support-ticket generator.

No pip step for the pack (no requirements.txt), but you need your H3 model, VAE and text encoder in the usual ComfyUI model paths, and ComfyUI 3.0.0 or newer. The pack ships no weights at all.

Common issues

"Expected an IAMCCS Pianosequenza State Keyframe." You've fed something that isn't a PSkf into a node expecting one - usually a chain where Pack got bypassed and the raw latent went straight through. The state object is what carries the handover and padding bookkeeping; the latent alone doesn't.

Numbers that don't add up. visible_frame_count above zero when you didn't generate with a head context, or a hand context that exceeds the latent. Both raise, both are your input values, and both are readable off state_info before you queue a 20-minute run.

It "did nothing". Correct - it's a pure bookkeeping node with no output node attached, so if nothing downstream consumes pskf, ComfyUI prunes it from execution entirely. That's the caching behaviour working as designed, not a bug.

Where it fits

Pack → IAMCCS_H3PSkfSave for the checkpoint, or Pack → IAMCCS_H3TrueLongExtend as previous_latent if you're continuing in the same run. Do both: save and extend. The save is your insurance against the second half of the sequence going wrong.