[PD] Fwd: Sinesum, cosinesum and cubic interpolation's guard points
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 m...@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 adr...@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 zmoel...@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.10001490116119384765625 [1]. comparing the values, you can see that they are not *very* wrong: array[512]-array[0] = -5.30668e-6 = -0.053 array[513]-array[1] = -5.30718e-6 = -0.053 array[514]-array[2] = -5.30668e-6 = -0.053 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@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 - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Sinesum, cosinesum and cubic interpolation's guard points
The read points actually rangee from 1 to 9 (or 8.9 - 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 m...@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 adr...@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 zmoel...@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.10001490116119384765625 [1]. comparing the values, you can see that they are not *very* wrong: array[512]-array[0] = -5.30668e-6 = -0.053 array[513]-array[1] = -5.30718e-6 = -0.053 array[514]-array[2] = -5.30668e-6 = -0.053 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@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 - http://lists.puredata.info/listinfo/pd-list ___ 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 - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Sinesum, cosinesum and cubic interpolation's guard points
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 m...@ucsd.edu wrote: The read points actually rangee from 1 to 9 (or 8.9 - 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 m...@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 adr...@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 zmoel...@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.10001490116119384765625 [1]. comparing the values, you can see that they are not *very* wrong: array[512]-array[0] = -5.30668e-6 = -0.053 array[513]-array[1] = -5.30718e-6 = -0.053 array[514]-array[2] = -5.30668e-6 = -0.053 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@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 - http://lists.puredata.info/listinfo/pd-list ___ 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 - http://lists.puredata.info/listinfo/pd-list
