I have been getting into playing music lately. A particular interest of mine is video game music, which tends to be covered less frequently than mainstream top-40 stuff. When transcribing music, it is helpful to be able to hear each instrument individually. This is rarely possible with most music, which can have a lot happening at once, but it is possible for VGM.

With video game music, particularly for older consoles, there exist a variety of technologies for ripping the contents of a game’s soundtrack. The resulting files are generally very small (under 100kb in many cases), but are more complex than an mp3 to play back, because they are essentially rips of RAM contents for their respective consoles’ sound chips. The software that can play such a file is generally a small emulator of that sound chip. This means that the music is effectively synthesized in real time, allowing for changes to the tune’s tempo, muting of certain voices, and other modifications.

I thought it would be useful to whip up a utility that can process a track and split it into WAV files each containing a single voice of the track. The result, which I called VGMSplitter, is on my Github. It’s not pretty: a horrific mishmash of C and C++, and ultimately pretty damning evidence against the idea that I can write in either language. It’s my first project in C++ written for an x86 processor since university, and I found myself shocked at the amount of effort necessary to do something as simple as iterating over the contents of a directory. Java has spoiled me.

VGMSplitter uses a library called game-music-emu for the emulation/playback. It’s also probably not going to run on Windows, yet. When I figure out how to write C/C++ directory manipulation calls for Windows, I’ll probably fix that.

expandable list view filters

ExpandableListViews are tricky. They make sense when you’re done implementing one, but extending BaseExpandableListAdapter and then having your IDE fill in all the methods you need to override can be pretty overwhelming. A question I had when working on mine was whether it was possible to implement a Filter for one. It is, but oddly the answer to that question was not available anywhere on the internet.

There are a few additions you need to make in order to turn a regular ListView into a filtered ExpandableListView:

  1. Instead of being backed by an array-like collection, your Adapter must be backed by a collection of collections. The top-level collection corresponds to the items you can click on to expand; the internal collections correspond to the items that show when you expand their parent.
  2. Your adapter should contain two such backing collections: one which contains the full dataset, and one into which we place the filtered dataset.
  3. There are various getters for which implementation is required (for example: getChild, getGroupCount, etc;) their purposes are for the most part obvious if you’ve ever implemented a standard ListView. The getGroupView and getChildView methods are very similar to getView, with just a few distinctions in this case:

    In order to implement the view-holder pattern, it’s necessary to create two holder classes – one for group views, and one for child views. Also, note that the data you will populate these views with should come from the filtered dataset.
  4. Finally, implement a class that extends Filter:

    As implemented above, any groups that contain children which match the constraint (in this case, a CharSequence) will be shown, along with those children. If the constraint is invalid (for example, the user left the EditText you got the constraint from empty) the filter returns the entire original dataset.

Add in a few layout XMLs and some way of calling filter(String) on your Filter (perhaps an EditText and a TextWatcher), and you’ve got yourself a filtered ExpandableListView.


gradle directory trouble

If you ever move an Android Studio project, you’ll probably notice that Gradle will get mad at you for a while. This is also true if you try to git clone a project to another computer, for example.

Gradle ‘Android’ project refresh failed:
Could not execute build using Gradle distribution ‘’.
Project directory ‘<old_directory>’ does not exist.

It  tries to help you out by providing a link to a dialog where, ostensibly, the issue can be resolved.


Unfortunately, there is no field in this window that applies to the broken setting. I’m sure this oversight will be resolved in a later Android Studio release, but until then, you can fix the issue by editing /.idea/gradle.xml within your project directory. Set the externalProjectPath option to the appropriate value. Problem solved!

music library

I recently undertook the task of attempting to listen to my entire music collection. I have a lot of music, so this took me the better part of a year (just under 250 days, if I remember right. I have a lot of music. It’s a bit of a problem.) I opted to do this by setting my music collection to play in alphabetical order by title, starting with a random selection.

Truth be told, I did a lot of skipping tracks. You’d be surprised how many movie and video game soundtracks are mostly filler.

I began and ended on the letter E. I had been noticing throughout the experience that some letters contained a lot more music than others, which is to be expected; the usual Wheel of Fortune suspects R, S, T, L, and N all seemed to be well-represented, and I was expecting E to be a triumphant, long home stretch. It seemed to be over much quicker than I expected, though. So this got me thinking what the actual alphabetical distribution of my music collection was.

I put together a Python script to evaluate it for me. Here was the result.



This came as a bit of a surprise. I had no idea so many tracks would be distributed into S and T. Then I remembered that I was not ignoring the word “The” at the start of a title. Adjusting for that produced the following:



I want to say this makes more sense, but I’m not sure what I was expecting or not expecting. This does confirm my suspicion that the letter E (the most common vowel in English) was underrepresented. It’s not the lowest ranking letter, but lower than I would expect.

My music collection is probably an outlier, though. Most people do not have one Final Fantasy soundtrack in their collection, let alone seven. I’d like to release the script publicly and get some anecdata to publish, but it currently doesn’t work in Windows. When the remaining issues are sorted out, I’ll update this post.

I’ll also probably use a less awful UI toolkit than Tk.

live wallpaper + OpenGL ES 2

I’ve been messing around a bit with OpenGL ES 2, and I thought a neat project might be to try and recreate one of the default wallpapers that ships with Google’s Nexus 4:

Nexus 4 Wallpaper

In my limited experimentation, it actually looked a lot cooler than I expected, so I thought it might be a good idea to implement it as a live wallpaper. As it turns out, I am not the only dedicated fan of the Android 4.2 wallpaper set; developer Chickenbellyfinn has released the excellent Nexus Triangles LWP ( based on one of the others.

I’ve put together a very basic version of it and uploaded it to Google Play. It’s functional and stable, but lacks any configuration options, and doesn’t work on tablets (every triangle renders at least one vertex at the origin, which sounds like I’m doing something wrong in OpenGL). These drawbacks will be remedied eventually, but in the meantime, I wanted to talk about how I implemented an OpenGL ES 2 rendering environment in a live wallpaper, because it’s far from obvious and not well-documented in the Android API docs. The following should work with APIs 14 and above.

As a side note, I will not be uploading the source code for the wallpaper to my Github, because there are already do-nothing clones of the wallpaper on the Play Store with loads of ads, and I’d rather not make their stealing any easier.


In general, Android LWPs consist of a service subclass called WallpaperService, which serve to manage instances of WallpaperService.Engine. I subclassed both to allow for interaction with a Renderer class and a State class which I created for my update thread.

On instantiation of an OpenGLES2Engine, I instantiate a Renderer and a State if necessary. I also instantiate a WallpaperGLSurfaceView, which is defined as an inner class of the Engine:

Within the WallpaperGLSurfaceView class, the most important things are to override the superclass’s getHolder() method in order to change where it gets a SurfaceHolder from, and to define another method that allows for manual destruction of the View:


In addition, there are some lifecycle methods that need to be implemented, though in my case they mostly amount to starting and stopping my update thread. My Renderer is configured for dirty rendering, so as long as my update thread stops, no rendering occurs; battery life and UI performance should be minimally impacted if at all.


You can find a more detailed skeleton of my GLWallpaperService class at my Github.
You can also find some more details on how to work OpenGL ES 2 into a LWP here, although this article has not been updated in a while.
Finally, you can install my Nexus Circles Wallpaper from the Play Store.

android “R” class, and package names

Android’s R class is a very handy way of externalizing resources. It’s also for the most part pretty intuitive, which is a good thing because its use is practically mandatory in order to do anything interesting with Android. Recently, though, I ran into a strange issue where Eclipse would claim not to be able to resolve a reference to it. As an example, here is the code I would use to load an OpenGL ES 2 shader program:

The constructor in the above snippet takes two int’s; each is internally passed to an Android framework method that uses the int to load the shader text file (in this case, <project>/res/vs.glsl is the path to the vertex shader, and similarly fs.glsl for the fragment shader.) By having put those two .glsl files into the /res/ folder, the Android SDK should more or less automatically generate the appropriate ID necessary to find them; it works perfectly for me most of the time.

However, when I pulled this line of code into a different project, Eclipse threw the following error:

R cannot be resolved

No further details are given for this error. The ints were generated and did exist (verifiable in Eclipse by accessing the ‘gen’ directory in your project.) It turns out there were a few things that needed to be resolved to convince Eclipse of that, though.

Package Renaming

It turned out in the making of this project, I had attempted to rename the application’s package. I did this the way I normally would when working on a Java project in Eclipse: right clicking the project name and then Refactor > RenameGenerally Eclipse handles this type of thing pretty well, but package names need to be changed in several more places in an Android project:

  1. Any source files
  2. The ‘gen’ folder has its own package
  3. AndroidManifest.xml
  4. Probably others

So, rather than trying to hunt down every instance of the package name and trying to make them all match, a better idea is to right click the project name, and choose Android Tools > Rename Application Package. This function actually even fixed all the damage I caused by bumbling about and trying to fix it on my own, although I did have to clean the project to get that bonus.

Import Organization

If you’ve used Eclipse’s “Organize Imports” function to try and solve the problem, you may find that Eclipse tried to import android.R. Effectively, since the compiler was unable to find what you were looking for in your project’s R class, it tries to solve the problem by looking for it in Android’s more general resource class, which not only doesn’t work, it causes other problems: from then on anything you try to use in R will by default reference android.R, where it probably won’t be found. Deleting that import line appears to be good enough to undo the mistake.

It’s Not a Big Deal

Ultimately, running into this problem was probably my fault for trying to rename a package, which in hindsight seems like it’s probably not a great idea to begin with. I’ve always had a tenuous grasp on why the name of a Java package matters anyway, but it seems like the lesson to be learned is to pick one and stick with it.

Oddly, this issue really only seemed to affect files in /res/raw; when trying to debug the issue, referencing files in /raw/layout did not appear to throw additional errors. This is probably indicative of unintended behavior, but it’s easy enough to avoid and correct that it’s probably not worth Google spending development time to fix it.


Bluetooth is a really fascinating technology. It’s quite fliexible; you can use it to make phone calls, listen to music, connect a game controller, and just about a million other things.

Or at least you could if it worked reliably.

Unfortunately, as with any other wireless technology, flexibility correlates positively with complexity, and inversely with ease of use. I own dozens of gadgets that use bluetooth and sometimes it can be tricky to make them work together. My car for instance, has something like a 50% success rate for connecting to my phone on any given day, and even when it does connect, sometimes it doesn’t seem to properly detect which profiles my phone supports (so I’ll be driving along, listening to Pandora, and a phone call comes in, and I have to pick up the handset to answer like it’s the stone age.)

I can’t help but feel part of this is because bluetooth is ironically such a black box – we know these things are supposed to work together, but for the most part as consumers we don’t really know how or why, or more importantly, why they don’t work together. So I came up with a little prototype Android app I call BlueLogger:

BlueLogger Screenshot


It consists of a couple of BroadcastReceivers that listen for bluetooth events from the OS and keeps a log of them. It’s crude and far from feature-complete, but it’s already served as a handy tool in understanding a little bit more about the inner workings of the Android bluetooth stack. For example, did you know that if you leave the bluetooth menu, Android will stop an ongoing scan operation?

BlueLogger is available in the play store:

And you can find the source code on github:


So this is my development blog. Here, you’ll eventually find my work in progress ideas and thoughts on various technical topics.

I am an Electrical Engineer by trade, but I’m more interested these days in software development. Particularly mobile and web development. So you’ll likely see more of that type of content here.

I also wouldn’t be surprised to see some experimentation with CSS. Why else have a wordpress blog, right?