<div dir="ltr">Ok, but why don&#39;t you need the guard points at the end of the array when you&#39;re using [tabread4~], and only the first guard point? In the audio examples of Pd&#39;s browser, the patch B04.tabread4.interpolation.pd demonstrates the use of the object where it reads an array of 11 elements, from index 1 up to (and including) index 8. Why is there an index 9 and 10 if those values are not needed? What&#39;s the difference between [tabosc4~]&#39;s interpolation and [tabread4~]&#39;s interpolation?<br>
<div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Miller Puckette</b> <span dir="ltr">&lt;<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>&gt;</span><br>Date: Thu, Sep 5, 2013 at 4:35 PM<br>
Subject: Re: [PD] Sinesum, cosinesum and cubic interpolation&#39;s guard points<br>To: Alexandros Drymonitis &lt;<a href="mailto:adrcki@gmail.com">adrcki@gmail.com</a>&gt;<br><br><br>It&#39;s only necessary if you want to smoothly wrap around from the &quot;last&quot;<br>

index to 0 (as you do in most uses of tabosc~, but not, for example, if<br>
you&#39;re using tabread4~ as a sampler.)<br>
<br>
I should fix Pd to uniformly use PI from math.h - &quot;3.14159&quot; was a bit<br>
slapdash in retrospect :)<br>
<br>
cheers<br>
<span class="HOEnZb"><font color="#888888">Miller<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Sep 05, 2013 at 04:26:20PM +0300, Alexandros Drymonitis wrote:<br>
&gt; OK, that&#39;s clear, thanks. Still when using [tabread4~] or [tabosc4~] you<br>
&gt; still need a copy of the last element in the first index and copies of the<br>
&gt; first two elements in the last two indices, right? Even if you&#39;re not using<br>
&gt; sinesum or cosinesum but some other mathematical function..<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Sep 5, 2013 at 1:56 PM, IOhannes m zmoelnig &lt;<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt; &gt; Hash: SHA1<br>
&gt; &gt;<br>
&gt; &gt; On 2013-09-05 09:45, Alexandros Drymonitis wrote:<br>
&gt; &gt; &gt; OK, index 0 is the negative of index 2,<br>
&gt; &gt;<br>
&gt; &gt; no not really, they just happen to be the same.<br>
&gt; &gt;<br>
&gt; &gt; &gt; which can again make sense as it&#39;s a sine (supposing that index 0<br>
&gt; &gt; &gt; is a copy of the table&#39;s last element), but index 512 doesn&#39;t have<br>
&gt; &gt; &gt; that value, why? And why do indices 1 and 513 have different values<br>
&gt; &gt; &gt; too?<br>
&gt; &gt;<br>
&gt; &gt; do they?<br>
&gt; &gt;<br>
&gt; &gt; when it comes to floating point, &quot;equality&quot; becomes a little bit fuzzy.<br>
&gt; &gt; e.g. &quot;0.1&quot; is really the &#39;same&#39; as &quot;0.100000001490116119384765625&quot; [1].<br>
&gt; &gt;<br>
&gt; &gt; comparing the values, you can see that they are not *very* wrong:<br>
&gt; &gt;<br>
&gt; &gt; array[512]-array[0] = -5.30668e-6 = -0.0000053<br>
&gt; &gt; array[513]-array[1] = -5.30718e-6 = -0.0000053<br>
&gt; &gt; array[514]-array[2] = -5.30668e-6 = -0.0000053<br>
&gt; &gt;<br>
&gt; &gt; so the errors are really rather small, and hopefully don&#39;t matter so<br>
&gt; &gt; much in the interpolation (which is another approximation anyhow).<br>
&gt; &gt;<br>
&gt; &gt; the reason why the error is not smaller, is that Pd internally<br>
&gt; &gt; (src/g_array.c:896) deals with a PI value of 3.14159, which is a<br>
&gt; &gt; rather rough estimate and is the reason why the cycle is not exactly<br>
&gt; &gt; 512 points long.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; fgamsdr<br>
&gt; &gt; IOhannes<br>
&gt; &gt;<br>
&gt; &gt; [1]<br>
&gt; &gt;<br>
&gt; &gt; <a href="http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conversion_and_rounding" target="_blank">http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conversion_and_rounding</a><br>

&gt; &gt; -----BEGIN PGP SIGNATURE-----<br>
&gt; &gt; Version: GnuPG v1.4.14 (GNU/Linux)<br>
&gt; &gt; Comment: Using GnuPG with Icedove - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
&gt; &gt;<br>
&gt; &gt; iEYEARECAAYFAlIoY3UACgkQkX2Xpv6ydvTY1wCcDCyH8kY50snbVOv5AxwspIAB<br>
&gt; &gt; jwQAoLJOrVoESvzyqrZyvWKky0ec1eUT<br>
&gt; &gt; =YqkS<br>
&gt; &gt; -----END PGP SIGNATURE-----<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; <a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
&gt; &gt; UNSUBSCRIBE and account-management -&gt;<br>
&gt; &gt; <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
&gt; &gt;<br>
<br>
&gt; _______________________________________________<br>
&gt; <a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
&gt; UNSUBSCRIBE and account-management -&gt; <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br>
</div></div></div><br></div></div>