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
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
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
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([
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
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),
