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: https://lists.cs.princeton.edu/pipermail/chuck-users/2006-January/000293.htm... 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. Thanks David