[PD] OSC limitations in Vanilla

IOhannes m zmoelnig zmoelnig at iem.at
Mon Apr 19 09:17:17 CEST 2021

On 4/18/21 10:32 PM, IOhannes m zmölnig wrote:
> i checked and double checked the specs but could not find anything about 
> this.
> where do you get the idea that the OSC specs mandate wall clock time?
> OSC-1.0 speaks about "NTP format" (but this is just the structure of the 
> 64 bits data chunk) and "the number of seconds since midnight on January 
> 1, 1900" (but it doesn't say whether this is supposed to be wallclock or 
> idealized)

i just thought that maybe we are really talking about different things here.

so i'd like to clarify what I mean by "logical time".

Pd keeps an track of an internal monotonic value "pd_systime" that is 
incremented whenever time advances within the Pd world.
the incrementation of this value is losely synched to the passing of 
time in the real world ("wall clock time").
"losely" insofar as the increments do not happen at exactly the same 
time, but the maximum difference between the wall clock time and the 
logical time is bound to a somewhat small value (<<1sec).

wall clock time is typically provided by the OS by means of 
gettimeofday() or similar.

while the two times are synched, they have different offsets.
Pd's logical time simply starts whenever the Pd instance started.
however, gettimeofday() counts seconds since the beginning of the epoch 
(currently: 1970-01-01 00:00).

to complicate things, NTP-timestamps (as used by OSC) use their own 
epoch that starts on 1900-01-01 00:00.

using Pd's logical time "as is" as an OSC timestamp, is of course 
useless (unless you are communicating withing the same Pd-instance), as 
all participants need to agree on a common epoch.

so what i'm really suggesting to "fix" the timestamps in [packOSC] is to 
use logical time for *advancing time* (and add some offset to put the 
timestamps into the same calendar as NTP)

so basically:
- when packOSC gets instantiated, determine the offset of the logical 
time with respect to the NTP time.
- when creating a timestamp, use this to calculate the ideal NTP time:

in the actual implementation there's two issue that should be addressed:
- probably the synching of logical time to wall clock time (that is: the 
calculation of the offset) should only be perfomed once for all the 
[packOSC] and [unpackOSC] objects in the running instance, so they are 
all tightly synched.
- make sure to handle epochs correctly (the next unix epoch starts in 
2038; this is still far in the future for many, but for [packOSC] 
birthday is about as far in the past)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210419/c11c22ad/attachment.sig>

More information about the Pd-list mailing list