# Constraints for plugin developers

> The few rules Maru's architecture depends on, for developers coming from JUCE or another framework, with links to the guides that own the details.

Canonical: https://maruaudio.com/docs/constraints-for-plugin-developers
Documentation index: https://maruaudio.com/llms.txt

If you have built plugins before, most of Maru will feel familiar: parameters,
presets, audio and MIDI processing, a UI and a set of plugin formats. A few
rules differ, and they are what let one source play in a browser, a DAW and
other targets. This page names them. The details belong to the linked guides,
and they evolve as the platform does.

## Realtime code stays realtime

Sound processing is written as restricted TypeScript that compiles to each
target. The audio callback must not allocate, lock, block or do I/O. State is
prepared ahead of processing, and controls change through the building blocks'
own setters. Model inference, file access and network calls happen outside it.
See the [Audio SDK](https://maruaudio.com/docs/audio-sdk.md) and [DSP library](https://maruaudio.com/docs/dsp.md).

## A module owns the sound; the host owns services

A module declares its ports, parameters, presets, assets and interface. Devices,
files, sign-in, account access and other services come from the host. Faces
never produce audio or open devices. See [How it works](https://maruaudio.com/docs/how-it-works.md).

## Parameters mean the same thing everywhere

Each parameter's range, steps and response curve are declared once, on the
parameter. Host automation, MIDI CC and the interface all read that declaration,
so they agree position for position. Shape a parameter's feel there, not in the
face. See [Contracts](https://maruaudio.com/docs/audio-contracts.md).

## One source, qualified targets

The browser, native plugin formats and devices are built from the same source.
Each target is built and checked separately, and each release lists what it
supports. A browser demo does not by itself establish a native or hardware
target. See [Check, build and export](https://maruaudio.com/docs/export.md) and
[Native plugins](https://maruaudio.com/docs/native-plugins.md).

## Reuse before writing new DSP

Prefer the library's effects and building blocks, and extend a shared building
block rather than copying it into a module. `maru dsp effects`, `maru dsp nodes`
and `maru module list` show what exists. See
[Effects, instruments and custom DSP](https://maruaudio.com/docs/effects-and-instruments.md).

## Availability and licensing

The `maruaudio` package is published on npm. The local workbench and plugin
builds currently need a toolchain provided in the selected-developer beta; see
the [Quickstart](https://maruaudio.com/docs/quickstart.md). The SDK, CLI and generated plugin shells are
not published under a general open-source license; see
[Licensing](https://maruaudio.com/docs/licensing.md). [Choosing Maru](https://maruaudio.com/docs/choosing-maru.md) compares the
approach with JUCE, Cmajor and RNBO.