[chuck-users] Audio Range and Zero-crossings

[Veli-Pekka Tätilä]

Hi,
And thanks for an extremely quick reply. I'll snip myself here.

joerg piringer wrote:
> Veli-Pekka Tätilä wrote:
>>  chuck version: 1.2.0.7b (dracula)
>>    exe target: microsoft win32
>> 1. What's the range of the audio float datatype and what would be
>> the best way to detect zero crossings? My aim is to write a simple
>> app that counts the samples in the low and high phases of a pulse
>> wave and prints out the pulse width whenever it changes. If I can
>> also get MIDi input into the app it would be quite easy to determine
>> how pulse width in percentages changes as the function of the pulse
>> width knob in my virtual and real analogs, whose exact values are
>> not documented.
>>
>> Here's some prototypical code (this is my first real chucK script):
>>
>> Code:
>> 100::ms => dur blockSize; // Processing resolution.
>> until(adc.last() < 0) // Measure low-phase first.
>>    blockSize => now;
>> // SAmple counters:
>> 0 => int positive;
>> 0 => int negative;
>> while(true)
>> {
>>    adc.last() => float sample;
>>    if(sample > 0)
>>       ++positive;
>>    else if(sample < 0)
>>    {
>>       ++negative;
>>       if(positive > 0) // Measured at least one cycle.
>>          <<< "Width: ", 100 * negative / (negative + positive) >>>;
>>       0 => positive => negative; // Reset counters.
>>    } // else if
>>    // Ignore the pure 0 value.
>>    blockSize => now;
>> } // while
>> End code.
>>
>> However, when I run this, the app doesn't ever seem to get past the
>> until loop. I'm assuming here that samples are floats or doubles
>> from -1 to 1 as in VST, as I didn't find the range in the manual. Is
>> this correct? IF not, it's no wonder the code won't work, <smile>.
>> Of course the rather grainy test processing rate, ten times a sec,
>> affects matters greatly but I don't ever seem to get negative sample
>> values even in arbitrary audio. The adc and dac modules do work. IF
>> I patch them together and record from the wave input I get a delayed
>> copy of the input in the output I guess this is the audio equivalent
>> of "cat".
> i didn't look too closely to your code but what you seem to have no
> statement like:
> adc a => blackhole;
> or
> adc a => dac d;
> at the beginning. so in fact adc isn't working at all because it's not
> in the ugen chain.
Ah I see, only chains leading to DAC are processed to save CPU cycles. 
Somewhat counter-intuitive initially, in this case. I wish one could have 
the ability to print out warnings about diagnostics related to disabledd 
modules. Most GUi-enabled modular environments show it in some way.

Seems my query is still valid, though. I added:
adc => dac;
At the top of the script and now I get an echo effect because there's plenty 
of latency between the input and output. It still doesn't get past the until 
loop, probably some other common newbie goof.

-- 
With kind regards Veli-Pekka Tätilä (vtatila at mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/