When you send this message [sinesum 512 1( to a table Pd will automatically add one index to the beginning of the table and two indices to its end, and you end up with a table of 515 indices. The three additional indices are the guard points for the cubic interpolation, right? So the first index should be a copy of the last element (here, index 0 a copy of index 512), and the last two indices should be copies of the first two elements (here, indices 513 and 514 copies of indices 1 and 2 respectively). Am I getting it right up to here? Well, with the message [cosinesum 512 0 1( this is indeed true; these are the values I get: index 512 = 0.999925 index 0 = 0.999925 index 1 = 1 index 513 = 1 index 2 = 0.999925 index 514 = 0.999925
Well, the second and the last elements have the same value anyway (index 2 and 512), which makes sense as it's a cosine. But if I send [sinesum 512 1( I'm getting these results: index 512 = -0.0122768 index 0 = -0.0122715 index 1 = 0 index 513 = -5.30718e-06 index 2 = 0.0122715 index 514 = 0.0122662
OK, index 0 is the negative of index 2, 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?
-----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...
Hello,
ist there any way to read the tempo information contained in a midi file? Or do I really have to set up a metro for mrpeach/midifile everytime ?
Thanks for any advice,
Maciej
On 2013-09-05 07:04, Maciej Sledziecki wrote:
Hello,
ist there any way to read the tempo information contained in a midi file? Or do I really have to set up a metro for mrpeach/midifile everytime ?
It's been a while since I worked on that but I think you can dump the info and use that to set up a metro. I could probably add a message to get it to play automatically.
Martin
On 2013-09-05 09:29, Martin Peach wrote:
On 2013-09-05 07:04, Maciej Sledziecki wrote:
Hello,
ist there any way to read the tempo information contained in a midi file? Or do I really have to set up a metro for mrpeach/midifile everytime ?
It's been a while since I worked on that but I think you can dump the info and use that to set up a metro. I could probably add a message to get it to play automatically.
If you bang the [midifile] after opening the file, the right outlet will emit ticks_per_quarternote and microsec_per_quarternote messages.
So the millisecond rate for the [metro] would be = (microsec_per_quarternote/ticks_per_quarternote)/1000
See attached patch.
Martin
That works great ! Even tempo changes within the file are updated. Thank you very much. Maciej
Am 05.09.2013 um 18:36 schrieb Martin Peach:
On 2013-09-05 09:29, Martin Peach wrote:
On 2013-09-05 07:04, Maciej Sledziecki wrote:
Hello,
ist there any way to read the tempo information contained in a midi file? Or do I really have to set up a metro for mrpeach/midifile everytime ?
It's been a while since I worked on that but I think you can dump the info and use that to set up a metro. I could probably add a message to get it to play automatically.
If you bang the [midifile] after opening the file, the right outlet will emit ticks_per_quarternote and microsec_per_quarternote messages.
So the millisecond rate for the [metro] would be = (microsec_per_quarternote/ticks_per_quarternote)/1000
See attached patch.
Martin <midifile_tempo.pd>
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
-
Alexandros Drymonitis -
IOhannes m zmoelnig -
Maciej Sledziecki -
Martin Peach