Skip to content

Deferred: Keyframes & Cues, from Composer's Side

The generalised per-property keyframe timeline and the cue/retiming system are the Resolver Engine's features, designed and delivered there (Resolver Engine → Cues, Resolver Engine → Keyframe Animation). This page holds only what is Composer's own: why Composer doesn't need them for its job, and the one hook-in the Change model has to leave room for.

Why Composer defers this, concretely

Composer's core value — adding, removing, and configuring structure — doesn't need the full generalised per-property keyframe timeline. Whatever motion vocabulary the engine offers when Composer ships is enough: its named-animation library once that exists, and whatever interim archetypes precede it. Which of those an Element's author reaches for is the engine's concern, not Composer's. The cue/retiming system is even more clearly orthogonal: it's about stretching a whole creative to a different voiceover length, not about composing structure at all.

What Composer owes the engine's design

  • Change[] gains an override variant when this resumes. Manual cue overrides — an author dragging a cue after auto-retiming — are a per-campaign fact and belong in Change[] as an additive union member (overrideCue, or a keyframe override), not a fifth bespoke override mechanism of the kind the Change model exists to prevent (The Change Model). Deliberately not designed against yet.
  • The engine notes that overrides need a mutation path for its own delivery, slotting into whatever document-mutation mechanism TemplateBuilder uses today (Resolver Engine → Cues). When Composer exists, that path is Change[]; until then the two are separate, and the engine's interim path is not something Composer inherits.

Risks

Open questions

  • The concrete shape of the overrideCue / keyframe-override Change type — depends on the engine's real cue schema entity existing first, which is the engine's own open work.