[chuck-users] Audio Range and Zero-crossings

[joerg piringer]

Veli-Pekka Tätilä wrote:
> 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.
> 

you can always use:
adc a => blackhole;
it routes the adc into nothing but still constructs a chain.

but maybe that's not the problem.

you can try to substitute your until-loop with the following:
until(adc.last() < 0) // Measure low-phase first.
{
    blockSize => now;
    <<< adc.last() >>>;
}	

so it should print out the value of the adc. that could give you a hint...
in my case it was always zero... but that's because of my soundcard 
settings on the laptop.

best
joerg


-- 
http://joerg.piringer.net
http://www.transacoustic-research.com
http://www.iftaf.org
http://www.vegetableorchestra.org/