Connecting stuff is one of the things musicians naturally do with gear. So, there’s really no reason that musical gear shouldn’t network as easily as Web servers. And yet a basic protocol, built largely on existing standards, meets with responses like this:

“We’ll support OSC when there’s hardware out there.” “Name one piece of hardware that supports OSC other than the Lemur.”

OSC has some major advantages as a network protocol, as a way of connecting software with software, software with hardware, and yes, even hardware with hardware. It doesn’t have to “compete” with MIDI – you can even send MIDI message data over OSC, thus taking advantage of features OSC has that MIDI doesn’t (like time stamps, which your tools could use to calculate latency even if you don’t use them directly). Yet I’ve been listening to this argument for years now. “Any computer” counts as an OSC device, but even when tens of millions of iPhones and iPod touch devices hit the market (not to mention other mobiles), software developers were still pointing to a (completely absurd) “lack of hardware.” How tens of millions of gadgets can count as “nothing,” I don’t know, but maybe it’s because a lot of them were phones, not music devices.

Well, here’s a combination that ought to get someone’s attention. With the iPad about to launch next month – likely to be followed by more multitouch devices running Android, Linux, and Windows – we’re not just talking phones any more. And the folks at Symbolic Sound, makers of the insanely-powerful sound generation Kyma environment, are adding a proper OSC implementation. Even if you have no interest in the (wonderful) Kyma, now available in more-affordable Paca(rana) devices, this is one to watch.

What you can do:

Use OSC directly, via a direct connection and even onboard Ethernet on the Paca(rana). That opens up the use of devices like Lemur, and, yes, iPad.

Use MIDI over OSC from your existing MIDI devices and software. Explanation (again, worth reading even if you aren’t in the market for a Kyma):

In this case, the OSC connection acts as a virtual MIDI devices, with three merged inputs and one output. The same is possible on other devices, too, however, meaning that combining OSC and MIDI doesn’t have to be a chore.

Details on the software update:

OSC-enabled Kyma X.74 is a free software update for registered Kyma X owners. OSC communication requires the Paca or Pacarana sound engine. Kyma X.74 also comes with additional features, including an 11-times speedup in the Virtual Control Surface, support for the MOTU Ultra Lite Hybrid mk3, TC Electronic Impact Twin, and Prism Audio Orpheus converters, track-pad compatible menus, refinements to the Tau resynthesis, and more.

Open Sound Control (OSC) for Kyma: Bidirectional communication between Kyma, iPad, Lemur, and other OSC-enabled devices & software

And if you’re using Max and Max for Live, you can use a custom external for MIDI over OSC in that environment, as well. (That said, control of Live could be more intuitive if Ableton were to evaluate native OSC control support in Live, as currently exists in nearly all mainstream live visual applications. There’s an unofficial method that demonstrates just how powerful this can be — see comments.)

Max and Kyma

Kyma is still a high-end solution, but at least the entry-level Paca – still absurdly powerful – is now down below US$3000. If I had $3 grand handy, I’d certainly consider buying one. I don’t, so I think of it as that Steinway grand I can’t afford or fit in my apartment. That doesn’t mean I can’t pay attention to what it does – and, indeed, OSC implementation like this could apply as well to a $5 or open source app, to mainstream hardware or DIY solutions, as much as the Kyma.

The phrase is overused in the media and culture today, but I think it’s appropriate here:
“Just sayin’.”

Thanks to Lowell Pickett, Martin Wheeler, and others who sent this in.

  • ST8

    You can access ableton live using OSC without max for live using the updated LiveOSC remote scripts which work on Live 8 on both mac and windows:

    I do need to update (or even add!) installation instructions though.

    I've being trying to get the official LiveAPI websites/code hubs to link to the updated version, not quite got there yet πŸ™‚

  • bar|none

    I have Kyma and a pacarana and yes it's a very deep and satisfying system. The real story here is OSC and it is making inroads. You didn't mention OSC Bonjour but this little gem allows OSC devices to find and configure themselves on the network which makes OSC connections much easier to work with. The pacarana advertises itself using bonjour. Recently the monome community as well has gained an autoconfiguration protocol based on OSC Bonjour detailed here.….

    Just this weekend I wrote a patch for the Snyderphonics Manta that automatically finds the pacarana via OSC Bonjour and connects automatically, being able to control notes as well as any sound parameters on the pacarana.

    So the point of this is that the time has come for OSC devices. No more excuses. All devices should be on your network the way it should be.

  • Bonjour — yep. And Bonjour, in turn, is just Zeroconf — a network standard. Part of the genius of what's happening with OSC is that a lot of it is simply about supporting standards already out there.

  • Jim Aikin

    It would be a wonderful thing to see OSC spread through the music industry. I would quarrel only with your lead sentence, Peter — connecting stuff isn't what musicians do. Playing music is what musicians do.

    Tonight I'll be at a symphony rehearsal. Great players, exciting repertoire. The only stuff that will be connected will be the lights clipped to the music stands.

  • Edited the opening sentence, Jim. I wasn't really suggesting the connection is the point, merely that it is a natural step.

    Also, there is more need to make connections with digital gear than with acoustic instruments – period. The natural flanging and acoustic cancellation you get with instruments played entirely by humans is very different than what happens if, say, two digitally-clocked delays drift. That's just one example. I think you have to make the digital gear connect in order to allow the humans to do their thing.

  • jln

    I must add to this that I can't wait to see how the work done with CopperLan goes. It looks really promising to say the least.

  • micah

    This is great news. Downloading X.74 now and will try it out with the M4L external. Surprised SS didn't inform us yet.

  • This may be old news, and off topic, but Audio Midi app provides for MIDI over TCI/IP via it's own internal protocol. Also, in xCode, there are NetSend and NetReceive AUs that allow inter-computer sending of information. Latency, as always, is an issue…

  • Yes, you can transmit MIDI over Ethernet – there are even some non-Apple tools. It works for simple tasks (I was just documenting how to do that in the Mac thing) However, there isn't a standard way of connecting, and it's not timestamped as OSC is.

  • Slightly off topic… I've had success transmitting midi timecode over ethernet connecting two macbooks with ableton slaving to the timecode on both machines. Works like a dream! Perfect sync. The weak point becomes the ethernet cable..they can be a bit fussy.

  • Right, so I should qualify, as well — simply being able to do MIDI over OSC is not in and of itself an advantage, nor is the fact that you can transmit OSC over Ethernet (because you can do that with MIDI). It's really a matter of being able to use the time stamping in less-ideal situations, (MIDI messages themselves are not timestamped), and the ability to have the open-ended messaging possible in OSC.

    This probably deserves a full article rather than a comment, however. πŸ™‚

  • I should note, the timecode transmission I mentioned above is generated from Audiofile Engineering's Backline. And given that it's timecode, it is time stamped. One machine can even come out, restart ableton, and jump right back in sync to the same measure. πŸ™‚

  • Sorry, yes, correct. The difference with OSC is that all messages have time stamping. If you're running most MIDI messages or MIDI clock, those do not. But yes, the Backline case is sending time-stamped MIDI messages.

  • Jim Aikin

    Thanks for the clarification, Peter. I knew you knew that, and I agree with your basic point.

    There was also a sort of meta-critique lurking within my previous comment, though. I do think that musicians who use electronics sometimes get so into the gear that they forget about the goal, which is to make great music!

    It don't mean a thing if it ain't got that swing. Or, to put it another way, "Those instances of it which lack the quality referred to as 'swing' are meaningless."

  • Right, Jim, but on the other hand, there were people centuries ago whose specialty it was carving pretty faces to go on the tops of gambas. Maybe those discussions don't have to be related all the time.

  • bar|none

    Regarding timestamping…my experience is that most OSC endpoints ignore the timestamps because dealing with them is problematic. Kyma for instance ignores them, so does the Lemur. So I'm not really sure the advantage beyond debugging latency issues. One of the exciting things about sending per note data over OSC for me is to get beyond things like global pitch bend and 127 levels for other controls, global channel pressure etc. These limitations are really frustrating especially with the resolution and expressiveness of next gen controllers these days.

  • I think there's some potential for timestamping, but this is correct; currently, there's no immediate advantage. You do have the advantage of a single networking protocol, though, in that an OSC connection can send both OSC + MIDI data, *and* you have the advantages of being able to send all that OSC goodness. So, um, yeah, separate article.

  • Peter I agree with the way you have propositioned OSC in this article. It seems all to often that people dismiss OSC with the typical refutations when they view it as a MIDI or OSC debate. OSC in a way like USB.. no one says "ohh hell no why would I want to stream midi over usb". I think many people have a vested interest in MIDI and assume that OSC is a threat to their knowledge /marketplace when in fact OSC can be seen as an enhancing technology.

  • Mudo

    Well… articles like this and backlinks maybe change the world, uh?


  • teej

    Personally, I am keen to see OSC penetration happen. That said, one of the first sentences in this article gives me pause:

    "…So, there’s really no reason that musical gear shouldn’t network as easily as Web servers."

    The problem is that there are still a massive amount of musicians who wouldn't consider web servers as something easy to manage, and subsequently, would likely be pretty intimidated tinkering with OSC.

    A decent understanding of "IP addresses, Ports, hostnames" are but a few of terms involved with even the most basic OSC configuration. Not to mention the syntax. The audience of musicians interested (not capable, but interested) in dealing with any of that is relatively low when compared to the number of musicians who have musical ideas in there heads that they want to simply get into their ears.

    Way I see it, there are a few camps out there who make up the potential OSC adopters. These are obviously generalizations but:

    – The people who live for this stuff. Coding, tinkering, building. The Max/MSP, Plogue, Lemur, Processing, monome people of the world.

    – "Purist" musicians. They want to play instruments and make music. Period. The people who are the reason Yamaha, Roland and Korg still sell plenty of hardware workstations. Hardcore Reason-only users probably live here as well.

    – The "recognizers". People who are more focused on pure music making but keep a finger on the technology pulse and see benefits of things like OSC. Not willing to make a hobby out of code, but willing to learn enough to get it up and running initially to then add value to their processes.

    In a circle graph, that last group represents the overlap between all three camps. But that group isn't the likely party which drives a platform forward with focused development. Making music at all these days without a computer involved in some way or another is virtually non-existent. Whether that means figuring out how to "set up your myspace" or building a custom spectral synthesizer in Max for Live.

    The gap is obviously shrinking. But for real mass-adoption of anything it has to be, above all else, easy. Really easy. Really super easy. Hell, there are a bazillion computer musicians who have no grasp on using features of the basic MIDI protocol. Not because they can't, because they'd rather hit record and play notes on their keyboard than figure out how to send 1's and 0's from what is supposed to be a musical instrument. And they are having a satisfying blast making their music.

    Right now I think incorporating OSC and making music, for the end-user, still require two very different hemispheres of the brain to enjoy. I don't think everyone is interested in using both of them. For a lot of folks music is a creative escape from their daily grind of having to use that other side of their brain.

    Again, it just needs to become really super easy. It's already better than MIDI. Now it just needs to become easier than MIDI. That's what will drive mass adoption.

  • Ken

    I've been using OSC through Touch OSC and Ableton Live for almost a year now. While its a pain to set up, and isn't necessarily reliable on a windows machine, its been working GREAT with my mac, and does NOT give me issues when trying to reconnect and get things back in order (thanks to OSCulator) If windows had such easy support with it, I guarantee it would be much more popular. The need to use puredata or max can be intimidating for some, and if it was easier, ANY itouch user that is also an ableton user could benefit from being able to make your own knobs, faders, and other multitouch layouts.

    Also, the ipad can scale ipod/iphone applications to its screen size, so are things like TouchOSC going to be scaleable? or will Hexler need to release a new version of the code to create 10" layouts?

    As long as it works, sign me up. I dont need to spend $2000 on a lemur, when I could get something very very similar for $500!


    Looks like they're already on it…

  • Swami Digital

    I think in audio old crappy standards tend to hang on for way to long, because the mainstream in audio is afraid to innovate. OSC just makes so much sense, it's really ridiculous that we haven't jumped on this bandwagon sooner.

  • golden master

    I like the idea of OSC, but my experiences with it involved a lot of head-scratching. MIDI was confusing for me the first time i used it too, I guess, many years ago :). OSC will be great when there is a standardized implementation of it across the industry, and you don't have to be fiddling with your software forever to figure out what kind of messages you're looking for or should be sending. For now it seems stuck in the realm of the nerds… but looking forward to when it's matured.

  • Peter, don't you mean "my" networked future? If there is a iPad in my future I better keep working at living in the presence.

  • poopoo

    MIDI is successful because it works like an audio cable. Plug one end into an output and the other end into an input and away you go. Right from the start it worked with no configuration when connecting different manufacturers equipment.

    I think what is needed is a 32bit or 64 bit 'midi' implementation over OSC. Take standard midi definitions, extend all the data fields to 32bits. Now you have a midi system but with 4 billion possible pitch vales, 4 billion channels, 4 billion continuous controllers etc.

    Then you encapsulate those bigger midi messages in a stardardised OSC address space using a prefix like a device name and a device id.

    With this system, any device could pattern match on OSC addresse's and work in a standard way without excessive configuration. Mostly you need match the controller and channel numbers around if you have a lot of devices.

  • jg

    Wait a minute, Pete. Not all OSC messages have a timestamp. They have a timestamp only if you put them into something called a "bundle".

    Also note that OSC's "MIDI wrapper" doesn't support System Exclusive messages.

    But the real problem with OSC is that it's just a way to pack data. Unlike with MIDI, there is no standard set of "OSC messages". For example, one product could use an OSC Path of "/Note On" to trigger a note, followed by a note number (as an 8-bit value), and a duration in milliseconds. Another product may instead use a path of "/Sound", followed by a frequency in hertz (as a double), and a duration in microseconds to trigger a note. And a third product may do use an entirely different message. There's no standard message set. And having dealt with the people on the OSC mail list, I doubt there ever will be a standard message set. Most of them appear to be either professors who use OSC for weird research projects that will never see light of day in the marketplace, or people who only script for Max and therefore aren't all that familiar with what the majority of musicians (who buy retail gear) want and need.

    Someone else once said "OSC is a standard that doesn't do anything by itself", and that's quite true. It's a way to pack data for tranmission over a network, but it doesn't define any set of messages for any specific purposes. Everyone using OSC has to come up with his own proprietary messages for whatever purpose he deems. You can't have a "standard" if everyone is using this data-packing scheme in entirely different ways.

    And that's what has held OSC back all these years.

    On the other hand, RTP MIDI does have a standard set of messages, which just happens to be the same set as MIDI.

  • Bipolart

    How peoples can say TouchOSC is 'very very' similar to Lemur???

    I guess you didn't watch the previous news…

  • mat

    @jg: agree!

    it is somehow funny that the standardisation of Midi is a restriction on one hand (beneath other limitations) and on the other hands it is what it make easy to use, cause we can "plug and play" and any machine knows that this is a note with a special pitch coming in.

  • kid versus chemical

    @poopoo my thoughts exactly.

    Also, everytime I have used OSC I have gotten confused quickly. Granted, it could just be because I'm a moron, but still, I bet a lot of other people feel the same way.

  • Christian Blomert


    There is applications with very similiar functionality already out for TouchOSC on iPhone / iPod – and there will be adapted versions for the iPad on release date.

    Google for TouchControl & Ableton or go to… πŸ™‚


  • Getting people on board with Midi over OSC would be a way to pull in all the legacy MIDI equipment that needs to interoperate with newer devices (real and software) and information transports. But MIDI has never really been about music, its mostly been about button presses.

    That prejudices the kind of music that can be described by MIDI.

    Nevertheless it was exciting when MIDI was invented, because it was the first time different Synth companies cooperated enough to allow standardized interoperation. There were lots of incompatible proprietary standards prior to MIDI, analog as well as digital. But MIDI was also designed to be cheap to implement, and back in 1982, there wasn't much power in the required serial chips. That put a cramp on the speed and resolution of a MIDI stream.

    OSC, because it's a system of tagging signals, lets you operate at a higher level than that.

    The missing link in OSC is a syntax for self description. combines with Bonjour/Zeroconf, and devices will be able to discover and configure themselves in a dynamic manner.

    The iPad and other larger multitouch surfaces are exciting for musical purposes, but even with fast processors, I suspect latency will still be a major issue. But if you keep it simple, something rewarding will happen, I'm sure.

  • @jg: Sorry, correct, I should have said "bundle" there. But it's still correct to say that, generally, timestamped messages are an essential feature of OSC and not MIDI, even if you can send OSC messages without them and certain specialized MIDI messages with them.

    However, let's see how MIDI "standardization" is doing — that "plug and play" format.

    Note on and note off do indeed do what's expected.

    Pitch along with note data is probably the most standardized. And you always get exactly what you expect. Erm, unless a device puts middle C in a different location. Or the synth has been tranposed. Or you need tuning other than equal temperament. Or an instrument doesn't respond to pitch bend. Or you've changed the pitch bend range.

    And Control Change messages are standardized, too. Why, when you send a modulation message, you can guarantee that something will be … modulated. Somehow. And then you have a fantastic table of Control Change messages, which are implemented via a rigorous standard through which … they're … assigned completely arbitrary mappings.

    See what I mean? The problem you're describing for OSC is also a problem for MIDI, with all but a handful of still somewhat unpredictable messages.

    And OSC doesn't claim to be a finished standard; MIDI does but I think disingenuously so. (How long have we been at "1.0"? At least OSC implementers are making forward progress.)

    This deserves a longer rant, but I think on some level we're in agreement. I'd love to have the kind of standardization you suggest. I just don't think it's possible — not with MIDI or with OSC. I think we need to start building note implementations around actual music, and build mechanisms into the protocol so that devices can describe to other devices what they're sending.

  • And yes, it's what Jhhl is saying — self-description. OSC can't do that currently, but because it's an open standard, it couldn't. MIDI has never been able to do it, and I think it's too rigid to fix in that way.

    That's no reason not to continue to use MIDI for the things we use it for, but it's time it had some genuine competition, and that there was a standard – more importantly – for doing things MIDI can't do.

  • jg

    I know what you're saying, Pete. We all know that MIDI has some limitations that, circa 2010, are getting pretty painful to endure.

    But it can't be stressed enough that OSC is just a data packing standard, and nothing else. And because of this, "OSC doesn't really do anything itself". For example, if you press the middle C note on any MIDI keyboard, you know you're going to get 3 bytes (well 2 if running status), and you know exactly what each byte contains. If you press the same note on some "OSC keyboard", how many bytes do you get? You don't know. What is the OSC path going to be? You don't know. Is the first field going to be type 'm' (ie, a MIDI message)? You don't know. Are _any_ fields going to be that type? You don't know. Are there other fields, and if so, what purpose do they serve? You don't know. None of this has ever been standardized in all the years that OSC has been around (and as I said above, given what I've seen on the official OSC list over the past 8 years, I don't see it ever being standardized). And this is just for a single key press, let alone all the other musical actions for which some standard messages need to be defined.

    Yes, you can restrict yourself to using _only_ the 'm' datatype in OSC. But then, you're stuck with all those MIDI limitations you outlined above. The only OSC advantage you get is that the MIDI messages can fly over a cable way faster than a MIDI connection… if you use a hardware standard that supports that, such as Ethernet.

    But wait! OSC is just a data packing scheme, and nothing more. OSC doesn't specify any hardware protocol. (Yes, most people tend to use UDP protocol with an Ethernet connector. But OSC doesn't mandate that). What's to stop someone from using TCP instead of UCP? In fact, some people do that. A TCP using OSC keyboard won't work with a UDP using OSC unit. And what if some guy doesn't want to use an Ethernet connection? What if he wants to instead use some superfast parallel port connection that outputs OSC (with no UDP/TCP header no less)? OSC says that's perfectly legal. And note that Bonjour/Zeroconf is a UDP thing. It isn't going to work with any of these other hardware protocols. What if some crazy person wants to use a serial port at 31K baud to transfer OSC messages? That's perfectly legal with OSC. See what I'm getting at with that last example especially?

    OSC itself does nothing useful for a musician. It needs a _whole lot_ of additional standardization in order to be of use to anyone other than a prof who wants to do some isolated research work where he creates a system that doesn't work with anything outside of his lab. And because no one has ever done all that extra standardization (nor do enough OSC people seem interested in getting behind any effort to do so) is why it has made no impact in the music market (unlike MIDI, which _is_ much more than just a data packing scheme. MIDI is full hardware and software communication protocol. Data packing is just one small part of MIDI).

    OSC as it stands today is not a standard that is ready to replace MIDI. I know people will say "It can be done". But who's gonna do it? I can show you posts from 8 years ago on the OSC list from people saying "This should be done". And here it is 8 years later, and it ain't done.

  • No, I agree about what should be done… I just think from a technical standpoint, it is more doable in OSC than in MIDI, and with MIDI we've been waiting nearly three decades for some things to be done.

    A couple of notes, though: there's nothing stopping you from doing MIDI over any number of transports, too, so technically MIDI is also transport-independent.

    You're incorrect about Zeroconf. Zeroconf works over TCP/IP or UDP, and any application protocol, including SOAP over HTTP.

    I don't think the hardware protocol thing is an issue. I do think the lack of implementable standards is, and it hasn't gotten enough work. I think the way to get there is just to *start* implementing. See TUIO and what it's done. They didn't try to create a standard; they just did some stuff that worked.

  • Is there anyone else who finds it disturbing that somebody like Peter sees the need to "prove" OSC's relevance as a free and open protocol in terms of the popularity of some of the most expensive and closed devices the world has ever seen?

  • jg

    We know MIDI is pretty well tapped out. There's no room for adding new features to it without either a lot of ugliness/overhead (like even more "standard" SysEx messages — and SysEx was supposed to be for only the manufacturer "exclusive" stuff), or breaking

    backward compatibility (not worth it unless the spec is so vastly changed/improved that it isn't MIDI as we know it). And the MMA has completely lost its way as a standard-setting organization. It's merely a specialty book publisher now.

    So we can stick a fork in MIDI. It's useful for whatever it's doing right now, and will not be useful for anything more than that, at any time in the future.

    Yes, the time is ripe for a new standard. But OSC lacks too much, and frankly, these go-it-alone initiatives aren't going anywhere. I mean, if a company the size of Yamaha couldn't get mLan off the ground, then a much, much smaller company going it alone isn't going to fare any better with OSC.

    People are putting the horse before the cart. Before you have a new standard, you need a new standards organization with the involvement of enough entities that matter. And that certainly hasn't happened with OSC (and after almost 10 years, I doubt it ever will). I think RTP MIDI has a better shot because at least it's a recent, RTP standard, it's endorsed by Apple, and unlike OSC, it's a full communication protocol. (Unfortunately, it's also a wrapper around MIDI messages, just like OSC's 'm' datatype. So there's some things to criticize about it).

  • Bipolart


    Yes but i more interested by all the physical simulation stuff in the lemur.

    Do you think something like that will be release on the ipad one day??

  • Suffice to say that commercial and/or expensive and/or closed devices should indeed not be the only future for OSC. And some of these advantages are more easily realized when they can be developed by individual musicians, with the agility that provides. So, no, not just about the iPad.

    As to the other question, there's no reason you couldn't write an app for iPad that does what Lemur does, but I'd hope you'd try something a little different.

  • Christian Blomert

    There will definitly be software comparable to the LemurOS, including physics etc. The big question is how long it takes till there is πŸ™‚



  • Be fans of OSC at Facebook, and help spreading the word of OSC!!/pages/OSC/357220159002

  • great ! Thanks Marcus !

    and peter , it's could be interesting to list soft and hardware using OSC…?

  • bar|none

    This post inspired me to try to put all these devices together using OSC.

    So Snyderphonics Manta + Lemur controlling a microtonal didgeridoo patch in Kyma

  • I have long given up trying to track the DIY, open source, one-off and commercial devices that use OSC. There are dozens of them. We have built at least 15 devices at CNMAT and it is a critical part of Meyer Sound products, for example.

    The MIDI/OSC debate is pretty tired now.

    OSC is a person-friendly transport-independent encoding. MIDI is an MMA member-friendly protocol covering an encoding, semantics and physical layer. Apples and Oranges really.

    People go for OSC if they need high performance in throughput because there are lots of toolkits for ethernet. They go for OSC if the mapping of their functionality has to be twisted to fit the MIDI model. This is painfully obvious when you try to represent gesture independently of semantics and leads to nice work such as TUIO.

    People go for OSC for motion synthesis since and this was never part of MIDI scope.

    OSC is handy when you need to change the protocol design because your device is experimental.

    Some OS's provide privileged support for MIDI latency and timing. We have worked out in recent papers how to achieve bounded low latency with various OS's but I don't have the patience to advocate with the vendors so they build it in. Soon this wont be necessary anyway because ethernet AVB will require OS services that will at last deliver bounded latency.

    We have worked on various cheap platforms (PIC and Atmel) to provide

    reasonable OSC implementations and I claim that it is now cheaper to implement OSC than MIDI because no clunky old DIN connectors

    or current loop optoisolators are required. OSC over USB is interesting in this respect since USB provides power to the sensing and actuating device.

    Finally, watch the CNMAT site for new work on a server that

    translates all computer I/O (midi, hid, accelerometers, mice, serial etc.) into OSC. This is another potential to exploit in OSC: the syntax of the encoding and API is stable and simple.

  • bar|none

    Adrian, very interesting and I hope you work with Peter on a more informative and in depth piece.

    The one question I have is whether the "m" type in OSC is sufficient to send midi over OSC. It seems that not many OSC vendors have implemented it. Probably because it is an optional type.

    "OSC applications are not required to recognize these types"

    I know Symbolic Sound has implemented something but I was confused whether the OSC spec defined the type in a way that would encourage interoperability.

    Seems it could be a stepping stone because the basic MIDI semantics do encourage a baseline of functionality that encourages interoperability. Stepping stones are important.

    I'm sure you have talked at length about this and it's probably not possible to respond in a comment like this, but throwing it out there anyway.

    I was involved with defining a auto-config procotol for the monome that uses zero config together with OSC to connect devices. I'm now sold that zero conf combined with OSC (over UDP) leads to much better user experiences than configuring IP and ports manually. It seems that most OSC implementations I have run across so far are over UDP, but I don't understand the full range of implementations. Symbolic Sound also uses zeroconf and it's really fantastic connecting devices this way but it could use some standardization of how OSC devices connect and identify themselves.

  • Pingback: Create Digital Music » OSC Files: Play That Funky Music, Hexagons()

  • Pingback: Funky OSC Hexagons, is that a Lemur I see back there? « logan caldwell()