hello list.
i was terribly surprised the way [metro] behaves -
checking it agains [timer] of coruse doesn't give any latency ever!
but with [realtime] and [cputime] - the result is is far from acceptable
and even unproportional, (icresing twice doesn't give any aproximatable
result).
how ever
sorry .. i have realised how wrong was my measuring method.
also Romain (on #dataflow) told me that it's an 'old [metro] discussion'.
but anyhow, could someone please give an opinion on the [block~]
approach ..
___
PD-list@iem.at mailing list
hi ilya
On Tue, 2007-11-20 at 04:52 +, ilya .д wrote:
hello list.
i was terribly surprised the way [metro] behaves -
checking it agains [timer] of coruse doesn't give any latency ever!
[metro] does its job accurately in logical time. it's not accurate, if
a) you have audio dropouts
b)
On Tue, 2007-11-20 at 06:51 +0100, Roman Haefeli wrote:
you forgot the attachment.
i am just a stupid tired whatsoever...
i had a look at it and it is actually quite interesting. it doesn't give
at all the same values that [metro] would give, as i stated in the
previous mail. for easier
On Tue, 2007-11-20 at 07:27 +0100, Roman Haefeli wrote:
1.
2.
5.
10.
21.333
i am actually running pd @ 48kHz, that is why these numbers all are
2^n*1. and not 2^n*1.45 (which would be the value for 44.1kHz)
however, i checked the helpfile of [block~] again and it says,
