From an idea to a working audio tool.
Start with a runnable project. Describe the sound and experience you want. A coding agent builds the graph and interface while you listen, steer, and test in the development workbench. Export only after the project checks pass.
In Studio, you can direct the work without writing code. Local projects also let developers inspect and extend the same module. Both paths use the shared engine, UI kit and publishing tools.
We work with artists.
We partner with artists and labels on signature instruments, effects, and sound banks. You bring the idea and audience. We build the product together.
Let us build itThe process
Six steps, one continuous project.
The technical details belong in the project and agent reference. The product workflow is simpler.
Step 1: Choose a starting point
Open the closest working starter or use a playable module as a reference. You begin with a project that already runs, so the first task is shaping an idea, not assembling infrastructure.
Result: A runnable project in the development workbench.
Step 2: Describe the tool
Tell your coding agent what it should sound like, which controls matter, and how the interface should feel. A musical brief is more useful than a list of implementation instructions.
Result: A shared product direction for sound and interaction.
Step 3: Build sound and interface together
The agent assembles the typed audio or MIDI graph, exposes the parameters, and builds the interface as a normal web app. React, Vue, animation, WebGL, 3D, and custom visualization can live in the same project.
Result: A playable tool, not a disconnected DSP patch and UI mockup.
Step 4: Work live
Play the result in the workbench while the agent edits it. Listen, move controls, inspect meters and logs, and keep directing the next change. The loop stays short enough for musical decisions.
Result: Fast iteration with your ears and judgment in the loop.
Step 5: Verify and export
When the tool is ready, run the project checks and build the formats supported by that beta project. Browser, VST3, CLAP, Audio Unit, and standalone paths exist, with verified availability listed per module.
Result: A checked browser experience and supported native builds.
Step 6: Prepare the release
Test the real build in the hosts you care about, confirm the current commercial terms, and package the product around the formats and platforms that have been verified.
Result: A release plan grounded in evidence and written terms.
Start with intent
Give the agent a product brief, not a command recipe.
Name the musical outcome, the important controls, and the desired interaction. The agent guide carries the current project rules and workflows, so your prompt can stay focused on the tool.
Working with coding agentsRead https://syntho.app/llms.txt and use the starter project already open.
Build a warm stereo delay called Driftwood. It should feel immediate and musical,
with Time, Feedback, Tone, Width, and Mix as the main controls.
Create a responsive interface with a clear delay-tap visualization. Keep advanced
settings out of the main view. Let me hear and review each meaningful change in
the workbench. Run the project checks before you call it ready.The bundle
The pieces needed to keep the loop moving.
Working starters
Effects, instruments, MIDI tools, and examples that give an agent a real project to reshape.
Development workbench
Live audio and MIDI, hot reload, parameter inspection, diagnostics, logs, and repeatable test inputs.
Web-native interface kit
Audio controls and visual building blocks that remain ordinary, editable web source in your project.
Typed audio toolkit
A bounded authoring surface that helps agents assemble graphs and gives them actionable validation errors.
Native build paths
Generated host plumbing, interface packaging, saved state, parameters, and builds for supported formats.
Verification
Project checks and format-specific evidence so availability is shown per module instead of implied globally.
Keep the project. Choose the release path later.
The graph, interface, assets, presets, and tests remain normal source in your workspace. Generated bundles are outputs from that project, not the only copy of your work.
Plan a releaseSource of truth
Product behavior stays in the module and interface code that you and your agent can inspect and change.
Rebuildable output
Browser and supported native bundles are produced from the project after its checks pass.
Written terms
Access, commercial permissions, support, and long-term rights are confirmed for the selected project before release.
Syntho removes the handoffs.
Most alternatives solve one part of the product: DSP, patching, interface, or native hosting. Syntho carries a musical brief through a typed graph, normal web interface, live workbench, verification, and supported bundle in one TypeScript project.
| Capability | SynthoAgent-first TypeScript product workflow | Raw C++Maximum control, maximum responsibility | JUCEMature cross-platform C++ framework | CmajorDedicated DSP language and code generation | RNBOMax patching with export targets | Max/MSPOpen-ended visual patching environment |
|---|---|---|---|---|---|---|
| Coding-agent workflow | First-classOne typed project, agent guide, validation, and live workbench | High supervisionA broad low-level surface with few product guardrails | Possible, not structuredLarge C++ API and build matrix remain in the loop | DSP-friendlyThe product shell and interface still need another layer | Patch-firstVisual patch editing is less natural for code agents | Patch-firstAgents work indirectly through patch files and Max conventions |
| Audio and interface | One TypeScript projectGraph, parameters, UI, tests, and product behavior together | You choose every layerUsually C++ plus a UI toolkit and host integration | C++ firstNative UI is built in; web UI adds a WebView and bridge | Split stackCmajor for DSP, scripts or generated host project for UI | Split stackRNBO device plus a separate interface for web products | Inside MaxRich patcher UI, Jitter, and scripting within its ecosystem |
| Web UI freedom | Native to the workflowReact, Vue, WebGL, 3D, animation, and ordinary packages | ManualSelect, embed, and maintain the entire web or native UI stack | Available with integrationWebViews are supported, but the bridge is product work | Possible, separateGUI scripts do not remove the product integration handoff | Interface is your jobThe web export is integrated through @rnbo/js | Powerful but ecosystem-boundMax UI and Jitter are not a normal web product repo |
| Live browser iteration | Built inHear the graph and use the real interface while the agent edits | Build it yourselfAudio runtime, reload loop, diagnostics, and UI hosting | Not the default loopNative builds and hosts remain the center of gravity | Strong DSP reloadHTML and WASM export exists; product UI remains separate | Export then integrateCreate the device, then build the browser experience | Live inside MaxImmediate patching, but not a browser delivery workflow |
| Native product plumbing | GeneratedParameters, saved state, UI packaging, builds, and verification | Entirely manualFormats, hosts, state, automation, installers, and validation | Framework suppliedYou still own builds, signing, installers, and host testing | Generated project handoffExport C++ or JUCE projects, then compile and finish them | Export systemRequires the Max and RNBO toolchain and target workflow | Additional route requiredUse Max for Live, RNBO, Gen export, or custom native code |
| Specialist knowledge | LowestDirect the product, listen, and let the agent operate the technical loop | HighestRealtime C++, memory safety, hosts, build systems, and platforms | HighC++, realtime audio, JUCE architecture, formats, and toolchains | ModerateLearn a DSP language plus the surrounding host and UI layers | ModerateLearn Max and RNBO patching, exports, and target constraints | ModerateLearn Max patching and the conventions of its broad ecosystem |
| Main tradeoff | Private betaFaster integrated workflow with narrower verified coverage today | Everything is yoursMaximum flexibility also means maximum engineering load | Mature but heavyBroad production coverage at the cost of C++ complexity | DSP is not the whole productA second language and generated-project handoff remain | Export is not the whole productWeb UI and product integration remain separate | Great laboratory, indirect product pathShipping beyond Max needs another route |
Fewer handoffs
The audio graph, parameters, interface, workbench, and packaging stay in one project instead of crossing tools and languages.
More agent-readable
Typed contracts, project guidance, validation, and the CLI give a coding agent a direct loop from request to audible result.
More UI freedom
Build a normal web application, not a native widget tree or an exported DSP device waiting for a separate product interface.
JUCE and raw C++ offer broader mature control today. Max/MSP and RNBO remain capable patching environments. Those strengths do not make them shorter routes to an agent-built, web-native audio product.
Questions before you start.
Start with a tool you want to hear.
Explore the working modules, choose the closest starter, and bring a focused musical brief into the selected developer preview.