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

[Miller Puckette]

The read points actually rangee from 1 to 9 (or 8.99999 - something) - and if,
for nstance, you want to read teh value at 8.5, you need the points
7, 8, 9, and 10.  So teh sze is 11 (indices 0-10 nclusve).

It's confusing, I know....

cheers
Miller

On Fri, Sep 06, 2013 at 01:53:54PM +0300, Alexandros Drymonitis wrote:
> 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

> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list