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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
