Files
hyperframes/skills/hyperframes-audio/references/attributes.md
T
Vance IngallsandClaude Opus 5 f423ea293f docs(skills): add /hyperframes-audio, with a headless carve
Mixing was the one audio surface no skill covered: the effect chain, automation
lanes and the voiceover carve existed with no guidance, so an agent had the
attributes and none of the judgement for using them. The skill teaches the carve
as what it is — a relationship between two tracks, wired like a sidechain, with
the settings on the bed naming the voice — and routes the effect families by the
problem each solves rather than listing parameters.

It ships scripts/carve.mjs because a skill teaching a feature agents cannot
operate is not much of a skill: the analysis needs decoded PCM, and the only other
way in is clicking a Studio panel. Same core functions and same decode rate, so
headless output and panel output are the same three attributes. It finds the voice
and the bed itself — names first, then by ear, measuring how much of each track is
quiet, since a voice stops between phrases and a bed does not — and refuses rather
than guessing when two tracks are too close to call.

References carry the full registry with which parameters can actually be automated
(the four worklet effects expose none, so a lane on one is silently inert) and the
exact JSON of the three attributes.

Counts, catalogues and the core-skill manifest updated in lockstep; the pinning
test in skillsManifest is what caught the two surfaces the maintenance checklist
in CLAUDE.md does not name.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 13:26:25 -07:00

4.2 KiB

The three audio attributes

All three go on the <audio> / <video> element itself, JSON-encoded, so a composition carries its whole mix in the HTML with nothing to load beside it. Nothing static validates them: preview plays an unreadable chain dry to stay workable, and the render refuses the whole mix rather than shipping a dry track that sounds plausible and is wrong.

data-fx-chain — the effects

{
  "version": 1,
  "nodes": [
    { "type": "highpass", "id": "n1", "params": { "frequency": 120, "q": 0.707, "poles": "2" } },
    { "type": "peaking", "id": "n2", "fromCarve": true, "params": { "frequency": 1600, "gain": -6, "q": 1.4 } },
    { "type": "limiter", "id": "n3", "enabled": false, "params": { "limit": -1, "attack": 5, "release": 50, "level_out": 0 } }
  ]
}
  • Order is signal order. Each node processes what the one before produced.
  • type is an effect id from the registry. params are in the units a person thinks in — dB, ms, Hz — and out-of-range values are clamped on read, so a chain that parses is always safe to realise.
  • id is a stable handle. Automation addresses nodes by id, never by position, so reordering the chain cannot re-point a lane at a different effect. A node with no id loads fine but cannot be automated. Writing a chain by hand, any unique string works; Studio hands out the first free n1, n2, … so matching that convention keeps a hand-written chain and an edited one looking alike.
  • enabled: false is bypass — the node stays in the chain, out of the signal path. Absent means enabled.
  • fromCarve: true marks a node the carve analysis generated. Re-running the carve replaces exactly these and leaves hand-built effects alone. Do not set it by hand: a node tagged this way will be deleted by the next carve.

data-automation — the envelopes

{
  "version": 1,
  "lanes": [
    { "target": "volume", "points": [{ "t": 0, "v": 1 }, { "t": 2.5, "v": 0.4 }] },
    { "target": "fx.n2.gain", "points": [{ "t": 0, "v": 0 }, { "t": 1, "v": -6, "curve": 0.4 }] }
  ]
}
  • target is volume for the track's own level, or fx.<nodeId>.<param>.
  • t is seconds from the start of the clip, not of the composition. A bed starting at data-start="8" has t: 0 at composition time 8.
  • v is in the parameter's own unit: dB for a gain, Hz for a frequency, 0..1 for volume.
  • A lane holds its first value backwards to the start of its clip and its last value forward to the end. So a bed that begins before the voice needs an explicit "no cut" point at t: 0, or it starts out already ducked.
  • curve (-1..1) bends the segment leaving a point: positive holds low then rises late. viaX/viaY name an interior point the segment passes through (progress 0..1, value travelled 0..1) and supersede curve when both are present — that is what the timeline writes when a bend is dragged.
  • 512 points per lane, maximum.
  • A lane whose node is gone is pruned on read rather than erroring.

A lane on a non-automatable parameter is silently inert. Automation is delivered as native AudioParam scheduling, so a knob that no AudioParam backs cannot move: worklet processor options, a WaveShaper curve and a convolution impulse are all set wholesale. fx-registry.md marks each parameter; the four worklet effects (compressor, limiter, gate, bitcrush) have none at all.

data-fx-carve — the carve's settings

{ "source": "narration", "strength": 0.35, "dynamic": true }
  • source is the element id of the voice track to listen to. It lives on the bed being processed, not on the voice.
  • strength 0..1 derives the whole mechanism (see carveProfile).
  • dynamic follows the voice moment to moment instead of holding one depth.

This attribute is not read at playback — the chain and lanes it produced are what play. It exists so the settings can be read back and re-derived rather than guessed from the filters, which is what makes changing strength on an existing carve possible.

Older projects may carry the six mechanism numbers (maxCutDb, bands, q, intelligibilityBias, duckDb, headroomDb) instead of strength. They still load: the depth maps back onto a strength and everything else is re-derived.