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