2010/11/27 Kassen
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. :¬)
When I was in Japan, after I gave a talk on ruck some Japanese folks in the audience had questions that I had trouble answering in English, Japanese, or pictures on paper. But once I demonstrated the answer with Ruby, everyone understood. :)
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.
Me too! Though I just realized that 35 and 36 points correspond to coefs array sizes of 104 and 107. So I searched ChucK for "100" and found: #define genX_MAX_COEFFS 100 D'oh.
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.
Ohh, I'm definitely going to play with that. Was it logarithmic, or something less regular? Also, while turning the LiSa code into a UGen-like class, I realized that the ADSR in my original e-mail was not being quantized, and once I moved it inside, the sound became much less pleasant. The laser whizzing noises (aliasing?) become much more apparent. Interesting again with only 3 bits, though. -- Tom Lieber http://AllTom.com/ http://favmusic.net/