This post originated from an RSS feed registered with Ruby Buzz by James Britt. Original Post: Ruby, OSC, and SooperLooper Feed Title: James Britt: Ruby Development Feed URL: http://feeds.feedburner.com/JamesBritt-Home Feed Description: James Britt: Playing with better toys Latest Ruby Buzz Posts Latest Ruby Buzz Posts by James Britt Latest Posts From James Britt: Ruby Development

There’s a terrific audio looping application called SooperLooper:

SooperLooper is a live looping sampler capable of immediate loop recording, overdubbing, multiplying, reversing and more. It allows for multiple simultaneous multi-channel loops limited only by your computer’s available memory.

Among the interesting feaures is an OSC interface. In fact, OSC is how the applications’s GUI comunicates with the SooperLooper engine.

Wanting to drive SL using Ruby I found a Ruby OSC library and started experimenting.

Things seemed pretty straightforward while writing some simple Ruby client/server stuff, but when it came to controlling SL, no good. The only command that had any result was `/quit`.

I did some Googling on this, and found a few posts from people with a similar problem, but with no useful answer.

I thought perhaps there was something quirky in how SL was handling OSC, and looked for some existing SL/OSC code I could look at for clues.

I found some Processing code that played nice with SL and touchOSC.

There’s a very nice Processing OSC lib by Andreas Schlegel; the touchOSC link has an example for SL.

With a little tweaking and playing around I got it running nicely, with some additions to get it to load a session or add a loop.

So I 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:

       OscMessage myMessage = new OscMessage("/loop_add"); 
       myMessage.add(2);
       myMessage.add(60);

That got me thinking about the Ruby code and how the ruby-osc lib was creating messages.

I was sending messages like this:

       # WRONG!
       sl_client.send Message.new("/loop_add  2 56")

That doesn’t work, at least not with SL. This is what works:

       # 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.

In retrospect this now makes prefect sense; why would the SL 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.

There’s a certain “Doh!” aspect to all this I suppose, but maybe 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 (Ruby or otherwise) is creating the messages being sent to SL, and if it requires them to be constructed in a particular way.

Now on to drive SL from my Kinect