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, martin.peach@sympatico.ca
martin.peach@sympatico.ca 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