[OSC_dev] No dumpOSC output in pipe in non-interactive terminal

[Torsten Anders]

Dear Andy,

thanks for your reply. It appears we misunderstood each other. I  
don't want realtime scheduling to be part of the library (nor my  
application for that matter) exactly because of these complexities.  
Instead, I want an application designed to care about timing (like Ps  
or SuperCollider) receive OSC and then care about the scheduling of  
the events it received.

Therefore, I assumed, I need an OSC library which can send  
timestamped bundles (i.e. can generate the NTP timestamps, but does  
not do the scheduling itself). Its seems some OSC libraries (e.g.,  
Pd's orig [dumpOSC] and liblo -- according to its TODO file) can not  
encode/decode these time tags.

What did you actually mean when you said "Full support for  
timestamped bundles isn't really necessary"?

Thank you!

Best
Torsten


On Sep 9, 2007, at 12:11 AM, Andy W. Schmeder wrote:
> On Sep 8, 2007, at 1:10 PM, Torsten Anders wrote:
>> On Sep 8, 2007, at 8:46 PM, Andy W. Schmeder wrote:
>>> "Full" support for timestamped bundles isn't really necessary
>> I want the OSC receiver care about realtime scheduling. Therefore,  
>> I want to tell the OSC receiver that it should execute certain  
>> bundles at some precise time point in future. I assumed that  
>> timestamped bundles are intended for this purpose.
>
> This is one of the originally intended uses for the OSC bundle time- 
> tag, but the actual implementation of a realtime scheduler is  
> beyond the scope of the OSC specification itself and also beyond  
> the scope of a typical OSC encoder/decoder library.
>
> Realtime scheduling is really in the domain of the operating  
> system.  Its not possible to make a library that implements it --  
> at best you can make a wrapper around the appropriate system  
> calls.  A glance at the source code of an application such as PD or  
> the Jack audio daemon should give a feel for the kind of attention  
> to detail that is required.
>
>
>> Why is full support for timestamped bundles not really necessary,  
>> or what other way is there if I don't want to schedule events on  
>> the side of the OSC sender? (I could do it in principle in my  
>> language, but events may be irregularily delayed up to 20 msecs or  
>> more due to the design of its realtime system).
>
> An OSC encoder/decoder library does not have to understand or  
> necessarily be able to manipulate the data that it is passing.  Its  
> main function is to manage the parsing / state machine.  Some OSC  
> libraries go a bit beyond this and get into so-called "dispatching"  
> of the messages (i.e., typically, mapping addresses to function  
> callbacks).  The dispatch feature may be attractive to some but I  
> don't consider that to be essential either, and it certainly isn't  
> the only design pattern that is effective for message handling.
>
>
> ---
>
> Andy W. Schmeder
> andy [at] cnmat.berkeley.edu
> phone:	+1-510-643-9990 x.313
> cell: 	+1-510-717-6653
>
> Programmer/Analyst II
> Center for New Music and Audio Technologies
> University of California at Berkeley
> http://cnmat.berkeley.edu
>
>
>
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/osc_dev

--
Torsten Anders
Interdisciplinary Centre for Computer Music Research
University of Plymouth
http://strasheela.sourceforge.net
http://www.torsten-anders.de