As part of my Tonome LibGDX project I decided to convert the LibGDX application to use OSC messages instead of triggering samples internally to the application.

Tonome2

The application could broadcast OSC note on and off messages to a Puredata instance and map that down to MIDI with a Puredata script. The first part of that was to use a Java OSC library that I would build into the application.

I had a look at the existing Java OSC libraries available but I couldn’t use them as they relied on creating a new instance of each message for each message sent. This is a no no with Android as you would have the garbage collector running. The OSC specification is up on the OSC website so why not try and write my own using a pooled approach where we reuse messages sent. The result is the osc-common and osc-network components.

osc-common

This is an almost fully compliant implementation of the OSC message spec. There are bits missing but for my purposes nothing essential.

The library like all the components is fully mavenised and has unit tests to ensure the output of the objects comes out as expected using the encode and decoder components.

Technically you can flood your client app with messages unless you set the pool size to a maximum but hopefully that won’t be an issue if the throughput is high enough. I guess that remains to be seen in the real world. It’s not been an issue for me yet.

osc-network

This implements a client and server implementation for the encoder and decoder components. It uses NETTY a super fast networking library for all the networking parts and is unique in that I have not seen any examples of NETTY4 using UDP to implement anything like this. This was a big sticking point in the development as I wanted to use NETTY4 but it was still in beta at the time with not many source code examples. There might be more recent version of NETTY but I’ll leave it as it is for now.

I got this component working with my Tonome project against the Puredata script that I had written but I found out that Puredata would choke when sent a lot of messages. Initially my heart sank I as I could see that I would have to write my own application to do this. But any failure is an opportunity right? My Swing skills are non-existent but my Flex skill are strong so I figured I would try to look for a Java UI library that would fit my needs. After looking around I noticed Pivot and JavaFX (which had just reached version 2 at that point). Rather than go straight in I thought I would prototype something easier (and more useful) so I embarked on trying to put a front-end on my Mavenize command line tool instead.

Pivot was eventually thrown out instead of JavaFX which I have successfully used to put a useful UI onto my application for converting any existing Java project to the Maven file structure. Once I had the skills I sat down and started to develop an application which uses the osc-common and osc-network libraries to route OSC messages to MIDI. That application is osc-router.

osc-router

oscrouterfx
The osc-router will listen to OSC messages sent to it on the chosen port and then you can assign labels to the message value received. You can’t edit the labels whilst the tool is in ‘listen’ mode but once you pause you can set them. The interface lets you route the messages (as long as they have the expected note-on and note-off values) to a specified MIDI device. It will let you save and load your settings.

This is very much a work in progress. There are possibly latency issues to do with the fact I am creating other objects to represent the incoming messages. I think there is a rewrite of the message path on the books.

The project has been put up onto GitHub here.

Lot’s of interesting JavaFX stuff to look at including file open/save dialogs,  editable label cells, combobox selection cells, icon status cells and a background service. The application also sports a message cache, MIDI device handling  and lots more. I’m also  using XStream to persist the the OSC message values and label settings to an XML file which has proved to be quite seamless.

Update #1

  • I have modified the application to load a default message configuration file. This is for illustration so you can see how the UI works without having to have an OSC producing tool.
  • I am in the process of posting the Tonome OSC code up on Github as well.

Update #2

The Tonome OSC-aware application is now up on Github. You can find it here. It runs on Android but there are still a few issues to iron out like the inability to edit the hostname and port values. It is here.

If you run it from the desktop it will connect to the stated hostname and port that the OSC-Router application is setup for. I have altered the router to load up the Tonome message definition by default. All you need to do it map the note on/off message and route them to a midi target.

More details in further posts.