# Choosing Maru

> Choose an authoring workflow around your product, existing tools and delivery needs.

Canonical: https://maru.audio/docs/choosing-maru
Documentation index: https://maru.audio/llms.txt

Start with the sound, instrument or workflow you want to make. Maru brings
agent-driven editing, a central audio SDK, reusable DSP, web faces, presets and
build tooling into a module project. The intended benefit is less repeated
integration between an idea, a playable tool and a usable release.

## Choose an entry point

For a musician or sound designer, start with an existing tool in
[Studio](https://maru.audio/docs/studio-workflow.md): describe changes, listen and refine the result.
For a developer, use the [SDK](https://maru.audio/docs/audio-sdk.md), [UI kit](https://maru.audio/ui-kit) and a local
project. For an established product team, a bounded integration pilot can test
one authoring or delivery improvement before a wider migration.

The web Studio and desktop Studio are both editing surfaces. They share
module and tool foundations, but their assembled workflows and supported
targets are still being qualified in beta. Start with a specific product and
intended host; a successful browser preview does not establish native or
hardware compatibility.

## Evaluate alternatives fairly

The best choice depends on your existing assets, team and product requirements.

| Tool family | What to consider |
| --- | --- |
| Native plugin frameworks | JUCE provides established plugin tooling and a WebBrowserComponent. Existing C++ products may benefit most from a narrow integration seam. [JUCE learning](https://juce.com/learn/), [web interfaces](https://docs.juce.com/master/classjuce_1_1WebBrowserComponent.html) |
| DSP languages and patching | Cmajor provides DSP tooling and web examples; RNBO exports to web, plugins and other targets. Multi-target export alone is not a reason to switch. [Cmajor](https://cmajor.dev/docs/GettingStarted), [RNBO exports](https://rnbo.cycling74.com/learn/export-targets-overview) |
| Sampler authoring | HISE combines sampler, scripting and interface workflows; Decent Sampler documents a library format. A content library may solve the need without a new plugin. [HISE](https://docs.hise.audio/introduction/index.html), [Decent Sampler](https://decentsampler-developers-guide.readthedocs.io/en/latest/index.html) |
| Web interfaces | Familiar web tools can remain part of the product. Check the audio runtime, state, automation, dependency and packaging requirements alongside the interface. |

If you already build with one of these, [Constraints for plugin developers](https://maru.audio/docs/constraints-for-plugin-developers.md)
summarizes the rules that differ in Maru.

Compare a complete task: build the sound, refine the interface, recover a failed
edit, restore a saved preset and deliver it to the intended user. Include
maintenance and support effort. A shared language, agent conversation or
successful first build does not by itself prove a better workflow.

## What to try first

Choose one useful musical outcome and a small set of controls. Start from the
closest [module](https://maru.audio/modules), make a meaningful edit, save it and test the
supported output. Use [Publishing](https://maru.audio/docs/publishing.md) to prepare a release, or
[Quickstart](https://maru.audio/docs/quickstart.md) for local authoring. Tell us where the workflow
helps and where specialist intervention is still required; that feedback shapes
the beta.