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@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/