Hi Peter/Roman/Frank, hi list,
Thanks for the lively discussion and your insightful contributions.
Peter Plessas wrote:
So realtime is dependent on the audio clock? I always thought that it took the cputime/OS time...
[realtime] takes the system time as measured by the OS.
(For clarity, I would not call it "CPU time", since that "is the amount of time a computer program uses in processing central processing unit (CPU) instructions, as opposed for example to waiting for input/output operations" (Wikipedia), as measured by [cputime] in Pd in order to derive the current CPU load in Pd's load meter, for example.)
For example, when you reset the clock using the Unix 'date' command during an ongoing [realtime] measurement, that change will affect the measurement's result.
So in my understanding, [realtime] does _not_ depend on the audio clock (or audio driver); it gives accurate values also for measurements of [metro 2], etc. It's the actual timing of [metro] which gets messed up. Or am I getting your question wrong here?
I understand that logical time in timer is the internal "perfect" representation of pd's time.
That's my understanding as well. [timer] represents the ideal "score" derived from all timed objects ([del], [metro], etc.). It's what Pd 'aims for'.
i never understood, why [timer] is giving different values from the ones that you expected, when connected to a [bang~] inside a re-blocked subpatch. would be cool to have that either explained or declared as a bug.
Sorry, Roman - could you clarify which blocksizes you are talking about? What Peter and I have observed is that block sizes < 64 give the same [timer] results as a block size of 64, so there seems to be a lower limit. I am not sure though whether you are you talking about the same phenomenon?
best, flo.H