# WebPd: compiling Pure Data patches to JavaScript or WebAssembly

> WebPd is a compiler that takes a Pure Data patch and turns its audio graph and processing objects into plain, readable JavaScript or AssemblyScript. The generated code runs on its own, with no WebPd and no Pure Data in the picture afterwards, which is a different deal from a patch runtime and a different deal from a Pure Data port.

**sebpiq/WebPd** — Run your Pure Data patches on the web.

- Repository: https://github.com/sebpiq/WebPd
- Stars: 1,003 · Forks: 90
- Language: TypeScript
- License: LGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/sebpiq-webpd

## A compiler, with a white-box approach

WebPd is a compiler for the Pure Data audio programming language, allowing you to run .pd patches in web pages.

The sentence that explains the project is the second one in the introduction. WebPd is highly modular and takes a white-box approach to audio programming. It converts the audio graph and processing objects from a patch into plain human-readable JavaScript or AssemblyScript, and the pure audio generated code can then be integrated directly in any web application without using WebPd or Pure Data ever again.

That is the whole idea, and it is a genuinely different approach from the two obvious alternatives. Rather than shipping a Pure Data runtime to the browser, which is what libpd does, WebPd translates the patch into code you can read. The result is not an interpreter with a patch inside it, it is JavaScript that a browser executes natively.

The AssemblyScript option matters for the same reason. AssemblyScript is a TypeScript-style language which compiles to WebAssembly, and it gives you a smaller, faster artefact than JavaScript for the same patch. The output being human-readable is the other half of the appeal, because a generative audio patch you cannot read is a patch nobody can maintain.

The project is by Sébastien Piquemal, the primary language is TypeScript, and the licence is LGPL-3.0, which is the licence of the LGPL and the reason the generated code is not encumbered in the way a copyleft library normally would be.

## What WebPd is not

The Integration and scope section is unusually honest, and it is the part to read before you plan a project around it.

WebPd is not, in itself, a complete editor and a live performance platform like Pure Data. The Pure Data graphical interface, as well as GEM, are out of the scope of WebPd. WebPd is not either a simple executor like libpd. It is rather a lean audio compiler, which generates high-performance, human-readable and easily integrable audio code with no bloat.

The three exclusions cover the three things people usually expect. You do not get the editor, because the editor is Pure Data itself and you author there. You do not get GEM, which is the graphical side of Pure Data and depends on OpenGL in ways a web port cannot reproduce. And you do not get a runtime, because that is the point.

On the integration side, the README argues that there are plenty of good JavaScript libraries for building interactive visual interfaces, Three.js and p5.js among them, and integrating them with a WebPd patch should be fairly easy, with the patch player demo as the example.

The use cases follow from that. Publish generative musical works on the web, execute, tweak and share patches collectively on any machine, and produce, filter and play back sound and music data in real time from web based applications and games.

## The web compiler, and the URL that carries the state

The web compiler and patch player are live at sebpiq.github.io/WebPd_website, and the flow is short.

You upload a patch or give a URL of one, it is compiled just in time, and you get an interface for playing that patch in real time in the browser. Once the compilation succeeds you can copy and share the resulting URL from the player, and that URL contains all the modified parameters of the patch you have played with, so that it is shared completely in its current state.

That last property is the interesting one. The shared URL is not just a pointer to the patch, it is the patch with the state of your session baked in, so a listener opens the link and hears what you heard. The patch can come from anywhere, since you can use any public URL of a patch found in the wild, on GitHub or the Pure Data forums for example.

There is one limitation and it is stated in a footnote, because it is the kind of thing that only appears when you try it. Sharing a compiled patch does not work if you used local files for compilation, which makes sense, since the browser that compiles it cannot reach a file on your disk and a shared URL could not include it either.

The compile step being just in time is the other design point. Nothing is built ahead of time, the patch is compiled when you ask for it, which is what makes the any-URL workflow possible.

## The command line interface

The command line interface offers more customization options, including the ability to generate a fully-functional, but bare bones, web page embedding your patch.

Running the CLI requires node.js version 18 or higher, and the install is a global npm install:

```bash
npm install -g webpd
```

And you verify it with:

```bash
webpd --help
```

which is supposed to output help for the CLI and get you started.

That is the whole interface, and the difference from the web compiler is the important part. The web compiler compiles a patch and gives you a player. The CLI compiles a patch and can also generate the page around it, which is what you want when the patch is going into an application you ship, rather than into a link you share.

The bare bones qualifier is honest and useful. You get a working page that plays the patch, and you replace the surrounding page with your own, which is consistent with the white-box approach: the audio code is the part WebPd is responsible for, and the page around it is yours.

The package metadata matches the workflow, with the version at 1.0.0-alpha.14, the binary declared as webpd pointing at bin/cli.mjs, the engine requirement of Node 18 or later, and the published files being the CLI, the build output and the icon.

## Writing patches that survive the port

The Advices for writing WebPd compatible patches section is three bullets, and every one of them is a real trap.

Make sure that you only use supported features, which the README points at the ROADMAP file listing the implemented objects and features. Always use [trigger] objects to make message send order explicit, including in initialisation with [loadbang] and when loading soundfiles, and the reason is given: due to different constraints, Pd and WebPd's message sequencing order might be different. And use the [samplerate~] object instead of hard-coding the sample rate with a fixed value.

The trigger advice is the subtle one. Pure Data orders messages in a way that is well defined but that WebPd, being a different implementation with different constraints, does not reproduce exactly. A patch that relies on the order of two messages arriving will behave differently after the port, and the fix is to make the order explicit rather than to hope.

The samplerate advice is the practical one. A hard-coded sample rate in a patch is a number that is right for the machine you authored it on and wrong for the browser the listener opens, so the object that reports the current rate is the only safe thing to use.

Together they are a good summary of what porting an audio patch costs. It is not the DSP, it is the parts of Pure Data's behaviour that were implicit rather than declared.

## Four repositories, one build

The project is built in several sub-packages in addition to this one, which combines them all, and the contributor section names three of them with their repositories.

The Pd file parser is WebPd_pd-parser, the WebPd compiler is WebPd_compiler, and the WebPd runtime is WebPd_runtime. The repository you are reading is the package that ties them together.

The package manifest shows how that assembly is built. There are three Rollup configurations, configs/cli.rollup.js, configs/dist.rollup.js and configs/runtime.rollup.js, and the build script runs them in order after a clean, so the runtime is built first, then the distribution, then the CLI. The test script runs Jest with the configuration from node_modules/@webpd/dev, with Node options for the experimental VM modules and a two gigabyte heap limit, which suggests the compiler tests are memory hungry.

The development scripts are worth noting because they describe a multi-repository local workflow. build:dev:deps walks into the sibling directories and builds each of the three sub-packages, and link:local npm links them all into the main package so the changes propagate without publishing. There is an unlink:local to undo it.

That is the cost of a monorepo split across four repositories, and the payoff is that the parser, the compiler and the runtime can be versioned and consumed separately, or so that the runtime can exist without the compiler in a browser build.

## Alpha status, and what the licence allows

The status is stated without softening, and it should shape your expectations.

WebPd is currently under heavy development, but it is still a work in progress. The list of implemented objects, features and the roadmap is in ROADMAP.md. The project is currently in an alpha release state, which means that many of your patches will not work out of the box, and many objects and features are indeed still missing. The version in the package manifest, 1.0.0-alpha.14, is consistent with that.

So the honest reading is that this is a research and production tool for people who are willing to check the roadmap before they start, and who will report the objects that are missing. The bug reporting template in the README is correspondingly specific: narrow it down first by removing all objects in the patch that are not related with the bug and finding the simplest patch that reproduces it, then describe the current behaviour and the expected behaviour.

The contribution guidance is lighter than the rest of the documentation. One-time contributions or regular work on the library are more than welcome, contribution guidelines are coming, and the suggestion for people who want to get involved is to get in touch on the issue tracker. For anyone who wants to try developing a new object, the README points at clip.ts and clip~.ts as examples to start from, and the object source lives under src/nodes/nodes/.

The licence is the GNU Lesser General Public License version 3. WebPd is free software, you can redistribute it and modify it under those terms, and it is distributed in the hope that it will be useful but without any warranty.

The last push was on 2026-07-02 and the repository is not archived, and there are no GitHub releases, which for a project at the alpha stage with a version in the manifest is the normal arrangement.

## Conclusion

Adopt WebPd if you want to author audio in Pure Data and ship the result as ordinary web code that your team can read, review and integrate into an existing application. Do not adopt it expecting Pure Data itself, since the graphical editor and GEM are out of scope, and do not adopt it for production use while it is in the alpha state the README describes. Before you start, read ROADMAP.md for the list of implemented objects, and write your patches with trigger objects and samplerate~ so that the message ordering and the sample rate do not break in the port.

## FAQ

### What does WebPd do with a Pure Data patch?

It compiles it. The audio graph and the processing objects are converted into plain human-readable JavaScript or AssemblyScript, and the generated code can then be integrated directly into any web application without using WebPd or Pure Data ever again.

### How is WebPd different from libpd or from Pure Data itself?

WebPd is not a complete editor and live performance platform like Pure Data, the Pure Data graphical interface and GEM are out of scope, and it is not a simple executor like libpd. It is a lean audio compiler that generates high-performance, human-readable and easily integrable audio code with no bloat.

### How do I install the WebPd command line interface?

You need node.js version 18 or higher, then run npm install -g webpd and verify with webpd --help. The CLI offers more customization options than the web compiler, including the ability to generate a fully-functional but bare bones web page embedding your patch.

### What should I watch out for when porting a patch to WebPd?

Only use supported features from the ROADMAP, always use trigger objects to make message send order explicit including in initialisation with loadbang and when loading soundfiles, because Pd and WebPd's message sequencing order might differ, and use the samplerate~ object instead of hard-coding a sample rate.

### Is WebPd ready for production use?

The project says it is in an alpha release state and that many patches will not work out of the box, with many objects and features still missing. It is MIT-style permissive for the LGPL-3.0 licence, distributed without any warranty, and the version in the manifest is 1.0.0-alpha.14.

## Sources

- [Issues](https://github.com/sebpiq/WebPd/issues)
- [License: LGPL-3.0](https://github.com/sebpiq/WebPd/blob/main/LICENSE)
- [README](https://github.com/sebpiq/WebPd/blob/main/README.md)
- [sebpiq/WebPd on GitHub](https://github.com/sebpiq/WebPd)

---

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