Saturday, February 18, 2012

Instrutorials - Part 1 - Getting Started

Hi all,

By request of my promotor Prof. Dr. Wim Lamotte, I've decided to blog about the progress of my Bachelor's thesis. The goal is to write a mobile application (I've chosen the Android platform) which is tied to the API, and will allow users to learn how to play songs on a specific musical instrument, by providing a visualization of the instrument, and how to play the notes.

I've already made quite some progress, so chances are this post is going to be a bit lengthy. Anyway, let's get started.

The first question I needed to ask myself, is which platform I'd choose for development. Personally, this choice wasn't hard to make. Blackberry? LOL. iOS? Well, firstly, one needs a Mac to start coding, an iPhone, as well as a license. Since I don't have any of those, the choice for Android was obvious. No costs at all, open source, and development possible on all PC Platforms. The fact that I own a Samsung Galaxy S II also was a big reason to choose for Android. Coding on an emulator isn't that fancy.

Secondly, I needed to decide which API level to use. I must admit I lost some sleep about it. The latest API's provide an enormous amount of new functionality, both before and behind the curtains. However, Ice Cream Sandwich isn't wide spread at all. But the fact that my application wouldn't see any daylight until the end of the semester, as well as the new functionality of the API's, I decided to take a plunge in the unknown and develop my app for Ice Cream Sandwich. This way, both tablets as well as smart-phones would be greatly supported, and I could follow the new official design guidelines (these) by Google as much as I can. Since fragmentation is one of the worst enemies of Android, I chose to try to be consistent and follow those design guidelines, with hopefully a clean and great app at the finish.

Getting started
The second thing on my mind was obvious. I was supposed to use the API for providing my users with a huge database of music scores. The amount of file-types offered by the API was quite substantial, so I needed to find a file-type which allowed me to create a visualization of an instrument based on the score.

 MusicXML: This was an obvious first choice for me. MusicXML provided everything I needed in a clean XML format. However, I found the amount of data in the files so substantial, that writing my own parser would take a lot of time. And we've got open source libraries for that, don't we?

The first library I found was JFugue. It provides a MusicXML parser, and has a great structure to implement my own Renderers based on events thrown by the parser. At first sight, this was the perfect solution. But after importing the library in my project, I soon found out that it needed the javax.sound.midi library. And guess what? That library is NOT included in the Android Java SDK. Oh noes! I've tried lots of different things to try and fix this problem:

  1. Hey. I don't even need MIDI support from that library. I just need MusicXML! So instead of downloading the .jar library, I downloaded the source code and deleted everything which had nothing to do with MusicXML or the structure of the library itself. But even then, it still couldn't build because it made use of "EventListenerLists". And guess what, that also isn't supported in Android.
  2. Secondly I downloaded the java files of EventListenerLists to put them in my own package, so even if Android didn't had them, my application could make use of it. But this broke JFugue even more, and it started to fail in parsing the XML files correctly. Even including another library - the error message stated I missed the nu.xom library - didn't fix the problem.
  3. Back to square one.
  4. Another library than JFugue perhaps? I tried lots of different libraries, but all had the same problem. Dependencies on javax.sound.midi. Rats.
MIDI: After all the failing on MusicXML for missing MIDI libraries, I turned on searching for custom MIDI libraries for Android. Soon, my search resulted in android-midi-lib. A quick check ensured me that it provided in everything I needed for my project:
This code provides an interface to read, manipulate, and write MIDI files. "Playback" is supported as a real-time event dispatch system. This library does NOT include actual audio playback or device interfacing.
Sounds promising, right? I imported the library in my project and was finally ready to start coding. However, by parsing a quickly made MIDI file made with MuseScore, the library crashed with NullPointerExceptions. Great! The exception took place in code written by the developer of the library, and had nothing to do with my own code, so I sent a mail to the developer. He quickly replied that the MIDI file wasn't conform with the MIDI specifications, but that I could fix the problem with some dirty fixes. After contacting the MuseScore developers, I learned that the MIDI file WAS conform with the specifications, but that the library crashed on unknown MIDI events instead of ignoring them. After the dirty fixes mentioned by the developer of the library, I was finally ready to start coding my application.

In my next blog post I'll talk about the current structure of my app, and show some screenshots.

Until next time,


No comments:

Post a Comment