[chuck-users] Audio Range and Zero-crossings

[Veli-Pekka Tätilä]

Spencer Salazar wrote:
> On Mar 4, 2007, at 8:55 AM, Veli-Pekka Tätilä wrote:
>> Ah I see, only chains leading to DAC are processed to save CPU
>> cycles. Somewhat counter-intuitive initially, in this case. <snip>
>> 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.
> I believe this a current bug with adc (definitely not a newbie
> goof).  My solution is something like this, although there may be
> better ways:
>
> adc => Gain g => blackhole;
>
> until( g.last() < 0 )
>     blockSize => now;
>
> Let us know if that doesnt work!
Ah it does, thanks for the correction. I think stuff like this should end up 
in the manual, as reading from the ADC is a common needd anyway.

WEll, here's an improved version which seems to measure PWM OK:

adc => Gain g => blackhole;
1::samp => dur blockSize; // Processing resolution.
until(g.last() < 0) // Measure low-phase first.
   blockSize => now;
0 => int negative => int positive;
50.0 => float width => float lastWidth;
while(true)
{
   g.last() => float sample;
   if(sample >= 0)
      ++positive;
   else
   {
      if(positive > 0)
      { // Measured at least one cycle.
         100 * negative / (negative + positive) => width;
         if(width != lastWidth)
         { // Only print new widths.
            <<< width, " %", negative, positive  >>>;
            width => lastWidth;
         } // if
         0 => positive => negative;
      } // if
      ++negative; // Also the 1st sample of the next cycle.
   } // else
   blockSize => now;
} // while

I've also solved the mystery of the machine locking up when I run in a tight 
loop of 1::samp. WHen the script gets noise as input, as it does if I don't 
play anything, it tries to detect the noise pulse width too which may print 
out new values on almost every sample. That means thousands of print calls a 
sec. WIthout the Screen reader the machine doesn't really hault. But with 
it, the poor app tries to magnify and speak each and every print, though 
there's a bit of optimization, and thus leaves very little CPU time to other 
processes including chucK. Quite logical, actually.

Is there a noies gate module? I should patch such a thing after the ADC to 
avoid the above situation. THere's also probably some minor logic error or 
else the waveforms I get in my synths don't cleanly match the sampling rate. 
That is I'm testing the script with the pulse waves from my Roland JP-8080 
and Waldorf Pulse. In both cases, I get minor fluctuations in the output 
that happened pretty often. That is Sometimes the amount of negative or 
positive samples varies by one, even though I play one long static note and 
don't touch the width at all. Changing the pitch doesn't seem to eliminate 
the problem either, though of course the sample counts are different. I 
wonder what's wrong. Probably some classic off-by-one bug I've missed.

Could the above code be re-written using the ZeroX module? I still am a bit 
unsure as to how it works exactly.

-- 
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/