[PD] OSC bundles with time tag

[Torsten Anders]

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))));
>                 #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 at 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 at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>>
>
> _______________________________________________
> 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