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 possible that Pd delays the processing of
received OSC messages because of some time tag which lies in the
future? I planned to let Pd do the actual scheduling, because I
figured its timing will be rather reliable...
Thank you!
Best Torsten
-- Torsten Anders Interdisciplinary Centre for Computer Music Research University of Plymouth strasheela.sourceforge.net www.torsten-anders.de
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%08lx\n", ntohl(*((unsigned long *)(buf+8)) ), ntohl(*((unsigned long *)(buf+12)))); #endif
In which the timetag is so nicely ignored completely. Torsten, 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.
I may play around with creating abstractions using mrpeach objects to replace dumpOSC and sendOSC, as it seems this is about due.
Steve
On 8/30/07, Torsten Anders torsten.anders@plymouth.ac.uk wrote:
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 possible that Pd delays the processing of received OSC messages because of some time tag which lies in the future? I planned to let Pd do the actual scheduling, because I figured its timing will be rather reliable...
Thank you!
Best Torsten
-- Torsten Anders Interdisciplinary Centre for Computer Music Research University of Plymouth strasheela.sourceforge.net www.torsten-anders.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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), 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?
Thank you!
Best Torsten
PS: I am using Pd-0.40.3-extended-20070830 for Intel Mac.
On Aug 30, 2007, at 5:53 PM, Stephen Sinclair wrote:
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%08lx\n", ntohl(*((unsigned
long *)(buf+8)) ), ntohl(*((unsigned long *)(buf+12)))); #endifIn which the timetag is so nicely ignored completely. Torsten, 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.
I may play around with creating abstractions using mrpeach objects to replace dumpOSC and sendOSC, as it seems this is about due.
Steve
On 8/30/07, Torsten Anders torsten.anders@plymouth.ac.uk wrote:
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 possible that Pd delays the processing of received OSC messages because of some time tag which lies in the future? I planned to let Pd do the actual scheduling, because I figured its timing will be rather reliable...
Thank you!
Best Torsten
-- Torsten Anders Interdisciplinary Centre for Computer Music Research University of Plymouth strasheela.sourceforge.net 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
-- Torsten Anders Interdisciplinary Centre for Computer Music Research University of Plymouth http://strasheela.sourceforge.net http://www.torsten-anders.de
-
Stephen Sinclair -
Torsten Anders