[chuck-users] Audio Range and Zero-crossings
joerg at piringer.net
Sun Mar 4 09:15:20 EST 2007
Veli-Pekka Tätilä wrote:
> And thanks for an extremely quick reply. I'll snip myself here.
> joerg piringer wrote:
>> Veli-Pekka Tätilä wrote:
>>> chuck version: 22.214.171.124b (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):
>>> 100::ms => dur blockSize; // Processing resolution.
>>> until(adc.last() < 0) // Measure low-phase first.
>>> blockSize => now;
>>> // SAmple counters:
>>> 0 => int positive;
>>> 0 => int negative;
>>> adc.last() => float sample;
>>> if(sample > 0)
>>> else if(sample < 0)
>>> 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;
>> 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.
More information about the chuck-users