[chuck-users] 8-bit?

[Tom Lieber]

2010/11/27 Kassen <signal.automatique at gmail.com>:
> 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/