| Connect custom controls and state | Shared descriptors and controlsFace bindings and generated host metadata consume the module contract; product DSP and custom layout remain authored. | Choose an integrationUse a parameter/state library or implement the binding in the selected host. | Framework attachmentsAPVTS and native/WebView attachments connect parameters, UI gestures and saved state. | Shared patch connectionEndpoint metadata, gestures, parameter updates and stored-state APIs are available to the custom GUI. | Device and wrapper APIsExported parameter/preset metadata and custom native or WebView editors provide the integration path. | Patcher controls and storageBuild the interaction in Max; delivery beyond its hosts follows a separate export path. |
| Run the sound in browser and DAW | One authored moduleJS/WASM and native Programs are derived outputs; admission and evidence are specific to each release and host. | Choose both runtimesA browser DSP build and a plugin shell are separate integrations over the chosen source. | Native plugin plus browser deploymentA plugin WebView shares frontend code; it does not by itself run the native DSP in a web page. | Documented exportsWeb Audio/WASM and native CLAP or JUCE projects; custom patch GUI export is supported. | Documented exportsWebAudio devices and native plugin targets; the current JUCE template also supports HTML/CSS/JS interfaces. | Live in MaxUse Max for Live for that host, or assess RNBO/other export routes for independent consumers. |
| Check what an edit broke | Module-owned regression workflowContract baselines, signal audits and qualified browser/native artifact checks; selected evidence must be current. | Choose the test harnessExisting C++ testing/audio tools can be integrated; coverage depends on the project. | Tests and validatorsUse the project's unit/audio tests, Pluginval and templates such as Pamplejuce. | Patch testing toolsThe command-line tools can test and render patches; product/host checks depend on the workflow. | Test exported behaviorDrive parameters, presets and events through the exported APIs and native product's tests. | Test the actual patchExercise signals, messages, storage and performance in its intended Max/Live environment. |
| Use a coding agent | Ordinary project plus audio contractsAgent guides and shared operations exist; restricted DSP rules and validation still matter. | Editable sourceAgent assistance is possible; supply the project's realtime and host constraints. | Editable source and existing examplesAgents can work with C++ and web frontends; their changes still need the project's checks. | Editable DSP and GUI sourceUse its language, patch metadata and validation tools; no comparative agent-success rate is established. | Patch/code and exported interfacesAssess the agent's actual patch-editing workflow rather than assuming visual authoring prevents assistance. | Patch and script authoringAgent assistance can operate on patch files and scripts; verify behavior in Max. |
| Choose whether to switch | Evaluate one new effectGuided beta, limited targets and unfinished public package/release paths. No measured productivity lead. | Keep a deliberate custom stackUseful when control or integration requirements justify owning the stack. | Keep an established product frameworkExisting DSP, tests and shipping infrastructure may outweigh any migration benefit. | Keep a working portable patchBrowser/native delivery already exists; require a specific control or verification benefit before migrating. | Keep an effective patch workflowFast patching and export may already fit the job; changing stacks needs a demonstrated benefit. | Keep a host-specific solutionA Live/Max performance tool need not become an independently distributed plugin. |