Open Sound Control


Well-known member
I am considering someday (perhaps in the distant future) adding a Teensy 3.0 Tools > USB Type option for OSC. This thread is intended to discuss how USB-based OSC might (eventually) work. If you're interested in OSC on Teensy3, please subscribe to this thread. When/if a test version is ever made, preliminary info or invitations to beta test will be posted here.

First, I must confess I have never really used OSC. Well, there was one project where I used KineticSpace to control a pyrotechnic fire art installation, but I just wrote a program in C that listened for UDP packets (on the same machine, and parsed the text for a couple specific numbers. I've also read about OSC and exchanged several emails with Adrian Freed, but still my knowledge and experience about how people actually use Open Sound Control for real musical projects is rather limited. That's where I really need your input and help.

My thoughts on OSC so far are implementing a limited USB Ethernet interface. Fortunately, OSC uses only UDP protocol, which makes this doable, since all the complexity of TCP isn't needed. Lower level stuff like ARP, ICMP and maybe DHCP are probably needed, adding to the complexity a bit.

How the IP number, netmask & gateway are assigned is a big question. I believe all 3 operating systems will default to looking for a DHCP server, so if the OSC implementation responds to DHCP queries it should be able to set this stuff up, right? If it implements a response-only nameservice, it could give itself a name which could be used, but probably only on that computer.

This actually leads to all sorts of questions.....

Do you see OSC applications on Teensy 3.0 listening for messages, where the sender needs to know the name or IP number of the Teensy 3.0? Would the sender be on the same computer where the USB cable is plugged in, or somewhere else on the network.

Or would you need your OSC project to embed the name or IP number of some other OSC entity. Would it be on the same computer, or would the computer need to route packets to deliver your OSC messages elsewhere?

While a lot of this stuff is normal IP networking setup, I feel it's important to make a system that's easy to use. Sure, it's possible to make things work in lots of ways by manually editing network numbers and routing rules on your computer, but that's a difficult and error-prone process (and the reason protocols like DHCP and DNS exit). I want to consider how this stuff is actually going to work for any USB-ethernet OSC option.

Another question involves maximum packet size? I've looked at a few Arduino OSC implementations which limit the message size to only a couple hundred bytes. Presumably that's enough? There will be some sort of limit, but what is a useful threshold?

I'd also like to hear what sort of things you'd actually do with OSC, which can't be done with MIDI?

And again, I want to mention this is all very early discussion about a feature that might be implemented eventually, but highly unlikely to happen within the next few months.
Hi, Paul

Adrian here, coinventor of OSC.
We have done and continue to do lots of OSC projects with Teensy.

The best code base is here:
Yotam Mann wrote it while he was working with us at CNMAT.
It supports OSC over ethernet if you add the usual extra hardware
and OSC over serial.

OSC is an encoding not a protocol.
Some OSC libraries and apps only support UDP for some reason but from the beginning it has
been run over serial, TCP/IP and UDP. I have tunneled over MIDI too.
oscuino shows you how to separate the encoding from the protocol.

Because some applications only listen for OSC over UDP there is an advantage making the Teensy appear to be a
source and sink of UDP packets.

Here is a use case or two worth looking at:
1) We have been building fabric multitouch with the teensy. With teensy 2.0 we didn't
have the crunch to do the blob detecting on the Teensy side. With Teensy 3.0 we can
but then we would want to encode the blobs with the standard way everyone does multitouch
TUIO which is built on top of OSC. All the TUIO apps (there are dozens of them) are listening for
2) Control your favorite music app/sequencer from a control surface you have built with the teensy.
This is what people are doing with all the iPhone and Android OSC apps. The programs are all listening for udp.
3) Beyond music: OSC is used for lighting control, robotics and all kind of things. I wish we had called it Open Systems Control.
Here is an example OSC arduino lighting application:
Most professional computer controlled lighting is done over the ethernet with boxes that break out to DMX. Sometimes they use OSC
encoding other times with protocols like art-net:
My point here is that there are reasons other than just OSC for teensy 3.0 to be able to do TCP/IP. One that comes to mind
immediately is Skype devices. We know the Teensy 3.0 ARM can do the audio I/O for a phone-like device. It can probably run the audio compression/decompression too.

Most simple apps can use small OSC packet buffers. There are lots of applications that generate or can listen for huge
OSC buffers. One application we just wrote encodes a bunch of features computed on every part of the body from the Kinect
skeletonization software. That's hundreds of OSC parameters/bundle. Yotam struggled with this with oscuino because embedded
programming often calls for the fixed buffer model which doesn't scale very well to lots of libraries all needing buffers.
oscuino uses the Arduino "style" but I think this will evolve towards the malloc model eventually as the memory on the microcontrollers continues to climb. The tricky thing the library takes care of is checking incoming packets to avoid overrunning the buffer.
Do you see OSC applications on Teensy 3.0 listening for messages, where the sender needs to know the name or IP number of the Teensy 3.0? Would the sender be on the same computer where the USB cable is plugged in, or somewhere else on the network.

Hey Paul. I use OSC in just about everything I do for control from lighting, sound, physical actuators, to inter-process communication in software. Without delving too deep into technical details, here's what I would expect from Teensy:

I plug Teensy via USB into a computer

A DHCP handshake happens and both computer and Teensy are assigned an IP in the 10.0.0.x range. Ideally this is predictable, i.e. Teensy always gets
It should be possible to set a manual IP to avoid collisions on a larger network.

I plug Teensy into a router

A DHCP handshake happens and an IP + port is assigned according to the router configuration.

In either case

  • Everything should be over UDP, simply because UDP is the de facto standard. Most non-technical people, when they say "OSC", imply UDP as the transport protocol.
  • There is an option to force assign Teensy the router's broadcast IP (i.e., or even automatically like *.*.*.255).
  • There is a default Teensy port (i.e. 7335). There is an option to set an arbitrary port.
  • I don't want to run custom PJRC software on my computer. Everything should just work with no extra software required.
  • Inspection and configuration of Teensy's network/OSC settings should happen over OSC, and you could provide a client to do this, but I should also be able to configure Teensy programmatically from my own software just by sending OSC messages (i.e. /teensy/1/config/ip/set, /teensy/1/config/ip/setbroadcast [sets IP to *.*.*.255]).
  • Each Teensy should come with a unique-ID so that it can be referenced uniquely on then network (i.e. /teensy/frodo/..., /teensy/gandalf/...). The UID's should be human-readable, memorable names and ideally references to films/literature. There should be both a hard-coded UID that always works and a user-configurable UID.

Other nice to have features

  • The full OSC spec is implemented, including globbing, time-tags (however, you probably need an RTC for this), etc.
  • Network device-discovery is hard problem without an accepted solution right now, but it would be nice if Teensy could somehow get a list of all devices on the network using zeroconf or whatever. Likewise, it would be nice if it could register itself in existing network discovery systems.

I'm not sure if that's everything, but that's what I can think of for now. Really excited about this!
Last edited:
Oscuino implements the full encoding spec.
I just sent an alpha version of oscuino for Teensy 3.0 to CNMAT's release process.
Oscuino has to be tested on a rather large number of platform/device combinations so if you need a copy earlier
please e-mail me:
Time tags don't need a real-time clock, they need a synchronization protocol between the two parties.
We developed one in 2008 and AVB includes one that is now on all Apple computers. It will take a while before this stuff makes
it into Arduino and Teensyland but we know how to do it and the footprint is small.
What does the "plug and play" OSC dream require?

There are a few routes to this but a relatively easy path is to implement one of the ethernet-over-USB standards (RNDIS and/or ECM)
in the Teensy. Muiltiplatform support has been challenging in the past (the usual, boring Microsoft vs Apple thing).
This driver may solve the RNDIS problem for OS/X:
The Teensy code footprint will be small for this and the performance quite good on a Teensy 3.0. You don't even need to provide
all of TCP/IP because OSC commonly uses UDP packets which are easy to assemble for an IP stream.

It's not hard to find people around the net who want this badly, e.g.,
There are lots of "solutions" involving proxy daemons with node.js to translate between serial/midi etc. and ethernet but we have shown (Andy Schmeder and I) that these introduce latency and latency variation and the number of steps to install these solutions is daunting to many people.

Other routes for "plug and play" are making the Teensy a PPP device (this is what OS/X seems to ask about when you first plug in a Teensy).
It is also possible to make it a SLIP device but enabling SLIP requires some different ifconfig commands on each of the platforms.

Another, related use of Teensy and OSC is for the community of users who want to build the host interactions in their web browser.
Again they rely usually on proxy daemons because of the security sandboxing in the browser. A teensy that can move ethernet over USB would solve this because it could run a simple httpd daemon the browser can talk to. There are cloud based solutions for this but they are only viable for slow datalogging applications.
A lot of people are building powerful sound synthesis and graphics into the browser these days and they want tight interaction with devices.
I also reviewed serial port extensions to web browsers to address this but there is no multiplatform implementation (Microsoft Explorer in the way) yet.
Last edited:
We put the latest OSCuino beta release code up on

While others test and fix this I will be moving from this to the roadmap for the main missing feature in all the Arduino OSC attempts: time tags. The api to set and get them is there but we need two elements in Arduino/Teensy land to implement them: deadline scheduling and time synchronization. The theory and practice of this is decades old but
to pull it of on Arduino will require harmonization of two models of timing represented rather well now on Teensy 3 as the Time library and the IntervalTimer library.
These libraries model time as a "thing calibrated from somewhere else in seconds" and "time that goes by in locally measured intervals" respectively.
One useful step will be to get the UTC seconds stuff in Time fixed to do NTP synchronization using something like "The Kernel Discipline" which brings it to microseconds like the resolution of the Arduino baseline "time flowing with a wrapping phasor" API.
We may publish the code to our version of this sort of discipline developed some years ago for 8-bit microchip controllers (uOSC) to help with this task.
As it turns out UTC is probably the wrong time standard to build these things on because it requires consultation of a table of leapseconds to correctly measure time differences. Most modern timing standards being developed for the "Internet of Things" use PTP as the base format with conversions to UTC mostly for display purposes.
One of our testers noticed that OSC is faster over USB serial than with Arduino ethernet shields with the Wiznet 5100.
I checked the specs and found that yes indeed that ethernet chip is very slow:
For applications like (Teensy -> Rasberry PI, Beaglebone or Teensy->laptop) there is not much benefit over ethernet wiring. With
USB you get reasonable performance and power. This is why we have been doing OSC over SLIP serial-USB for many years instead of UDP OSC.
This situation may change as Arduinos migrate to better ethernet connections or use chips that have integrated Ethernet Macs.
Our OSC library work is now in the Teensyduino 1.14 release. We focussed on stability in this first release and
we are now working on performance tuning and increasing the number of examples. The good news for this community is
that we are optimizing for Teensy 3.0 and Teensy 2.0 first. I checked in a few improvements today, so if performance is a concern for your application
pick up the regular updates from the github repository:
I have just come across OSC and in previous projects I used ArdOSC (UDP only). I use this to communicate with TouckOSC for a remote control solution for my lighting systems . Per WiFi usng an WIZ812MJ Ethernet module but I also had it runnig on a WIZ820io.

I order not to really have to configure the network connection I am using the Arduino Bonjour library. The OSC server running on the Teesny++2 is announced on my network and I can simply select it in TouchOSC. while TouchOSC only woks with UDP the Bonjourt part should generally also work with TCP.
Gien that TouchOSC was very recently also released for Androind I am sure it will gain even more popularity.

A such, some TouchOSC examples for the new OSC library would be very nice!
Thanks for your interest. Yotam Mann is busily working on TouchOSC examples. He just put in some more Processing examples. Keep an eye on the GIT repository in the coming weeks and some TouchOSC examples should appear.
Adrian, that is great to hear. I have the WIZ820io working with the Teensy3. So far I can get an Ethernet Address per DHCP and register the OSC service per Bonjour.
The next logical step would be to replace the ArdOSC part of my little app with OSC so the TouchOSC examples will come in handy ;-)
It's good to hear you got the Wiz820io working. This can be challenging. Do you reset the module with a pin from the Teensy 3.0?
Yes, I followed user manitou's example an use pin 7. Still it did not work until I connected the PDWN pin on the WIZ820io to GND. This is all still connected on a breadboard so the wiring may also not be the most reliable.
Now that I can see that this will be working I am soon going to lay out a little board similar to the one in the image. This combined a Teensy++2 and a WIZ812MJ. On the left side the WIZ812MJ is connected to a TP-Link WiFi router and to the right side the Teesnsy++2 is connected per I2C and Ethernet cable to one of my LED shields . That same set-up in installed in my lighting systems just with 4 more LED shields.
I am hoping to recreate the same with a Teensy3 and WIZ820io, however, with much higher performance, perhaps for some music responsiveness and something interactive.
This is exciting work.
Thanks for sharing it. There will be a lot of interest in the combination of Teensy 3 + ethernet + audio.
Hi there,

I'm Camille, author of the Mac application OSCulator. I've recently received requests from some users that would like to use OSC with Arduino or Teensy boards so I worked on a small application that acts as a router between the serial port and OSC.

The specs are:

- plug and play connection to the serial port via a drop down menu, if connection is lost, then try to reconnect a bit later (e.g. useful when developping with the Arduino IDE).
- plug and play OSC service discovery using DNS-SD (aka Zeroconf).
- a priori not restricted to Arduino, should work with any serial device that encodes OSC with SLIP.

Current limitations:
- no support for manual OSC host and port configuration, but I can add it on request, not a big deal.
- OSC over UDP only, no TCP at the moment.
- currently runs in a window, in the future I would like to see that in the system tray (Windows) or menu (OS X).

Right now, I have a working prototype for Mac that I am porting to Windows (struggling with Windows 8 to install the Teensy drivers!).
I would be happy to share it with those who are interested, please contact me.

Best Regards,
Hi Cam,

Thanks for letting us know what you are doing.

Please take a look at things we are checking into the CNMAT/OSC repository during these coming weeks. We are working on building the kind of bridge application you are talking about into the Arduino and Processing IDE's. I suspect that at some point we will want to develop a way for the IDE and applications like yours (or Max/MSP or PD) to coordinate
so that there isn't a fight over the serial port.
As indicated in a post above I created a board that combines a Teensy3 the WIZ820io, I2C etc. While the main purpose was to be able to directly connect it to one of my LED shields it turned more into a Frankenduino:


While I am waiting for the board from OSH Park, it would be nice to have some look at OSC examples for TouchOSC. Any word on a ETA ?
The boards for my Frankenduino and the components will arrive on Monday and I hope to have everything assembled and working not later than by the end of next week. Then I could really use some examples of how TouchOSC would work with the OSC library.
Also there seems to be interest in coming up with a good Benchmark to measure performance. Developing such thing would exceed my abilities at the current time, so I am hoping for some advice, and collaboration and hopefully an interesting learning experience!

What happened to Tuesday ?
Tuesday? My colleague went on holiday. Oops!
I will see if I can conjure something useful up myself while they are away.
There are some interesting dedicated hardware devices that support OSC well coming out for those of you who don't want to do
the heavy lifting with Arduino or Teensy, i.e., and
These will fill some of the gap left by the exit of the best supported OSC device I have seen built so far:

There are also some Rasberry PI examples:
I would expect some nice Beagle Bone things soon too.

And a wireless OSC to MIDI box:
Last edited: