jonasholmer

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%.

Hey, really awesome work! As someone that makes a lot of music and creates instruments and plugins, there's one thing though I feel need to push back against slightly. So now you're in the position where I'm assuming the codebase is quite young an malleable. I think it's worth asking yourself: do we need another garageband-like linear music tool? I would say, no. The reason I'm bringing this up in first place is because, yes, there will always be people that think you should make another... superhero-movie or something. But why not make an effort to make something instead that genuinely introduces some new ideas?

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.

Happy to answer questions about how people structure larger test suites or how the matcher system works.

Hi HN, Having spent close to a decade working in the medtech industry, I’ve seen API test suites become brittle over time — not because the APIs broke, but because the tests asserted too much. When you snapshot an entire response body, you're asserting every field, including ones irrelevant to the test. The moment your API adds a new field (a completely valid, non-breaking change), half your suite fails and you spend the afternoon clicking “update snapshot.” Nothing was actually wrong. Skivvy's default is the opposite: assert only what you care about: { "url": "/api/users/1", "response": { "name": "Alice" } }

This passes even if the response contains 20 other fields. You declared that you care about name, so Skivvy checks name. Tests are plain JSON files in git — no GUI, no export step, no proprietary format. State can pass between tests declaratively ($store / <variable>), so auth flows and chained requests work without imperative hooks. Custom matchers are simple Python functions if you need to go beyond the built-ins. We've used Skivvy for all backend API tests at my current company for a couple of years. Curious whether others have landed on similar patterns — especially when dealing with hundreds or thousands of tests.