I'm grateful that Kassen dropped some code for LiSa, because I didn't

understand his description until I was knee deep in CurveTables and
had finally worked through all the problems Kassen's succinct proposal
addresses.

You're welcome, as always. It's also nice to see how a formal language can sometimes be *easier* to understand than a natural one. I think that's a non-trivial point if we want to consider the relative importance of livecoding. :Ź)

While I got the CurveTable working, I can't get real sharp
transitions between the quantization levels because CurveTable crashes
if I give it a coefs array with more than 35 points.

Weird, and what a odd number for it to crash at; I'd expect a power of 2. Just increasing the resolution should help but as you note; LiSa is happy to deal with hundreds of thousands of points. Interestingly, for this niche-application; LiSa, unlike SndBuf, has no option to turn off interpolation. If she did we could stick to far smaller tables and a lower overhead setting them. Not sure that's worth "fix" because this is a bit of a niche application and a "proper" crusher might be a much nicer investment of dev-time.

As a side-note; a big part of the sound of older d-a converters came from deviations in the actual value of the resistors in them compared to their nominal value (to put it bluntly; cheap crap was used). Basically that means the "steps" aren't all the same height. If you really want to emulate that things will get a bit more tricky. It's interesting though, because if we discard quantisation in the time domain the errors of bit-depth crushing should all be harmonic so such errors should give slightly different spectra. I don't think many implementations do this.

Yours,

Kas.