Hi Kassen, this sounds interesting, but I can't follow your steps. Have you got an example of this idea? Thanks a lot! El 18.11.2010, a las 20:00, Kassen escribió:

On 18 November 2010 19:44, Andrew Turley wrote: You could build a generator using Gen7 or CurveTable. That might be a little more efficient, but maybe not worthwhile.

How about a Lisa set to sync? If you feed that with a arbitrary signal at gain .5 mixed with a step set to a value of .5, (which would turn a signal from range -1 to 1 into one from 0 to 1) you can set any mapping you'd like. Filling that LiSa with a line from -1 to 1 would get you your original signal back, a "staircase" would give bit-depth reduction, etc.

Multiple mappings could be made and by changing the loop start and end these could be selected.

Shreds might be more versatile as those also give you easy access to modulating bit rate in addition to depth and to get a resolution equal to double floats you'd have to use a very large buffer indeed... but then shreds are often expensive and the code gets messy looking, IMHO.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Kas you are gorgeous!! Thanks so much for this example and the clear explication. Lars El 19.11.2010, a las 06:27, Kassen escribió:

Hey Lars!

this sounds interesting, but I can't follow your steps. Have you got an example of this idea?

Here we go;

-----------8<-----------------------------

LiSa l => dac;

//more time here means more resolution //here more time actually prevents LiSa's interpolation from cleaning our intended dirt second => l.duration;

//only calculating constants once (l.duration()/ samp) $ int => int NUM_SAMPS; 2.0 / NUM_SAMPS => float STEP_SIZE;

//straight ramp from -1 to 1 for (int x; x< NUM_SAMPS; x++) { l.valueAt ( -1 + (x * STEP_SIZE) , x::samp); }

//get signal's range between 0 and 1. //slightly less, actually, to avoid edge-case glitches SinOsc signal => Gain mix => l; .49 => signal.gain; Step offset => mix; .5 => offset.next;

//use the LiSa to map the signal to new values 1 => l.sync;

//off we go. you should hear a pure sine here 1 => l.play;

5::second => now;

//now we start crushing. 6 => int bits;

//the "-1" is for above and minus zero //again we use a constant to minimise per-value processing Math.pow ( bits - 1, 2) => float QUANT;

//cheap&dirty quantisation //we take the original value, multiply it by the number of steps in our chosen bit-depth //then round this by casting to int //finally dividing it again to get back in the original range //and putting the value back for (int x; x< NUM_SAMPS; x++) { l.valueAt ((l.valueAt(x::samp) * QUANT) $ int / QUANT , x::samp); }

//and there we go again 5::second => now;

---------------------------------------8<--------------------------------

I hacked this up quite quickly, there are bound to be some issues in the details, especially in the rounding. At the very least this should illustrate the technique of using LiSa as a waveshaper for arbitrary shapes. Note that "signal" is a placeholder for any signal you'd like to process, but it must not (initially) exceed the range of -1 to 1 (normal UGens conform to this, as should the ADC) or the result will wrap (that too might sound cool...). Of course using a oscillator here makes no sense; if a plain oscillator would do you are better off using a wavetable set to some suitably lo-fi single cycle wave instead of actual bitcrushing.

Another likely issue here is that LiSa is trying to prevent the exact kind of artefact we are trying to create by using interpolation. I'm fairly sure the effect of that can be minimised by extending the size of the buffer and hence it's resolution. This might be a interesting element to play with.

Hope this is at least a decent starting point for further experimentation. No warranties, no refunds, please mind your neighbours, pets and speakers.

Have a noisy weekend! Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Very cool, This is why I wish ChucK either had an Array UGen or if normal ChucK arrays could be treated like UGens somehow. Coming from other languages (Pd, Csound for example) one becomes very used to arrays (or ftables) being part of the signal chain. Using LiSa as a workaround is pretty rad. The ChucK wish-list keeps growing. Later, Kurt 2010/11/19 Kassen :

Hey Lars!

...

this sounds interesting, but I can't follow your steps. Have you got an example of this idea?

Here we go; -----------8<----------------------------- LiSa l => dac; //more time here means more resolution //here more time actually prevents LiSa's interpolation from cleaning our intended dirt second => l.duration; //only calculating constants once (l.duration()/ samp) $ int => int NUM_SAMPS; 2.0 / NUM_SAMPS => float STEP_SIZE; //straight ramp from -1 to 1 for (int x; x< NUM_SAMPS; x++)     {     l.valueAt ( -1 + (x * STEP_SIZE) , x::samp);     }

//get signal's range between 0 and 1. //slightly less, actually, to avoid edge-case glitches SinOsc signal => Gain mix => l; .49 => signal.gain; Step offset => mix; .5 => offset.next; //use the LiSa to map the signal to new values 1 => l.sync; //off we go. you should hear a pure sine here 1 => l.play; 5::second => now; //now we start crushing. 6 => int bits; //the "-1" is for above and minus zero //again we use a constant to minimise per-value processing Math.pow ( bits - 1, 2) => float QUANT; //cheap&dirty quantisation //we take the original value, multiply it by the number of steps in our chosen bit-depth //then round this by casting to int //finally dividing it again to get back in the original range //and putting the value back for (int x; x< NUM_SAMPS; x++)     {     l.valueAt ((l.valueAt(x::samp) * QUANT) $ int / QUANT , x::samp);     }

//and there we go again 5::second => now; ---------------------------------------8<-------------------------------- I hacked this up quite quickly, there are bound to be some issues in the details, especially in the rounding. At the very least this should illustrate the technique of using LiSa as a waveshaper for arbitrary shapes. Note that "signal" is a placeholder for any signal you'd like to process, but it must not (initially) exceed the range of -1 to 1 (normal UGens conform to this, as should the ADC) or the result will wrap (that too might sound cool...). Of course using a oscillator here makes no sense; if a plain oscillator would do you are better off using a wavetable set to some suitably lo-fi single cycle wave instead of actual bitcrushing. Another likely issue here is that LiSa is trying to prevent the exact kind of artefact we are trying to create by using interpolation. I'm fairly sure the effect of that can be minimised by extending the size of the buffer and hence it's resolution. This might be a interesting element to play with. Hope this is at least a decent starting point for further experimentation. No warranties, no refunds, please mind your neighbours, pets and speakers. Have a noisy weekend! Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- -------------------------------------------------- www.kurtkotheimer.com --------------------------------------------------

On Thu, Nov 18, 2010 at 10:44 AM, Andrew Turley wrote:

You could build a generator using Gen7 or CurveTable. That might be a little more efficient, but maybe not worthwhile.

2010/11/18 Kassen :

How about a Lisa set to sync? If you feed that with a arbitrary signal at gain .5 mixed with a step set to a value of .5, (which would turn a signal from range -1 to 1 into one from 0 to 1) you can set any mapping you'd like. Filling that LiSa with a line from -1 to 1 would get you your original signal back, a "staircase" would give bit-depth reduction, etc. Multiple mappings could be made and by changing the loop start and end these could be selected.

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. 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. So I think I'll be using LiSa because it doesn't crash with longer buffers to get around the linear interpolation. Thanks everybody, especially Kassen and Andrew. (here's the CurveTable code: SinOsc s; CurveTable c; Step dc; s => c => dac; dc => c; .49 => s.gain; .5 => dc.next; 35 => int res; // # of CurveTable points 4 => int levels; // # of quantization levels (/ 2) // build CurveTable coefs levels => float flevels; float coefs[res * 3 + 2]; for( 0 => int r; r < res; r++ ) { ((r $ float) / res) * 2 - 1 => float f; // [0, res) -> [-1, 1) // the triplet r => coefs[r * 3]; // time ((f * levels) $ int) / flevels => coefs[r * 3 + 1]; // value 0 => coefs[r * 3 + 2]; // curvature (linear) } res => coefs[res * 3]; // time 1 => coefs[res * 3 + 1]; // value coefs => c.coefs; day => now; ) -- Tom Lieber http://AllTom.com/ http://favmusic.net/

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/

Hey, Tom. 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. :)

Victory!

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.

Ok... does that make any sense at all, as a limit? Wouldn't ChucK memory be divided in some sort of blocks?

Ohh, I'm definitely going to play with that. Was it logarithmic, or something less regular?

Well, say that we are using n bits to describe a range from 0V to 1V. First we'll consider bit 0. Assume this one is the most significant one. If it's high it should contribute .5V to the total. However, the resistors used would be cheap and may have as much as a 10% error (medical and military grade ones with smaller margins would be lots more expensive, if available). Because of this and depending on the exact properties of the device in our hands we'd get something like .47V instead. Let's consider bit 1 and say it's high too. This should contribute .25V. In practice it might instead add .26 . At this point the total value should be .750000 but instead it will be (.47 + .26 =) .73 . Repeat for all bits. I think you can assume the error per resistor to stay constant over the use of the "dac", for pieces of a realistic length. I also think that a 10% margin of error is about realistic, maybe we have members who used to solder back in the mid 80's who will know more. Oh, and of course these used plain analogue LPF's, not some sort of phase-linear FIR filter over a over-sampled version of the signal like modern soundcards. For the ultimate in realism of emulating old digital stuff note that often compander (compressor / expander) chips were used to suppress noise. Those might well be a bigger factor in the "punch" instruments like the MPC brought to genres like HipHop than the low bit-depth and rate on their own. There is a whole world of fascinating phenomena there.

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.

Yes, that makes a difference. I do think that real historical gear would sometimes put the envelope last (where this is viable, of course, it would be in the S612, not so in the gameboy) to suppress noise. This is why all non-modular analogue synths have the ADSR after the filter, even if the filter wouldn't ever self-oscillate. In anything hybrid I'd predict the envelope would be last. In purely digital stuff the envelope would be before the converter and it's trigger quantised to the bitrate. That last bit is a bit obvious when you think about it, but it matters in how static the final result will be perceived to be if we repeat the same drum a few times. To conclude; it's not entirely unlikely that we'll have grey beards (where appropriate) before we'll be able to perfectly emulate the sounds of our youths¹. ;¬) Kas. ¹Some might simply have greyer beards, but they may have to deal with tape and tube-amp emulation so it evens out.