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