<br><br><div><span class="gmail_quote">On 11/2/07, <b class="gmail_sendername">Stephen Sinclair</b> <<a href="mailto:radarsat1@gmail.com">radarsat1@gmail.com</a>> wrote:</span><div><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Has anyone noticed this? What measures do you take to fix it?</blockquote><div><br>Hi, Steve!<br><br>It's quite normal for audio-programing languages to have a sample-rate for audio and a rate at which modulation takes place. Modulation in that case is slower then the audio rate in order to save CPU. Setting the two to be the same leads to no zipper noise (but it may still cause aliasing) yet high CPU costs. ChucK is no different, except that in ChucK the "control rate" (as it's called in CSound) can be set depending on the context and be changed at will (and there can be many at the same time as well).
<br><br>So, in order to have no zipper noise at all you will have to set the controll rate to 1::samp, you can use "Envelope" to do the interpolation for you but you'll have to write the values to the actual parameter yourself.
<br></div><br>That's where we are right now, better then many of the other languages and systems (at least more flexible) but not quite perfect.<br><br>There was some talk on the forum about this, for example SuperCollider interpolates such values over the size of it's block. That's relatively easy for SC as SC uses block processing (which is cheap on the cpu) but we don't (expensive but it pays off as soon as you want to use feedback, in that case using blocks means hell, IMHO).
<br><br>I think we could use a solution there, I think everybody does. We could simply wait for CPU's to become so fast we don't notice such tight 1::samp loops anymore, we could have some sort of build-in interpolation or we could support things like
<br><br>SndBuf b => dac;<br>Envelope e => b.rate;<br><br>Or perhaps somebody very clever will come up with something yet better.<br><br><br>I realize I'm not giving you a true solution but hopefully this will explain a little about the problem? In the meantime you can try to get clever, for example when modulating a oscillator's pitch you could make the modulation run at the same rate as the oscillator and try to only set it at times when it crosses the zero, that could save CPU while not zippering.
<br><br>Yours,<br>Kas.<br></div>