hi,
After the comments on my previous post saying that metro drift wouldn't be too much of a problem, I ran a test or two, and roughly found this to be true.
I set up three metros, one to bang once every beat, one to bang every 27th of a beat (triplet-based time), and one to bang every 49th of a beat (1/7th-based time). Then I left it running for a while, using timer and realtime to measure drift over each beat. The patch I used is attached.
Over 60 minutes:
Between whole beat and beat counted from 27ths: realtime 0.002ms drift timer 0.144ms drift
Between whole beat and beat counted from 49ths: realtime 0.01ms drift timer 0.149ms drift
Between whole beat counted from 27ths and from 49ths: realtime 0.002ms drift timer 0.007ms drift
Now, I'm not totally sure how to interpret these numbers, and certainly don't understand the huge discrepancies between realtime and timer outputs, but it seems like drift isn't going to be any problem for this amount of time.
As I understand it the human ear starts to hear things as two different events at around 15-20ms time separation, so in theory these drifts should be utterly inaudible.
The question is, will these .1 ms drifts be sensed even if not consciously audible? In the case of a hardware device like the Akai MPC2000, there's a whole mythology that's arisen around the 'perfection' of its swing function, being supposedly sub-ms accurate in a way that no other machine can match...
Hope this information is useful to someone :)
cheers d
Hallo Damian, Damian Stewart hat gesagt: // Damian Stewart wrote:
I set up three metros, one to bang once every beat, one to bang every 27th of a beat (triplet-based time), and one to bang every 49th of a beat (1/7th-based time). Then I left it running for a while, using timer and realtime to measure drift over each beat. The patch I used is attached.
Over 60 minutes:
Between whole beat and beat counted from 27ths: realtime 0.002ms drift timer 0.144ms drift
Between whole beat and beat counted from 49ths: realtime 0.01ms drift timer 0.149ms drift
Between whole beat counted from 27ths and from 49ths: realtime 0.002ms drift timer 0.007ms drift
Now, I'm not totally sure how to interpret these numbers, and certainly don't understand the huge discrepancies between realtime and timer outputs, but it seems like drift isn't going to be any problem for this amount of time.
You have a kind of bug in your patch because at several points the execution order isn't well defined. The [timer] output actually should not drift at all, as the clock used by timer to read the time is the same as the clock used by metro to "set the time", that is, its own period. The interesting number is the realtime measurement. Here also it is important to take care of execution order using [t b b] and such objects. Otherwise it will for example happen, that you get the time of different beat numbers.
I attached a version of your patch that uses a well-defined execution order. The drift measuremeants are initiated by a delayed bang, so it will always measure the drift of the same beat.
With that patch I get no time drift with [timer] as expected. The results for the intervals between beats measured with [realtime] however ocillate regularily up to about 5 msec on my linux system for every metro period. As this happens in a very regular pattern I suppose this is some kind synchronisation problem between the Pd clock and the realtime clock of the operating system used in [realtime]. Check the table "drift" to see the regularity of the pattern.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
This, my friends, is what the list is all about.
Good science guys!
~Kyle
On 4/1/06, Frank Barknecht fbar@footils.org wrote:
Hallo Damian, Damian Stewart hat gesagt: // Damian Stewart wrote:
I set up three metros, one to bang once every beat, one to bang every 27th of a beat (triplet-based time), and one to bang every 49th of a beat (1/7th-based time). Then I left it running for a while, using timer and realtime to measure drift over each beat. The patch I used is attached.
Over 60 minutes:
Between whole beat and beat counted from 27ths: realtime 0.002ms drift timer 0.144ms drift
Between whole beat and beat counted from 49ths: realtime 0.01ms drift timer 0.149ms drift
Between whole beat counted from 27ths and from 49ths: realtime 0.002ms drift timer 0.007ms drift
Now, I'm not totally sure how to interpret these numbers, and certainly don't understand the huge discrepancies between realtime and timer outputs, but it seems like drift isn't going to be any problem for this amount of time.
You have a kind of bug in your patch because at several points the execution order isn't well defined. The [timer] output actually should not drift at all, as the clock used by timer to read the time is the same as the clock used by metro to "set the time", that is, its own period. The interesting number is the realtime measurement. Here also it is important to take care of execution order using [t b b] and such objects. Otherwise it will for example happen, that you get the time of different beat numbers.
I attached a version of your patch that uses a well-defined execution order. The drift measuremeants are initiated by a delayed bang, so it will always measure the drift of the same beat.
With that patch I get no time drift with [timer] as expected. The results for the intervals between beats measured with [realtime] however ocillate regularily up to about 5 msec on my linux system for every metro period. As this happens in a very regular pattern I suppose this is some kind synchronisation problem between the Pd clock and the realtime clock of the operating system used in [realtime]. Check the table "drift" to see the regularity of the pattern.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- http://perhapsidid.blogspot.com (((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
-
Damian Stewart -
Frank Barknecht -
Kyle Klipowicz