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