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@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@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@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_convers...
-----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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
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@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@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@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_convers...
-----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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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@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@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_convers...
-----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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
-
Alexandros Drymonitis -
Miller Puckette