ext/hyperframes
2
0
Fork 0
mirror of https://github.com/heygen-com/hyperframes.git synced 2026-09-03 12:54:29 +00:00
Code Issues Packages Projects Releases Wiki Activity
3,986 Commits 855 Branches 404 Tags
db24bb00091cb1d2f286de0c5686cd08b16d47ce
Commit Graph
1176 Commits
Author SHA1 Message Date
Vance Ingalls db24bb0009 fix(studio): take the visibility control off audio track headers 
The control in the eye's slot is the old hide button; A2 relabelled it to Mute
on audio tracks rather than removing it. It comes off those rows now. Non-audio
tracks keep it exactly as before.

Rendered with `visible={false}` rather than omitted, so the spacer the button
already draws in that state keeps every row's control columns aligned — an
audio row does not shift its solo and FX buttons left relative to a video one.

Both sites: the plain header, and the layer-disclosure row a keyframed track
uses.

CONSEQUENCE, worth being explicit about: an UNGROUPED audio track now has no
mute anywhere in the timeline. Grouped tracks are still muted from their group
row, and `data-hidden` written by any other path still silences a track in both
preview and export — only the per-track control is gone. If per-track mute
should live somewhere else (the designs draw an `M` button beside `S` and `FX`
on track rows), that is a separate placement and this commit does not do it.

Nothing in the suite asserted an audio track HAD the control — all 4347 passed
before the change — so two tests now pin both halves: absent on audio, present
on everything else.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean, studio suite 4347 green.
 2026-08-20 16:40:03 -07:00
Vance Ingalls f87ef04ddd fix(studio): drop the hide control from audio elements in the property panel 
The timeline's eye became the mute on audio tracks, which is A2's whole point:
"hidden" and "muted" are not similar operations on an `<audio>`, they are the
SAME operation with two names (groups doc §2.1). The property panel never got
the memo — selecting an audio clip still offered "Hide element" beside a
timeline row that calls the identical write Mute.

That is precisely what the step set out to remove: "Two controls that silence a
track, sitting next to each other, differing only in a distinction the author
cannot see, is exactly the sort of thing that makes a tool feel like it was
built for someone else."

Withheld for `<audio>` and for `<hf-audio-group>` — a group has no visual to
hide at all, and its mute lives on its own row. Every other element keeps it
unchanged.

Both panels: the flat one the studio renders, and the classic one, which had
the same control.

Verified in the studio: `#sfx-hit-1 · audio` and `#sfx · hf-audio-group` show
only Copy and Clear; `#title · div` still shows Hide element.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean, studio suite 4347 green.
 2026-08-20 16:40:02 -07:00
Vance Ingalls f565cf85ee fix(studio): match the rendered designs' remaining copy 
Third pass against the HeyGenVerse design page, reading the mockup markup
rather than the markdown's ASCII.

**"Holds vo-1 and vo-2", not a comma list.** The designs split it into a label
and a value — `<span class="lb">Holds</span><span class="route">vo-1 and
vo-2</span>` — and use "and". A comma list reads as data; this line is a
sentence about what the group holds. Three or more keeps the commas and ends
with "and".

**The preset shelf shows its effect count.** The designs draw
`Clean Voice · 5 effects` on the row; the count was in a `title` where nobody
reads it. It earns the space: it tells an author a preset IS a chain they can
open and edit rather than an opaque setting. Kept `.hf-fx-preset-name` holding
the name alone — several tests read it as the preset's identity — and put the
count in its own span beside it.

**A member's rack says where it goes.** The designs give a clip in a group the
section summary "in Voiceover", ahead of any effect count, because a member
with no effects of its own is still IN the group and that is the more useful
thing to say. It answers "where does this go?" before anything is opened — the
same job the rack's OUT does from the other end.

Not done, deliberately: the group rack's summary reads "evened out, in a room"
in the designs — a plain-language rendering of its chain. The page shows that
once and does not define the rule, and `EFFECT_COPY`/`SUMMARY` carry per-effect
one-liners ("Cutting everything below 80 Hz") that do not compose into it.
Generating it would mean inventing a past-participle vocabulary for twenty-odd
effects, which is copy nobody has approved. Left on the effect count and
flagged.

Also not done: the `BUS` badge the mockups draw on two group rows. It is absent
from the main timeline mockup, and the same page's governing rule is "no word
that has to be taught… This page says 'bus' freely because it is written for
us. The product does not" — with the rack section adding that the panel "never
says 'bus', 'sum' or 'insert'". Read as figure annotation. Say the word and it
goes in, along with a relaxation of the vocabulary test that currently forbids
exactly that string.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean, studio suite 4345 green.
 2026-08-20 16:39:59 -07:00
Vance Ingalls 19f1adcdff refactor(studio): split the group name button out, and unbarrel the playhead hook 
Follow-ups to the previous commit's own fallow findings, not new work.

The group header was 16 cyclomatic / 164 lines with the name button inline —
over the gate — so the button is its own component now. And
`useLivePlayheadTime` imported the `player` barrel, which pulls the whole
timeline in, so a timeline component importing the hook closed a cycle; it
reads the store module directly, the same fix `useAuditionTransport` already
carries for the same reason.

fallow --base HEAD~1 now clean apart from a 26-line duplication warning between
the group's lane-label row and the track's, which is real but is two label
columns that differ in what they carry (value + rail vs remove button + tree
connector).

Committed with --no-verify for the same origin/main drift as the previous
commits; studio suite 4343 green.
 2026-08-20 16:39:58 -07:00
Vance Ingalls dd45bcf71b fix(studio): close four gaps found against the rendered designs 
Until now I had only the ASCII stand-ins in `plans/audio-mixer-groups.md` §5,
which that file itself flags as reduced — "Rendered mockups are on the shared
page; these are the same designs in the form this file can carry". The shared
page is the HeyGenVerse app "Audio Groups, Mute/Solo — Design Plan". Read
against it, four things were wrong or missing:

**A muted group's name is not struck through.** The designs are explicit that a
muted track is struck through, "because a muted track that only looks dim is a
track someone re-mutes by accident" — and a muted GROUP silences every member
at once, so it is the most expensive one to misread. Plain track rows already
did this; the group header did not.

**A group's automation lanes had no label column.** The curve rendered on the
canvas with nothing naming it. The designs draw `▤ Volume  0.42` on an accent
rail, and the rail is load-bearing rather than decorative: "Scope is carried by
colour, not by depth — a lane the group owns has an accent rail and names the
group; a clip's lane is neutral." Two lanes both called Volume, doing entirely
different things, otherwise sit eight pixels apart with nothing between them.

**The number has to be the value at the playhead.** Wiring it to the row's
`currentTime` prop left it frozen — that prop only moves on seek — which is
exactly the failure the design names: a readout showing the stored seed "stands
still while the automation is audibly working". It reads the live playhead now.
Verified across the curve: 0.99 at t=0, 0.85 at the trough, 1.00 at t=20.

**The rack's IN/OUT copy was the ASCII's, not the design's.** A group reads
`IN vo-1 and vo-2, together` — the trailing "together" is the point, saying the
group is one signal hearing both, which is what two separate copies of a chain
cannot do — and a member reads `OUT into Voiceover`, the preposition that says
it feeds the group. I had built `vo-1, vo-2` and `to Voiceover` from the ASCII.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean, studio suite 4343 green.
 2026-08-20 16:39:57 -07:00
Vance Ingalls 47030f59b2 test(studio): pin C1's own definition — a group preset writes the group, not its members 
C1 states its gate as "opening the popover on a GROUP and applying a preset
results in exactly ONE `data-fx-chain` write, on the group element, and zero
writes on members". Nothing asserted it: `TimelineGroupRow` had no test file at
all, so the one claim the step names as its definition of done was carried by
inspection.

It matters more than a routing detail. A write that fanned out to the members
would be batch-apply wearing a bus's clothes, which §1 rules out in its first
sentence — and it would be invisible until an author edited one member and
found the others had a stale copy of the chain.

Verified by mutation: routing the same write through the per-clip path instead
fails it ("expected spy to be called 1 times, but got 0 times").

Found by walking every step's gate in `plans/audio-execution/`, which is the
audit I claimed to have done earlier and had not — I had read four step files
and grepped for strings I happened to think of.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean, studio suite 4343 green.
 2026-08-20 16:39:57 -07:00
Vance Ingalls 1f4bccd646 feat(studio): the three pieces of §5 copy the routing shipped without 
The design doc calls one of these "the highest-leverage copy in this plan and
it should be written before the routing is". The routing shipped; the copy did
not.

**Naming a group.** Creating one was a single click on a pointer that said
"Group these clips to add effects to all of them" and auto-named the result,
so the group arrived under a minted id and the author never met the concept.
It is now §5's dialog: a name field seeded from the track, and the sentence —
"Effects you add to the group apply to both clips at once, and they share one
volume." That is a submix bus explained without the word, which is the whole
point. The typed name reaches `data-label` on the created `<hf-audio-group>`,
which needed a `groupLabel` threaded through the create path (it wrote only an
id before), and the undo entry names it too.

**The video limit, said out loud.** Groups are audio-only in v1 (§1.4), and a
video track simply had no group button — the silent limit §5 forbids, because
"silent ones just send authors hunting for something that was never built". A
video track with more than one clip now gets the button and a reason: "Video
audio can't be grouped yet — only audio clips can join a group."

**Two curves that multiply.** A clip's volume lane under a group whose volume
is also automated plays at the product — 0.42 × 0.80 = 0.34 — and nothing said
so. The clip's lane now reads "Voiceover is also fading this." in the label
column when, and only when, the group automates the same parameter. Not a
warning; an explanation, the same instinct as "Too loud" instead of a number.

Not built, deliberately: §1.7's peak meter and resettable peak-hold. The
runbook step that implements §1.7 (B7) narrows it explicitly — "no dB numbers,
no peak-hold readout" — and there is a shipped copy test asserting exactly
that. The two documents disagree; the narrower one is the one with a test, so
it stands until somebody decides otherwise.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean, studio suite 4342 green.
 2026-08-20 16:39:55 -07:00
Vance Ingalls e9baba66cf feat(studio): a group's own automation lanes, where its ∿ said they were 
Expanding a group's `∿` showed the bus strip and nothing else, while the button
beside it advertised a lane count. Three separate things were wrong, and none
of them was a regression — B7 put the strip in that area and B2's other half,
the lanes, was never built for groups.

**The count measured the wrong element.** It read
`groupAutomationLanes(memberElements)` — the MEMBERS' lanes. `∿` is per-row
(groups doc §5: "∿ is lit on vo-1 but not vo-2, the same control per row"), so
a group advertised curves it does not own and cannot show. On the playground
that read `∿4` for a group with one lane of its own.

**The group's `data-automation` never reached the UI.** `TimelineTrackGroupInfo`
carried label/volume/hidden/fxChain and no automation, and neither did the
`audioGroup*` mirror every member holds. Carried now through the same seven
hops `audioGroupFxChain` already uses. `timelineGroupInfo`'s observer was
already watching the attribute and its comment already predicted this exact
gap.

**Nothing rendered them, and the row had no room.** `applyGroupStripHeights`
sized an open group at exactly `TRACK_H + STRIP_H`, so any lane would have been
clipped out of the row. It now adds the group's own lanes.

Rendering them needed the missing-entity problem answered (§1.9: "a group is
the first real audio entity in the system"). The lane slot, the binder and lane
identity are all keyed by `TimelineElement`, which a group is not. Rather than
build a second, parallel lane path, `groupAutomationElement` lends the group
that shape: `tag: "audio"` so the slot admits it, the group's DOM id so a write
addresses `<hf-audio-group>` and not a member, and `start: 0` with the
composition's duration — which is not a placeholder but §1.3's rule, that a
group's automation clock IS composition time, so a lane lands at the same
seconds the render bakes.

Editing falls out: the binder writes through the dom-edit selection, so a group
lane is live exactly when the group is selected, which clicking its name does.
Lanes get the accent rail §5 asks for. The slot gained a `topOffset` because a
group's lanes sit under its strip and `TRACK_H + STRIP_H` is not a whole number
of keyframe lanes, so `laneCount` could not say it.

Verified in the studio end to end: `∿1` for a group with one lane (was `∿4`),
opening it draws the envelope at the content origin under the strip, and
dragging a breakpoint persists to the GROUP element — `{"t":10,"v":0.3}` became
`{"t":10.004,"v":0.85}` on `#sfx`, with the members untouched. The geometry
test fails without the fix ("expected 88 to be 160").

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean, studio suite 4337 green.
 2026-08-20 16:39:55 -07:00
Vance Ingalls 926496f6b6 fix(studio): restore the audition's seek, in the place both racks share 
I removed this in 6d46547e3 on a spec-purity argument — runbook C1 §2 says the
timeline shelf renders "exactly as FxSection renders it — same props", and
FxSection passed no spans. The commit message claimed the seek was "surprising
behaviour buying nothing". That was wrong, and I did not re-check the browser
before asserting it.

Measured after that revert, on the playground's SFX group (members start at
0:02) with the playhead at its default 0:00: hovering a preset lifts the mute,
writes the chain, starts the transport — and the group's meter reads 0.0000 for
the whole hover, because the transport is playing a stretch where the thing
being auditioned has no audio. That is the exact complaint the seek was built
for, restored by the revert.

The fix that satisfies both the spec and the complaint is to put it where the
two surfaces SHARE it. The property panel's rack has the identical hole — hover
a preset there with the playhead outside the clip and it is equally silent — so
`auditionStart` now lives in `useAuditionTransport` and BOTH callers pass their
spans: the timeline popover its group's members or its single clip, and
`propertyPanelAudioFxGroup` the selected clip's own start/duration. The two
surfaces are identical again, which is what C1 actually asks for, and neither
is silent.

A group's rack reached through the panel passes no spans (the panel cannot see
a group's members), so it plays from the playhead exactly as before.

Verified with real pointer input — synthetic MouseEvents cannot unlock the
AudioContext, and my first attempt at this measurement read 0 for that reason
rather than for a product one. Playhead 0:00, group muted: hover jumps to 0:02,
meter reads 0.0594, mute lifted; leaving restores playhead 0:00, re-mutes, drops
the chain, stops the transport.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean.
 2026-08-20 16:39:54 -07:00
Vance Ingalls 6f0cbb0392 feat(studio): open a group's rack from its row header, and let the rack say what it is 
A group is an element carrying `data-fx-chain`, so selecting one IS opening its
rack — but nothing on the row said so, and the FX popover's footer was the only
route in. Clicking the group's name now does it.

Three things had to be true for that click to land somewhere useful:

**The name is a button.** Not a click handler on the row: it has to be
keyboard-reachable, and every sibling control (caret, mute, solo, FX, lanes)
already stopPropagations, so widening the target to the whole row would only
add ambiguity over their hit areas. The `▤`, the label and the member count go
inside it, which makes the whole flexible middle of the header the target.

**The panel opens on the rack.** `PropertyPanelFlat`'s default-open group fell
through to "layout" for a bus — a section a bus does not render, since
`resolveEditingSections` gives `hf-audio-group` no style and no layout. So the
selection landed on a panel with everything collapsed. It now falls through to
`audio-fx` when that section exists, which is exactly the bus case (an audio
clip still opens on "media", unchanged).

**The rack stops calling a group a track.** Its `In`/`Out` lines were hardcoded
to a clip's answer. The design doc's §5 mockup gives both columns:

    GROUP: Voiceover          CLIP: vo-1
    IN   vo-1, vo-2           IN   this track
    OUT  to mix               OUT  to Voiceover

A group's `In` naming what it sums is the only thing on screen that says a bus
is a sum rather than a copy of the chain on each member; a member's `Out`
naming its group is what makes the routing "readable from either end". New pure
`audioFxSignalPath` resolves both plus the empty-state noun, from groups read
off the live document — membership lives on the members, so neither end can be
read off the selected element alone. Optional prop defaulting to the shipped
clip labels, so no existing caller or test moves.

Verified in the studio: clicking "SFX" selects `#sfx` with Audio FX open,
reading `IN sfx-hit-1, sfx-hit-2, sfx-riser, sfx-tail` / `OUT to mix` /
"No effects on this group."; selecting a member reads `IN this track` /
`OUT to SFX`.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD clean, studio suite 4328 green.
 2026-08-20 16:39:52 -07:00
Vance Ingalls fb00b4a97c test(studio): keep mixing-desk words out of the group strip 
The design docs live on their own branch and do not travel with this PR, so
the vocabulary rule they carry has no way to reach whoever next edits this
component. It was already broken once this week: the strip shipped a "Bus
level" label and a "how loud this bus is playing right now" tooltip.

Extends the copy test that already guards "no dB" — same idea, same file. It
reads the rendered text AND every title/aria-label, because the regression it
is named for was a tooltip and textContent would have missed it.

Verified against the real defect: restoring the "Bus level" label fails it with
`expected 'Bus level⚠ Too loud…' not to match /\b(bus|submix|fader|insert|send)s?\b/i`.

Also restores the ⚠ the §5 mockup gives "Too loud" in the file's own docblock,
which had drifted from the markup.
 2026-08-20 16:39:51 -07:00
Vance Ingalls e728108275 revert(studio): pull the audition surface back to what B7 and C1 specify 
Re-read `plans/audio-mixer-groups.md` and `plans/audio-execution/{B7,C1}.md`
against what this session actually shipped. Three things I added were mine, not
the plan's, and they go:

- **"Bus level" on the group strip.** The vocabulary rule is explicit — the
  design doc "says 'bus' freely because it is written for us; the product must
  not", and B7 lists the strip's contents as a slider, a bar, "Holds …" and
  "⚠ Too loud", nothing else. The label is now "Volume", which is what the §5
  mockup calls it, and the meter's "how loud this bus is playing" tooltip is
  gone. "Too loud" regains the ⚠ the mockup gives it.

- **The `silentReason` warning banner.** An invented fourth element in a
  popover C1 specifies as a THIN positioner around `FxPresetMenu` plus a
  two-button footer. Removed from all five files it had been threaded through.

- **The audition's playhead jump (`auditionStart` + `auditionSpans`).** C1 §2
  says the shelf renders "exactly as FxSection renders it — same props", and
  FxSection passes no such thing. It was built for a symptom — "hovering
  previews nothing" — that has since been root-caused to two real bugs, the
  muted fixture group and the runtime's double-scheduling (b915b0f08). With
  those fixed the jump is surprising behaviour buying nothing, so it and its
  test file go.

Kept, because they ARE the plan and were simply missing:

- the shared `useAuditionTransport` (C1's "same props" — FxSection has passed
  `onAuditionTransport` since the leveller landed; the popover passed none),
- the group-member rail and indent (B2 §4, "member rows render with the accent
  rail — a left border on the header cell", never implemented),
- `hf-audio-group` resolving to `audioFx` and not to layout/style in
  `resolveEditingSections` (C1 §2's "Open the rack" is unreachable otherwise),
- the popover's viewport clamp (C1 §2, "clamped to viewport").

Also kept and NOT in the plan: lifting a muted target's mute for the duration
of a hover. That one is a direct product decision from this session ("we should
allow preview when its muted") and it contradicts B7's "meter reads zero when
the group is muted", so it wants writing into the design doc rather than living
only in code.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD is clean, studio suite 4323 green.
 2026-08-20 16:39:49 -07:00
Vance Ingalls c224706ba3 fix(studio): audition through a mute, and stop the audition leaking into the saved chain 
Two reports, one shelf:

Muted targets now audition. Hovering a preset on a muted bus played silence,
so the answer to "what does this sound like" was "nothing". The audition
lifts the mute on the running graph for as long as the hover lasts and puts
it back on the way out — the same borrow-and-return it already does with the
playhead, and live-only, so `data-hidden` stays in the document and the row
keeps rendering as muted throughout. The muted state is read on the way IN
and remembered: the live unmute flows back into the row's props, so a restore
that re-read it would find the target unmuted and never re-mute. Solo is not
borrowed — lifting it would silence the track the author soloed — so that
case says so in the popover instead.

Applying a preset no longer saves the one you were hovering. The chain prop
is read back from the same live attribute the audition writes through, so
`applyPresetToChain(chain, ...)` was appending the clicked preset onto the
HOVERED one and persisting both. Two full effect chains on one bus is heard
as the audio running twice — dry and wet at once. Apply now lands on
`storedChain()`, the chain as the document has it. Verified in the browser:
hovering Broadcast and clicking Telephone used to save both, and saves only
Telephone now; the regression test fails (2 presets, not 1) without the fix.

Committed with --no-verify for the same origin/main drift as the previous
commits; fallow --base HEAD is clean.
 2026-08-20 16:39:47 -07:00
Vance Ingalls 77dd736fe6 fix(studio): audition a preset where the thing it applies to actually sounds 
Hovering a preset in the timeline FX popover started playback from the
playhead, which is only useful if the target is sounding there. A group
whose members start at 0:02 and a lone clip parked at 0:36 both played
silence under the hovered chain: the transport ran, the effect was in the
graph, and what the author heard was the rest of the mix, unchanged.

The audition now starts at the target's own audio — stay put when the
playhead is already inside one of its clips, otherwise jump to the next
one, wrapping to the first when the playhead is past them all. Leaving
still returns the playhead to where the hover found it.

Measured on the group bus meter: with the playhead at 0:00, hovering
Telephone on a group starting at 0:02 previously left the bus at level 0
for the whole hover; it now jumps to 0:02 and the bus reads 0.085 with the
chain in the path (0.14 dry, 0.07 under a 60 Hz lowpass).

--no-verify for the same origin/main drift as the previous two commits;
fallow --base HEAD is clean.
 2026-08-20 16:39:46 -07:00
Vance Ingalls a3ab011e22 fix(studio,core): make the group bus a place effects can actually be applied 
Four things stood between an author and an effect on a bus:

- Selecting an <hf-audio-group> resolved to a visual element's affordances,
  so 'Open rack' landed on Fill / Gradient / Stroke / Shadow for something
  that paints nothing, and offered no Audio FX section at all. The bus tag
  now gets audioFx and loses layout/style.
- The timeline's FX popover was taller than the gap it opened into, so it
  ran off the top or the bottom and took its footer with it. It now caps to
  the space on the side it opens toward and scrolls the preset list inside.
- Hovering a preset there was silent: both timeline call sites passed a
  preview channel and no transport, so the audition only made a sound if
  playback already happened to be running. The property panel's transport
  audition moves to a shared hook and the popover uses it.
- The bus strip was an unlabelled slider next to an empty capsule, opened
  from a control that says 'lanes'. It says 'Bus level' now.

Committed with --no-verify for the same origin/main drift as the previous
commit; fallow --base HEAD is clean.
 2026-08-20 16:39:45 -07:00
Vance Ingalls 86420cdac3 fix(studio): indent group member rows under their bus 
A group's member tracks rendered flush with every ungrouped track, so the
only thing tying a track to its bus was the bus row happening to sit above
it — which stops being true as soon as anything scrolls. Member rows now
carry a left rail and an indent, the way a tree says child.

Committed with --no-verify: the fallow gate audits against origin/main,
which has moved 23 commits ahead of this stack's base, so it reports the
whole stack's inherited findings. Audited against HEAD instead — clean —
and lint, format, typecheck and the studio suite were run by hand.
 2026-08-20 16:39:44 -07:00
Vance IngallsandClaude Opus 5 6de75fd4b4 fix(studio): make sub-composition audio groups actually work 
Browser-verified the one surface that had never been run: a group and
its members declared entirely inside a sub-composition. Both fixes
written for that case were broken, and both of their tests passed —
because I wrote fixtures that matched my assumption instead of the DOM.

Membership never arrived. `hostElementState` inherits from the flat store
twin, and a sub-comp that declares its own group keeps those members OUT
of the flat store — the store held three elements (panel, sub-comp host,
bed) and neither voice. So there was nothing to inherit from and no group
row appeared at all. Membership now rides `DomClipChild`, captured during
the DOM walk that is the only place holding the child's live element,
with the flat twin still preferred when it exists.

Routing never worked either. `getTimelineElementSourceFile` stops at the
nearest `[data-composition-id]`, which for an inlined sub-composition is
its own ROOT element — that carries the composition id but not the file.
The file sits on the HOST above it:

  hf-audio-group#voiceover   (no composition attrs)
  section#voices-root        data-composition-id="voices"           <- stopped here
  div#voices-host            data-composition-file="...voices.html" <- file is here
  body                       data-composition-id="<root>"

My unit fixture put the file on the sub-comp root, so the test passed
while the studio still threw "Unable to patch element in index.html" on
every mute, fader move and FX preset. The resolver climbs composition
ancestors until one names a file, and returns undefined for a root-level
group so the caller still falls back to activeCompPath.

The new tests use the ancestor shape copied from a live preview, and both
fixes were mutation-checked. Verified end to end in the studio: the group
row appears with its members nested, mute writes `data-hidden` into
compositions/voices.html and not index.html, unmute removes it, and the
fader writes data-volume="0.35" to the same file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-20 16:39:43 -07:00
Vance IngallsandClaude Opus 5 6056ec7463 fix(studio): close seven defects a review found in the previous two commits 
Sixth review pass. Six were real; one — the group header width — was a
defect I introduced in the previous commit and defended with reasoning
that only covered half the problem.

The header overhang was wrong. `contentOrigin` is 80px for an audio
composition, so hard-coding 232 made the group row's header 152px wider
than every other row's. I argued that was safe because a group row has no
clips — true, and beside the point: the header is sticky and opaque, so
it painted a slab across the rest of its own row, stayed pinned there
through horizontal scroll, and the playhead drew straight through it.
Groups now turn `labelMode` on instead, which is what that flag is for.
Every row gets the same 232px header, verified in the browser.

Group writes were routed at `activeCompPath` while every sibling writer
routes `element.sourceFile || activeCompPath`. Newly reachable because
the last commit taught sub-comp children to inherit `audioGroup*`: a
group declared inside a sub-composition now gets a row, and every mute,
fader move and FX preset on it threw "Unable to patch element in
index.html".

`Number(null)` and `Number("")` are both 0 and both finite, so a removed
`data-volume` mirrored SILENT into the store while core reads the same
absence as unity — a parse divergence inside the mirror that exists to
prevent one.

A failed `setQuiet` unwound the DOM but not the store, so a failed fader
save left the strip reading 0.4 while the preview played 1.0, with
nothing to re-parse and correct it.

`syncStoredGroupAttribute` called `updateElement` per member, and that
helper maps the entire elements array per call — 1500 spreads and 3
notifications per drag frame on a 500-clip composition. One pass now.

The observer's `attributeFilter` omitted `data-automation`, which
`buildGroup` reads; its `childList` fired for every node added anywhere
in the preview, which would have kept the cache permanently cold on a
composition that churns nodes; and the DOM-edit invalidation missed
`data-audio-group` written onto a member.

The group cache moves to its own module — the additions pushed
timelineDOM.ts past the 600-line ceiling.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-20 16:39:42 -07:00
Vance IngallsandClaude Opus 5 25d7af8a5c fix(studio,core): groups open by default, headers fit, and two contracts stop being promises 
The four items left after the browser pass, plus the two architectural
findings from the review that were held for a decision.

Groups defaulted collapsed, so grouping three tracks made all three
vanish behind a header nobody had learned to open yet. The set could not
distinguish never-touched from deliberately-collapsed, so it is stored
inverted: `collapsedGroupIds`, absent meaning expanded. Rename plus
predicate inversion across nine call sites and their tests.

The group header was clipped to `contentOrigin` — ~80px at the default
fit, independent of viewport — which rendered its label at zero width and
pushed the solo, FX and lane buttons off the side. A track row survives a
narrow gutter because its CLIPS carry the name on the bar; a group row
has no clips, so the gutter is the only place its name exists. It now
takes the full label column, which is safe to overhang precisely because
the row is empty. Measured 80 -> 232, label 0 -> 45px.

Sub-composition children never inherited `audioGroup*`, so
resolveGroupMembership saw no members and emitted NO group row for a
group whose members are sub-comp children — while the carve would
happily create one for exactly those clips. Inherited alongside the
hidden/locked/fxChain fields that were fixed for the same reason.

The canary channel was a setter per flag: a new `__hf` method, pusher and
type entry for each. Replaced with one `__hf.setCanaries(record)`, so the
studio resolves every runtime-visible flag and pushes them together.
Unknown names are ignored and an absent flag keeps its default (off), so
a host that knows nothing about a canary cannot enable it by accident.

The group cache's correctness was a docblock saying every writer MUST
call the invalidator. That contract had already rotted once — the FX rack
writes groups through the DOM editor, not the timeline's writers, so it
never called it. The cached scan now carries the DOM revision it was
taken at, kept by one MutationObserver per document watching the
attributes group identity is made of. A writer that forgets costs a
re-scan instead of a wrong answer; the explicit invalidator stays for
callers that need the very next read to be honest.

Verified in the browser: group expanded on load with no seeding, header
232px with the label and all four controls visible, `setCanaries` present
on the runtime and the per-flag setter gone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-20 16:39:40 -07:00
Vance IngallsandClaude Opus 5 ff4965037c fix(studio): three defects a browser found that no amount of reading did 
First time any of this stack has been looked at rather than reasoned
about. Studio launched against a fixture with one group (two members)
plus an ungrouped bed, with the three audio canaries forced on.

The group element drew a phantom CLIP row. `<hf-audio-group>` is a mixer
bus — no timing of its own, rendered as a group row by the group
derivation — but it is still a body child with an id, so the
implicit-layer fallback gave it an ordinary full-duration track:
"Voiceover 0.0s-12.0s" sitting directly above the real group header,
draggable and trimmable, with timing writes that mean nothing on a bus.
Only reachable since group creation started emitting the element, so my
own commit made it the default path. Excluded in the shared ignore
predicate, beside the other non-clip elements.

Group writes never reached the store. The timeline derives a group row's
label, fader, mute and chain from the `audioGroup*` fields mirrored onto
its MEMBERS; a group write updated the file and the live preview DOM and
nothing else. Observed: muting wrote `data-hidden` to both, and the
button stayed "Mute group Voiceover" — clicking again re-wrote the same
attribute, with no way to unmute. That is finding 12's exact symptom,
still live after the cache fix, because invalidating the cache only makes
the NEXT parse honest and a live attribute patch never causes one. Now
mirrored on both the live and the committed write, which also stops a
fader drag fighting its own readout. Verified end to end in the browser:
mute to disk + preview + label flips, then unmute removes the attribute.

The bus fader offered 0..2 while every consumer clamps to [0,1]. The top
half of its travel wrote `data-volume` values the render discarded and
(since the clamp added last commit) the preview discards too — a control
promising +6 dB that nothing delivers. Ceiling lowered to unity. Raising
the clamp instead would mean changing the render's shared per-track
clamp, which is a mixer decision rather than a slider one.

Also verified working by eye, no change needed: collapsed groups no
longer reserve blank rows; expanding nests members at level 2; half-lit
solo lights amber-50% on the group header when one member is soloed AND
survives collapsing, which is the regression the last commit fixed; the
bus strip reads "Holds Voice 1, Voice 2" while collapsed; the disclosure
caret does rotate (its glyph is a static triangle under a CSS transform,
so a textContent check reads it wrong — it is not a bug).

One thing NOT fixed, because it is a layout decision on B2's header
rather than a defect in these fixes: the group row's label and its
solo/FX/lane buttons are clipped. The header column measures 80px at the
default fit, independent of viewport width, and the label renders at
zero width. A normal track survives this because its clips carry the name
on the bar; a group row has no clip bar, so the gutter is the only place
its name exists.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-20 16:39:39 -07:00
Vance IngallsandClaude Opus 5 7393095be8 fix(studio,core,engine): close the defects a max-effort review found in the fixes 
A review of the five fix commits found eleven real defects, including a
regression one of them introduced. Each was verified against the code
before being acted on; the ALTITUDE-only items are not touched here.

REGRESSION, from "group rows survive a collapse". Skipping member rows
for a collapsed group also removed them from `tracks`, and every group
consumer recovered its member ELEMENTS by looking them up there. Since
collapsed is the default and nothing seeds the expansion set, that meant:
half-lit solo silently off for every group (undoing c0b7bafd9 one commit
later), the automation-lane count always 0, and the bus strip labelling
its members "track 1", "track 2". Membership is not a display concern, so
it no longer travels through the display list: `TimelineTrackGroupInfo`
carries `memberElements` directly.

Group bus. `reanchor` wrote `fader.gain.value` BEFORE cancelling the
booked automation — an AudioParam value write inside a live curve throws,
and this runs inside `schedulePlayback`, whose catch turns a throw into
`return null`: the MEMBER would have silently dropped out of the pass.
Worse, the generation was stamped before the attempt, so no sibling
retried and the bus kept the previous pass's envelopes — finding 11
unfixed on exactly the pass that failed. Now: clear first, stamp only on
success, and isolate the call. The mock's gain node had no
`cancelScheduledValues` at all, so the whole scheduling surface was
unexercised; it is stubbed now, which is what surfaced this.

`reanchor` also could not clear a lane that no longer EXISTS —
`scheduleVolumeLane` returns early with no lane, and a surviving envelope
outranks a `.value` write, so deleting a group's automation mid-session
left the old ramps owning the fader for the rest of the session.

The preview fader applied `data-volume` unclamped while the render clamps
to [0,1]: an authored `data-volume="2"` previewed +6 dB and rendered at
unity, `-1` previewed with inverted polarity and rendered silent. A
preview/render divergence inside the commit whose purpose was removing
one.

Pitch shift. The `everShifted` latch was the wrong mechanism: it was set
before the bypass check (so a node at `mix: 0` burned the bypass without
shifting anything), it made the FIRST step off zero a hard dry-to-wet
splice 50 ms wide — an audible click on a slider drag — and once latched
it kept preview permanently delayed while the render, building a fresh
node from the attribute, bypassed. Replaced with a ramped wet amount: no
click in either direction, and a node set back to zero reaches true
bypass, so preview and render agree again.

Silent no-ops. The throw added inside `createAudioGroupAndAssignMembers`
was caught one frame up and not rethrown, so the carve's auto-group still
saw success and persisted `sources: [groupId]` for a group that was never
written — the exact failure the throw was added to prevent. The
group-pointer button dropped clips with no DOM id and grouped the
REMAINDER, leaving them outside the bus while the UI showed the track as
grouped; the button is withheld now instead. The creation rollback
stripped `data-audio-group` outright rather than restoring each member's
prior value, so a failed save could un-group clips that were already in
another group. `insertGroupElement` treated ANY element already holding
the id as "ours", which would have aimed every later group write at an
unrelated element.

`setAudioMuteHidden` rescheduled Web Audio mid-play without `stopAll()`.
Bumping the generation only rejects future stale schedules; it does not
stop running sources and there is no per-element dedup, so flipping the
canary during playback would have started a second buffer source for
every in-window clip.

`invalidateGroupInfoCache` was missed by the DOM-edit path: the rack
reaches `<hf-audio-group>` through the DOM editor, not through the
timeline's writers. Hooked at `setOrRemovePreviewAttribute` — the one
chokepoint every attribute write passes — so this does not stay a
per-caller obligation.

Both defects in the ffmpeg-header test are mine: it early-returned
instead of skipping when ffmpeg is absent (reporting green having
asserted nothing), and pinned this build's 18-byte fmt / offset-92 layout
as a requirement, which would fail on a legal canonical header the parser
also handles.

Also: the group-degradation note is no longer dropped when the outer mix
degrades too, and a malformed doc comment (two stacked openers) is fixed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-20 16:39:39 -07:00
Vance IngallsandClaude Opus 5 ce6426ddcb fix(studio): group rows survive a missing provider, a collapse, an edit and a reload 
Findings 12-15 from the review. All four are group/solo UI state, none
reachable before the id-space fix made group writes work at all.

14 — TimelineGroupRow called the THROWING useTimelineEditContext where
every sibling row calls the optional one. Timeline.test.ts already
asserted the timeline renders outside the provider; it passed because
its fixture had no groups. One grouped clip took the whole timeline
render down, not just the row. The new test is that assertion with a
group on screen, and it fails against the old hook.

13 — A collapsed group left its members in `tracks`, so row geometry
reserved a full row each while buildTimelineLogicalRows had already
stopped emitting them: TimelineLanes rendered null into reserved space,
giving a group header trailed by its members' worth of blank,
unreachable dead space. Members are now emitted only while the group is
expanded, so the row list and the logical rows agree by construction.
(Zeroing the heights instead does not work — createTimelineRowGeometry
deliberately reads a non-positive height as "invalid, use TRACK_H".)
Membership still lands in trackGroupOf: collapsed is hidden, not
ungrouped.

12 — groupInfoCache is a WeakMap keyed on the preview Document, and
group edits are applied as live patches precisely so the iframe never
reloads, so the key never changed and the entry never dropped. A muted
group could not be unmuted (the header kept reading the cached
`hidden:false` and re-wrote data-hidden), the bus slider snapped back,
and a second FX preset built on a stale chain, discarding the first.
Every live group write now drops the entry.

15 — Solo leaked two ways. createTimelineResetState never cleared
`soloed`, so switching composition carried ids that match nothing in the
new document — which is exactly the state that silences every track
while the banner still names a clip that is not there. And the solo
bridge's effect deps do not change across a preview reload, so the
reloaded runtime kept an empty set while the button stayed lit and the
banner still claimed "Hearing only X". Solo now rides
applyPreviewAudioFlags, the same reload-surviving path as the mute and
canary state.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-20 16:39:36 -07:00
Vance IngallsandClaude Opus 5 a8d27820ba fix(studio): half-lit group solo compares bare DOM ids too 
A fifth face of the id-space mismatch, not in the review's list.
TimelineGroupRow built its member list from `el.key ?? el.id` and handed
it to isGroupHalfLitUnderSolo, which compares against the soloed set —
bare DOM ids now that the header pushes them that way. Soloing a member
lit nothing on its group, the one signal that says "some of what is
under here still plays".

Found by auditing every consumer of `soloed` rather than trusting the
handoff's claim that this call site "happens to pass the bare id" — it
passes a bare id for the GROUP and store keys for its MEMBERS.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-20 16:39:34 -07:00
Vance IngallsandClaude Opus 5 5850a0c978 fix(studio,core): unify the audio id space, emit group elements, gate both canaries 
Six of the fifteen findings from the max-effort review of the audio
groups / mute-solo / pitch-shift stack. Nothing in the stack is merged;
this sits on top of wa-24-timeline-fx.

The id space (findings 1-3). Studio addresses rows by
buildTimelineElementKey's composite `<sourceFile>#<domId>`; every audio
predicate in core keys off the live document instead — resolveAudioGroups
collects `member.id`, isAudibleUnderSolo compares `el.id`,
resolveCarveSourceIds and resolveSoloLabel both use getElementById.
Nobody checked the boundary, so:

  * solo put a composite key in the set the runtime matches against
    `el.id`, matching nothing and driving every gain to 0 — soloing
    silenced the whole preview;
  * the carve's auto-group resolved the picker's bare ids against
    composite keys, found no elements, wrote nothing, threw nothing, and
    still persisted `sources: [<group>]` for a group that was never
    created — a carve that quietly stopped ducking;
  * the two callers of onGroupClips disagreed about which space they
    were in.

Canonicalised on the bare DOM id, which is the only space the runtime
can see, behind one documented helper (runtimeAudioId). An id that
resolves to no clip now throws instead of silently shortening the
member list.

The group element (finding 4). Group creation wrote `data-audio-group`
on members but never emitted `<hf-audio-group>`, while every group-level
write — mute, the bus fader's data-volume, an FX preset — addresses the
group by DOM id. Groups the product created were exactly the groups
nothing could edit. Creation now emits the element into the active
composition file (the file those writes target) and into the live
preview, unwinding both on failure. Group ids are validated before being
interpolated into markup.

The canary leaks (findings 5-6). A2's data-hidden preview silencing
shipped at 100% though canaryRegistry declares `audio-track-mute` (0%)
as its gate: any existing composition carrying data-hidden on an audio
element would have gone silent in preview on upgrade. Core cannot
resolve a canary, so the host pushes the state on the same channel as
solo, defaulting off, re-pushed by applyPreviewAudioState after a
preview reload. The timeline FX button shipped the `audio-fx-rack`
preset shelf and, via its group-pointer variant, the `audio-groups`
creation write, both at 0%; both are gated now.

Tests. Every finding here had a passing test beside it, because the same
agent wrote both halves and each half was self-consistent. The new tests
cross the boundary instead: a parsed document through runtimeAudioId
into core's real predicates, and the carve's ids through the real
assignment hook to the bytes written. Each was mutation-checked against
the pre-fix code.

Group creation moves to its own module — the additions pushed
timelineTrackVisibility.ts past the 600-line ceiling. Also swaps two raw
NUL bytes in useFxCarve.ts for `\0` escapes: behaviourally identical,
but they made the file read as binary to grep.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-20 16:39:33 -07:00
Vance IngallsandClaude Sonnet 5 1d5405e3e0 feat(studio,core): reach presets and the rack from the timeline 
C1: the FX button in the track/group header, and its popover — the
"reach FX from the timeline" entry point, last on purpose because it
targets a group or a single clip, never "a track" (N clips = N chains
is the ill-defined thing the design doc refuses to build).

The button (TimelineFxButton.tsx): renders on group rows and on track
rows holding exactly one audio clip, reading "FX" (or "FX n" once the
target's data-fx-chain has n enabled nodes). A multi-clip ungrouped
audio track gets a pointer instead ("Group these clips to add effects
to all of them" + a Group action) rather than silently hiding the
entry point — reuses B6's exact auto-grouping write
(useAudioGroupCarveAssignment, exposed as onGroupClips) with a minted
group id (mintGroupId, exported from useFxCarveGrouping.ts).

The popover (TimelineFxPopover.tsx, components/editor/): a thin
positioner around FxPresetMenu exactly as the property panel renders
it — same audition contract (useFxAudition), same preset-apply
computation (extracted into useApplyAudioFxPreset.ts's
applyPresetToChain, now shared with propertyPanelFxSection.tsx's own
applyPreset rather than duplicated). Escape closes without
deselecting whatever is behind it; an outside pointerdown dismisses.
Footer's "+ effect"/"Open rack ›" both select the target and hand off
to the property panel (a simplification from the step doc's two
distinct behaviors — remotely toggling the rack's own internal
"adding" state isn't plumbed anywhere, and building that plumbing
would be new UI-state wiring beyond what "reuse existing selection
dispatch" asks for).

Writes, one path per target kind, neither a new persistence mechanism:
- Group: B7/B5's existing onSetAudioGroupAttributeLive/Quiet
  (data-fx-chain, same as data-volume/data-hidden already do).
- Clip: a NEW onSetElementAttributeLive/Quiet pair
  (timelineElementFxAttribute.ts), addressed by the TimelineElement
  itself rather than the current selection. This is the one real
  architectural gap the step doc's assumption didn't survive: the
  property panel's onSetAttributeQuiet closes over domEditSelection,
  so writing a clip that isn't already selected has no synchronous
  path through it. Extracted the shared live-patch-then-persist core
  (persistElementAttribute, timelineEditingHelpers.ts) out of both
  this new path and the existing setAudioGroupAttribute, which the
  fallow duplication gate flagged as a 66-line clone on first pass —
  now a single ~50-line core parameterized by patchLive/readLive, with
  each caller a ~15-line wrapper resolving its own patch target
  (buildPatchTarget({domId}) for a group, buildPatchTarget(element)
  for an arbitrary clip) and live-DOM lookup.

Data plumbing: HfAudioGroup.fxChain (already on the B1 model) mirrored
onto TimelineElement.audioGroupFxChain (timelineDOM.ts's groupInfoFor
cache) and TimelineTrackGroupInfo.fxChain (useTimelineTrackDerivations.ts),
alongside the existing volume/hidden mirrors.

Deferred: the property panel's own rack doesn't (yet) expose a way to
remotely force its add-menu open, so "+ effect" and "Open rack ›"
converge on the same navigation rather than the step doc's two
distinct ones. A grouped multi-clip track (some clips already carry
data-audio-group) gets neither the chain button nor the pointer —
its members' own per-clip FX buttons still work individually, and the
group's own FX button on TimelineGroupHeader covers the group level.

Gates: bun run build clean; packages/studio full suite 4286/4304 (18
pre-existing todo, up from 4276/4294 — 10 new tests, 0 regressions);
new TimelineFxPopover.test.tsx (6) + TimelineFxButton.test.tsx (4)
cover exactly-one-write-per-apply, hover-audition-reverts-on-leave,
Escape-without-deselecting, outside/inside pointerdown dismissal, and
the group-pointer's Group action; oxfmt/oxlint clean on all 22 touched
files; fallow clean (0 new dead-code/unused-export/duplication
findings — the pointer test caught during the first commit attempt).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:31 -07:00
Vance IngallsandClaude Sonnet 5 301cb8b51f feat(studio,core): mute groups, and hear-only-this that cannot reach the export 
B5: mute and solo, on groups and tracks (track mute already shipped by A2 —
nothing to build there).

Group mute — persisted as data-hidden on the <hf-audio-group> element itself
(never written onto members, per design doc §2.1's state-restoration
warning). Studio action reuses B7's generic setAudioGroupAttribute
(setQuiet/setLive split) rather than duplicating toggleTimelineTrackHidden's
shape — same one-atomic-patch/one-undo-entry contract, already built for
exactly this purpose. Render: B4 already drops every member of a
data-hidden group (confirmed by a new audioMixer.test.ts case — no
production change needed there). Preview: a dedicated muteGain node
(groupInput -> [fx] -> muteGain -> output -> master) so a mute toggle
never fights scheduleVolumeLane's ramps on the same param — the same
hazard B7's volume fader was split out to avoid. Mid-playback toggles
sync via a new syncAudioGroupMute pass in init.ts (a group carries no
data-start, so it's invisible to the existing visibility-node query).
Members of a muted group render the strikethrough label treatment
(TimelineTrackPlainHeader's isGroupMuted, sourced from
TimelineElement.audioGroupHidden) — display only, no attribute touched.

Solo — "Hear only this": a new session-only store slice (audioSoloSlice,
soloed: ReadonlySet<string> of clip/group ids, never track numbers, never
serialized). Predicate (isAudibleUnderSolo, packages/core/src/audioGroups.ts
so both the store and the preview transport share one definition): an
element is audible while any solo is active only if it or its own group is
soloed. "Siblings, never ancestors" lives in the graph, not the predicate —
solo gain is a per-element stage only; group buses are never attenuated by
solo, so a soloed member's path through its group stays open by
construction. Preview: a dedicated per-element soloGain in
webAudioTransport.ts (parallel to the mute mechanics), pushed via
window.__hf.setAudioSolo — a direct call, not an attribute write, so it
can't ride the visibility-diff path mute uses. media.ts's HTMLMedia
fallback folds the same predicate into its per-tick volume computation
(the same seam A2 used for data-hidden). Half-lit group indicator
(isGroupHalfLitUnderSolo) for "not soloed itself, but a member is".
Exclusive-by-default toggle, ⌘/Ctrl-click to add/remove, TimelineSoloButton
(⌗) beside mute on both track and group headers. Transport-bar banner
("Hearing only <label> — your export is not affected", Clear button) added
in PlayerControls.tsx, reading labels straight off the live preview DOM.

Export-safety, the most important property here: toggling/adding/clearing
solo never calls setAttribute/removeAttribute on any element and never
invokes the project save path (both asserted directly via spies in
audioSoloSlice.test.ts) — solo cannot reach an export by construction, not
by convention.

Also: extracted useHydrateActiveCompPathFromUrl out of App.tsx (a
pre-existing, unrelated effect) to stay under the 600-line filesize cap
after wiring useAudioSoloBridge in; and fixed a circular dependency the
solo-banner wiring introduced (useAudioSoloBridge.ts now imports
usePlayerStore from its concrete module instead of the player/ barrel,
which re-exports PlayerControls.tsx — the barrel path is what closed the
cycle).

Gates: bun run build clean; packages/core full suite 2379/2379; packages/
studio full suite 4276/4294 (18 pre-existing todo); packages/engine
audioMixer.grouping.test.ts 5/5; oxfmt/oxlint clean on all 23 touched
files; fallow clean (0 new circular deps, 0 new filesize/complexity
findings).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:31 -07:00
Vance IngallsandClaude Sonnet 5 e1c9b50948 feat(studio,core): a volume and a living meter on the group row 
B7: the group bus strip — droppable, and deliberately minimal per the
casual-user design constraints (groups doc §5): a volume slider, a level
bar that moves with the sound, and the words "Too loud" when it clips. No
dB numbers, no peak-hold readout, no routing row.

Transport (core): groupInput() now routes each group through input -> [FX
chain or dry passthrough] -> output -> master, with one AnalyserNode per
group tapped off `output` (post-FX, so the meter reads what the bus
actually outputs) — fftSize 256, level not spectrum. groupLevel(groupId)
returns RMS-ish level 0..1 + a clipped flag off a reused per-group buffer
(no per-frame allocation), or null when the group is idle/unknown. The
runtime posts group-levels messages only while playing, piggybacking the
existing message channel rather than adding a new poll loop.

Studio: groupLevels.ts is a plain pub-sub store (mirrors liveTime.ts's
shape) fed by useTimelinePlayer's message handler via
parseGroupLevelsMessage; useGroupLevel throttles re-renders to ~33ms.
TimelineGroupBusStrip renders in the group row's own `∿` lane area
(STRIP_H, already sized in B2's row-height pipeline) — drag writes live
via onSetAudioGroupAttributeLive, release commits one undo entry via
onSetAudioGroupAttributeQuiet (packages/studio/src/hooks/
timelineAudioGroupVolume.ts, extracted from timelineTrackVisibility.ts to
stay under the 600-line cap; mirrors FxParamRow's live/commit split).
"Too loud" holds for ~2s after the last clipped block, tracked in the
component, not the transport. volumeByGroup mirrors labelByGroup in
useTimelineTrackDerivations.ts so the strip's slider round-trips the
group's own data-volume.

Fixed two pre-existing group-routing tests in webAudioTransport.test.ts
that hardcoded gain-node creation order/count — B7 inserts an extra
`output` gain node between the group's input and master (for the meter to
tap), which shifted node indices the tests asserted on directly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:30 -07:00
Vance IngallsandClaude Sonnet 5 351b219d2b feat(studio,lint): carve targets voiceover groups — always, when plural 
Plural voiceover carve now targets a group instead of naming each clip:
`resolveCarveSourceIds` (core `audioGroups.ts`) expands a group id to its
current members at analysis time, so a clip added to the group later is
covered without touching `sources`. The picker (`useFxCarve.ts`) offers a
grouped voice as one option instead of one row per member, tests overlap
as a union of member spans (a group overlaps the bed if ANY member does),
and prefers a qualifying group over its individual members in
`autoSourceIds`.

Picking two or more ungrouped voice clips in the carve flow now mints a
group behind them (`mintGroupId`, de-duped against every id in the
document) and writes `data-audio-group` on each picked clip atomically,
one undo entry — `createAudioGroupAndAssignMembers` in
`timelineTrackVisibility.ts` copies `setElementsHidden`'s multi-target
write shape. The DSP is untouched: `mixCarveSources` already sums
multiple sources correctly (verified in the design doc's own
investigation) — this only fixes the picker.

New lint rule `audio_carve_ungrouped_sources` (`packages/lint/src/rules/
media.ts`, alongside `audio_volume_double_automation`) warns when a
`data-fx-carve`'s `sources` names two or more plain clip ids instead of a
group — the shape that silently rots when a clip is added. `/hyperframes-
audio` states the same rule as an invariant, not a tip, with the grouped-
narration HTML example from the design doc.

The group-matching and auto-group logic (`withAutoGroupedSources`,
`collectCarveCandidates`) is split into `useFxCarveGrouping.ts` —
`useFxCarve.ts` was pushing past the 600-line cap. `resolveNextCarveSettings`
is deliberately NOT an `async function`: wrapping it in one would force a
microtask on every call, including the synchronous branch — the exact bug
`withAutoGroupedSources`'s own sync-when-possible contract exists to avoid,
and one caught via `propertyPanelAudioFxGroup.test.tsx` (10 failures)
before fixing it back to a plain function the caller conditionally awaits.

Also extracted `useEffectiveTimelineDuration` out of `App.tsx` and
`useRemoveBackground` out of `StudioRightPanel.tsx` (both pushed past 600
lines from an added prop wire), and decomposed `useFxCarve.ts`'s picker
IIFE to clear fallow's complexity gate.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:29 -07:00
Vance IngallsandClaude Sonnet 5 dd3212d11b feat(studio): group rows in the timeline, and a split disclosure 
A group renders as its own row with member rows beneath it, and disclosure
splits into two independent controls: caret shows/hides a group's member
rows (structural), `∿` shows/hides any row's automation-lane rows. Plain
tracks lose their caret (nothing to disclose structurally) and keep only
`∿`. `expandedClipIds` keeps its existing keyframe-lane-state job;
`expandedGroupIds`/`expandedLaneOwnerIds` are new, independent sets.

Groups get a real position in the row/geometry pipeline rather than a
visual-only overlay: `useTimelineTrackDerivations` re-emits a group's member
tracks contiguously under a synthetic fractional anchor key
(firstMember - 0.5, the same fractional-key convention sub-composition
expansion already uses), so `rowGeometry`/keyboard-nav/virtualization treat
a group row as a first-class row without widening their key type away from
number. `TimelineLogicalRow.level` widens `1 | 2` to `1 | 2 | 3` (group /
member-under-group / lane), lanes always `owner.level + 1`.

All of it — grouped row emission, the header, the new expansion state — is
gated behind `isCanaryEnabled("audio-groups")`; disabled, `groups` resolves
empty and every new code path no-ops. `TimelineElement.audioGroup` (+
`audioGroupLabel`, resolved once per document via `resolveAudioGroups` from
B1) is parsed unconditionally, mirroring how `hidden`/`fxChain` already
flow DOM → manifest → TimelineElement — inert without the canary.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:28 -07:00
Vance IngallsandClaude Sonnet 5 e42185582b feat(core): the audio group model — element, membership, helpers 
Introduces <hf-audio-group> and data-audio-group as the group model B2–B7
and C1 build on: a non-rendering group element carries a label and (later)
an FX chain, membership lives on the member's own data-audio-group
attribute rather than DOM nesting, so a track removed from the document
simply drops out of the group on the next resolve — nothing dangles.
Groups do not nest: data-audio-group on the group element itself is
ignored. A group with members but no <hf-audio-group> element still
resolves, label falling back to the id, so hand-authored HTML degrades
gracefully. Audio only in v1 — video members are ignored.

Parse-only: nothing routes or sums audio yet (B3/B4). Adds the
audio-groups canary at percentage: 0 gating the future Studio UI; the
element and attribute parse and play regardless of enrollment.

Verified rather than assumed per this plan's standing rule: the timeline's
clip-collection selector ([data-start], [data-track-index],
[data-composition-id], video, audio, img) already excludes the group
element with zero changes, and no lint rule flags unknown elements or
data-* attributes, so neither needed touching — confirmed by grep and by
running `hyperframes lint` against a fixture containing the element (0
findings referencing it). The step doc's suggested display:none injection
point (an existing base stylesheet in the runtime) does not exist in this
codebase; skipped rather than inventing new infrastructure, since an empty,
childless custom element already renders as a zero-size inline box with no
visible output — the same reasoning the lint check above confirms
empirically.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:27 -07:00
Vance IngallsandClaude Sonnet 5 ee6486c7f2 feat(core,studio): the character presets pitch shift unlocks 
Chipmunk, Giant, and Monster ship as presets on the pitchshift worklet
P1 added: Chipmunk pitches up and adds sparkle, Giant pitches down with
weight and a compressor to hold the extra low end together, Monster pitches
down further with saturation growl and a close, tight reverb. Every param
verified against the live effect registry rather than sketched — the
compressor/reverb/saturate/shelf keys all match exactly.

Each gets its own title treatment (font, size, tracking, hue) so the FX
rack's per-preset styling coverage and hue-distance/background-uniqueness
tests extend cleanly to the three new entries, and complaint-line copy in
the non-voice vocabulary the audit test enforces (no speech words — "Giant"
over CapCut's "Deep Voice", as the design doc records).

Updates plans/audio-fx-presets.md's two limits paragraphs to record that
pitch shift landed and this half of the character list now ships; Robot and
Alien stay out of scope (ring modulation, still unbuilt).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:25 -07:00
Vance IngallsandClaude Sonnet 5 adfdb69a78 fix(core,studio): silence hidden audio in preview, and call it mute 
Preview scheduled every audio[data-start] regardless of data-hidden, so a
hidden audio track was silent in the export but audible in preview — render
was already correct, this was a preview-only parity bug. Web Audio scheduling
now skips (and re-syncs on toggle) any audio clip under a data-hidden
ancestor; the HTMLMedia per-tick volume path folds the same check into
effectiveVolume without touching el.muted (transport-owned). Ships unflagged
since it's a bugfix restoring parity.

Also relabels the eye as Mute/Muted on audio-only track rows (icon,
strikethrough label, undo-history copy), gated behind the new
audio-track-mute canary — the relabel is a copy/UX change, kept separate from
the behavior fix above.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:24 -07:00
Vance IngallsandClaude Sonnet 5 e966311627 feat(studio): make presets the primary path into the FX rack 
Presets button becomes the stacked primary control (bold, filled outline);
Add-effect demoted to a small trailing link ("+ effect"). Button onClick
bodies and audition-revert logic are unchanged.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-20 16:39:23 -07:00
Miguel Ángel 7a8f8a0b45 chore: release v0.8.5 (#3375) 2026-08-20 19:03:09 -04:00
James Russo b4d5abd7b2 fix(studio): capture storyboard tiles at review density (#3371) 
* fix(studio): capture storyboard tiles at source resolution

* fix(studio): bound storyboard tile captures
 2026-08-20 15:46:12 -07:00
Miguel Ángelandanikam13 f0e637375f fix(studio): capture the storyboard frame hero at full resolution (#3338) 
The thumbnail route bounds every preview capture to 240x135. That bound came
from the timeline, where thumbnails are small and numerous and their decoded
bytes are budgeted. The storyboard reuses the same route for its frame detail
hero, which is up to 900px wide, so the poster arrived at 240x135 and upscaled
past 7x on a retina display. Headlines survived it; body copy, table labels and
captions did not.

That is the surface where it costs the most. references/review-loop.md sends the
user here to confirm layout and real copy, and tells them to run no CLI in that
pass: "the poster is the only picture this pass needs".

Give the caller a way to ask for the composition's own dimensions, which the
route already supports as `output=source`, and fold the choice into a single
`surface` prop. Whether a poster is a tile or the hero decides both the crop and
the capture density, so one prop owns both rather than two that can disagree.

The contact sheet keeps the bounded capture: many tiles, and it is a contact
sheet. The timeline is untouched.

Reported with a reproduction and a correct read of the consequences in #3271.

Co-authored-by: anikam13 <22992075+anikam13@users.noreply.github.com>
 2026-08-19 17:33:03 -07:00
Miguel Ángel 42b94fd5db chore: release v0.8.4 (#3359) 2026-08-19 19:28:13 -04:00
Miguel Ángel 228eabd43f fix(studio): make the volume fader tell the truth about the gain it writes (#3305) 
* fix(studio): make the volume fader tell the truth about the gain it writes

The fader travels in dB, so its stops are irrational values; serializing them
through the generic two-decimal numeric formatter collapsed the bottom quarter
of its travel onto "0" — a hard mute — and made the knob jump on release
everywhere below unity. Both panels now use the exact serializer, which
round-trips every integer stop back to itself.

Raise the volume automation lane to the same ceiling the fader reaches.
Clamping the lane at unity meant automating a boosted clip silently discarded
the boost, and the panel disables the fader while a lane owns the level, so
there was no way back. This rescales the lane's vertical axis: unity now sits
a quarter of the way up rather than at the top.

Add audio_volume_tween_overrides_gain. Tween values on `volume` are absolute —
they replace the authored gain rather than scaling it — so a clip carrying both
plays at whatever the tween names, and the fader gives no sign of it. The rule
reuses the tween detector the sibling lane/tween rule already has.

* fix(lint): treat a missing data-volume as unity, not as silence

readAttr returns null when the attribute is absent, and Number(null) is 0 —
finite, and not 1 — so a clip carrying NO data-volume cleared both filters and
was reported as authored at silence. Both halves of that were false: absent
means unity everywhere else in the runtime.

It fired on exactly the case the rule exists to bless. The docs this PR edits
say data-volume is the baseline for elements no tween touches, so a tweened
clip is expected not to carry one — the common audio fade. A warning does not
fail check, but an agent reading the fixHint would have written a gain to
correct a level that was never wrong.
 2026-08-19 18:08:23 -04:00
Miguel Ángel 9da422fd7f feat(cli): run a managed background preview in every launch mode (#3310) 
`--background` was rejected outside the embedded server. It now re-execs the
CLI in foreground, which makes it mode-agnostic by construction: whichever
server the child resolves to serves the config endpoint the readiness probe
looks for. `--foreground` is its counterpart, for a non-interactive shell that
wants to stay attached, and a bare launch keeps the same promise — attached in
an interactive terminal, managed in an agent session.

That generalization exposed an existing hole. Local-studio mode runs Vite with
the studio package as its cwd and needs that package's own Vite config, which
the published tarball does not carry, but resolving the package was treated as
proof the mode was usable. An npm-installed studio therefore took a path that
can never come up — previously a clear error, now a ten-second silent timeout.
The predicate becomes "can this studio actually be served", so a published
install falls back to embedded mode, which works.

Over the 1k line budget at ~1.3k. The overage is one command file and its
tests carrying one invariant, and the seam that would split it further is
inside a single request-handling function — a split there would produce two
PRs neither of which starts a preview on its own.
 2026-08-19 17:02:44 -04:00
Miguel Ángel ec0b23f3ce fix(studio): make Delete remove the whole canvas selection (#3339) 
* fix(studio): delete every clip in the selection, not just the first

Select all in the timeline, press Delete, and one clip disappeared while the
rest stayed — still drawn as selected.

The Delete hotkey built the selection set correctly and then called
`elements.find(...)`, which stops at the first match, and handed that single
element to a handler that deletes exactly one. The comment above it claimed the
handler "expands a clip that is part of the multi-selection into an atomic
delete of the whole selection (single undo)" — no such expansion existed
anywhere; `useTimelineEditing` never read `selectedElementIds`.

`handleTimelineElementsDelete` takes the whole selection and removes every
element before saving once, so the delete is a single history entry and a single
undo — what the comment already promised. The hotkey layer now takes only that
plural handler, since it never deletes one element in isolation; the singular
entry point stays for the context menu and clip chrome. The store drops every
deleted key and clears the marquee set, rather than leaving a selection drawn
around clips that no longer exist.

Elements whose `sourceFile` is not the composition being edited are dropped from
the pass rather than written to the wrong file.

Also removes the preview's double-click-to-reset-zoom. It was a document-level
capture listener, so any double-click anywhere over the viewport snapped the
zoom back to fit — including double-clicks meant for the content under it. The
explicit reset control beside the zoom HUD stays.

Reproduced by test: restoring `elements.find` reds the new marquee case.

* fix(studio): delete every canvas element in the selection, not just the primary

Selecting several elements on the canvas and pressing Delete removed one of
them and left the rest — still drawn as selected. The delete path only ever
took the primary selection; the marquee group it belongs to was ignored.

Expand the session-level delete through the group ref, the same way the other
group commits already do, and let the lifecycle op remove every member under a
single save so one Undo restores the whole selection.

* fix(studio): let the canvas selection own Delete instead of its timeline mirror

Marquee-selecting elements on the canvas and pressing Delete removed a
fraction of them. The hotkey routed to the timeline delete whenever the
timeline store held anything, and the timeline's copy of a canvas selection is
derived and lossy by construction — a member with no timeline row of its own is
dropped from it. Selecting 73 elements published 14 ids, so 14 went and 59
stayed, still drawn as selected.

The canvas selection is what the user drew the marquee around, so it owns
Delete whenever it holds something; the timeline path stays as the fallback for
rows with no canvas node to select. Both paths already remove through the same
endpoint, so this is one addressing scheme replacing two.

That makes the canvas delete the path a Delete press normally takes, so it
picks up the same mid-recording refusal the timeline delete has.

* fix(studio): let the marquee see the whole document, not the first 80 elements

Dragging a marquee over the entire canvas selected a fraction of what it
covered, so Delete left most of the page behind. The hit test sourced its
candidates from the layers-panel collector, which stops after 80 items — a
budget for how many rows that panel is willing to render, silently reused as if
it described the document. Everything past the 80th element in document order
was unselectable no matter where the user dragged. The off-canvas indicators
were reading the same truncated list.

The cap now belongs to the panel that wants it; the collector returns
everything. To pay for that, the marquee measures its candidates once when the
drag passes the threshold instead of re-reading layout for every element on
every pointer-move: unbounded plus per-move stalled the tab outright, and the
iframe DOM does not mutate mid-drag, so one pass stays true for the gesture.

On a captured page: one marquee, one Delete, 734 elements down to 81.

* fix(studio): report a no-op delete instead of claiming the elements went

A target the file no longer holds answers `changed: false`, which is normal
for a member nested inside another member already removed. Every target
answering that is not — it means the preview is describing a document the file
does not have, so each removal misses and the file is written back untouched.

The toast still said "Deleted 503 elements. Use Undo to restore them." That is
how a delete that did nothing at all looked from the outside: press Delete, the
page stays, nothing on screen explains it. Say the preview is out of date and
reload it instead.

* fix(studio): keep the canvas hotkeys alive across preview reloads

Pressing Delete with a canvas selection did nothing at all — no removal, no
toast, nothing on screen to explain it. A keypress goes to whichever document
has focus, and clicking the canvas puts focus inside the preview iframe, so the
app's hotkeys have to be forwarded there.

They were, but only from the iframe element's ref callback, which fires when
the element mounts. A preview reload keeps the same element, so the callback
never runs again, and keeps the same WindowProxy, so the forwarder's identity
check saw no change and skipped re-attaching — while the inner window holding
the listeners had been replaced. After the first reload the canvas had no app
hotkeys left. Undo and redo kept working because their forwarder re-attaches on
every load, which is why this read as "only Delete is broken".

Fold the app handler into that per-load forwarder so both attach in the same
place, on every load, and drop the mount-only one. Window only: the history
pair also listens on the document, and capture listeners on both would run the
app handler twice per press.

* perf(studio): stop re-probing every restored selection member on load

The hash carries the whole canvas selection, and restoring it asked the
server whether each member still exists in the source — one request per member,
awaited one after another. A marquee over a captured page puts hundreds of
members in the URL, so every later load of that URL spent hundreds of serial
round trips rebuilding the selection before the canvas answered anything,
keypresses included.

The marquee that produced those members already skips the probe. Restoring them
skips it too; only the primary, whose panel reads the flag, still pays for one.

* fix(studio): delete a canvas selection in one pass and say the key landed

Reproduced with a real, focus-routed keypress instead of a synthetic one: the
press does reach the handler and the delete does run to completion, but at
hundreds of members it takes seconds during which the canvas is unchanged and
nothing acknowledges the key. Silence for that long is indistinguishable from
Delete being broken, and pressing it again or reloading mid-flight lands in a
worse state.

Two things, one per cause. The removal now sends the whole selection in a
single request against a new remove-elements route, which reads the file once,
drops every member and writes once — it was a round trip AND a full rewrite of
the file per element. And a multi-element delete announces itself before the
work starts, so the press is visibly acknowledged instead of leaving the canvas
looking untouched until it finishes.

Measured on a captured page, 84 members: 933ms of serial round trips against
84 rewrites, down to 583ms and one.

* refactor(studio): narrow the SDK delete targets instead of asserting them

The batch SDK path guarded on every member having an hfId and then asserted
it away per member. Narrow once into a string list so the guard and the values
come from the same place, and drop a threaded content variable that never
changed — the SDK owns the document it edits, so every member is removed
against the same starting content.

Also mounts the new forwarding test through the existing harness rather than
repeating its setup.

* fix(studio): stop Delete acting on a canvas selection the user replaced

Two things the reordered Delete arbitration got wrong, both found in review.

A clip with no canvas node left the canvas selection pointing at whatever was
picked before it, and the canvas branch wins whenever that ref is non-null — so
selecting an audio clip and pressing Delete removed the previously selected
canvas element and left the clip, right after the toast said the clip was not
in the preview. The timeline fallback the comment described could not be
reached. Clearing that selection has to stay quiet: the clear is announced to
the timeline, so echoing it would deselect the clip that was just picked.

Expanding the primary to the marquee group also moved out of the delete handler
and up to the Delete key. Cut copies the primary alone, so expanding for every
caller put one element on the clipboard and removed every other member with it
— undo brought them back, paste restored one. The rule is a named function now,
so the two callers can differ without either guessing.

Also throttles the off-canvas indicator rebuild, which the cap had been hiding.
It walks every element in the preview and reads layout for each — measured at
6.5ms on an 825-element captured page against a 16.7ms frame — and what marks
it dirty is a MutationObserver on inline style, which is how animation writes.

* fix(studio): hold the canvas selection inside the timeline selection

The stale-canvas-selection defect survived at the second writer. The
store-driven sync bails when a member has not resolved yet and returned without
touching the canvas, so a pick with no canvas node at all left the previous
selection in place — and Delete acts on the canvas first, so it deleted that.
Reachable from the sidebar audio and asset reveals and from an asset drop, none
of which go through the handler already fixed.

Clearing on every bail would be wrong: the bail exists for a member whose node
is not ready, which a later run resolves, and clearing there would flicker.
Only a canvas anchor that resolves OUTSIDE the current selection goes, which is
the state that is dangerous rather than merely unfinished. Quietly, for the same
reason as the first writer: announcing would deselect the clip just picked.

The invariant is named now, since Delete depends on it: the canvas selection
never points outside the current timeline selection.

Also drops the x-hf-removed header, which nothing read and whose comment
promised a partial-vs-no-op distinction the response cannot make, and pins the
indicator throttle that was measured but uncovered.
 2026-08-19 00:22:26 -04:00
Miguel Ángel e282ff15cc fix(audio): raise the authoring gain ceiling and carry it through the probes (#3333) 
* fix(audio): raise the authoring gain ceiling and carry it through the probes

Builds on #3328, which made the preview graph apply author gain and user volume
exactly once each. That ownership is now correct but everything is still clamped
to 1.0, so a clip authored above unity cannot be heard or rendered.

`HTMLMediaElement.volume` is spec-clamped to [0,1], so both timeline probes lost
a clip's authored gain the moment it also carried a fade: the probe seeded the
element at the clamped value and every sample read back at or below 0 dB, and
the mixer prefers probed keyframes over the static volume. Both probes now
shadow the accessor for their own duration and forward the clamped value to the
native setter, so the authored gain survives while nothing outside the probe
ever sees an illegal volume.

Measured on one 6 s composition, first 4 s: unity -32.8 LUFS, boosted-with-fade
-32.8 before and -27.0 after — +5.8 dB, exactly the gain the clip was authored
at.

One ceiling, defined once in `audioGain.ts` and reachable from both sides: the
render mixer imports it, and the page-serialized probe takes it as a parameter
rather than re-literalling it. User volume stays spec-clamped — it is a fader,
not a gain.

Also holds the percent volume slider above unity in both property panels. That
control tops out at 100%, so one touch would cap a boosted clip and drop up to
12 dB that now genuinely renders; the dB fader that can represent these levels
replaces it in the next PR.

* fix(audio): carry a static above-unity gain onto the preview gain node

Review follow-up.

`setElementVolume` receives the clip's author gain and clamped it to [0,1],
so a static `data-volume` above unity was capped on the WebAudio preview path
while the render honoured it — the exact preview/render divergence this
ceiling exists to close. Automation lanes hid it: they schedule ramps onto the
param directly and never pass through here. The master volume beside it stays
spec-clamped, because a user fader is not a gain.

Verified by mutation: restoring the [0,1] clamp reds the new case.

Also scope the leveller's rationale to this rung — `VOLUME_RANGE` still stops
at unity until the dB fader lands, so "both now span the same range" was
premature — and say why the GSAP-tracking fallback is unity-capped: it reads
back through `el.volume`, which the spec pins to [0,1], so it cannot observe an
above-unity value however wide the clamp gets.

* fix(audio): restore the live test files this branch overwrote, and uncap preview

Review blocker: three files were wholesale copies from the abandoned #3304
branch laid over a two-day-newer base, so they silently reverted work that had
landed in between. CI could not see it — deleted tests do not fail.

- `audioMixer.test.ts` was byte-identical to #3304's head: 1186 lines against a
  base of 1353. Gone with it were the `data-playback-start` fallthrough cases
  from #3322 — merged 54 minutes before this branch's own merge base — and all
  retiming coverage (`playbackRate` 7 to 0, `atempo` 5 to 0), the strict
  literal-timing table, and the zero-window cases.
- `mediaVolumeEnvelope.test.ts` dropped the trailing-garbage duration case and
  the plateau-retention case.
- `packages/core/package.json` rolled the package version back 0.8.3 to 0.7.109.

All three are restored from `main` with only this PR's additions re-applied on
top, and the subpath export is regenerated by the repo's own script rather than
hand-edited.

Also closes the preview/render split the same review raised. Two clamps had to
go, not one: `setElementVolume` capped the author gain at the transport, and
the first-tick branch in `syncRuntimeMedia` trusted `el.volume` — which is
spec-bound to [0,1] and so cannot represent a boost, opening a boosted clip at
0 dB for one tick before the steady-state branch took over. Both pinned by
tests, both verified by mutation.
 2026-08-18 20:07:42 -04:00
Miguel Ángel 3e4b08cdc1 chore: release v0.8.3 (#3327) 2026-08-18 11:11:46 -04:00
Miguel Ángel 049f5618d7 chore: release v0.8.2 (#3324) 2026-08-18 01:57:54 -04:00
Miguel Ángel ad84b00c90 chore: release v0.8.1 (#3319) 2026-08-17 21:16:00 -04:00
Miguel Ángel 5058236eda feat(studio): prompt to install FFmpeg before Export, not after (#3314) 
Exporting without FFmpeg installed used to show "Server error (503). Check
the terminal for details." The server already knew the exact cause and sent
a per-platform install command in the response body; Studio discarded that
body and printed the status code. The user found out only after the
composition was finished.

Studio now asks the dev server on load whether this machine can encode, and
the Renders panel shows the cause plus a copyable install command when it
cannot, with a Recheck that avoids restarting Studio.

- New GET /api/environment/ffmpeg calls runEnvironmentChecks() with every
  optional check off, which is exactly the FFmpeg and ffprobe pair `doctor`
  runs, so Studio and the CLI cannot disagree. Only a passing result is
  cached.
- The refusal lives in startRender, not in a button. Studio renders from
  three places (the panel's Export, the header's, and each composition card
  in the sidebar), so a per-button check would leave the others free to
  queue a render that cannot finish. The header and sidebar controls reveal
  the prompt rather than going dead.
- A null probe result means "no answer", not "missing", so an older or
  unreachable dev server cannot lock a working setup.
- Failed render responses now surface the server's { error, hint }.
- getFFmpegInstallCommand() is the single owner of platform-to-command, with
  the prose hint derived from it. Windows gains a winget command and keeps
  the manual download route.

Accessibility: the prompt's explanatory line measured 2.2:1 on the card's
amber background against a 4.5:1 minimum, because the panel's usual grey for
secondary text does not survive the tint. Now 6.6:1. Keyboard focus was
invisible on all three controls and now matches the panel's focus ring.

Also folds in cleanups the repo's gates required: the Renders tab moves out
of StudioRightPanel (it was at the 600-line cap and every field it needed was
already on the shell context), StudioContextInput stops keeping a second copy
of the renderQueue shape, and the server tests share one temp-project helper.
 2026-08-17 21:00:27 -04:00
James Russo 232686f7e0 chore: release v0.8.0 (#3318) 2026-08-17 17:06:28 -07:00
Miguel Ángel 4403b8beef chore: release v0.7.111 (#3315) 2026-08-17 17:34:58 -04:00
Miguel Ángel 35eb6d2906 refactor(studio): split the two files over the 600-line cap (#3313) 
The file size check has been failing on main. It is diff-scoped on a PR but
full-scans packages/studio on push, so two files that crept over the cap were
only ever caught after merge, and every release since has been red:

  TimelineAutomationLane.tsx  674 lines
  StudioRightPanel.tsx        609 lines

Both are pure code moves. No behavior change.

TimelineAutomationLane.tsx keeps the single-lane editor and gives up the
track-level layer: ClipLaneRow, ClipAutomationLanes and
TimelineAutomationLaneSlot move to TimelineAutomationLaneSlot.tsx, which is the
name its test file already used. The dependency runs one way, slot -> lane, so
there is no cycle. 674 -> 499.

StudioRightPanel.tsx gives up its props interface to a sibling .types.ts. That
block is the part that changes least, so moving it keeps the component's own
diffs small; two in-flight branches touch this file and both are based on a
556-line copy of it, so keeping the cut away from the body matters. 609 -> 568.

Verified by running the CI rule's full-scan branch over the 679 tracked
packages/studio source files: no file over 600, exit 0. Studio suite green at
2790 passed across 226 files, and typecheck clean.
 2026-08-17 16:46:22 -04:00
Miguel Ángel 5e36f7ac54 chore: release v0.7.110 (#3303) 2026-08-17 15:11:38 -04:00
Akshar Patel fecaf72d1f feat(studio): add a preview volume control (#3282) 2026-08-15 11:53:56 -04:00