The uber-hip Monome controller is some of the new hotness to grow out of OpenSoundControl support. Photo: George P. Macklin, aka Granular Matter.

You hear plenty of chatter about the powers of OpenSoundControl, the open, high-res, network-savvy control protocol for music and visuals. But standards are no good without implementation — and some implementations just aren’t very good. Now, users, you can go have a sandwich or whatever, but developers, pay attention. (And users, enjoy that sandwich in the knowledge that someone somewhere is giving you better toys to play with soon!)

Our friend Ray, co-developer of live visual app VDMX, has put up a Cocoa, Mac-based framework for OSC. While it’s all in Objective-C (natch), it wouldn’t be too hard to port a similar framework to other open-source languages and platforms. Ray is working on a kind of best-practices OSC implementation. Worth a peek — and if you’re a Cocoa dev, of course, even better.

Described thusly:

VVOSC is an Objective-c framework for assembling, sending, and receiving OSC (Open Sound Control) messages on OS X. A
simple sample application which sends and receives OSC messages is also included.

more information on OSC:
http://opensoundcontrol.org/

VVOSC is licensed under a Creative Commons Attribution-Noncommercial-Share Alike license:

http://creativecommons.org/licenses/by-nc-sa/3.0/us/

vvosc [Code+Examples]

Cocoa fans, they’ve also whipped up an Objective-C framework for MIDI:

VMIDI is an Objective-c framework which simplifies working with MIDI in OS X. A sample application capable of sending and receiving MIDI built from the framework is included.

vvmidi

(Insert here: “Daddy? Tell me more stories about MIDI and how you used to use values from 0 to 127 back in the day!”)

“vvosc” is likely to cause confusion with the Windows-only vvvv — which is also visual, also wonderful, and also supports OSC — but hopefully you can sort that out.

Now that I have your attention, developers, I’m curious: got questions about OSC? Challenges with implementation on different operating systems and in different frameworks? What are the best implementations you’ve seen in common environments like C++, Java, and Python?

  • Andrew Turley

    I've done some development work with OSC under Python and Java/Groovy/Jython.

    For Python I've used simpleOSC (http://www.ixi-software.net/content/body_backyard_osc.html). I had to make a few modifications to get it to work. I'm not sure if it's actually broken or if it just wasn't working on my Mac or with my version of Python. SimpleOSC has some shortcomings. The biggest one for me is that it is set up to only work with one incoming connection. Well, you can abuse it and use more than one, but they won't get closed properly when your program exits. In my case, I was trying to use two iPhones running touchOSC as input devices and I needed a way to tell which phone was sending the message. I ended up punting, using Pure Data to handle the incoming messages from the phones on different ports and then sending slightly different messages with phone identifiers to the application on a single port.

    I just started using javaosc (http://www.illposed.com/software/javaosc.html) for another project. Right now I've only tried sending messages, but after looking at the documentation it looks like it would be pretty easy to add multiple listeners.

  • ninjabong

    There's already OSCulator which works very good for tying any of the various iPhone OSC (like Mrmr & OSCemote) apps to software on the host mac, and not just MIDI remapping but keyboard/key-combos as well.

  • http://bioticaudio.com samBiotic

    simpleOSC in python from ixi software

  • Falk Koziol

    Thanks for the simpleOSC link!

    But we still need full implementations driver- & softwareside for all platforms. Especially Window$ users are screwed.

    Back in the day…when your parents used 31.25 kBaud and to much controller-data killed the clock :-(

  • http://www.postlude.co.uk/blog Jamie Bullock

    What's wrong with liblo? It's a portable, fast, simple implementation written in C with Perl and Python bindings. I've used it on OS X, Linux and Windows XP, and it's licensed under the GPL, so doesn't have the 'non-commercial' restriction of VVOSC.

    What problems does VVOSC seek to address that aren't already solved in liblo?

  • http://ruinwesen.com wesen

    actually lots of controller data won't kill the midi clock, except if a device fucks it up. clock message hav epriority over anything, and can interrupt sysex and any kind of messages. sadly not all implementations handle that.

  • http://www.createdigitalmusic.com Peter Kirn

    @Falk, why are Windows users "screwed"? Aside from the occasional niceness of Osculator or something… these libraries are really not PC-suited, but that doesn't mean there aren't plenty of alternatives.

    And yes, I agree with others that a cross-platform library is more ideal. That said, I know Ray and David built this for their own needs, so presumably there was some reason they wanted it — and might likewise be some things to learn from poking around what they did. :)

    Curious what people are doing in Processing-land, speaking of Java. javaosc looks quite nice (unnecessary GUIs aside). Then there's a Processing-specific library:

    http://www.sojamo.de/libraries/oscP5/

    … again, looks nice, and I've used it a couple of times. Thoughts?

  • Andrew Turley

    @Peter Kirn, I'm not sure what you mean about "unnecessary GUIs". You don't have to have a GUI set up to use the library. Now, if you mean that Java GUIs can be pretty ugly if you aren't careful, then yes, you are correct. That said, combining Groovy's Swingbuilder and javaosc gives me a good way to quickly prototype ideas that require a GUI.

    I've used oscP5. I thought it worked pretty will within the framework of Processing, giving you a nice event hook for receiving messages. But it does bring up one of my major problems with Processing, which is that it requires the user to understand too much about the underlying implementation and associated data structures. Take a look at the OSCMessage sample and look at how much code is spent in type bookkeeping.

  • http://www.createdigitalmusic.com Peter Kirn

    @Andrew: okay, fair enough.

    Yeah, oscP5 definitely *works*, but really — and this is true of the MIDI libraries, too — if you wanted to keep with the aesthetic of Processing core, you'd use higher-level messages. I'm not sure why that's a problem with Processing; to me, it's a problem with the library. Having to follow the constructor with individual add statements and then send … I mean, that's craziness. :) There has to be a way to streamline that a bit more.

    I'll have a go at a bit more of this stuff. I think it'd also be fantastic to add Bonjour-style auto-discovery in Processing… at least for talking to other Processing apps. :)

  • Andrew Turley

    @Peter Kim: I agree that oscP5 could be more in the spirit of Processing by working with some higher level messages. The beef I'm getting at with Processing is that it is firmly based on Java (my mental model of Processing is that it is a preprocessor for Java code), and Java forces the user to be overly verbose for certain things. I think the OSC message system in javaosc is more like what you want, and yet because it uses Java the code is still very verbose. Compare these two code snippets:

    Python with simpleOSC:

    <code>

    import osc

    osc.init()

    osc.sendMsg("/test", [123, 12.34, 'burger', "127.0.0.1", 9055)

    </code>

    Java (or Processing) with javaOSC:

    <code>

    OSCPort sender = new OSCPort();

    Object args[] = new Object[3];

    args[0] = new Integer(12);

    args[2] = new Double(12.34);

    args[1] = "burger";

    OSCMessage msg = new OSCMessage("/sayhello", args);

    sender.send(msg);

    </code>

    Don't get me wrong, I still think Processing is pretty cool, I just feel like it might be a little easier to use if the syntax had been based on something like Python or Groovy. That might have also made it easier to set up a REPL workflow.

    Sorry, this message turned into a Processing critique.

    Yes, bonjour-style auto-discovery would be awesome. Combining that with an OSC program on the iPhone would let you do some pretty amazing interactive applications.

  • http://www.createdigitalmusic.com Peter Kirn

    Okay, I see what you're saying. And this is fair — it's just really a Java critique more than a Processing critique. (In fact, part of the impetus for Processing I'm sure is that Ben and Casey would agree with you. Java was chosen as a platform that suited their desired outcome, not because they preferred verbose syntax … if they did, they would have just used Java and never created Processing.)

    Although, just to be clear — the import statement aside, right, there's no reason you couldn't write a QuickOSC library that did exactly what that Python example at top does, right?

    I mean, Processing itself as you know is not terribly verbose. So this isn't really about languages or platforms, either, it's more about style. I think some of the *style* of Java gets, well, just ridiculous at some point — some of that because of the language, absolutely, but some of it just the culture around the way the language is used. So that's not to take away from what Python does, which is very impressive.

    But, am I missing something? Is there any reason you couldn't make a library that does what your Python example does at top — and in the process is much closer *stylistically* to Processing's core (particularly the drawing functions)?

  • TJ

    Would vvosc and SIMBL make a monome+ultrabeat marriage possible?

  • Andrew Turley

    OK, ultimately what I'm talking about is a Java issue. But in Java it kind of makes sense, because forcing you to declare types makes it run more quickly than it might if it was a more dynamic language. Speed is important in Processing, but I would have thought that they would have been willing to sacrifice a little speed in order to get a system that didn't require you to spend time thinking about datatypes. But I took a look at the Processing FAQ and apparently they wanted the speed and thought it was a reasonable trade off. Given the success of Processing, I don't know that I'm in a very good position to argue against their decision.

    You could write a Processing library for OSC that had an interface that was more or less the same as the interface for simpleOSC. But to pass a list of values to be included in the message, Java/Processing would still force you to jump though the hoops associated with creating an array in Java. In my examples I tried to show that there is a large overhead involved in doing that. By contrast, scripting languages like Python, Groovy, and Ruby (and languages like Lisp and Scheme and Scala and Haskell and . . .) give you an easy syntax for creating lists and dictionaries. The importance of this cannot be overlooked. Many programming problems can be solved (or at least a prototype solution can be found) using lists and dictionaries. The easier it is to work with these structures, the easier it is to implement new ideas quickly.

    Now, as far as making things more like the drawing functions, I think you may be on to something here, if by "like the drawing functions" you mean "don't make me create a bunch of objects just to do something cool". You could have something like this:

    <code>

    import org.blah.quickosc.QuickOSC;

    Object args[] = new Object[3];

    args[0] = new Integer(12);

    args[2] = new Double(12.34);

    args[1] = “burger”;

    QuickOSC.send("/test", args, "127.0.0.1", 9055);

    </code>

    And you could make "send" polymorphic so that you could pass in a list instead of an array if you wanted. Then your Processing code looks like this:

    <code>

    import org.blah.quickosc.QuickOSC;

    LinkedList args = new LinkedList();

    args.add(new Integer(12));

    args.add(new Double(12.34));

    args.add(“burger”);

    QuickOSC.send("/test", args, "127.0.0.1", 9055);

    </code>

    Sadly, as you can see, you still end up adding elements to the message one at a time. But now using the same library your Groovy code (and your Jython code) looks like this:

    <code>

    import org.blah.quickosc.QuickOSC

    QuickOSC.send("/test", [12, 12.34, "burger"], "127.0.0.1", 9055)

    </code>

    So in this case, I think we have an interface that is more in line with the Processing style (give people an easy way to do something), but because Processing's syntax is based on Java's you still have to go through the process of creating list of arguments.

    By the way, here are some links for using Processing with Scala and Jython. I guess at some point it's a question of which tradeoffs people want to make.

  • http://www.createdigitalmusic.com Peter Kirn

    @TJ: best bet there is to just translate OSC to MIDI, I'm afraid. And, anyway, you should get a fair number of MIDI assignments in Ultrabeat, I think.

    @Andrew: Brilliant Scala, Jython links… the Scala one I could see being particularly useful. And you got me exactly right, I think the idea would be to send without all of this object creation … without so many lines of code, basically.

    I like the direction you're going — and yes, see the point as far as Java syntax, though I wonder if people aren't sending messages that in practice aren't a bit more predictable (ie, they know what sort of thing they're doing in advance and can build a simple library that automates some of this process). May have to have a think on this one.

  • TJ

    @Peter Kim: i was talking about step input and representation of the grid though. MIDI will not accomplish that, unfortunately.

  • Andrew Turley

    @Peter Kirn: Well, you could always do something like this:

    <code>

    class QuickOSC {

    static void send(String addr, String inetAddr, int port) { … }

    static void send(String addr, Object msg1, String inetAddr, int port) { … }

    static void send(String addr, Object msg1, Object msg2, String inetAddr, int port) { … }

    static void send(String addr, Object msg1, Object msg2, Object msg3, String inetAddr, int port) { … }

    static void send(String addr, Object msg1, Object msg2, Object msg3, Object msg4, String inetAddr, int port) { … }

    static void send(String addr, Object[] msg, String inetAddr, int port) { … }

    static void send(String addr, List msg, String inetAddr, int port) { … }

    }

    </code>

    That way you have an API for messages with 0-4 parts, along with interfaces for arbitrary numbers of parts. In Java 1.5 you could just use varargs like this:

    <code>

    class QuickOSC {

    static void send(String addr, String inetAddr, int port, Object… arguments) { … }

    }

    </code>

    But Processing and Java 1.5 still aren't friends.

    True enough, people could build their own libraries. But I read an article a while back talking about how sometimes it's best to provide people with something that handles simple cases well right out of the box. You want someone to have an idea and be able to run with it pretty quickly using your library or language or whatever. I think that's especially true for people who may not be "serious" programmers and just want to be able to throw in a line or two of code to get something to work.

  • http://www.createdigitalmusic.com Peter Kirn

    Yeah, I see what you mean … and that's an excellent illustration of why varargs might be nice. (may give this a go for my non-Processing OSC projects)

    Here's the current status as near as I can tell:

    "# Starting in release 0136, Java 1.5 is required to run the Processing Development Environment and projects created with Processing.

    # It is not yet possible to use any of the new syntax introduced in Java 1.5 within Processing, even if you have 1.5 installed (the preprocessor and compiler used by Processing don't understand the 1.5 syntax). This includes the enhanced "for" loop, templates, generics, enums, varargs, and lots of other crap that Sun added because they felt that the older syntax was too simple and usable. A couple of these features are very useful (the for loop, some aspects of generics) so if you would like to help get things running with 1.5 syntax, please help us fix things. More information cane be found here. "

    Bug report here:
    http://dev.processing.org/bugs/show_bug.cgi?id=59

    And here's what they say about it:

    "The grammar is called pde.g, and is an extension of the java.g grammar

    found in app/antlr/java. Anyone who has the chops to update the java.g

    grammar from 1.3 to 1.5 would be greatly appreciated. In addition then, the

    grammar for pde.g needs to be updated to make sure it still works.

    This is a time consuming/mind-bending process, and has been put off since

    the new Java syntax features are not a priority, and using

    ArrayList<Integer> is way slower than just dealing with an int array… and

    speed is important for interactive graphics."

    – actually, I was unaware of that; ArrayList is slower than arrays? (And what are they talking about, exactly, given that you can use ArrayLists in Processing and it isn't a syntax issue in the same way?)

    Anyway, yes … varargs. Sounds like a good idea.

    I agree about libraries, but I think something like adding those bunch o' methods to a QuickOSC class wouldn't be a bad idea. At least it saves trouble in future; that was exactly what I was proposing.

    And maybe at this point, Andrew, you and I should continue offline. :)

  • http://bioticaudio.com samBiotic

    i made this ages ago with processing.

    this thread has inspired me to upload it.

    http://bioticaudio.com/roseosc/

    a kind of 3d didital flower that responds to 7 variables.

    i've omitted the source as it's kind of embarrasing being a bodged effort way back in 2003 before the oscP5 implementation was released. Really it was just osc wrapped around an example sketch.

    even so, i could still see the some potential as a vis/ui platform back then.

    new pd test patch to go with though.

  • Andrew Turley

    For the record, I was wrong about Processing's relationship to Java 1.5. It looks like it should play nice with external libraries written in Java 1.5, you just can't use Java 1.5 syntax in Processing code. So I think libraries can use varargs. I just wanted to clear that up.

  • http://www.createdigitalmusic.com Peter Kirn

    @Andrew: ah, that's great. Yeah, I was confused about that … I thought based on that readme that the preprocessor would get confused if you tried to include some of that syntax in a library…. so, great. Time to go practice my varargs chops.

    @samBiotic: cool, will check that out! I'm proud of my embarrassing code, myself. ;)

  • http://bioticaudio.com samBiotic

    @peter kim hopefuly you'll never find out my dark past!

  • http://bioticaudio.com samBiotic

    +r

  • http://davebv.es davebv

    this framework is amazin, I am currently including it in my MusicController wiimote app:
    http://code.google.com/p/musiccontroller (Still in the SVN, the code is not finished yet)

  • http://www.steim.nl JC Reus

    There's also the excellent cross-platform C++ library OSCPack.

    Found here:
    http://www.audiomulch.com/~rossb/code/oscpack/

  • http://www.steim.nl JC Reus

    I've been mucking around with VVOSC and am curious.. does anybody know if an implementation of the Blob datatype is in the works?

    For the project I'm working on we absolutely must have blobs. I'd use oscpack (or possibly liblo, but I haven't read up enough on that library yet) … the only "problem" is that I really love the zero-conf networking neatures of VVOSC.

    Couldn't find Ray Cutler's email anywhere in the library or on Google Code. Any clues comrades?