Hi, Volker!<br><br>I&#39;m not sure if this is your issue here but some theory;<br><br>ChucK uses a &quot;pull through&quot; model to calculate samples. So; every time the DAC wants to output a sample the DAC asks (pulls) all Ugens connected to it to report a value and those in turn ask all their inputs for one before returning it (recursively). This works very well and guarantees a proper calculation order of samples (compare that to MAX which uses a left to right evaluation and PD which calculates modules in the order they are placed, I think).<br>
<br>All is well until we use feedback. If the DAC depends on a delay and that delay in turn depends on itself we would get stuck so there we stop and the sample used there is actually the *last* sample the delay calculated. This last sample is called the &quot;Z-1&quot; (two samples ago would be &quot;Z-2&quot;, etc).<br>
<br>So; all feedback loops get a sample added to their length, which can and will affect tuning. Of course the higher the pitch the larger a samp as a fraction of the pitch will be and so the more detuned it will be. Fortunately this can be compensated for by subtracting a samp from the set delay time.<br>
<br>Again, not sure if this is your issue but I&#39;m a bit short on time at the moment so I didn&#39;t run your code, it looks like it though. At least a little theory can&#39;t hurt. It&#39;s a well known issue in systems like ours, but at least thanks to having dur as a data type have plenty of tools to deal with it and it&#39;s much, much better then the kind of thing you would get if you tried the same in a system using block processing.<br>
<br>Hope that helps,<br><br>Yours,<br>Kas.<br><br><div><span class="gmail_quote">On 29/02/2008, <b class="gmail_sendername">volker böhm</b> &lt;<a href="mailto:vboehm@gmx.ch">vboehm@gmx.ch</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
hi,<br> i was running some simple tests to hear the difference between<br> allpass vs linear interpolating delay lines when i noticed that there<br> is obviously a little bug in how the delay time is calculated in the<br>
 delay UGens from STK.<br> <br> the following example feeds an impulse into a DelayA with high<br> feedback and compares the tuning to a TriOsc.<br> <br> can&#39;t i trust my ears or is the tuning only correct if i add 1 to<br>
 deltime before calculating the frequency for TriOsc?<br> <br> thanks,<br> volker.<br> <br> <br> <br> Impulse imp =&gt; Gain out =&gt; dac;<br> out =&gt; DelayA delay =&gt; out;<br> TriOsc tri =&gt; dac;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// test oscillator<br>
 <br> 44100.0 =&gt; float sr;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// sampling rate<br> <br> // delay time in samples<br> 150.5 =&gt; float deltime;<br> <br> deltime::samp =&gt; delay.delay;<br> <br> // calc tri freq from delay time<br> // have to add 1 to deltime to get correct tuning<br>
 sr / (deltime) =&gt; tri.freq;<br> <br> // set feedback level<br> 0.999 =&gt; delay.gain;<br> 0.3 =&gt; tri.gain;<br> <br> <br> while(true) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 =&gt; imp.next;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6::second =&gt; now;<br> }<br> _______________________________________________<br>
 chuck-users mailing list<br> <a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br> <a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
 </blockquote></div><br>