Hi, I'm wondering about what's the maximum control rate that Pd can work for managing control data.
I guess this may differ for different objects, but thre may be a general rule I guess.
By the way, I see metro doesn't seem to bang in times that are less than 1 ms, right?
curiously, [line] seems to be able to run at no limits, exceeding audio rate, if that's possible.
thanks
hello,
Le 12/03/2015 06:37, Alexandre Torres Porres a écrit :
Hi, I'm wondering about what's the maximum control rate that Pd can work for managing control data.
control data are computed between every audio block. using the default audio block size (64 sample), at 48KHz, a audio block represent 1.27ms but you can reduce audio block size and increase audio frequency to get faster data rate.
I guess this may differ for different objects, but thre may be a general rule I guess.
By the way, I see metro doesn't seem to bang in times that are less than 1 ms, right?
it did work with higher frequency, but there is a bit of jitter in the data frequency.
here is the time (computed with the [realtime] object) between bangs generated by a metro 0.5 using a 256 sample block size at 48KH (5.33ms between audio block) print: 5.137 print: 0.001 print: 0.001 print: 0.079 print: 0 print: 0.04 print: 0 print: 0 print: 0.038 print: 0.001 print: 0 print: 5.132 print: 0.001 print: 0.079 print: 0.001 print: 0 print: 0.046 print: 0 print: 0.001 print: 0.035 print: 0
about 10 bangs are generated between 2 audio block.
curiously, [line] seems to be able to run at no limits, exceeding audio rate, if that's possible.
same as metro.
cheers c
thanks
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2015-03-12 at 02:37 -0300, Alexandre Torres Porres wrote:
Hi, I'm wondering about what's the maximum control rate that Pd can work for managing control data.
The smallest time interval in Pd is probably 0 (samples, milliseconds, whatever). The smallest non-zero time interval is probably the smallest number that can be represented by Pd's number type, which is usually a single-precision (32-bit) floating point number. The smallest number that (my) Pd is able to print is 1.4013e-45. And since most time-related object classes in Pd use milliseconds as unit, I'd argue the smallest non-zero time interval representable by Pd is 1.4013e-45 ms.
Roman
On Thu, 2015-03-12 at 02:37 -0300, Alexandre Torres Porres wrote:
By the way, I see metro doesn't seem to bang in times that are less than 1 ms, right?
That is an artificial lower limit that saves Pd users from locking up their Pd by accidentally running a metro with an interval of 0 (There is no way out of a [metro] trying to send ∞ bangs in zero logical time.
It's easy enough to cook your own replacement metro based on [delay] that allows for lower numbers, if you need it.
Roman
hello
this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period)
cheers c
Le 12/03/2015 08:51, Roman Haefeli a écrit :
On Thu, 2015-03-12 at 02:37 -0300, Alexandre Torres Porres wrote:
By the way, I see metro doesn't seem to bang in times that are less than 1 ms, right?
That is an artificial lower limit that saves Pd users from locking up their Pd by accidentally running a metro with an interval of 0 (There is no way out of a [metro] trying to send ∞ bangs in zero logical time.
It's easy enough to cook your own replacement metro based on [delay] that allows for lower numbers, if you need it.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote:
hello
this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
Roman
hello,
Le 12/03/2015 10:12, Roman Haefeli a écrit :
On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote:
hello
this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
sorry, i was not aware of this old limitation.
I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question.
cheers c
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
ok, so the metro at 1ms is because I'm using extended.
as for the minimum time pd can process and send data, what's the final word on it?
something like 1.4013e-45 ms?
cause that's a lot more than an audio rate at 44.1khz :)
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here on the thread.
thanks
2015-03-12 10:04 GMT-03:00 Cyrille Henry ch@chnry.net:
hello,
Le 12/03/2015 10:12, Roman Haefeli a écrit :
On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote:
hello
this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
sorry, i was not aware of this old limitation.
I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question.
cheers c
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
hello,
i don't understand your patch.
using [timer], a delay 0 will give a 0 delay... logical time will always be consistent.
cheers c
Le 12/03/2015 15:41, Alexandre Torres Porres a écrit :
ok, so the metro at 1ms is because I'm using extended.
as for the minimum time pd can process and send data, what's the final word on it?
something like 1.4013e-45 ms?
cause that's a lot more than an audio rate at 44.1khz :)
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here on the thread.
thanks
2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net mailto:ch@chnry.net>:
hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period) You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms. sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters. yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question. cheers c Roman _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"
*i don't understand your patch.using [timer], a delay 0 will give a 0 delay...logical time will always be consistent.*"
well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this...
So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this.
thanks
2015-03-12 11:55 GMT-03:00 Cyrille Henry ch@chnry.net:
hello,
i don't understand your patch.
using [timer], a delay 0 will give a 0 delay... logical time will always be consistent.
cheers c
Le 12/03/2015 15:41, Alexandre Torres Porres a écrit :
ok, so the metro at 1ms is because I'm using extended.
as for the minimum time pd can process and send data, what's the final word on it?
something like 1.4013e-45 ms?
cause that's a lot more than an audio rate at 44.1khz :)
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here on the thread.
thanks
2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net mailto: ch@chnry.net>:
hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay based metroand a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?) have anupdated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not [timer] toillustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to whathappens. it's just the way i understand the original question.
cheers c Roman _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :
"/i don't understand your patch.
using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./"
well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this...
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
what i don't understand is your intention with the spigot in the patch.
cheers c
So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this.
thanks
2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net mailto:ch@chnry.net>:
hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's the final word on it? something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below the audio rate, but curiously it can go over. 1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer] check my patch attached, based on the one that was sent here on the thread. thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>: hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period) You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms. sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters. yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question. cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
I know they are different, and I don't really know what I want either :)
I just wanted to measure how long it takes between each control message.
you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working.
what i don't understand is your intention with the spigot in the patch.
just wanted to have a way to close the message stream, but you can forget about it
cheers
2015-03-12 14:14 GMT-03:00 Cyrille Henry ch@chnry.net:
Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :
"/i don't understand your patch.
using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./"
well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this...
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
what i don't understand is your intention with the spigot in the patch.
cheers c
So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this.
thanks
2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net mailto: ch@chnry.net>:
hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's thefinal word on it?
something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below the audiorate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to sendbangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here onthe thread.
thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net mailto:ch@chnry.net>>:
hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay basedmetro and a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?) havean updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not[timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is morerelated to what happens. it's just the way i understand the original question.
cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list < http://lists.puredata.info/__listinfo/pd-list%3E < http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E%3E
___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list < http://lists.puredata.info/__listinfo/pd-list%3E < http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E%3E
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock:
double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif }
The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do.
The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to /do/ control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch.
The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way.
If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars
-David
On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
I know they are different, and I don't really know what I want either :)
I just wanted to measure how long it takes between each control message.
you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working.
what i don't understand is your intention with the spigot in the patch.
just wanted to have a way to close the message stream, but you can forget about it
cheers
2015-03-12 14:14 GMT-03:00 Cyrille Henry <ch@chnry.net mailto:ch@chnry.net>:
Le 12/03/2015 18:04, Alexandre Torres Porres a écrit : "/i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./" well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this... timer and realtime compute 2 different things (logical time and real time). i don"t know what your want. what i don't understand is your intention with the spigot in the patch. cheers c So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this. thanks 2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>: hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's the final word on it? something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below the audio rate, but curiously it can go over. 1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer] check my patch attached, based on the one that was sent here on the thread. thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>>: hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period) You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms. sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters. yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question. cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do."
I got less in a mac with pd vanilla 0.46-5 64 bits, tried 1e-08 on [delay] and it was not accurate, [timer] giving me around 9.73e-09
then tried even lesser numbers and [timer] stopped 1.08126e-09
2015-03-12 16:42 GMT-03:00 David Medine dmedine@ucsd.edu:
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock:
double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif }
The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do.
The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to *do* control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch.
The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way.
If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars
-David
On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
I know they are different, and I don't really know what I want either :)
I just wanted to measure how long it takes between each control message.
you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working.
what i don't understand is your intention with the spigot in the patch.
just wanted to have a way to close the message stream, but you can forget about it
cheers
2015-03-12 14:14 GMT-03:00 Cyrille Henry ch@chnry.net:
Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :
"/i don't understand your patch.
using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./"
well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this...
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
what i don't understand is your intention with the spigot in the patch.
cheers c
So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this.
thanks
2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net mailto: ch@chnry.net>:
hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's thefinal word on it?
something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below theaudio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able tosend bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here onthe thread.
thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net mailto:ch@chnry.net>>:
hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delaybased metro and a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?)have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not[timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is morerelated to what happens. it's just the way i understand the original question.
cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list < http://lists.puredata.info/__listinfo/pd-list%3E < http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E%3E
___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list < http://lists.puredata.info/__listinfo/pd-list%3E < http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E%3E
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yeah, I am realizing now, as I continue to think about this instead of working, that I don't fully understand this detail.
On 3/12/2015 12:57 PM, Alexandre Torres Porres wrote:
"1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do."
I got less in a mac with pd vanilla 0.46-5 64 bits, tried 1e-08 on [delay] and it was not accurate, [timer] giving me around 9.73e-09
then tried even lesser numbers and [timer] stopped 1.08126e-09
2015-03-12 16:42 GMT-03:00 David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu>:
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock: double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif } The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do. The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to /do/ control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch. The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way. If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars -David On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:> timer and realtime compute 2 different things > (logical time and real time). i don"t know what > your want. I know they are different, and I don't really know what I want either :) I just wanted to measure how long it takes between each control message. you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working. > what i don't understand is your intention with > the spigot in the patch. just wanted to have a way to close the message stream, but you can forget about it cheers 2015-03-12 14:14 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>>: Le 12/03/2015 18:04, Alexandre Torres Porres a écrit : "/i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./" well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this... timer and realtime compute 2 different things (logical time and real time). i don"t know what your want. what i don't understand is your intention with the spigot in the patch. cheers c So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this. thanks 2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>: hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's the final word on it? something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below the audio rate, but curiously it can go over. 1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer] check my patch attached, based on the one that was sent here on the thread. thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>>: hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period) You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms. sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters. yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question. cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well, anyway, I was hoping for a simpler answer, and my original guess was that the control rate limit might be at the block size, now I'm all confused :)
I'm seeing that maybe we can't really measure the speed efficiently in a patch, and that Pd might actually be able to manage tiny and fasty clocks, but that there is also a limit on the way they are computed that depends on the block size, right?
What about a block size of one, and a large sample rate? I wonder if we could get control messages to work at 192Khz for example, huh?
One way or another, I guess there might be a pretty straightforward answer to this. I didn't find any in Miller's book yet.
cheers
2015-03-12 16:42 GMT-03:00 David Medine dmedine@ucsd.edu:
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock:
double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif }
The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do.
The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to *do* control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch.
The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way.
If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars
-David
On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
I know they are different, and I don't really know what I want either :)
I just wanted to measure how long it takes between each control message.
you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working.
what i don't understand is your intention with the spigot in the patch.
just wanted to have a way to close the message stream, but you can forget about it
cheers
2015-03-12 14:14 GMT-03:00 Cyrille Henry ch@chnry.net:
Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :
"/i don't understand your patch.
using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./"
well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this...
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
what i don't understand is your intention with the spigot in the patch.
cheers c
So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this.
thanks
2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net mailto: ch@chnry.net>:
hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's thefinal word on it?
something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below theaudio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able tosend bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here onthe thread.
thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net mailto:ch@chnry.net>>:
hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delaybased metro and a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?)have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not[timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is morerelated to what happens. it's just the way i understand the original question.
cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list < http://lists.puredata.info/__listinfo/pd-list%3E < http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E%3E
___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list < http://lists.puredata.info/__listinfo/pd-list%3E < http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E%3E
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
for the simple answer, i would say that : -from inside a patch, pd clock accuracy is "infinite"
- from the outside, clock accuracy is related to block size and sample rate.
cheers c
Le 12/03/2015 21:06, Alexandre Torres Porres a écrit :
Well, anyway, I was hoping for a simpler answer, and my original guess was that the control rate limit might be at the block size, now I'm all confused :)
I'm seeing that maybe we can't really measure the speed efficiently in a patch, and that Pd might actually be able to manage tiny and fasty clocks, but that there is also a limit on the way they are computed that depends on the block size, right?
What about a block size of one, and a large sample rate? I wonder if we could get control messages to work at 192Khz for example, huh?
One way or another, I guess there might be a pretty straightforward answer to this. I didn't find any in Miller's book yet.
cheers
2015-03-12 16:42 GMT-03:00 David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu>:
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock: double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif } The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do. The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to /do/ control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch. The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way. If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars -David On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:> timer and realtime compute 2 different things > (logical time and real time). i don"t know what > your want. I know they are different, and I don't really know what I want either :) I just wanted to measure how long it takes between each control message. you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working. > what i don't understand is your intention with > the spigot in the patch. just wanted to have a way to close the message stream, but you can forget about it cheers 2015-03-12 14:14 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>>: Le 12/03/2015 18:04, Alexandre Torres Porres a écrit : "/i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./" well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this... timer and realtime compute 2 different things (logical time and real time). i don"t know what your want. what i don't understand is your intention with the spigot in the patch. cheers c So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this. thanks 2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>: hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's the final word on it? something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below the audio rate, but curiously it can go over. 1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer] check my patch attached, based on the one that was sent here on the thread. thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>>: hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period) You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms. sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters. yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question. cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Don, 2015-03-12 at 21:16 +0100, Cyrille Henry wrote:
for the simple answer, i would say that : -from inside a patch, pd clock accuracy is "infinite"
That is actually what I meant when I said it was limited by the precision of the floating point format being used.
- from the outside, clock accuracy is related to block size and sample rate.
Depends on what you mean with "from the outside". You can use the precise timing to start a ramp with [vline~] between samples. You may use that for a signal generator that is played through [dac~ ]. I'd consider that "from the outside", too, and it is still more precise than block-rate.
Roman
Le 12/03/2015 21:06, Alexandre Torres Porres a écrit :
Well, anyway, I was hoping for a simpler answer, and my original guess was that the control rate limit might be at the block size, now I'm all confused :)
I'm seeing that maybe we can't really measure the speed efficiently in a patch, and that Pd might actually be able to manage tiny and fasty clocks, but that there is also a limit on the way they are computed that depends on the block size, right?
What about a block size of one, and a large sample rate? I wonder if we could get control messages to work at 192Khz for example, huh?
One way or another, I guess there might be a pretty straightforward answer to this. I didn't find any in Miller's book yet.
cheers
2015-03-12 16:42 GMT-03:00 David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu>:
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock: double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif } The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do. The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to /do/ control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch. The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way. If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars -David On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:> timer and realtime compute 2 different things > (logical time and real time). i don"t know what > your want. I know they are different, and I don't really know what I want either :) I just wanted to measure how long it takes between each control message. you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working. > what i don't understand is your intention with > the spigot in the patch. just wanted to have a way to close the message stream, but you can forget about it cheers 2015-03-12 14:14 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>>: Le 12/03/2015 18:04, Alexandre Torres Porres a écrit : "/i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./" well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this... timer and realtime compute 2 different things (logical time and real time). i don"t know what your want. what i don't understand is your intention with the spigot in the patch. cheers c So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this. thanks 2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>: hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's the final word on it? something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below the audio rate, but curiously it can go over. 1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer] check my patch attached, based on the one that was sent here on the thread. thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>>: hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period) You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms. sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters. yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question. cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/12/2015 10:11 PM, Roman Haefeli wrote:
On Don, 2015-03-12 at 21:16 +0100, Cyrille Henry wrote:
for the simple answer, i would say that : -from inside a patch, pd clock accuracy is "infinite"
That is actually what I meant when I said it was limited by the precision of the floating point format being used.
actually time stamps in Pd do not use "Pd's native number type" (t_float aka single precision float in almost all cases), but "double".
so clock accuracy is really very high.
otoh, finding a single number (like 1.4013e-45) for the clock tick accuracy is a misconception, as the timestamps are really "absolute timestamps" (in relation to Pd's start-time which is set to "0"). so the clock resolution gets worse the longer you run Pd.
think of the good ol' example if a patch-implemented [counter] implemented, that stops incrementing by 1 at 10000000 or so; otoh if your numbers stay small, you can increment by (say) 1e-6; the same holds true for the timestamps: far in the future, the time-stamp resolution will be e.g. 1 second or worse; luckily, using double precision, this will be FAR in the future.
fmds IOhannes
On 03/12/2015 09:16 PM, Cyrille Henry wrote:
- from the outside, clock accuracy is related to block size and sample
rate.
i think this is a but misleading, as it completely ignores the output objects.
e.g. when dealing with audio-processing, audio samples are calculated in bursts of small blocks (usually 64samples). even if those bursts would be processed at a fixed clock (e.g. every 1.5ms), i'm sure that we all agree that this does not match what we are hearing: we do hear a (DA-converted) steady stream of samples at a fixed rate of (say) 44.1kHz rather a burst each 1.5ms of 64 very short samples. in practice this should be even worse, as the 1.5ms between the blocks may be slightly shorter or longer, depending on what else is going on on your system. you can tweak how long these blocks can get with the "audiobuffer" parameter in Pd's audio settings. If you put there "100ms" you *might* end up with all the audio processing being done only ever 0.1 seconds.
but we don't hear our sound cards making stuttering at 10Hz. (most of the times, at least). we also don't hear any sample jitter (unless we have some serious shit of soundcard).
this is mainly because Pd doesnt play back samples into our ears, but it sends them to a soundcard, which has a buffer and which uses some quartz or other rather precise clock that is synchronized to the "real world" to play back those samples.
so the timing resolution of the audio processing is handled mainly by your output device and by the objects that communicate with this device.
the same *can* be (made) true for any event that happens in Pd's logical time and that needs to be converted to some "real world event".
unfortunately it often isn't, because...
- it doesn't really matter (e.g. who cares about precise timing when
printing "bang" to the Pd-console)
- a device doesn't provide a means to specify exactly when it will react
onto an event
- the API that handles communication with a device, doesn't provide a
means to specify exactly when it will react onto an event
- the object's author was lazy and didn't care about telling the device
when the events should appear (but rather tells them to make them happen "now" - with "now" being the jittery burst when the CPU sees the events)
- other reasons
gdsrt IOhannes
Yeah, of course. Block size 1 and high sampling rate will make the timing between control and audio super tight (ChucK does this, for example). It will also eat the hell out of your CPU. It's a trade off. This is because you start calling all the DSP functions once every 1/192k seconds instead of once every 1.45ms.
On 3/12/2015 1:06 PM, Alexandre Torres Porres wrote:
Well, anyway, I was hoping for a simpler answer, and my original guess was that the control rate limit might be at the block size, now I'm all confused :)
I'm seeing that maybe we can't really measure the speed efficiently in a patch, and that Pd might actually be able to manage tiny and fasty clocks, but that there is also a limit on the way they are computed that depends on the block size, right?
What about a block size of one, and a large sample rate? I wonder if we could get control messages to work at 192Khz for example, huh?
One way or another, I guess there might be a pretty straightforward answer to this. I didn't find any in Miller's book yet.
cheers
2015-03-12 16:42 GMT-03:00 David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu>:
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock: double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif } The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do. The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to /do/ control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch. The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way. If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars -David On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:> timer and realtime compute 2 different things > (logical time and real time). i don"t know what > your want. I know they are different, and I don't really know what I want either :) I just wanted to measure how long it takes between each control message. you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working. > what i don't understand is your intention with > the spigot in the patch. just wanted to have a way to close the message stream, but you can forget about it cheers 2015-03-12 14:14 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>>: Le 12/03/2015 18:04, Alexandre Torres Porres a écrit : "/i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./" well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this... timer and realtime compute 2 different things (logical time and real time). i don"t know what your want. what i don't understand is your intention with the spigot in the patch. cheers c So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this. thanks 2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>: hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's the final word on it? something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below the audio rate, but curiously it can go over. 1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer] check my patch attached, based on the one that was sent here on the thread. thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>>: hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delay based metro and a [metro]. (both can do faster than 1ms period) You're right. More recent versions of Pd (>= 0.45?) have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms. sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not [timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters. yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is more related to what happens. it's just the way i understand the original question. cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list> <http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Mar 12, 2015 at 3:18 PM, David Medine dmedine@ucsd.edu wrote:
Yeah, of course. Block size 1 and high sampling rate will make the timing between control and audio super tight (ChucK does this, for example). It will also eat the hell out of your CPU. It's a trade off. This is because you start calling all the DSP functions once every 1/192k seconds instead of once every 1.45ms.
This last sentence is also a misconception--the dsp tick function is called every 64 samples, as commonly defined.
sys_time_per_dsp_tick = (TIMEUNITPERSECOND) *
((double)sys_schedblocksize) / sys_dacsr;
sys_schedblocksize gets set from DEFDACBLKSIZE
So, the dsp_tick gets called, and when there is a sub-patch with [block~ 1], it loops over the graph generated from the sub-patch 64 times.
You'd find this behavior coded with the block prologue and epilogue functions.
On 3/12/2015 1:06 PM, Alexandre Torres Porres wrote:
Well, anyway, I was hoping for a simpler answer, and my original guess was that the control rate limit might be at the block size, now I'm all confused :)
I'm seeing that maybe we can't really measure the speed efficiently in a patch, and that Pd might actually be able to manage tiny and fasty clocks, but that there is also a limit on the way they are computed that depends on the block size, right?
What about a block size of one, and a large sample rate? I wonder if we could get control messages to work at 192Khz for example, huh?
One way or another, I guess there might be a pretty straightforward answer to this. I didn't find any in Miller's book yet.
cheers
2015-03-12 16:42 GMT-03:00 David Medine dmedine@ucsd.edu:
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock:
double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif }
The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do.
The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to do control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch.
The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way.
If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars
-David
On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
I know they are different, and I don't really know what I want either :)
I just wanted to measure how long it takes between each control message.
you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working.
what i don't understand is your intention with the spigot in the patch.
just wanted to have a way to close the message stream, but you can forget about it
cheers
2015-03-12 14:14 GMT-03:00 Cyrille Henry ch@chnry.net:
Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :
"/i don't understand your patch.
using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./"
well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this...
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
what i don't understand is your intention with the spigot in the patch.
cheers c
So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this.
thanks
2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net mailto:ch@chnry.net>:
hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's thefinal word on it?
something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below theaudio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able tosend bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here onthe thread.
thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.netmailto:ch@chnry.net <mailto:ch@chnry.net mailto:ch@chnry.net>>:
hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delaybased metro and a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?)have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not[timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is morerelated to what happens. it's just the way i understand the original question.
cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at><mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list>
___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at><mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list>
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
@Charles: None of those five sentences is a misconception. When I said 'DSP functions' I meant the functions of the form 'whatever_tilde_perform', not the dsp tick function. I see how this might lead to a misunderstanding.
Also, I see that suseconds_t (which is the type of now.tv_usec) is an integer, as I had previously thought, so I am really perplexed as to how [delay] can apparently deliver bangs within less than 1us. I would love for someone to explain this to me. It is a small detail and it doesn't really matter in practice, but I am annoyed when my inferences are not correct -- especially when I send them to the Pd list!
On 3/12/2015 1:58 PM, Charles Z Henry wrote:
On Thu, Mar 12, 2015 at 3:18 PM, David Medine dmedine@ucsd.edu wrote:
Yeah, of course. Block size 1 and high sampling rate will make the timing between control and audio super tight (ChucK does this, for example). It will also eat the hell out of your CPU. It's a trade off. This is because you start calling all the DSP functions once every 1/192k seconds instead of once every 1.45ms.
This last sentence is also a misconception--the dsp tick function is called every 64 samples, as commonly defined.
sys_time_per_dsp_tick = (TIMEUNITPERSECOND) * ((double)sys_schedblocksize) / sys_dacsr;sys_schedblocksize gets set from DEFDACBLKSIZE
So, the dsp_tick gets called, and when there is a sub-patch with [block~ 1], it loops over the graph generated from the sub-patch 64 times.
You'd find this behavior coded with the block prologue and epilogue functions.
On 3/12/2015 1:06 PM, Alexandre Torres Porres wrote:
Well, anyway, I was hoping for a simpler answer, and my original guess was that the control rate limit might be at the block size, now I'm all confused :)
I'm seeing that maybe we can't really measure the speed efficiently in a patch, and that Pd might actually be able to manage tiny and fasty clocks, but that there is also a limit on the way they are computed that depends on the block size, right?
What about a block size of one, and a large sample rate? I wonder if we could get control messages to work at 192Khz for example, huh?
One way or another, I guess there might be a pretty straightforward answer to this. I didn't find any in Miller's book yet.
cheers
2015-03-12 16:42 GMT-03:00 David Medine dmedine@ucsd.edu:
My understanding of this patch and the guts of Pd tells me that this patch isn't really going to measure how long it takes between each control message. What it can do is show the time resolution of calls to sys_getrealtime, which is Pd's method of querying the CPU clock:
double sys_getrealtime(void) { #ifndef _WIN32 static struct timeval then; struct timeval now; gettimeofday(&now, 0); if (then.tv_sec == 0 && then.tv_usec == 0) then = now; return ((now.tv_sec - then.tv_sec) + (1./1000000.) * (now.tv_usec - then.tv_usec)); #else LARGE_INTEGER now; QueryPerformanceCounter(&now); if (nt_freq == 0) sys_initntclock(); return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq); #endif }
The code is from s_inter.c. It is apparent (at least in the non-Windows part of the code) that there is a microsecond resolution, hence 1e-6, but I could misunderstanding this. I was able to put 1e-7 on a Windows machine and it still worked -- I haven't had a chance to do try it in Unix/BSD land and I don't actually want to know what Windows is doing with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway) 1us is the smallest unit of time that Pd's clocks keep track of, so that should be the limit of what [delay] can do.
The actual time it takes for Pd to deal with messages depends on a great many things. Symbols in Pd are stored in a hash table, so I would guess that the size of the table (which needs to be searched) is the main factor controlling the rate at which those messages can be handled. However, I suspect that the number of symbols needed to slow Pd down on a modern computer is impractically large. Then there are control messages that don't have hashed symbols associated with them (like floats and bangs). Also, some external controls -- especially mouse/keyboard events and MIDI -- can be badly timed. These tend to queue up and get spit out at the OS's whim. Pd then simply does what it can with what it gets. So measuring the exact time it takes to do control in Pd is pretty hairy. I don't believe that meaningful measurements of this can be done with a Pd patch.
The other thing is that control messages get rolled up between dsp ticks and are then applied immediately on the start of the next tick. This means that two messages that are, say, .05ms apart somewhere in the midst of a 1.45ms block, get applied simultaneously at the start of the next block. This also means that at 44.1kHz with a block size of 64 samples, both of them may be anywhere from 0.02 ms to 1.45ms late -- depending on where they fall in relation to block boundaries. This also, also means that if one control message happens near the end of one block and the other happens near the start of the next block, their distance of .05ms in physical time will be expanded to 1.45ms. This is a very big, teeny-tiny problem in real-time audio programming because under certain conditions there can be serious (audible) repercussions. This is why there is [vline~], by the way.
If anyone else is interested in this stuff, I recommend these lectures (Miller's is the first in the series): http://repmus.ircam.fr/mutant/rtmseminars
-David
On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
I know they are different, and I don't really know what I want either :)
I just wanted to measure how long it takes between each control message.
you were using [realtime], and then Roman came in and said that'd be kinda random and how [timer] was best for it. So I tried with [timer] and got a very nice result indeed. But I'm not sure now if that actually relates to whats going on... or how it is actually working.
what i don't understand is your intention with the spigot in the patch.
just wanted to have a way to close the message stream, but you can forget about it
cheers
2015-03-12 14:14 GMT-03:00 Cyrille Henry ch@chnry.net:
Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :
"/i don't understand your patch.
using [timer], a delay 0 will give a 0 delay... logical time will always be consistent./"
well, I thought you were disucussing here and reaching the conclusion that [timer] is the one to be used to calculate this...
timer and realtime compute 2 different things (logical time and real time). i don"t know what your want.
what i don't understand is your intention with the spigot in the patch.
cheers c
So you mean this result is actually inconsistent? And the implication is that it is not going at that super fast rate at all? Please help me understand better about how to measure this.
thanks
2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch@chnry.net mailto:ch@chnry.net>:
hello, i don't understand your patch. using [timer], a delay 0 will give a 0 delay... logical time will always be consistent. cheers c Le 12/03/2015 15:41, Alexandre Torres Porres a écrit : ok, so the metro at 1ms is because I'm using extended. as for the minimum time pd can process and send data, what's thefinal word on it?
something like 1.4013e-45 ms? cause that's a lot more than an audio rate at 44.1khz :) I thought there was a limit control rate that was below theaudio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able tosend bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here onthe thread.
thanks 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch@chnry.netmailto:ch@chnry.net <mailto:ch@chnry.net mailto:ch@chnry.net>>:
hello, Le 12/03/2015 10:12, Roman Haefeli a écrit : On Thu, 2015-03-12 at 09:17 +0100, Cyrille Henry wrote: hello this patch show the same behaviors for a delaybased metro and a [metro]. (both can do faster than 1ms period)
You're right. More recent versions of Pd (>= 0.45?)have an updated [metro] that supports many more ways to specify time and the restriction was lowered. However, the [metro] in any available version of Pd-extended is still limited to 1ms.
sorry, i was not aware of this old limitation. I don't understand why you use [realtime] and not[timer] to illustrate your point. [timer] gives you consistent values (logical time) while [realtime] is very jittery and shows just some random value depending on the current cpu usage and probably other factors. When you render a soundfile, the logical time is actually the one that matters.
yes, for things that stay in pd, logical time is better. but if you want to send midi note, [realtime] is morerelated to what happens. it's just the way i understand the original question.
cheers c Roman ___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at><mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list>
___________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at><mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/____listinfo/pd-list http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list>
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
_________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Mar 12, 2015 at 5:01 PM, David Medine dmedine@ucsd.edu wrote:
@Charles: None of those five sentences is a misconception. When I said 'DSP functions' I meant the functions of the form 'whatever_tilde_perform', not the dsp tick function. I see how this might lead to a misunderstanding.
Sorry if I was unclear as well. We *are* trying to split hairs here, of course, just to have an accurate description.
It's not *all* of the dsp functions. I thought this was unclear and tried to clarify: rather than scheduling them more often, it actually just loops over the sub-graphs multiple times when the block size is low. There is always a parent function which is being run once every 64 samples (the default).
Also, I see that suseconds_t (which is the type of now.tv_usec) is an integer, as I had previously thought, so I am really perplexed as to how [delay] can apparently deliver bangs within less than 1us. I would love for someone to explain this to me. It is a small detail and it doesn't really matter in practice, but I am annoyed when my inferences are not correct -- especially when I send them to the Pd list!
On 3/12/2015 1:58 PM, Charles Z Henry wrote:
On Thu, Mar 12, 2015 at 3:18 PM, David Medine dmedine@ucsd.edu wrote:
Yeah, of course. Block size 1 and high sampling rate will make the timing between control and audio super tight (ChucK does this, for example). It will also eat the hell out of your CPU. It's a trade off. This is because you start calling all the DSP functions once every 1/192k seconds instead of once every 1.45ms.
This last sentence is also a misconception--the dsp tick function is called every 64 samples, as commonly defined.
sys_time_per_dsp_tick = (TIMEUNITPERSECOND) * ((double)sys_schedblocksize) / sys_dacsr;sys_schedblocksize gets set from DEFDACBLKSIZE
So, the dsp_tick gets called, and when there is a sub-patch with [block~ 1], it loops over the graph generated from the sub-patch 64 times.
You'd find this behavior coded with the block prologue and epilogue functions.
since it was mentioned here, what's the behaviour and deal with [vnsapshot~]? Cause there's no help file for ir yet.
thanks
2015-03-12 19:14 GMT-03:00 Charles Z Henry czhenry@gmail.com:
On Thu, Mar 12, 2015 at 5:01 PM, David Medine dmedine@ucsd.edu wrote:
@Charles: None of those five sentences is a misconception. When I said
'DSP
functions' I meant the functions of the form 'whatever_tilde_perform',
not
the dsp tick function. I see how this might lead to a misunderstanding.
Sorry if I was unclear as well. We *are* trying to split hairs here, of course, just to have an accurate description.
It's not *all* of the dsp functions. I thought this was unclear and tried to clarify: rather than scheduling them more often, it actually just loops over the sub-graphs multiple times when the block size is low. There is always a parent function which is being run once every 64 samples (the default).
Also, I see that suseconds_t (which is the type of now.tv_usec) is an integer, as I had previously thought, so I am really perplexed as to how [delay] can apparently deliver bangs within less than 1us. I would love
for
someone to explain this to me. It is a small detail and it doesn't really matter in practice, but I am annoyed when my inferences are not correct
--
especially when I send them to the Pd list!
On 3/12/2015 1:58 PM, Charles Z Henry wrote:
On Thu, Mar 12, 2015 at 3:18 PM, David Medine dmedine@ucsd.edu wrote:
Yeah, of course. Block size 1 and high sampling rate will make the
timing
between control and audio super tight (ChucK does this, for example).
It
will also eat the hell out of your CPU. It's a trade off. This is
because
you start calling all the DSP functions once every 1/192k seconds
instead
of once every 1.45ms.
This last sentence is also a misconception--the dsp tick function is called every 64 samples, as commonly defined.
sys_time_per_dsp_tick = (TIMEUNITPERSECOND) * ((double)sys_schedblocksize) / sys_dacsr;sys_schedblocksize gets set from DEFDACBLKSIZE
So, the dsp_tick gets called, and when there is a sub-patch with [block~ 1], it loops over the graph generated from the sub-patch 64 times.
You'd find this behavior coded with the block prologue and epilogue functions.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi, I've worked on an external that uses tv_usec for sending gpio pulses with a period under 1ms, it begin to work with no segfaults and low cpu process with the help of stallman's pthread library, it's not ready yet for sharing, maybe it's possible to send fast rate bangs like this? I would enjoy to see such attempts in other externals, good luck...
Colet Patrice
PS: it's really hard to believe that it's possible to go under 1us!
On 03/12/2015 07:07 PM, Patrice Colet wrote:
Hi, I've worked on an external that uses tv_usec for sending gpio pulses with a period under 1ms, it begin to work with no segfaults and low cpu process with the help of stallman's pthread library, it's not ready yet for sharing, maybe it's possible to send fast rate bangs like this? I would enjoy to see such attempts in other externals, good luck...
Do you use the vline~ approach?
-Jonathan
Colet Patrice
PS: it's really hard to believe that it's possible to go under 1us!
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'm not sure that the precision of clock-based classes (float for Pd users, double within the external API) or even Pd's event loop should be considered part of the topic "control rate". That term already means something in Csound and Supercollider, something like a rate for gaining efficiency by letting objects copy a scalar value for the entire block instead of computing each sample. For example, if you want to use a low frequency sine wave to attenuate some noise, you can compute one value of the sine wave per block and just copy it for each sample of that block. That will be more efficient that computing each sample, and still be fast enough to avoid zipper noise. In Pd, some of the math signal objects from d_math.c do something similar in nature. For example, [*~] has two signal inlets, but [*~ 0] has a control inlet on the right. That control inlet limits the maximum speed with which you can change the stored value (i.e., once per block). It's also presumably more efficient than [*~] because one of the increment operators is replaced with a single float variable. But that's still not really "control rate", because control objects don't have a requirement to fire on a set schedule. I guess making a chain of control objects below [bang~] would be the closest thing to Supercollider's "kr" method. But because of Pd's message-passing overhead that's probably not going to be as efficient.
But maybe the question is this: what is the smallest interval one can specify in Pd to reliably trigger messages through time? The answer is probably inside m_sched.c, but I can't figure it out with a casual glance. However, it looks to be dependent on the sample rate you choose, as the lowest common multiple of the common sample rates is used to calculate the granularity of the time units themselves. -Jonathan
On Thursday, March 12, 2015 7:24 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
since it was mentioned here, what's the behaviour and deal with [vnsapshot~]? Cause there's no help file for ir yet. thanks 2015-03-12 19:14 GMT-03:00 Charles Z Henry czhenry@gmail.com:
On Thu, Mar 12, 2015 at 5:01 PM, David Medine dmedine@ucsd.edu wrote:
@Charles: None of those five sentences is a misconception. When I said 'DSP functions' I meant the functions of the form 'whatever_tilde_perform', not the dsp tick function. I see how this might lead to a misunderstanding.
Sorry if I was unclear as well. We *are* trying to split hairs here, of course, just to have an accurate description.
It's not *all* of the dsp functions. I thought this was unclear and tried to clarify: rather than scheduling them more often, it actually just loops over the sub-graphs multiple times when the block size is low. There is always a parent function which is being run once every 64 samples (the default).
Also, I see that suseconds_t (which is the type of now.tv_usec) is an integer, as I had previously thought, so I am really perplexed as to how [delay] can apparently deliver bangs within less than 1us. I would love for someone to explain this to me. It is a small detail and it doesn't really matter in practice, but I am annoyed when my inferences are not correct -- especially when I send them to the Pd list!
On 3/12/2015 1:58 PM, Charles Z Henry wrote:
On Thu, Mar 12, 2015 at 3:18 PM, David Medine dmedine@ucsd.edu wrote:
Yeah, of course. Block size 1 and high sampling rate will make the timing between control and audio super tight (ChucK does this, for example). It will also eat the hell out of your CPU. It's a trade off. This is because you start calling all the DSP functions once every 1/192k seconds instead of once every 1.45ms.
This last sentence is also a misconception--the dsp tick function is called every 64 samples, as commonly defined.
sys_time_per_dsp_tick = (TIMEUNITPERSECOND) * ((double)sys_schedblocksize) / sys_dacsr;
sys_schedblocksize gets set from DEFDACBLKSIZE
So, the dsp_tick gets called, and when there is a sub-patch with [block~ 1], it loops over the graph generated from the sub-patch 64 times.
You'd find this behavior coded with the block prologue and epilogue functions.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
That is what I'm trying to say since - I don't know - at least three posts.
And I understood that even before I asked to the list in my first email, when I first mentioned that the fact was curious. By the way, I'm still finding it quite curious.
[timer] shows the correct number. However, even that simple patch clogs my CPU when setting it to 1e-06
I'm aware that CPU can choke on an absurdly fast control rate. Nonetheless, the concern and question is not to how much the CPU can take, but how small a period of time Pd could consistently and steadily send messages. To make it simple, the smallest time an object like [metro] is able to operate.
If [timer] calculates that period of time correctly and accurately, then I was able to go get consistent results at around 1e-09, where the values between metro time and [timer] kinda mismatch and it stops being accurate.
*> But maybe the question is this: what is the * *> smallest interval one can specify in Pd to * *> reliably trigger messages through time?*
About the "control rate" paradigm in Pd, I have to admit that when I asked about it I was thinking about it in relation to what that means in supercollider and Csound, but I also always considered that Pd doesn't really have that kind of "control rate" per se. It's nice that we can look deeply into what it all means in the Pd context.
But yeah, I think everyone gets the question anyway, but the final detailed answer is still out there somewhere.
This is what I get so far, anyway: By thinking of more of a general concept from the SC/Csound realm, a control rate is something that is slower than audio rate and it doesn't make sense that it can go higher than audio rate (thus some may consider it "curious"). Simply put, since Pd does not have this kind of paradigm in its structure, control messages have no real boundary and are free to be fired at any rate that your computer can manage and restricted only to bit float limitations.
By making it more straightforward, it has no limits, it can go faster than you'll ever need it to until it kills your CPU.
cheers
2015-03-12 23:47 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
I'm not sure that the precision of clock-based classes (float for Pd users, double within the external API) or even Pd's event loop should be considered part of the topic "control rate". That term already means something in Csound and Supercollider, something like a rate for gaining efficiency by letting objects copy a scalar value for the entire block instead of computing each sample. For example, if you want to use a low frequency sine wave to attenuate some noise, you can compute one value of the sine wave per block and just copy it for each sample of that block. That will be more efficient that computing each sample, and still be fast enough to avoid zipper noise.
In Pd, some of the math signal objects from d_math.c do something similar in nature. For example, [*~] has two signal inlets, but [*~ 0] has a control inlet on the right. That control inlet limits the maximum speed with which you can change the stored value (i.e., once per block). It's also presumably more efficient than [*~] because one of the increment operators is replaced with a single float variable.
But that's still not really "control rate", because control objects don't have a requirement to fire on a set schedule. I guess making a chain of control objects below [bang~] would be the closest thing to Supercollider's "kr" method. But because of Pd's message-passing overhead that's probably not going to be as efficient.
But maybe the question is this: what is the smallest interval one can specify in Pd to reliably trigger messages through time? The answer is probably inside m_sched.c, but I can't figure it out with a casual glance. However, it looks to be dependent on the sample rate you choose, as the lowest common multiple of the common sample rates is used to calculate the granularity of the time units themselves.
-Jonathan
On Thursday, March 12, 2015 7:24 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
since it was mentioned here, what's the behaviour and deal with [vnsapshot~]? Cause there's no help file for ir yet.
thanks
2015-03-12 19:14 GMT-03:00 Charles Z Henry czhenry@gmail.com:
On Thu, Mar 12, 2015 at 5:01 PM, David Medine dmedine@ucsd.edu wrote:
@Charles: None of those five sentences is a misconception. When I said
'DSP
functions' I meant the functions of the form 'whatever_tilde_perform',
not
the dsp tick function. I see how this might lead to a misunderstanding.
Sorry if I was unclear as well. We *are* trying to split hairs here, of course, just to have an accurate description.
It's not *all* of the dsp functions. I thought this was unclear and tried to clarify: rather than scheduling them more often, it actually just loops over the sub-graphs multiple times when the block size is low. There is always a parent function which is being run once every 64 samples (the default).
Also, I see that suseconds_t (which is the type of now.tv_usec) is an integer, as I had previously thought, so I am really perplexed as to how [delay] can apparently deliver bangs within less than 1us. I would love
for
someone to explain this to me. It is a small detail and it doesn't really matter in practice, but I am annoyed when my inferences are not correct
--
especially when I send them to the Pd list!
On 3/12/2015 1:58 PM, Charles Z Henry wrote:
On Thu, Mar 12, 2015 at 3:18 PM, David Medine dmedine@ucsd.edu wrote:
Yeah, of course. Block size 1 and high sampling rate will make the
timing
between control and audio super tight (ChucK does this, for example).
It
will also eat the hell out of your CPU. It's a trade off. This is
because
you start calling all the DSP functions once every 1/192k seconds
instead
of once every 1.45ms.
This last sentence is also a misconception--the dsp tick function is called every 64 samples, as commonly defined.
sys_time_per_dsp_tick = (TIMEUNITPERSECOND) * ((double)sys_schedblocksize) / sys_dacsr;sys_schedblocksize gets set from DEFDACBLKSIZE
So, the dsp_tick gets called, and when there is a sub-patch with [block~ 1], it loops over the graph generated from the sub-patch 64 times.
You'd find this behavior coded with the block prologue and epilogue functions.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2015-03-13 at 04:51 -0300, Alexandre Torres Porres wrote:
I'm aware that CPU can choke on an absurdly fast control rate. Nonetheless, the concern and question is not to how much the CPU can take, but how small a period of time Pd could consistently and steadily send messages. To make it simple, the smallest time an object like [metro] is able to operate.
In practice, it seems that the smallest time interval measurable by [timer] is dependent on how long you have Pd running. Attached is a patch that sends two bangs with an interval of 6.8e-11 every second. It seems that the first 1217 seconds you get a non-zero result from [timer] (though the result changes during the first few seconds). After 1218 seconds of running Pd, [timer] measures 0.
To give your question again a different answer, it seems that there is no absolute minimum time interval in Pd, but it increases over time of running Pd.
Roman
p.s.: Make sure to open the patch right away like this: pd -open shortest_time_intervall.pd if you intend to get consistent results with the numbers above.
On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres porres@gmail.com wrote:
About the "control rate" paradigm in Pd, I have to admit that when I asked about it I was thinking about it in relation to what that means in supercollider and Csound, but I also always considered that Pd doesn't really have that kind of "control rate" per se. It's nice that we can look deeply into what it all means in the Pd context.
But yeah, I think everyone gets the question anyway, but the final detailed answer is still out there somewhere.
This is what I get so far, anyway: By thinking of more of a general concept from the SC/Csound realm, a control rate is something that is slower than audio rate and it doesn't make sense that it can go higher than audio rate (thus some may consider it "curious"). Simply put, since Pd does not have this kind of paradigm in its structure, control messages have no real boundary and are free to be fired at any rate that your computer can manage and restricted only to bit float limitations.
By making it more straightforward, it has no limits, it can go faster than you'll ever need it to until it kills your CPU.
The attached patch lets you see Pd's "control rate" in action. It shows a
graph of a wave being chopped at control rate. It won't chop any faster than about 1ms and it's irregular.
Martin
The attached patch lets you see Pd's "control rate" in action.
this is not the best way to measure this, cause [*~ 0] is not able to convert data to audio as you expect, it's best to use [vline~].
cheers
2015-03-13 14:55 GMT-03:00 Martin Peach chakekatzil@gmail.com:
On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres <porres@gmail.com
wrote:
About the "control rate" paradigm in Pd, I have to admit that when I asked about it I was thinking about it in relation to what that means in supercollider and Csound, but I also always considered that Pd doesn't really have that kind of "control rate" per se. It's nice that we can look deeply into what it all means in the Pd context.
But yeah, I think everyone gets the question anyway, but the final detailed answer is still out there somewhere.
This is what I get so far, anyway: By thinking of more of a general concept from the SC/Csound realm, a control rate is something that is slower than audio rate and it doesn't make sense that it can go higher than audio rate (thus some may consider it "curious"). Simply put, since Pd does not have this kind of paradigm in its structure, control messages have no real boundary and are free to be fired at any rate that your computer can manage and restricted only to bit float limitations.
By making it more straightforward, it has no limits, it can go faster than you'll ever need it to until it kills your CPU.
The attached patch lets you see Pd's "control rate" in action. It shows a
graph of a wave being chopped at control rate. It won't chop any faster than about 1ms and it's irregular.
Martin
Yes with [vline~] it goes finer, but try using numbers around 756 in the upper number box in this patch, I get long intervals, it's as though the control rate is aliasing.
Martin
On Fri, Mar 13, 2015 at 3:16 PM, Alexandre Torres Porres porres@gmail.com wrote:
The attached patch lets you see Pd's "control rate" in action.
this is not the best way to measure this, cause [*~ 0] is not able to convert data to audio as you expect, it's best to use [vline~].
cheers
2015-03-13 14:55 GMT-03:00 Martin Peach chakekatzil@gmail.com:
On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres <porres@gmail.com
wrote:
About the "control rate" paradigm in Pd, I have to admit that when I asked about it I was thinking about it in relation to what that means in supercollider and Csound, but I also always considered that Pd doesn't really have that kind of "control rate" per se. It's nice that we can look deeply into what it all means in the Pd context.
But yeah, I think everyone gets the question anyway, but the final detailed answer is still out there somewhere.
This is what I get so far, anyway: By thinking of more of a general concept from the SC/Csound realm, a control rate is something that is slower than audio rate and it doesn't make sense that it can go higher than audio rate (thus some may consider it "curious"). Simply put, since Pd does not have this kind of paradigm in its structure, control messages have no real boundary and are free to be fired at any rate that your computer can manage and restricted only to bit float limitations.
By making it more straightforward, it has no limits, it can go faster than you'll ever need it to until it kills your CPU.
The attached patch lets you see Pd's "control rate" in action. It shows
a graph of a wave being chopped at control rate. It won't chop any faster than about 1ms and it's irregular.
Martin
On 03/13/2015 08:43 PM, Martin Peach wrote:
Yes with [vline~] it goes finer, but try using numbers around 756 in the upper number box in this patch, I get long intervals, it's as though the control rate is aliasing.
cannot reproduce. (though it's a bit unclear what yo umean by "in the upper number box" - presumably the rate of the metro that switches the noise on and off)
most likely you are seeing an artifact about updating the display graph. have you tried listening to the result and verified that it sounds "strange" (i guess thousands and thousands of people have run patches that turn on/off a sound at a rate of 756ms without having any problems)
fgmdsar IOhannes
The upper number box is then multiplied by 10^-5 so it should be .00756ms. Yes I don't have actual sound here so it could be the display that's aliasing. I'm using pd 0.46-5 on WinXP. I'll try again when I get home.
Martin
On Fri, Mar 13, 2015 at 4:03 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 03/13/2015 08:43 PM, Martin Peach wrote:
Yes with [vline~] it goes finer, but try using numbers around 756 in the upper number box in this patch, I get long intervals, it's as though the control rate is aliasing.
cannot reproduce. (though it's a bit unclear what yo umean by "in the upper number box" - presumably the rate of the metro that switches the noise on and off)
most likely you are seeing an artifact about updating the display graph. have you tried listening to the result and verified that it sounds "strange" (i guess thousands and thousands of people have run patches that turn on/off a sound at a rate of 756ms without having any problems)
fgmdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/13/2015 09:03 PM, IOhannes m zmölnig wrote:
On 03/13/2015 08:43 PM, Martin Peach wrote:
Yes with [vline~] it goes finer, but try using numbers around 756 in the upper number box in this patch, I get long intervals, it's as though the control rate is aliasing.
cannot reproduce. (though it's a bit unclear what yo umean by "in the upper number box" - presumably the rate of the metro that switches the noise on and off)
most likely you are seeing an artifact about updating the display graph. have you tried listening to the result and verified that it sounds "strange" (i guess thousands and thousands of people have run patches that turn on/off a sound at a rate of 756ms without having any problems)
ouch, i missed the [* 1e-05].
so your rate is really low, lower than sr.
when i change the tabsize to something small (like 44), and the input signal to something more predicatable ([sig~ 0.5]) the pattern looks very nice, with samples alternating between 0 and non-0 (0.5 in my case); every know and then a sample is repeated (e.g. two times 0.5, then continuing with 0, 0.5,...) but this is expected if your toggle-rate is not a multiple of your sr.
gfmsdr IOhannes
On 03/13/2015 09:10 PM, IOhannes m zmölnig wrote:
when i change the tabsize to something small (like 44), and the input
using a small tabsize has two advantages:
- signals with a high frequency can be inspected more easily
- there is less data sent from pd-core to pd-gui, does making the gui
more responsive (or rather: less likely to drop a table update)
gfmdsar IOhannes
On 03/13/2015 09:10 PM, IOhannes m zmölnig wrote:
so your rate is really low, lower than sr.
which of course should have read: "high"
btw, you are multiplying your input signal (at 44.1Hz) with a rectangle signal at 3*samplerate: of course you are getting aliasing.
fgrdsam IOhannes
Yes I just realized .00756ms is three times the sample rate, so the "control rate" is faster than the sample rate. Makes sense now. Does it make sense for that to be possible though? What use is it?
Martin
On Fri, Mar 13, 2015 at 4:17 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 03/13/2015 09:10 PM, IOhannes m zmölnig wrote:
so your rate is really low, lower than sr.
which of course should have read: "high"
btw, you are multiplying your input signal (at 44.1Hz) with a rectangle signal at 3*samplerate: of course you are getting aliasing.
fgrdsam IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/13/2015 09:23 PM, Martin Peach wrote:
Yes I just realized .00756ms is three times the sample rate, so the "control rate" is faster than the sample rate. Makes sense now. Does it make sense for that to be possible though? What use is it?
like: upsampling to an arbitrary rate, doing some weirdo processing and downsampling again¹?
seriously: i don't think that your *new* question makes much sense. the strong point of software like Pd is making things possible that no one has thought that they would make "sense". that's why it is useful in the arts. that's why it is useful in science.
gfmsard IOhannes
¹ you wouldn't need to *actually* process your new samples at any fixed rate; you would most likely re-block them and then batch-process them each dsp-tick; so it's really an artificial and bad example.
so another attempt: just use it to generate signals in the ordinary "fs/2 domain" (at least this is how i teach my students to generate rectangle signals); now "fs/2" could be virtually any number, and .007ms @ 192kHz is no longer "three times the sample rate".
You're measuring many things at once:1) lower limit of [metro] granularity, which is much higher than other clock-based objects in Pd like [del] and [pipe]2) common way in which control messages are converted to signals on the block boundaries (the other way is how vline~ and vsnapshot~ do it)3) probably something having to do with Pd's hard-coded default dac block size of 64 You can get rid of #1 by using a [delay] loop instead. But be careful-- if you accidentally set it to "0" then unlike [metro] it will carry out your instructions. As far as measuring the smallest "grain" with which you can trigger clock delays in Pd-- I guess there are two answers:
- For practical purposes, this seems to be limited only by the precision with which you can specify delays to Pd. As a patch author, that would be the float precision, or for Pd Double, double precision. If you're an external developer, you send a double to clock_set.
The other answer is based on my shaky understanding of m_sched.c. Here goes...
- The Shrunken Omniscient Demigod answer-- let's say you shrink down and stand next to the CPU to watch Pd's instructions fly by. You might notice that some [delay] triggering instructions arrive too closely together, while others are spaced too far apart. Since you're omniscient you would know this happens because the triggering of the control events are quantized to the dsp "tick" time (i.e., sys_time_per_dsp_tick). That means two delays that both happen before the next tick will get triggered one right after the other, while two separated by a block boundary will happen with a delay of one block.
Since you're omniscient, you would also know that the timestamps are not quantized to the dsp "tick" time. That means that Pd keeps track of and reports the correct timings with [timer] and friends regardless of how the block boundaries interact with the actual timings of control events firing in an object chain. Since mortals are so inept at measuring time on that level, precise bookkeeping is probably precision enough. -Jonathan
On Friday, March 13, 2015 1:59 PM, Martin Peach <chakekatzil@gmail.com> wrote:
On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres porres@gmail.com wrote:
About the "control rate" paradigm in Pd, I have to admit that when I asked about it I was thinking about it in relation to what that means in supercollider and Csound, but I also always considered that Pd doesn't really have that kind of "control rate" per se. It's nice that we can look deeply into what it all means in the Pd context. But yeah, I think everyone gets the question anyway, but the final detailed answer is still out there somewhere. This is what I get so far, anyway: By thinking of more of a general concept from the SC/Csound realm, a control rate is something that is slower than audio rate and it doesn't make sense that it can go higher than audio rate (thus some may consider it "curious"). Simply put, since Pd does not have this kind of paradigm in its structure, control messages have no real boundary and are free to be fired at any rate that your computer can manage and restricted only to bit float limitations. By making it more straightforward, it has no limits, it can go faster than you'll ever need it to until it kills your CPU.
The attached patch lets you see Pd's "control rate" in action. It shows a graph of a wave being chopped at control rate. It won't chop any faster than about 1ms and it's irregular.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2015-03-12 19:36 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
since it was mentioned here, what's the behaviour and deal with [vnsapshot~]? Cause there's no help file for ir yet.
Made a few tests and saw how snapshot~ only outputs the last saple from an audio block, and also how vsnapshot~ can output each audio sample...
thanks
2015-03-12 19:14 GMT-03:00 Charles Z Henry czhenry@gmail.com:
On Thu, Mar 12, 2015 at 5:01 PM, David Medine dmedine@ucsd.edu wrote:
@Charles: None of those five sentences is a misconception. When I said
'DSP
functions' I meant the functions of the form 'whatever_tilde_perform',
not
the dsp tick function. I see how this might lead to a misunderstanding.
Sorry if I was unclear as well. We *are* trying to split hairs here, of course, just to have an accurate description.
It's not *all* of the dsp functions. I thought this was unclear and tried to clarify: rather than scheduling them more often, it actually just loops over the sub-graphs multiple times when the block size is low. There is always a parent function which is being run once every 64 samples (the default).
Also, I see that suseconds_t (which is the type of now.tv_usec) is an integer, as I had previously thought, so I am really perplexed as to how [delay] can apparently deliver bangs within less than 1us. I would love
for
someone to explain this to me. It is a small detail and it doesn't
really
matter in practice, but I am annoyed when my inferences are not correct
--
especially when I send them to the Pd list!
On 3/12/2015 1:58 PM, Charles Z Henry wrote:
On Thu, Mar 12, 2015 at 3:18 PM, David Medine dmedine@ucsd.edu
wrote:
Yeah, of course. Block size 1 and high sampling rate will make the
timing
between control and audio super tight (ChucK does this, for example).
It
will also eat the hell out of your CPU. It's a trade off. This is
because
you start calling all the DSP functions once every 1/192k seconds
instead
of once every 1.45ms.
This last sentence is also a misconception--the dsp tick function is called every 64 samples, as commonly defined.
sys_time_per_dsp_tick = (TIMEUNITPERSECOND) * ((double)sys_schedblocksize) / sys_dacsr;sys_schedblocksize gets set from DEFDACBLKSIZE
So, the dsp_tick gets called, and when there is a sub-patch with [block~ 1], it loops over the graph generated from the sub-patch 64 times.
You'd find this behavior coded with the block prologue and epilogue functions.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Don, 2015-03-12 at 13:18 -0700, David Medine wrote:
Yeah, of course. Block size 1 and high sampling rate will make the timing between control and audio super tight (ChucK does this, for example).
You don't need to reduce the block size to get precise timing. [metro], [delay], [timer], [vline~], [vsnapshot~ ] and probably others work as precise as it can get without adjusting the block size. However, there are many tilde object classes that accept messages and many of those classes evaluate the incoming message only at block boundaries. For instance, you cannot use the precise timing from [metro] to trigger [tabwrite~ ] precisely, since [tabwrite~ ] will only ever start graphing at a block boundary.
Roman
On Thu, Mar 12, 2015 at 4:41 PM, Alexandre Torres Porres porres@gmail.com wrote:
ok, so the metro at 1ms is because I'm using extended.
as for the minimum time pd can process and send data, what's the final word on it?
something like 1.4013e-45 ms?
cause that's a lot more than an audio rate at 44.1khz :)
1.4013e-45 is smaller than 0.0226757....
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here on the thread.
thanks
There's an attempt to explain all this in chapter 3 of Techniques..
http://msp.ucsd.edu/techniques.htm
cheers Miller
On Thu, Mar 12, 2015 at 05:04:17PM +0200, Alexandros Drymonitis wrote:
On Thu, Mar 12, 2015 at 4:41 PM, Alexandre Torres Porres porres@gmail.com wrote:
ok, so the metro at 1ms is because I'm using extended.
as for the minimum time pd can process and send data, what's the final word on it?
something like 1.4013e-45 ms?
cause that's a lot more than an audio rate at 44.1khz :)
1.4013e-45 is smaller than 0.0226757....
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here on the thread.
thanks
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There's an attempt to explain all this in chapter 3 of Technique
awesome, I'm on it ;)
2015-03-12 13:13 GMT-03:00 Miller Puckette msp@ucsd.edu:
There's an attempt to explain all this in chapter 3 of Techniques..
http://msp.ucsd.edu/techniques.htm
cheers Miller
On Thu, Mar 12, 2015 at 05:04:17PM +0200, Alexandros Drymonitis wrote:
On Thu, Mar 12, 2015 at 4:41 PM, Alexandre Torres Porres <
porres@gmail.com>
wrote:
ok, so the metro at 1ms is because I'm using extended.
as for the minimum time pd can process and send data, what's the final word on it?
something like 1.4013e-45 ms?
cause that's a lot more than an audio rate at 44.1khz :)
1.4013e-45 is smaller than 0.0226757....
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here on the
thread.
thanks
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
"cause that's a lot more than an audio rate at 44.1khz :)
1.4013e-45 is smaller than 0.0226757...."
I meant to say a lot SMALLER :) my bad
2015-03-12 12:04 GMT-03:00 Alexandros Drymonitis adrcki@gmail.com:
On Thu, Mar 12, 2015 at 4:41 PM, Alexandre Torres Porres <porres@gmail.com
wrote:
ok, so the metro at 1ms is because I'm using extended.
as for the minimum time pd can process and send data, what's the final word on it?
something like 1.4013e-45 ms?
cause that's a lot more than an audio rate at 44.1khz :)
1.4013e-45 is smaller than 0.0226757....
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here on the thread.
thanks
On Don, 2015-03-12 at 11:41 -0300, Alexandre Torres Porres wrote:
ok, so the metro at 1ms is because I'm using extended.
as for the minimum time pd can process and send data, what's the final word on it?
As I said, for logical time it is the smallest number representable in Pd. In practice, you would never be able to run something that fast for long period (say, 1 second) of time, because your CPU most likely wouldn't be fast enough.
something like 1.4013e-45 ms?
cause that's a lot more than an audio rate at 44.1khz :)
I thought there was a limit control rate that was below the audio rate, but curiously it can go over.
That is what I'm trying to say since - I don't know - at least three posts.
1 sample at 44.1khz gives us 0.0226757 ms, and I was able to send bangs at 1e-06 ms, according to [timer]
check my patch attached, based on the one that was sent here on the thread.
[timer] shows the correct number. However, even that simple patch clogs my CPU when setting it to 1e-06, which actually means 'send a billion bangs per second'.
Roman
-
Alexandre Torres Porres -
Alexandros Drymonitis -
Charles Z Henry -
Cyrille Henry -
David Medine -
IOhannes m zmölnig -
Jonathan Wilkes -
Martin Peach -
Miller Puckette -
Patrice Colet -
Roman Haefeli