[chuck-users] OSC reliability issues

David Michael david.michael at gmail.com
Thu Jan 25 10:28:42 EST 2007

Hi Spencer

> OSC in ChucK, as in most other OSC implementations, uses UDP as its
> transport protocol, which basically means that one's OSC messages
> sent from ChucK are not guaranteed to ever arrive at their
> destination, nor are they guaranteed to arrive in order, nor are they
> guaranteed to arrive only once.  Under heavy load it is very likely
> that the network will drop packets.  Believe it or not this is
> actually desirable for many computer audio applications, as the
> latency overhead of a reliable transport protocol like TCP is often
> too great.

I understood this about UDP in general, but I thought that packets
would be dropped by the ~receiver~ rather than the sender (because of
network congestion, collisions, etc.)

What appears to be happening is that when a Chuck OSC sender is under
load, then it fails to fire off the message. So while UDP delivery is
not guaranteed, and this is generally not a big deal, it seems that
Chuck is getting bogged down somewhere and not actually firing off the
OSC event.

I need to write some simple test cases for this to actually prove that
it is the sender and not the receiver or the network that has the
problem - Ill also take the Ruby OSC out of the equation.

> Could you be a bit more specific about this particular problem,
> possibly providing an example?  It is possible to pipe ChucK's <<<
>  >>> style output to a file or another application--is this what you
> are saying does not work for you?  I think trying to get this working
> would be the best way to go right now.

Yes, this posting talks about that:

I am calling classes from several different files in order, all which
produce console output, and some of which I am interested in capturing
as text (until file i/o comes along), like so:

$ chuck file1 file2 file3 file4 >& output.txt

Since "file 4" is usually my "main()" and does not contain any console
output via the  <<<>>> syntax, the txt file is empty. It seems that a
workaround to this would be to concatenate all the files into one, and
run a much simpler command:

$ chuck all_files_in_one.ck >& output.txt

For sure, I need to do more testing. It is entirely possible that I
have a logical lapse somewhere, especially since my knowledge of
piping is newish. Ultimately I think that you are right, redirecting
the <<<>>> output to a file or application will be the best solution.
Just for informations sake, I would like to get some control data
generated by Chuck into Matlab (I know Chuck can deal with .mat files,
but this is only for audio matrices right??). If anyone on list has
experiences with this, do tell.


More information about the chuck-users mailing list