I have made a start on fully Mavenizing my LibGDX demos and placed them up on Github.
The good news is that the core netthreads-libgdx library and the demos have been converted to use the latest version of LibGDX (0.9.9 at the time of writing). Taking the latest build from the LibGDX repo should mean that it will be easier to keep these up to date with changes to Scene2d etc.
I used the LibGDX archetype so you should have no problems building these once you have jumped through a few (minor I hope) hoops to install some dependencies on non-maven-available jar files like the tween-engine and fixtureatlas. There are detailed instructions. If you are having problems make a comment/email me or raise an issue on the issues list.
The core library is here. You will need this for the demos.
The demos up so far are:
This is the same simple shmup as before but with a lot of code tidied up. It is here.
A straightforward Box2d demo with a central rotating fixture, falling objects and nice fading labels. It is here.
Bumper walls, anti-gravity, tumbling blocks and flashing psychedelics..what’s not to like? Shows how to detect collisions between box2d elements and how to handle them.
Putting these all the once place I have discovered a ton of bugs which I have had a chance to go through and fix. Later demos fixed stuff which I never went back and applied to the earlier ones like SimpleShooter so this has been a great exercise. It’s even given me a bit of a kick to write some more.
NOTE: All the LibGDX demos linked on this blog go to GitHub now. It is easier to manage them all in the one place. The new demos have a bunch of new concepts in them like the removal of the old Singleton patterns with Google Guice managing this stuff instead. Also it’s Maven from here on. If you are familiar with the old code and build mechanism then you’ll just have to come along for the ride. I promise you’ll learn stuff that will benefit you.
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.
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.
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.
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.
- 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.
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.
The mavenize-fx project is now up on GitHub. This will be the new home for the project.
I have left the google code site up to host executables only.
You can download an executable JAR file from here.
I have used the 32 bit JDK so I think it should run on any x86 based platform.