signalsmith

I'm not really a hardware person, although at this point I've done a couple of guitar-pedal projects. My favourite is to write OS-independent C++ DSP classes, and work with a team/client who handles the gnarly build/signatures/UI/embedded stuff.

I don't know anything about proprietary reverbs, I'm afraid - particularly hardware units! Sometimes you can tell things about a reverb's internals by looking at impulse responses, but I've always had more fun designing something from scratch.

Yes, I'm Geraint. :D I'm the tech side of Signalsmith Audio, and my partner is the Business Brain. The JSFX plugins are mostly from before we made a proper company (back when Signalsmith was just my username) - I'm glad you're enjoying them!

Some stuff is around the web, some is from other people. Particularly for classic kit, someone's usually analysed it before, but it's not always in a good tutorial kind of form. Personally, I did a lot of messing around with audio/programming from my early teens onwards, and built my intuition about how the maths and sound link up from years of tinkering without many reference resources.

A lot of this stuff can be made from relatively simple building-blocks though, and you don't have to copy a previous configuration. My thought process was pretty much exactly as written in the blog-post! I just wanted to make something which didn't require any special tuning skills.

Given the number of connections/nodes in my design, I'd be interested to know what the performance is.

For Web Audio, there's an increasing trend of compiling WASM and running it in an AudioWorkletProcessor, which is maybe 2-3x slower than native. It's actually how I do a lot of my prototyping now, because the Emscripten build times are faster than a full plugin, and I can send it to people without them having to install anything.

Haha, yeah - although their comment was only considering the 2D case, same as the book.

You can make a (very efficient!) diffuser from 2-channel rotations, but you have to tune it a bit to get it smooth without having a slow attack. With more channels, it's much easier to get right.

Whoah - the author (Signalsmith) here! This was a fun way to wake up, and I'm happy to answer any questions.

A few questions that I anticipate:

--- Shouldn't you find a replacement maintainer?

That's ideal (and compatible with this proposal), but it shouldn't be a requirement for stepping down.

--- Couldn't you just update the README when a project's inactive?

It would be good housekeeping to periodically do this for stale projects, but that's quite pro-active. Plus, it only tells users when it's too late - it doesn't give them any sense of how soon that might happen.

(Also, the latest commit or "last publish" for packages might be misinterpreted as an active contribution.)

--- How could anybody build on a project that has a finite lifetime?

We're already living with that uncertainty, it's just invisible.

And as I said in the README: "If you need stronger guarantees, you may need to produce/negotiate them yourself". If an open-source dependency is essential to your project, then it's not unreasonable to have a support agreement in place, or have a plan for who'll do buxfixes if the maintainer steps back.

OP here - fairly nervous about posting this, but just to give some context of where this is coming from:

A decade ago, I got interested in JSON Schema, and at the time there was no JavaScript validator. I quickly knocked one together and shared it. It took a couple of hours, and was 460 lines plus a bunch of tests.

Only a few years after that, it had grown into a much bigger project. Other people were contributing, but I was still the lead developer. I had my own personal life going on (and other projects), and started to feel tied to this thing, like I wasn't allowed to leave. I wanted to be a responsible maintainer, but it wasn't fun any more.

Maybe someone with more experience (or a different brain) could have sustained this project indefinitely, but I eventually hit open-source burnout. I didn't sign into GitHub for several years, because I couldn't handle seeing the little notification icon. In retrospect I should have stepped back in a more proactive way (reaching out to regular maintainers first, and then putting a notice on the repo if nobody stepped up), but by the time things got bad I couldn't face it.

The license had standard boilerplate saying: THE SOFTWARE IS PROVIDED "AS IS" - but that's a legal disclaimer, not a social one. The package was (and still is) being downloaded millions of times per week on NPM, and those people had a (reasonable!) expectation that a popular and relatively-established package would be maintained, and bugs would be fixed.

There's a tension between the two sides, and this discussion has happened a few times recently. Some open-source developers want to provide reliable tools, and some others say "this is free work, you shouldn't expect anything". Some open-source users say "you published this, so you wanted me to use it, and that comes with obligations", and these disagreements can get quite heated.

Sharing code is fun, but I think the default assumptions should have more explicit limits, and a natural path to stepping back. I'm not fixated on this particular format, but I would like to see what happens if a missing SUPPORT.txt raised as many questions as a missing LICENSE.

This is off-topic, but I really like the current GOV.UK (several years old now). I don't really have opinions on the visual stuff, but I find it really pleasant to use.

Filing my self-assessment tax return (only required because I run a side-business) is a fantastically straightforward experience. Step-by-step information entry, pre-filled with what they already know (e.g. main employer's salary), then they give you a number at the end which you pay by card.

Having done the paper version exactly once before moving over to doing them online, I feel grateful every time I see that distinctive custom font.