feat(studio): gate the VST FX section behind STUDIO_VST_ENABLED - #2605
feat(studio): gate the VST FX section behind STUDIO_VST_ENABLED#2605vanceingalls wants to merge 1 commit into
Conversation
Adds STUDIO_VST_ENABLED (default false, VITE_STUDIO_ENABLE_VST to turn on) alongside the existing STUDIO_*_ENABLED flags in manualEditingAvailability.ts, matching how other new/incremental studio surfaces (flat inspector, SDK cutover) are staged in. Gates the two places VST work actually surfaces: - PropertyPanel.tsx: the VstSection render, so the FX panel section never mounts for an audio element while the flag is off. - useVstPreview.ts: the "lazily start the sidecar once a vst-chain track appears" effect, so a composition with a stray data-vst-chain attribute can't spin up the sidecar process during preview while the feature is disabled. This is the sole call site of useVstHost's ensureStarted() in the app, so gating it here is sufficient — the FX panel never calls it directly, and useVstHost() itself does nothing until asked (no eager connection on mount). Render-time VST chain application (engine's processCompositionAudio/ vstBounce.ts) and the Lambda VST-chain rejection guard are left unflagged: those operate on whatever data-vst-chain content already exists in a composition's HTML regardless of which UI authored it, so gating them would silently change render behavior for existing content rather than just hiding an editing surface. Adds gating tests (PropertyPanel.test.tsx) proving VstSection is absent by default and present when the flag is mocked on, and mocks the flag on in useVstPreview.test.tsx so its existing 27 tests keep exercising the real behavior. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
Superseded by a recut stack: #2919 → #2920 → #2921 → #2922 → #2923. Same net result (68 files, +8,632/-491) with the add-then-delete churn removed and rebased onto current Per-PR deletions now: 122 (a net-negative refactor), 1, 297, 15, 54 — all real edits against |
|
Closing in favor of the recut stack: #2919 → #2920 → #2921 → #2922 → #2923. Same net result (68 files, +8,632/-491), rebased onto current Branches are left in place; nothing is deleted. |

What
Gates the VST FX section and everything that triggers the sidecar behind a new
STUDIO_VST_ENABLEDflag (default off,VITE_STUDIO_ENABLE_VST=trueto turn on), alongside the existingSTUDIO_*_ENABLEDflags inmanualEditingAvailability.ts:PropertyPanel.tsx: theVstSectionrender, so the FX panel section never mounts for an audio element while the flag is off.useVstPreview.ts: the "lazily start the sidecar once a vst-chain track appears" effect — the sole call site ofuseVstHost'sensureStarted()in the app, so gating it here is sufficient (the FX panel never calls it directly, anduseVstHost()itself does nothing until asked).Left unflagged on purpose: engine's render-time VST chain application and the Lambda VST-chain rejection guard — those operate on whatever
data-vst-chaincontent already exists in a composition's HTML regardless of which UI authored it, so gating them would silently change render behavior for existing content rather than just hiding an editing surface.Why
New, unreleased studio surface — stage it in behind a flag for incremental rollout/review rather than shipping it live to everyone by default.
Test plan
VstSectionis absent by default and present when the flag is onuseVstPreview.test.tsx's existing 27 tests updated to mock the flag on, so they keep exercising the real behavior🤖 Generated with Claude Code