[PD] logical timing question

[Florian Hollerweger]

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