[PD] OSC bundles with time tag

[Martin Peach]

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 at sympatico.ca>  
> <martin.peach at 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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>