How it works

Whether you build in Studio, with an AI assistant or in code, you are working on the same kind of project. Five ideas explain how it fits together, and why it is built this way.

In the Help Center: How Maru fits together for the same picture without technical detail.

An idea or prompt becomes an editable project. The project draws on a shared library of effects, modules, sound building blocks, interface controls and generative models, and produces a module: sound, parameters, interface and presets together. That module can be played in a browser, rack or your own app, built as a native plug-in, and shared or sold.

1. A module is the product

A module keeps its sound processing, parameters, interface, presets and assets together in one TypeScript project. The declaration (src/index.ts in a new project) connects typed audio and MIDI nodes, and TypeScript catches unknown nodes, invalid parameters and incompatible connections before anything plays.

Why: the same module can be played in a browser, connected in a rack, built as a plug-in, shared or sold without reassembling it for each destination. Project structure shows the files.

2. Sound and interface are separate layers

The interface, or face, is browser UI code. It reads and changes parameters through the SDK face contract; it never generates audio or opens devices. Build it from the shared UI kit, or add animation, video, WebGL, 3D and other browser-safe libraries.

Why: you can redesign an interface freely, or give an existing module a new one, without breaking its sound, presets or automation. See Module UI.

3. One sound source, several outputs

Most tools are assembled from included building blocks, and new realtime DSP can be added as restricted TypeScript when needed. The browser runs it as compiled WebAssembly in an AudioWorklet; native builds use the same graph and compiled DSP inside generated plug-in shells. The toolchain owns host integration, automation, state restoration and build plumbing.

Why: you write the sound once, and each target is built and checked from that source instead of being ported by hand. Supported formats are recorded per module and release. See Check, build and export and Keeping audio consistent everywhere.

4. Generation runs beside the audio, not inside it

Generative models create sounds, kits and MIDI on Maru's servers or in a separate runtime. The instrument then loads the result like any other sound.

Why: the realtime audio path stays glitch-free, and you never host or update a model yourself. See Generate audio.

5. Your agent uses the same tools you do

Every Maru operation is a CLI command, an MCP tool and a typed library call, with one input schema and one permission model. Studio's agent, your coding agent and your own scripts all change the project the same way.

Why: an agent's work is an ordinary project change you can inspect, keep and continue by hand. See Connect your AI assistant and Working with coding agents.

Where you work on it

Web Studio edits hosted projects through agent chat. Desktop Studio and the local developer workbench (maru dev) work with folders on your computer, with live audio and MIDI, hot reload, parameter inspection, diagnostics and export actions. See Studio workflow and the Quickstart.

Words that are easy to mix up

Term	Meaning
Module and host	A module owns musical behavior. A host (Studio, a web page, a DAW plug-in shell, your app) supplies devices, files, sign-in and other services.
Bank and preset	A bank maps samples and musical content for a sampler. A preset stores settings for a module. Neither is a program.
Browser preview and plug-in	Playing in the browser does not mean a plug-in format has been built and checked. Each release lists its formats.
Signed in and allowed to spend	Signing in identifies a person. Generating sound needs a separate permission to spend that person's credits.

Next, see the Capability map.