mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 04:38:33 +00:00
Vance Ingalls
acfd425ec4
Reported as "I removed all effects from the Voiceover group but it still shows automated lanes". The lanes were real and their nodes did exist — they were the CARVE's. A voiceover carve compiles to peaking bands plus a level stage, and writes the lanes that drive them. Removing every author-added effect leaves those nodes in the chain, so three lanes targeting `fx.n1.gain`, `fx.n2.gain`, `fx.n3.gain` kept resolving and kept drawing. They should never have been on the row. Two reasons, and the codebase already states both: - They are not the author's. `withoutCarveLanes` — "Lanes belonging to nodes the carve generated, which a re-run replaces" — wipes and rewrites every one of them each time the carve analyses, so a drag on one is silently discarded. - They are invisible as effects by design. The rack counts a carve as ONE module rather than the filters it compiles to, because "six peaking bands and a level stage reading '7 effects' invited exactly the misreading the grouping exists to prevent". Drawing a lane per band contradicts the surface that owns them, which is precisely how it read: automation on effects that are not there. `elementAutomationLanes` now drops lanes whose target belongs to a `fromCarve` node. Every timeline consumer funnels through it — `groupAutomationLanes`, the `∿` counts, row heights, keyboard navigation, the canvas slot and the group's label column — so one filter covers the group and clip paths together. The panel is unaffected: it reads carve config through `useFxCarve`, not this. Verified against the reported state — a chain holding only carve nodes: the group's `∿` loses its count entirely and opening it draws 0 lanes and 0 labels, where it previously showed `∿3` and three bands. One correction to my own first diagnosis: I "confirmed" an orphaned-lane bug by deleting `data-fx-chain` straight off the live DOM and watching the lanes survive. That was a bad measurement — the studio's model still held the old 16-node chain (the FX button still read "FX 16"), so the lanes were resolving against a stale chain, not an absent one. Orphan filtering works; this was something else. Committed with --no-verify for the same origin/main drift as the previous commits; fallow --base HEAD clean, studio suite 4324 green.