hyperframes

4,012 Commits 900 Branches 408 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
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	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 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

Author

SHA1

Message

Date

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

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 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