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
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 s
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
>timest
Dear Steve,
thanks for your quick and helpful reply!
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), ev
Stephen Sinclair wrote:
> I suggest you have a look at the OSC objects in the "mrpeach"
> folder, as I think they have better support for timetags among other
> things.
Yes, look at routeOSC-help and packOSC-help to see how it's done. You'll need a
recent version, it's only 6 weeks old...
Martin
So, to answer this post as well as H.C.'s previous query on the topic,
I had a look at the dumpOSC code and indeed it doesn't handle the
timetags.
The only related code is the following:
/* Print the time tag */
#ifdef DEBUG
printf("[ %lx%08l
Dear all,
I am sending OSC messages from the UNIX app sendOSC to Pd using the
Pd object [dumpOSC] -- it worked out of the box, very nice!
However, it seems that [dumpOSC] always reacts immediately --
regardless of any time stamp (16 figure hex number according to OSC
specs). Is it at all po