Thanks for helping to debug it, Torsten ;) I just tried the same sending from packOSC using a WinXP pc and receiving with unpackOSC on a linux box. I get a delay here in Montreal of +4 hours, which corresponds to the difference between EDT and GMT. So it looks like the linux/mac version is adding the timezone offset to the GMT time returned by gettimeofday. The Windows versions of packOSC and unpackOSC use the straight GMT from ftime. The man pages for both ftime and gettimeofday say that the timezone info is deprecated/not there. Now that I'm clear(?) on that I'll fix it in cvs as soon as I can. I'm wondering where you got sendOSC from, since the version in OSCx does the same timezone stuff as packOSC.
Martin Torsten Anders wrote: > Dear Martin, > > thank you very much for your reply. > > >> Did you try sending to and from pd on the the same machine? >> > > I sent timestamped OSC bundles from the UNIX sendOSC app to PD on the > same machine. > > >> Notice that 3.6 million milliseconds is one hour. It may be a >> timezone thing. The OSC spec says that the timestamp format is the >> same as NTP format but it doesn't talk about time zones or >> daylight saving time, so I assumed it means GMT/UTC. >> > > Would be great if things could be solved just by adding and hour :-) > I am currently in the UK and my machine is set to GMT. However, I > will try just adding another 3.6 million milliseconds.. > > Thanks again! > > Best > Torsten > > On Aug 31, 2007, at 4:36 PM, <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> wrote: > >> Torsten Anders wrote: >> >>> Unfortunately, using [unpackOSC] -- just using routeOSC-help.pd -- I >>> was not able to delay the effect of OSC messages either. This >>> helpfile patch shows some delay, but that is always negative >>> (something in the order of -3.5e+06 msecs), even if my OSC bundle >>> timestamp is several seconds (up to a minute) in the future. I >>> meanwhile confirmed that it works in SuperCollider, so my OSC >>> bundles/ >>> timestamps are seemingly fine. >>> >>> Does there perhaps exist a problem with the delay output by >>> unpackOSC? >>> >>> PS: I am using Pd-0.40.3-extended-20070830 for Intel Mac. >>> >> I just tried the same version of pd on an intel mac and I have no >> trouble sending timestamps between pd on the same machine or to >> another one running linux. >> It could be that the timestamp format is wrong somehow, but the >> code was basically lifted from OSC-timetag.c in OSCx, which is the >> same code that sendOSC uses. >> Did you try sending to and from pd on the the same machine? >> The timestamps in packOSC are specified in microseconds relative to >> now, but unpackOSC outputs the delay in milliseconds to be >> compatible with pd's delay. >> Notice that 3.6 million milliseconds is one hour. It may be a >> timezone thing. The OSC spec says that the timestamp format is the >> same as NTP format but it doesn't talk about time zones or >> daylight saving time, so I assumed it means GMT/UTC. >> >> >> Martin >> >> >> >> _______________________________________________ >> PD-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >> listinfo/pd-list >> > > -- > Torsten Anders > Interdisciplinary Centre for Computer Music Research > University of Plymouth > http://strasheela.sourceforge.net > http://www.torsten-anders.de > > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
