OSC protocol for future projects
  • I was looking at the Missing Link interface the other day and was wondering if there were some plans in having something working with OSC for wave 3 or later. Actually having OSC on the MidiPAL would have been a nice addition, but maybe there will be a MidiPAL 2…

    So far my experience with OSC is that it gives you quite some power and flexibility (over MIDI) but suffers a bit due to of the lack of standardisation, which is probably one of the reasons it never surplanted MIDI. But still it’s great for more experimental projects, especially if you work with MAX or PD…

  • This is not something I have planned, and not something I’m a super fan of. OSC through what? USB? Ethernet? And which sort of messages would this need to send/parse? Would running a web server on the device with a REST API (POST 64 to solve some problems?

  • Well, I don’t really have any answers to that. As I said, I know OSC to be more complex than MIDI, since it lacks proper standards and there is no such thing as an OSC cable. Some devices like the Monome, use USB to send and receive data, others work through Ethernet or WIFI. To be sincere, I asked more out of curiosity…

  • I read the specs and this is definitely not something designed for small microcontrollers: the non-realtime features require access to a real time clock ; the messages can’t be processed “on the fly” (you need to buffer and wait the end of a packet to know what to do) ; the messages can be very lengthy so you need a fast transport layer at 300 kbit/s if you want it to match MIDI’s “speed” – because on 2 bytes you can transmit a whole Note On with MIDI while you’re still sending the first half of the message size with OSC. I suspect a reasonable implementation supporting all data types and the full pattern matching system can’t be done in less than 5k of code (contrary to a few hundred bytes for MIDI).

    What’s really disappointing is that it looks to me like yet another generic message delivery + data serialization protocol/format ; like AMQP with a JSON payload ; or XMPP with MessagePack or whatever, with no effort on the standardization of the messages themselves. Are you aware of any “implementation chart”-like lists of methods that devices in a given category (controller, synth, sequencer…) can implement? Reminds me how every single website has its own “open” API, yet there is no universal sets of “methods” all web APIs can understand ; and no universal URI naming scheme.

  • Not for microcontroller? And the Monome/Arduinome???

  • Yeah, but the Monome doesn’t do anything without software running on a host computer, as far as I understand it.


  • I love the idea of a RESTful API; though I can't see how the latency would ever be acceptable for realtime music type of applications.

    MIDI may be slow and a bit awkward at times, but the latency is low. And it's everywhere.
  • Opinions differ on the MIDI latency issue, I hear. Some people still maintain it’s not possible to get timing acceptably tight with MIDI. I’ve certainly had issues with MIDI timecode, trying to sync other devices with their own sequencers (Nord Modular, xOxbOx, haven’t tried the Shruthi-1 yet) to my computer.


  • @EATYone: Monome/Arduinome are implementing a tiny subset of OSC – nothing more than controlling LEDs and switches. I don’t think they even approached bundles and timestamped messages. An OSC implementation for a synth would be way more complex due to the larger variety of messages to support. Also, I have seen the code of some Arduino projects using OSC and there’s nothing like a real protocol implementation inside – just a bunch of adhoc read / write / switch / ifs to get the communication with their host of choice working.

    @ryandaum: if you look at the OSC specs, you’ll see that a HTTP request in a TCP frame is in the same ballpark as OSC when it comes to message data size – so both would perform equally. It’s only a matter of latency of the transport layer.

    OSC doesn’t really solve more than MIDI when it comes to latency. It has support for timestamped messages, but this requires the internal clocks of each devices to be synchronized. The non-timestamped (immediate) messages are subject to transport layer latency. The shortest way of transmitting a clock tick on OSC seems to be a 4 bytes size / 4 bytes string (let’s say “/cl”) / 4 bytes tag “,” – so the transport layer has to be at least 12 times faster than 31250 bps to beat MIDI.

  • I'm really curious what kind of latency HTTP on embedded hardware on a LAN can get. My day job is working on ad server tech, real time bidding and so on, all over HTTP, and latency for us counted in the ms or tens of ms, but seems to me for synth timing you'd want it much tighter than that.
  • MIDI is tight as long as you don’t cram all 16 channels with loads of messages. And the advantage is you know about the latency and its reproducable because of the fixed BaudRate so you might shift events to adapt to the Bandwidth, something you shurely wont achieve on a HTTP request. If you have timing problems, try splitting your stream on more than one MIDI Port and try to get an Interface that has a good and reproducable timing. From my experience everything eMagic ever built is tight as MIDI can be (the AMT technology sends the Data to the interface with a Timestamp in advance, the Interface just throws the message out at the given time…), the worst i discovered is using a Novation Remote SL MIDI Out under Vista (no timing whatsoever and this randomly changing).

    So as always – if you know what your gear is capable of and if you use it right…... im repeating myself. Bottom Line: no need for OSC, it wouldnt make your life easier ‘cause it adds lots of computing overkill to achieve the same result as MIDI. Now grab a beer and have a Party to celebrate Dave Smith) and the 30s aniversary of MIDI!

  • MIDI suits well the Mutable Instruments philosophy, as in “The simplest thing that could possibly rock”.

  • Yes, if theres would have been no MIDI pichenettes probably would have invented it ;-)

  • hehe yeah but with 2-3 more pins to meet the mutable users need for integrated power supply ;-)

  • And a set of commands for makin coffe… or at least french fries and a prime number of Channels

  • ryandaum: There was just a thread on server/lan latency issues on analog heaven from a fellow who wanted to have a bring your laptops down and lock’n jam in the studio

  • Yeah can't see IP being a good protocol for this kinda thing.
  • “hehe yeah but with 2-3 more pins to meet the mutable users need for integrated power supply ;-)”

    Woo Hoo!

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion