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.

*EDIT*: I just realised that the demo you're talking about doesn't include the "early reflections"! So that demo only includes echoes which have gone through the main feedback delays at least once.

If you mix in some of the diffused signal directly, it bridges the gap between the initial sound and the feedback echoes: https://signalsmith-audio.co.uk/writing/2021/lets-write-a-re...

---

You can tune the diffuser to have an almost-instant onset. I can't remember what I did last time, but at a guess, having the largest diffuser stage increase by a factor of N (number of channels) instead of 2 might do it.

But also, if you're playing acoustic drums in a big space like a concert hall (instead of a long one like a staircase), the first echoes coming back from the walls are actually a bit delayed (1 foot ~= 1ms, at the speed of sound). So if your nearest wall is 10ft away, the first wall-echoes will come 10-20ms after the initial direct sound.

I haven't done anything with Rust yet, but it's on my free-time wishlist.

I'm working on WASM demos! I've been playing with WASM builds of my plugins, and it's great for prototyping/sharing, but it could definitely be set up better for demos/teaching: https://signalsmith-audio.co.uk/tmp/web-audio/?url=/tmp/basi...

First, join a good community! If you're on Discord, TAP is great: https://discord.gg/aBghGGcfYs - it's beginner-friendly while also having some heavy-hitters in there, and it's generally wholesome. You're not the only hobbyist learner, and it's important to have a place you can ask questions without feeling awkward.

If you swap language/environment later, you'll carry your understanding/intuition with you, so you don't have to start with C++ if that's not your bag (even though it's still the industry standard). There are audio-specific languages with JIT runtimes (which can be used in Logic/Reaper/GarageBand/etc.), Rust/JS frameworks, etc. so find the one that feels good to tinker with, and keep that momentum/motivation going. :)

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.

As always, there is a relevant XKCD: <https://xkcd.com/2347/>

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.

In this case, the fallback is still a plain-text field, into which the user should enter numbers. Perfectly usable, but without the keyboard hint, so it seems like a graceful fallback to me.

For me, I really appreciate the Bayesian approach because it makes it very explicit that you pick a prior.

Perhaps my experience is limited, but every (supposedly non-Bayesian) model I've used in practice has been possible to re-express using Bayesian terms, priors and beliefs and so on. Then I get to look at the intitial assumptions (model/prior) and use suitable human hand-wavey judgement about whether they make sense.

Bayes is a good way to _update_ models, but if you lose sight of the fact that the bottom of your chain of deduction was a hand-wavey guess, you're in trouble.

I've seen the question raised whether the "minimalism" (in terms of not owning much) often attributed to Marie Kondo is actually an accurate representation of what she says. The alternative interpretation being something more like "mindful ownership".

I'm in that second camp, slightly confused by people saying things like "Marie Kondo thinks I shouldn't own more than 20 books" or whatever, because that wasn't what I understood. The point is to think about whether that number of books is an effective use of your living space - and the answer can be yes.

So yeah, an online store seems a little odd, but by this point my default position on anything M-K related is "take a second and make sure this isn't misrepresenting her views". Maybe a little shop full of neat things that Marie Kondo likes is... fine? ¯\_(ツ)_/¯

I thought the whole magic of quantum-computing was that instead of just having individual bits in an uncertain/random state, you entangled a whole bunch of bits together, meaning you can meaningfully talk about the probability distribution of an 8-bit value, that's different from 8 independent 1-bit distributions.

Then, you perform operations where the value interacts with alternate values for itself (i.e. the full wave-function) - a bit like the double-slit experiment. For example, you can end up with a new 8-bit value where the probability distribution is the Fourier transform of the previous one's distribution.

So, if you can engineer the initial probability distribution to be "interesting", you can then sample its Fourier transform - using only the 8-qubit values, and not storing 2^8-point distribution in an array. Scale that up, and you could calculate a useful 2048-bit Fourier transform (or more accurately: observe a random sample from the result) with a 2048-qubit system, instead of a 2^2048-point array.

It's not obvious to me how stochastically-changing bits of state can get anywhere close to self-interacting (double-slit-like) calculations.

Slightly off-topic, but for anyone who hasn't encountered them: using continued fractions (https://en.wikipedia.org/wiki/Continued_fraction#Best_ration...), you can easily get the sequence of optimal approximations - where "optimal" means "better than anything else with a smaller denominator".

(e.g. pi -> 3, 22/7, 333/106, 355/113, ...)

This paper is about a different situation (Duffin-Schaeffer), where you don't just want the minimum denominator, but instead have more structured/custom constraints for whether a approximation passes/fails, based on the denominator.

I can also guess people's height to within an inch or two, but I can still have an abstract conversation about a friend-of-a-friend I've never met, without expecting to be (constantly!) told how tall they are unless it's relevant to the story.

So in terms of the order we learn things about people we've never met (when it's not directly relevant), we expect gender much earlier than many other attributes. It mostly reflects our values as a society, as language often does, but that's kind of my point.

In my second example, I used "Julie" instead of "a stranger". The subject is specified in exactly the same way, but people might find "they" more surprising in that case.

Some people might even take it as a potential clue that Julie could be non-binary, because of how much we expect gender-matched pronouns at that point. (Not saying they should, just that they might.)

It's kind of odd, because people seem to accept singular "they" for strangers, but not once there's a name.

If I say: "I bumped into a stranger on the street and trod on their toes, apologised to them, and they apologised to me" - generally (in normal spoken conversation, not here when we're paying attention) people don't care. Using singular "they" for strangers is pretty common, and hundreds and hundreds of years old.

The problem comes when we give someone a name. If I say: "I bumped into Julie on the street and trod on their toes, apologised to them, and they apologised to me", people might think it sounds odd (if they're not used to it).

It's as if we have an order/hierarchy in which we expect to learn information about people. Like, by the time we know someone's name, we assume we should already have been told their gender, and we confused if hasn't happened yet.

> [...] manually renew every 90 days

That's the opposite of the design goals - Let's Encrypt is designed to be automatable.

They set the expiry to 90 days precisely because they want you to automate the renewal.

I've also heard of Facebook Live being used to document police violence.

Same problem with content-moderation, but on the other hand it means the video is out there before the police force has time to confiscate the device or even lock-down their account.

Are you asking how much it costs to get a medical degree as a UK citizen?

In England* there is a cost (£9250/year), but it's slightly misleading to think of it like that because of how Student Loans work here.

You pay nothing on your Student Loan up to a certain income (£25k, or $33k), 9% past that point, and then the remainder gets forgiven after 25 years. So in practice, it's an additional marginal tax rate for having gone to university.

(* different elsewhere in the UK - e.g. free in Scotland)

Every time I see someone discussing Monads in JavaScript without _mentioning_ Promises, I pause a bit. To my eyes, aside from a bit of type-juggling which makes Haskell programmers break out in cold sweats, Promises and Monads are similar enough.

The main difference is that .bind()/.then() implicitly converts (a -> b) to (a -> M b) - i.e. if the function you pass to .bind()/.then() does not return a Promise/Monad as it should, it's converted. Promise.create() does something similar. This level of type-juggling is not weird for a dynamically-typed language.

So my question is: rather than attempting to define your own Monads that are more type-strict than the language itself, how many of the behaviours in this article can be implemented by extending Promise.prototype instead?

    Promise.prototype.binary = function (right, binaryFn) {
        return this.then(leftVal =>
            Promise.resolve(right).then(rightVal =>
                binaryFn(leftVal, rightVal)
            )
        );
    };

    onePromise.binary(twoPromise, (a, b) => a + b); // Adds two promises together

AFAIU, Tor has its own browser because it includes various privacy and anti-tracking features that can't be implemented as add-ons. Without these, your connection might be anonymised, but your browser can still be tracked between sites and sessions.

They work with the Firefox team to try and push many of these back into FF.

The JSON Schema spec was abandoned by its original authors, and was picked up by a series of other people with varying levels of standards experience (myself included).

Personally, I had some promising support from my then-employer (including an IETF connection), but then it kind of petered out, and I was buried under other stuff and had to pass it on. The team who picked it up since them seem pretty on-the-ball as far as I can see, so I would still recommend it as a useful project to contribute to.

It is supported by some tools - last I heard, Visual Studio could use JSON Schema for autocomplete and validation, as well as a couple of databases. I used to get a few million NPM downloads a month on my validator, so someone's clearly using it.

Unfortunately (as per the article), there is precedent for someone getting a DNR tattoo as a joke after losing a bet in poker.

https://link.springer.com/article/10.1007%2Fs11606-012-2059-...

This implies that people getting tattoos do not treat them as legal documents.

The doctors in this more recent case were justifiably cautious - they did the sensible thing, which is to consult an ethics/legal specialist ASAP, and then follow their advice.

There was a case in 2012 where someone had a DNR tattoo as a joke after losing in poker. It was published in a medical journal:

https://link.springer.com/article/10.1007%2Fs11606-012-2059-...

The doctors in this case were reportedly aware of this previous precedent: http://wapo.st/2AjHdLb