day 5 wrote:
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be rethought.
why not just implement a wrapper to liblo ?
Well because liblo is some other library that will probably cause trouble down the road when it changes into something incompatible with its current implementation, the way e.g. python causes problems when some apps want 2.3 and others insist on 2.4.
i find this OSC library to be both robust and efficient for several queues open on several machines.
dealing with the creation / performance of installation art spread across multiple computers, i'm biased towards Csound for my work as it presently uses liblo as it's OSC implementation.
I was thinking that pd offers a lot of flexibility and responsiveness for the user interface side of things, while csound is really good at generating sound, so it would be better to use OSC, MIDI, mouse, etc. as inputs to a pd patch which would control csound via a [csoundapi~] object. (I suppose you could just use OSC between pd and csound as well and skip the [csoundapi~]) Currently pd's OSC objects work fine, for me at least ;). Adding nested bundles just adds to the latency, and timetags in absolute time are not very useful except for archiving. For synchronization it's not hard to simply add integer timestamp arguments to an OSC message. The neat thing about OSC is that you're free to make up your own messages.
Martin