Big progress.
I found some Processing code that played nice with SL and touchOSC (
http://hexler.net/software/touchosc).
There's a very nice Processing OSC lib by Andreas Schlegel
http://www.sojamo.de/oscP5. The previous link has an example for SL.
With a little tweaking and hacking around I got it running nicely, with some additions to get to load a session or add a loop.
I kept wondering why my Ruby code was failing, even though it *looked* OK and apparently could interact with some other OSC apps and scripts.
The oscP5 example was creating messages by adding in a series of values:
Code: Select all
OscMessage myMessage = new OscMessage("/loop_add");
myMessage.add(2);
myMessage.add(60);
That got me wondering about the Ruby code and how the ruby-osc lib was creating messages.
I was sending messages like this:
Code: Select all
# WRONG!
sl_client.send Message.new("/loop_add 2 56")
That doesn't work, at least not with SL. This is what works:
Code: Select all
# Need to pass separate argument values
sl_client.send Message.new("/loop_add", 2, 56)
Note that the second version is passing three arguments; the Message class takes care of preparing them as a message to be sent. Passing in a single string that simply *looks* like an OSC command results in a message that is (surprise!) a request consisting of a single String item.
I've read other posts on this forum from people with problems that sounded much like mine; they could get SL to quit, but that was about it. The reason, at least in my case, was that "/quit" is a single-argument message. Without multiple values to pass I coincidentally created a message with the proper structure and it worked.
In retrospect this now makes prefect sense; why would the docs indicate different data types for parameters if the message is just a single String? However, with zero prior experience with OSC, and not one to RTFM a whole lot before hand, it's an easy mistake to make. Hopefully this post will help others avoid the same thing. Basically, if you are not getting the results you expect, see exactly how your OSC code is creating the messages being sent to SL, and if it requires them to be constructed in a particular way.
Now on to see if I can drive SL from my Kinect.