Libpd-WASM – running Pure Data in the browser

Libpd-WASM – running Pure Data in the browser(github.com)

2 points by jonasholmer 88 days ago | 3 comments

TL;DR

This playground contains a number of patches to play around with:

https://hyrfilm.github.io/libpd-wasm

Pd vanilla is completely supported. As well as what's sometimes called the "extras". With the exception of a few objects it also includes Cyclone & ELSE, with support for some additional libs/externals coming up.

Background

I recently started creating WebAudio nodes using tools like RNBO, FAUST etc. If you're not familiar with them they cover an impressive range of build targets, from embedded systems to VSTs to running patches in the browser as WebAudio worklets. I incorrectly assumed that someone had ported libpd to WASM, but that wasn't the case so... then I did.

https://github.com/hyrfilm/libpd-wasm

I did stumble over some cool projects but with slightly different goals though. Like the Heavy Compiler Collection (https://github.com/Wasted-Audio/hvcc) which allows you to compile patches into WebAssembly to allow you to host them. WebPd (https://github.com/sebpiq/WebPd) is another example of a similar approach.

I chose instead to actually port libpd. The main difference with that approach is that patches are interpreted at runtime, so you can load, reload, or swap them dynamically — just like you would on desktop. And it also opens up for things like generating patches at runtime and so on. If you want to use it yourself, there's a npm package for it - so it should be fairly straightforward to get started.

Rochus 88 days ago | |

This is incredible. Wouldn't have thought that it works so well in the Firefox on my old Lenovo T480.

jonasholmer 88 days ago | | |

Thanks! And that's awesome! You know, it's strange when I've been using RNBO to do much less heavy stuff than many of these patches do I kind of assumed that the reason it ended up with a fairly high WebAudio resource consumption was because... I'm an idiot. :D But now I kind of wonder if it could be connected to the fact that signal-rate processing (when using RNBO) is per sample - at least according to my understanding, I could be wrong. So if you have a vector size of, say, 128 samples then whatever you do would execute 128 more times than if you "just" did signal-processing PER vector. So maybe it could be related to that... I think I'm just might send a mail to cycling74 and ask hehe. But nonetheless, it's pretty crazy how insanely low the resource consumption is for the pd patches I've profiled so far. Sometimes it's not even above 1%.