NoiseCraft: a browser patchbay where the audio graph is compiled to an AudioWorklet

A patchbay in a browser tab, aimed at exchange

NoiseCraft is an open source, visual programming language and platform for sound synthesis and music making, with the goal of creating a community for the open exchange of musical ideas.

The design is loosely inspired by PureData and Max/MSP, and that lineage is the clearest description of the interface. You place nodes, connect them, and the connections carry numbers that become sound. The difference from those ancestors is where it runs. NoiseCraft is built on the Web Audio and Web MIDI APIs and runs in a web browser, and the plan is for the app to remain free to use and ad-free for the foreseeable future.

The project is explicit about its maturity. The README says NoiseCraft is a work in progress, and that we are looking for contributors to help build and debug it, and later that it is a passion project and a work in progress, that you may run into bugs, and that support for mobile devices is currently lacking. The live instance is at noisecraft.app, with a browse page at noisecraft.app/browse for projects other users have shared.

Browser support is stated precisely: it currently works in Chrome, Firefox and Edge, but not reliably in Safari due to issues with their web audio implementation. That is a specific technical claim rather than a general shrug, and it is worth noting that the same Safari web audio and pointer capture issues are mentioned again in the development setup section, where the project recommends developing in Chrome because it has the most mature web audio implementation and has been the most extensively tested.

The intended user is a musician, a sound designer, a teacher or a hobbyist who wants to patch a sound together quickly and share it, and the secondary user is the developer who wants to contribute to a small, opinionated project.

One number type, and no split between control and audio

The visual programming language design is the most consequential part of the project, and it is short enough to state exactly.

There is only one data type: floating-point numbers. There is no distinction between control signals and audio signals.

Compare that with PureData or Max/MSP, where the distinction between a control message and an audio signal is fundamental, and where the rate at which a signal is evaluated is part of the semantics. NoiseCraft removes that distinction, and every design consequence follows from it.

What it buys is a smaller language. There is no separate control-rate graph, no signal versus message typing rule to learn, and a single numeric connection type, which means the learning curve is about sound rather than about the framework. The stated UI goal of minimising the learning curve and reducing friction is consistent with a language that has one type.

What it costs is a range of behaviours that depend on rate semantics. Envelopes, sample and hold stages, sequencers and clock dividers, all of which are present in the example projects, have to be expressed with a single number flowing through a single graph, and the way the project does that is by compiling the graph into code rather than by scheduling different rates.

The minimalism extends to assets. The practical considerations are to avoid images and sound samples to keep bandwidth and server costs low, and the README notes that avoiding sound samples also forces people to think about how to generate sounds. That is a design decision with an operational reason behind it, since the platform stores and serves user projects, and every uploaded sample is storage and bandwidth for the operator. It also means the tool teaches synthesis rather than sample playback.

The model compiles to JavaScript and runs in an AudioWorklet

This is the mechanism that makes the single-type language workable, and it is the part of the README that deserves the closest reading.

Audio is produced by the `AudioView` class, which lives in `public/audioview.js`, and it is updated when state changes occur in the model. This compiles the audio graph into JavaScript code that can then be run in a background process, an `AudioWorklet`.

The last sentence of that paragraph is the important one: we only use the web audio API to output sound, not for sound synthesis. The Web Audio API is the transport, and the synthesis is code the project generated. The stated reason is that this helps guarantee that the sound produced for a given project will be the same on any browser or device.

That is a substantial design bet. Rather than relying on each browser's implementation of built-in oscillator and filter nodes, and rather than relying on the difference between the Web Audio implementations that makes Safari unreliable, NoiseCraft moves the synthesis into code that the project controls and the browser merely executes in a worklet. The remaining browser dependency is the output path and the Web MIDI input.

The compile step happens in the browser, in the `AudioView` class, and the resulting worklet code is what the browser runs, so the same project produces the same numbers and the same graph structure regardless of the browser's audio quirks.

For a user, the practical consequence is that a project is a piece of generated JavaScript plus a patch description, and what you hear is what the generated code computes. For a developer, it means the interesting work is in the compiler rather than in the node library, and it means a bug in the generated code is a bug in the project, not in the browser.

Multi-page layout and an immediate-mode interface

Two interface decisions are explained in the README, and both are about not losing the user's work.

The first is the multi-page design, as opposed to a single-page app. The New, Help and Browse links open new tabs, and the stated reasons are that this helps users avoid accidentally losing their work when clicking other tabs, and that it makes it possible to send new users direct links to the `/browse` and `/help` pages. A sound patch is unsaved work by nature, and a single-page app that navigates away from the editor is a data loss bug waiting for a distracted user.

The second is the immediate-mode GUI, where the interface is redrawn every time an action is performed on the model. The stated benefits are that this makes it trivial to implement undo and redo, because previous project states can simply be stored as copies, and that it reduces the coupling between the user interface and the model. In practice, caching is used to avoid redrawing the entire user interface for every single state change.

The undo and redo argument is the strongest one, and it is a good example of a constraint producing a good result. In a retained-mode interface, undo means storing a diff or a command history and worrying about how to apply it in reverse. In an immediate-mode interface, undo means keeping the previous state object, which is trivial to store and impossible to get out of sync with the model.

The interface rules themselves are stated as principles: minimise the learning curve, keep the interface simple and uncluttered, avoid drop-down menus and hidden options if possible, use key combos and controls that will likely seem familiar to most users, and avoid ambiguity by using known or existing terminology wherever possible. The no-drop-down rule is a real constraint on a node-based editor, where drop-downs are the conventional way to pick a parameter value, and it is the kind of decision that produces the unusual look of the project.

Project files as JSON, and the VST idea

Project files are saved in an easy to parse JSON format with the `.ncft` extension, and the README says this could allow external tools to eventually be built, giving the example that it is possible to imagine NoiseCraft projects being compiled into VSTs.

The reasoning is sound. A visual programming environment is a graph plus a set of node definitions, and if both are stored as data rather than as a proprietary binary, then other programs can read them. That is what makes an ecosystem possible at all, and the browse page of shared projects is the first step of it.

The example directory shows what a project actually looks like in practice, and the filenames are a better description of the language than the prose is. There is `first_craft.ncft`, `happy_sines.ncft`, `polyclocks.ncft`, `gateseq_clockdiv.ncft`, `acid_test.ncft`, `dual_saw_synth.ncft`, `midi_synth_with_delay.ncft`, `fold_modulated_example.ncft`, `midi_in_example.ncft`, `harmonize_the_noise.ncft`, `2instruments_1207_nodes.ncft` and `a_lot_of_pulses.ncft`, among others. Sequencers, clock dividers, a MIDI input example, a sawtooth synth with delay, a modular fold, a harmoniser and a noise generator. Reading a couple of those files is the fastest way to understand the language, and it is a direct consequence of the format being plain JSON rather than a proprietary blob.

The VST idea is a long way off, since it is stated as something to imagine rather than something in progress. The near term use of the format is simpler and already real, which is that someone can write a tool that inspects, generates or transforms a patch.

The server stores the shared projects, and the environment variable table shows the shape of that: `DB_FILE_PATH` defaults to `./database.db` and is the SQLite file path, and `HTTP_PORT_NO` defaults to 7773 and is the HTTP server port. The dependency list explains the stack, with `express` for the server, `sqlite3` for the database, `ejs` for templates and `crc` for checksums.

Running it locally, and in a container

The development setup is the README's shortest section, and it recommends Chrome as the browser to develop in, because it has the most mature web audio implementation and has been the most extensively tested. It notes that the project is waiting for a Firefox bug to be fixed, and that it has run into issues with the Safari web audio and pointer capture implementation.

Installing the dependencies is a standard Node setup:

# Install nodejs and npm
# Use apt-get on Ubuntu/Debian or brew on macOS
sudo apt-get install -y nodejs npm

# Update npm
sudo npm install -g npm

# Install the dependencies for this project
npm install

Then start the server:

node server.js

and NoiseCraft is accessible at `http://localhost:7773/`. The test suite is a single file, run the same way:

node tests.js

The Docker route is two commands:

# Build docker NoiseCraft image
docker build . -t noisecraft

# Start docker NoiseCraft container
docker run -p 7773:7773 -d noisecraft

which serves the same `http://localhost:7773/`.

The package metadata adds a few details. The package is an ES module, the main entry is `server.js`, the start script is `node server.js`, there is a `watch` script using nodemon, and the build script bundles the browser side with esbuild, taking `public/main.js`, `public/audioworklet.js`, `public/help.js` and `public/browse.js` into `deploy/public`. The `deploy.sh` script at the repository root and the `deploy/` output directory in the build script are how the static front end is served alongside the Express server.

One thing to check before you deploy this yourself is the Dockerfile, which is built `FROM node:16`, and the `esbuild` version in the dev dependencies, which is on the 0.14 line. The project documentation asks you to install a current Node and npm, and the container image is considerably older than that, so the two paths are not guaranteed to behave identically.

Where NoiseCraft is the wrong choice

The limitations here are stated by the project itself, which makes them easy to weigh.

The first is browser support. It does not work reliably in Safari because of the web audio implementation, and the development notes add the pointer capture implementation to the list of Safari problems. If your users are on Safari, the tool is not usable for them, and no amount of care on your side changes that.

The second is mobile. The README says support for mobile devices is currently lacking, which is a gap in the touch interface rather than in the audio path.

The third is the single data type, and it is the deep one. If your sound design needs a real distinction between a control signal and an audio signal, with different rates and different semantics, NoiseCraft's language will make you encode that yourself. The example projects show that sequencing, clock division and modulation are all expressible, so this is a constraint rather than a wall, but it is a constraint you accept at the start of a project.

The fourth is the state of the code. There are no GitHub releases, the version in `package.json` is 0.0.1, the last push was on 2026-09-23, and the project's own status line says it is a work in progress with a plan to stay free and ad-free. Ad-free and free is a good promise for a user, and it also means there is no commercial entity standing behind the uptime of the hosted instance. The contribution policy says it plainly: the project wants to avoid growing the functionality too fast, will be conservative about the additions it accepts, and considers bug fixes the contributions it is most likely to accept.

The alternative approach, for comparison, is a native modular environment such as PureData or a hardware Eurorack system. The difference in approach is that a native environment gives you sample playback, a mature and deep ecosystem, and a stable file format, at the cost of an installation and a steeper first hour. NoiseCraft gives you a link, a browser, a shared community and a generated audio graph, at the cost of a project that is still finding its shape and a language with one type.

Editorial conclusion

Adopt NoiseCraft if you want to sketch a sound in the browser, share the patch as a link, and do not want to install an audio stack, since the whole tool is a page, the projects are JSON and the audio graph is compiled rather than interpreted. Do not adopt it if you need a stable release, if you are on Safari, or if you need mobile support, because the README says all three. Verify three things first: that the project you intend to build is possible with one number type and no control and audio split, that your browser passes the audio and pointer capture behaviour the project needs, and that the state of the repository suits you, because the newest release tag does not exist and the code is still a passion project with a stated plan to stay free and ad-free.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. maximecb/noisecraft on GitHub
4. Project website
5. README