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

[Alexandros Drymonitis]

I understand this, I understand how cubic interpolation works, to some
extent. What I don't understand is in what way is this different to the way
[tabosc4~] deals with tables.
If I want to feed a table with values from a mathematical function, should
I copy the last element to index(0) and the first two elements to
index(length - 2) and index(length - 1), if I'm gonna use [tabread4~]? What
I understand is that this is necessary, whether I use [tabosc4~] or
[tabread4~], right?


On Fri, Sep 6, 2013 at 4:26 PM, Miller Puckette <msp at ucsd.edu> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130906/71376939/attachment.htm>