SooperLooper Forum

Hi. I'm trying to write a client app for SL that would allow me to load previously saved sessions using OSC.

I have some code that can send and receive OSC mesages, but so far the best I can get from SL is to make the engine quit.

I've read the thread "SL and OSC" (viewtopic.php?f=17&t=3&start=0&st=0) and while it was somewhat helpful I still cannot get SL to respond to my ping.

I'm sending SL a ping message that look like this:
james06 is the machine I'm on. (I tried using localhost and 127.0.0.1 as well, but it made no difference.)

I know I'm reaching SL because if SL is not running I get a connection error. I can also send SL the /quit command, and that works. But I never see a reply from ping. I can hit osc.udp://locahost:9961 with my own code, so I know it is running.

I have to believe there's some odd little thing I'm missing, but I can't figure it out.

How does one debug SL OSC?

If I send a command to load a session, how do I know SL was ale to act on it, and whether there was a problem or not.

I realize that UDP is a "fire and forget" sort of thing, but there must be some way of checking that commands are getting through and doing what you want.

Thanks!

As described on that thread you referenced, the actual ping command only has the return URL and path of your client, like this:
/ping osc.udp://locahost:9961 /pong

Yes, you send that to the 9951 port but you don't include that url in the OSC command. Does that help?

Nope, there is no debugging feedback for OSC use, usually your commands either do something obvious or they cause response OSC messages to be sent.

Thanks, don't know where I got that syntax for the messages, but even changing the syntax doesn't help. I still do not see any ping response.

This is what I'm sending

/ping osc.udp://james06:9961/ /pongo

I can hit that OSC server myself, but it never gets anything from SL. The only reaction I've gotten from SL is making it quit.

Are the server and client on the same machine? If so, just specify localhost as the host.

Everything is on the same machine. I've tried using localhost as well 127.0.01.

I'm going to go back through things methodically and note what I've done, plus I'm looking around for other people's code to see if I can get that to work or at least see what a (presumably) working example looks like.

What platform are you on? The SL GUI itself communicates entirely using the OSC interface, so if it works then at least something is right. It is open source too, of course if you want to look in there. Let me know and I'll tell you where to look.

I'm on Linux; Ubuntu 10.10.

I figured that if SL relies on OSC, and it works, then there's something running there, and they other day it occurred to be to go poke around in the source (though I haven't had time to do so yet).

But I also wonder if there's not something quirky at play, something someone else has run into and figured out.

If you send me the code you are using I can probably find the issue. Feel free to do so off-forum if you like.
jesse@essej.net

OK, I will, thanks,

One question, which might clear something up for me: If I use OSC to load a session, or add a track, or whatever, does the slgui update itself to reflect these changes? In other words does the GUI know when some other app has instructed the engine?

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:
That got me wondering about the Ruby code and how the ruby-osc lib was creating messages.

I was sending messages like this:
That doesn't work, at least not with SL. This is what works:
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.