# openDAW's plugin list reads like a synthesiser catalogue, and its pitch is a refusal

> A browser-based audio workstation whose readme spends a paragraph on what it will not do: no sign-up, no tracking, no cookie banners, no profiling, no terms, no ads, no paywalls. The second interesting thing is that its audio engine is compiled to WebAssembly, which is the technical fact that makes a browser a plausible DAW at all.

**andremichelle/openDAW** — openDAW is a next-generation web-based Digital Audio Workstation (DAW)

- Repository: https://github.com/andremichelle/openDAW
- Website: https://opendaw.studio
- Stars: 2,166 · Forks: 201
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/andremichelle-opendaw

## The pitch is a list of refusals, and that is unusual in a readme

There is a section headed as a statement of what the project stands for, and then a list of eight things it does not do: no sign-up, no tracking, no cookie banners, no user profiling, no terms and conditions, no ads, no paywalls, no data mining. Read that list carefully, because each item is a decision with a cost. No sign-up means there is no account system, which means there is no server-side storage of your work and no way for the project to monetise you, and it also means there is no password to forget. No tracking and no profiling means there is no analytics, which is exactly the thing most free web applications use to demonstrate traction to investors. No paywalls means the revenue has to come from somewhere else, and the readme's acknowledgements section answers that: a named list of supporters at two price points, plus a group of people described as ambassadors. No data mining is the one that matters most for a creative tool, because the obvious business model for a free music application is to look at what people make. The whole paragraph is a positioning statement, and its force comes from the fact that a browser-based tool is exactly the category where those refusals are unusual. The source is offered under the copyleft licence with an or-later clause, so the commitment is structural rather than a promise in a policy document.

## A WebAssembly audio core, which is the technical fact underneath the claim

The build step for the compiled audio core is one command in the root manifest:

```bash
npm run build-wasm
```

The root manifest contains one script that explains the architecture better than any amount of prose would. There is a build-wasm target that runs a package build for a WebAssembly module, and a package name ending in that suffix. So the audio engine is not JavaScript running in a browser. It is compiled to WebAssembly, which matters for three reasons. First, numerical code in WebAssembly is close to native speed, so a real-time audio callback does not have to be starved by garbage collection, and a digital audio workstation live or dies on whether its audio thread is reliable. Second, it isolates the engine from the host environment, so the same binary runs in any browser that supports the standard, which is what makes the no-install claim true. Third, it means the project is not relying on the browser's audio APIs for anything beyond input and output, which is the same decision a native application makes and is unusual for a web project. The rest of the tooling is a monorepo with a task runner, a workspace layout, separate development targets for the studio application and for two other applications the manifest names, and a test target that runs serially. Serial test execution is a deliberate choice for an audio project, where tests that share a timing assumption will fail if they run in parallel.

## Thirty stock plugins, and the instrument that is a script

The device list is the longest part of the readme and reading it as a catalogue tells you about the project's priorities. It opens with three items that are not effects. One is an instrument you program in JavaScript. One plays the notes of a chord one after another, which is an arpeggiator. One is a sampler for a single audio file. Then the effects, and the selection is revealing: a real-time monophonic pitch corrector, a noise gate with sidechain support, a brickwall limiter with automatic gain makeup, a convolution reverb described as zero-latency and partitioned with impulse-response samples, an algorithmic reverb based on a named academic design, a stereo delay, a frequency splitter that routes bands into separate effect chains, a multi-chain mixer, and a stereo processor that treats the channels separately. Three items name their algorithms explicitly: a subtractive synthesiser, a phase-distortion synthesiser, and a folding algorithm with oversampling. One models a guitar amplifier using a neural approach. Two more are programmable and scripted in JavaScript: a MIDI effect and the instrument. The pattern is a set built around a small number of general-purpose routing and shaping tools, so a user can assemble an unusual sound by wiring effects together rather than by choosing from a long preset menu. What is missing is as informative: no drum machine beyond the sample one, no wavetable synthesiser, no granular instrument, no sidechain compressor as a separate item, and no sampler with multiple zones.

## Three applications in one repository, and a docs directory per topic

The root manifest's development scripts name three separate applications, and that is the clearest statement of scope in the repository. One is the studio, which is the product. One is a lab. One is a manual, which is the documentation set. Plus a development target for a collaboration server. So this is not a single application with a settings page; it is a studio, a laboratory for experiments, a manual, and a server, sharing a monorepo. The repository layout supports that reading and adds more. There is a crates directory, which in a JavaScript monorepo is almost certainly a native or compiled component, consistent with the WebAssembly audio core. There are separate directories for announcements, audits, deployment, documentation, error definitions, future plans, licences, plans, scripts, test files, video and a wiki. The plans and future-plans directories are worth pausing on, because they are paired with the contribution rules. The readme says contributions should follow existing style, that AI-assisted code is fine but every contributor must understand every line they submit, that if you use an AI tool you should document your process in the plans directory, that pull requests must be small and focused, and that large ones will not be reviewed. A directory that holds the record of how a change was produced is an unusual and rather admirable convention, and it is what makes the plans directory load-bearing rather than aspirational.

## Release announcements, a contributor policy, and three named areas of need

The readme opens with a release announcement rather than a description, and it is specific: a one-point-oh release meetup at a named venue in a German city, on a Saturday in October, with free admission and required registration, talks and panels in a particular language, live acts produced entirely with the software, and stations to try it. Then it links a newsletter and a separate introduction document that maps every component of the repository and how they depend on each other, which is a genuinely useful thing to publish and unusual to find. The contributor section is the other part worth reading in full. It welcomes contributions that follow existing conventions, sets the rule about understanding your own code, and names three areas where help is wanted, in order of specificity: wrapping the application in a desktop shell for a native experience, turning it into an installable progressive web application with offline support, and design and user-experience help on timeline track management for layout, ordering, grouping and interaction. Naming three concrete gaps is more useful than a general appeal, and the fact that the first two are packaging problems says the project is functionally complete and blocked on distribution. The readme closes with an unusually long list of named contributors, a separate mention of the people described as the biggest bug hunters, and a two-tier supporter list with amounts. That supporter list is the honest business model of a project that refuses advertising.

## Conclusion

Adopt openDAW if you teach music production and want students to open a project in a browser without installing a desktop application or creating an account, since that is exactly the constraint the project is organised around. Do not adopt it for a session you cannot afford to lose, because it is a copyleft-licensed web application that stores your work in a browser and the readme does not describe the storage or export guarantees in detail. Four things to verify. Where your projects actually live, because a browser-based workstation raises real questions about local storage, device limits and what happens when you clear your cache. That the plugin you need exists, since the stock list is around thirty items and some of the most standard synthesiser forms are conspicuously absent. How you work with a copyleft licence, because the source is offered under a share-alike licence with no commercial exception, which is a constraint if you intended to build on it. And whether the release you read about is the one you get, because the readme announces a one-point-oh release event while the manifest version is a zero placeholder. The last push was on 2026-09-28 and the tagged releases are development builds of a software package rather than the application.

## FAQ

### What is openDAW?

A web-based digital audio workstation aimed at making music production accessible, with a stated focus on education and data privacy. The source is under a copyleft licence with an or-later clause, and the readme states the project is designed to democratise music production and resurface the process of making music.

### How does openDAW run audio in a browser?

Through a WebAssembly audio core. The root manifest has a dedicated build target for a package whose name ends in that suffix, so the audio engine is compiled rather than running as JavaScript, which is what makes the no-install claim and reliable real-time audio possible.

### What plugins does openDAW ship with?

Around thirty stock items, including a JavaScript-scripted instrument, a chord arpeggiator, a single-file sampler, a phase-distortion and a subtractive synthesiser, a pitch corrector, a convolution and an algorithmic reverb, a delay, a noise gate with sidechain, a limiter with automatic gain makeup, a frequency splitter, a stereo processor, and a neural amplifier model. Two further devices are programmable and scripted in JavaScript.

### What are openDAW's rules for contributors?

Follow the existing style and conventions, keep pull requests small and focused since large ones will not be reviewed, and understand every line you submit. AI-assisted code is allowed but if you use an AI tool you should document your process in the repository's plans directory. Three areas are named as needing help: a desktop wrapper, a progressive web application with offline support, and timeline track management design.

### What licence is openDAW released under?

AGPL-3.0-or-later, stated in both the readme and the package manifest, with no commercial exception. The manifest version is a zero placeholder for the private monorepo root, and the tagged releases are development builds of a software development kit package rather than the application. The last push to the main branch was on 2026-09-28.

## Sources

- [andremichelle/openDAW on GitHub](https://github.com/andremichelle/openDAW)
- [License: AGPL-3.0](https://github.com/andremichelle/openDAW/blob/main/LICENSE)
- [Project website](https://opendaw.studio)
- [README](https://github.com/andremichelle/openDAW/blob/main/README.md)
- [Releases](https://github.com/andremichelle/openDAW/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/andremichelle-opendaw