[chuck-users] chuck, PD and OSC

[Stephen Sinclair]

> > good to know. probably then some combination of udp for well timed
> > messages (except for multicasting, which also stinks for timing) and
> > tcp for single messages that *have* to get to their destination is
> > the way to go.
>
> The other alternative is time-stamping of some sort of sync signal,
> but that makes some kinds of r/t interactivity more difficult.


I believe the TCP-for-commands, UDP-for-parameters approach is a
pretty good one.

In my experience UDP packets aren't really dropped all that often, but
I often wondered if TCP might be a better approach in general.

Some day I'd like to see a standardized shared-memory approach to
passing OSC messages, which would be insanely fast on a local machine.
 (Though, I believe that local loopback sockets are often implemented
using shared memory, and are thus pretty much just as fast.  Not sure
if this is the case in Linux, I've been meaning to look it up for a
while..)

Keep in mind that if you have several OSC messages that must arrive
simultaneously, you can us bundles, which should be supported in most
implementations.

I believe you can use them in PureData by sending "[" and "]" messages
to the dumpOSC object.
Not sure if Chuck supports them?  In any case they are an under-used
part of the OSC standard.

Steve