[PD] Fwd: Sinesum, cosinesum and cubic interpolation's guard points

[Alexandros Drymonitis]

Ok, but why don't you need the guard points at the end of the array when
you're using [tabread4~], and only the first guard point? In the audio
examples of Pd'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's the difference between [tabosc4~]'s
interpolation and [tabread4~]'s interpolation?

---------- Forwarded message ----------
From: Miller Puckette <msp at ucsd.edu>
Date: Thu, Sep 5, 2013 at 4:35 PM
Subject: Re: [PD] Sinesum, cosinesum and cubic interpolation's guard points
To: Alexandros Drymonitis <adrcki at gmail.com>


It's only necessary if you want to smoothly wrap around from the "last"
index to 0 (as you do in most uses of tabosc~, but not, for example, if
you're using tabread4~ as a sampler.)

I should fix Pd to uniformly use PI from math.h - "3.14159" was a bit
slapdash in retrospect :)

cheers
Miller

On Thu, Sep 05, 2013 at 04:26:20PM +0300, Alexandros Drymonitis wrote:
> OK, that's clear, thanks. Still when using [tabread4~] or [tabosc4~] you
> still need a copy of the last element in the first index and copies of the
> first two elements in the last two indices, right? Even if you're not
using
> sinesum or cosinesum but some other mathematical function..
>
>
> On Thu, Sep 5, 2013 at 1:56 PM, IOhannes m zmoelnig <zmoelnig at iem.at>
wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 2013-09-05 09:45, Alexandros Drymonitis wrote:
> > > OK, index 0 is the negative of index 2,
> >
> > no not really, they just happen to be the same.
> >
> > > which can again make sense as it's a sine (supposing that index 0
> > > is a copy of the table's last element), but index 512 doesn't have
> > > that value, why? And why do indices 1 and 513 have different values
> > > too?
> >
> > do they?
> >
> > when it comes to floating point, "equality" becomes a little bit fuzzy.
> > e.g. "0.1" is really the 'same' as "0.100000001490116119384765625" [1].
> >
> > comparing the values, you can see that they are not *very* wrong:
> >
> > array[512]-array[0] = -5.30668e-6 = -0.0000053
> > array[513]-array[1] = -5.30718e-6 = -0.0000053
> > array[514]-array[2] = -5.30668e-6 = -0.0000053
> >
> > so the errors are really rather small, and hopefully don't matter so
> > much in the interpolation (which is another approximation anyhow).
> >
> > the reason why the error is not smaller, is that Pd internally
> > (src/g_array.c:896) deals with a PI value of 3.14159, which is a
> > rather rough estimate and is the reason why the cycle is not exactly
> > 512 points long.
> >
> >
> > fgamsdr
> > IOhannes
> >
> > [1]
> >
> >
http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conversion_and_rounding
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.14 (GNU/Linux)
> > Comment: Using GnuPG with Icedove - http://www.enigmail.net/
> >
> > iEYEARECAAYFAlIoY3UACgkQkX2Xpv6ydvTY1wCcDCyH8kY50snbVOv5AxwspIAB
> > jwQAoLJOrVoESvzyqrZyvWKky0ec1eUT
> > =YqkS
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >

> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130906/9385c7e3/attachment.htm>