Blog Without An Important Name

First update in a while, just fixes to various things.

• Overhauled the filename cleaning stuff, hopefully finally fixing issues on windows. — found more filenames that windows dies on, so this deals with them. Hopefully that’s the last of them.
• If the option ’spacesToUnderscore’ is ‘true’ then spaces will be converted to underscores in filenames. — someone asked for this, and it was easy enough to do when working on the other stuff
• Handle the case where the emusicj script is a symlink to the real location, and use that to find the program directory — makes it nicer for people who lay their applications out in complex ways.

Find it at the usual place

This is a pretty small one, mostly just to fix a problem some people were having.

Changelog:

• Truncate the pathname to save files to if it gets too long on windows (which has stupidly low limits) Some classical albums have really long names, and there were some that couldn’t be downloaded as a result. This hopefully fixes the problem, although I haven’t tested it yet.
• Added option to allow the user to specify that they don’t want cover art to be downloaded. This is done by adding the line ‘downloadCoverArt=false’ to ~/.emusicj/emusicj.prop. Someone wanted this, I can’t remember why, but it was easy enough to do.
• Updated build.xml to allow more flexible compiles, such as not always creating a dist build Apparently some people are making distro packages of eMusic/J, and this makes life easier for them. Related to this, I’ve started posting the source code of each release on the site, too.

It can be downloaded here.

I’ve just put out eMusic/J 0.23. The main reason for getting this out there is that there is a bugfix for a problem that occurs in a certain (rare) circumstance.

Here’s a list of the changes:

• Allow multiple tracks to be selected This means you can shift-click or control-click to perform operations on multiple tracks. This is a prelude to drag-and-drop support, which I hope to get to some time soon.
• Adds auto-remove timer to tracks that were finished when the program started Previously, and tracks there when the program started were never cleared automatically. Now they are.
• Trim spaces from ends of album/track/artist names as vfat doesn’t like them
• Changed default save location of files to ~/Music or ~/My Music (whichever exists), defaulting to the first one if neither do This should make its default save location a bit nicer on various platforms.
• Fixed an infinite loop if the album/artist/track names contain a path wildcard (e.g. %t). Thanks to Hugh Brackett for spotting this one. This caused the program to peg the CPU on this album due to the track “S#%t Outta Luck”

It can be downloaded from the eMusic/J homepage.

An extra note, a customised version of this program was developed for Reggae Country to use with their download service. Thanks for their support!

(Note: files updated for Ubuntu 8.04)

A little while back, I got a Hercules DJ Control MP3, which is an entry-level DJ console that connects to the computer with USB. Unlike most of these kinds of things, this isn’t a MIDI device, so making it work requires a bit of hacking.

Mixxx supports the Herc DJ Control Mk1 and Mk2 just fine, by talking to them directly over USB, unfortunately the Control MP3 requires some magic for this to work that noone has figured out yet. However, the kernel can talk to it using the HID system, which usually is used for keyboards, mice, and other random controllers. The problem with this is that the LEDs don’t work. For some reason, the Linux kernel (as of 2.6) ignores any LEDs that the device says it has if it doesn’t know what they are. With a bit of kernel hacking, this behaviour can be changed, and then Mixxx will use it just fine. If you don’t do this, the controls work, but the LEDs don’t. And we all want blinky LEDs, don’t we? (Also, I used some of the spare LEDs on the controller and made them into a VU meter, which works surprisingly well.)

So to start with: making the kernel work right. I’ve made a patch against the Ubuntu 2.6.22 2.6.24 kernel, here. Or, if you are using Ubuntu 32-bit with this kernel, you can just use these two modules: hid.ko and usbhid.ko. (Files for Ubuntu 7.10 are also available). With the Herc unplugged, do:

sudo rmmod usbhid; sudo rmmod hid; sudo insmod hid.ko; sudo insmod usbhid.ko

(it pays to do them all on one line, as USB keyboards and mice may stop working while the module is unloaded). If these load properly, then you’re half way there.

The next step is to make Mixxx work with this. By default, it only supports the Mk1 and Mk2, as it uses the direct USB way of talking to them. To make it use HID, you need to recompile it, using the current SVN version. How to do this is documented on the Mixxx website, but the compile command needs an extra option, thus:

scons djconsole_legacy=1

The binary that this spits out should handle the LEDs just fine.

This is all very hacky, but hopefully it won’t be in the future. I’m going to see if I can get that patch put in the kernel proper, which will solve the most annoying part of the problem. It would also be good to get Mixxx supporting both legacy mode and the newer one at the same time.

However, we’ve heard from Hercules, and they say that some time in the first part of this year, they’re going to try to get some Linux drivers out. Hopefully they’re open source, and turn the Herc devices into MIDI devices, which would make life a whole lot easier for support.

For the past couple of months I’ve been playing with Mixxx, practising mixing music. Today I played in front of a crowd for the first time ever. It was a friends birthday, and I’d raided his Gatecrasher CD collection first, so it wasn’t nice, heavy industrial like I’d like, but still, most of the people there seemed to like it. Coincidentally, I’d included a few tracks that people knew, which helped.

It was a load of fun, so hopefully I’ll get the chance to do it more. Even better if it’s the sort of stuff I prefer, although it’s much harder to mix the heavier stuff. But, if I put in more practise I’ll get better at it.

I really need to get a cheap control system to use with the laptop, it’ll be much better than using the keyboard for everything. I’m looking at the Hercules DJ Control MP3, it’s supposed to be pretty crap (very laggy), but it’s cheap, small and portable. It also works with Mixxx properly. When I get into this more, I can look into buying a more expensive and good one and hack Mixxx to work with it. Unfortunately, they don’t ship this outside the US, so I’ll have to find someone there to ship it to and send it on.

They’re coming thick and fast now, I’ve just released a new version of eMusic/J.

Here are the changes:

• Added quotes around $@ in launch script to make it work better with some temp file names. If your browser stores files in a location with a space in the path, eMusic/J probably would have had issues opening them. Now it won’t.
• Changed default cover art name for windows and mac to ‘folder.jpg’. Works better on Mac and Windows, iTunes should automatically pick the cover art up now. It still saves as ‘cover.jpg’ on Linux because that seems to work well enough there.
• Cover art filename can be overridden by coverArtFilename option in prefs file. If the above doesn’t suit, you can change it by providing a name in the preferences file (~/.emusicj/emusicj.prop)
• Current download list saves when files are added, this means that the computer crashing won’t lose the current progress. Previously, the current download state was only saved when the program closed. However, if the computer crashed, the in-progress stuff was lost. Now, whenever you add files to download the list is saved, so the worst that’ll happen is that it’ll retry them.
• Added ” and & to the stripped out characters, they may be causing issues on some file systems. I’ve had reports of files repeatedly refusing to save. It may be caused by these characters, so they’re turned to ‘_’. Hopefully that deals with it.

Go here to get yours!

After a hiatus of about a year, I finally made a new release of eMusic/J. This was mostly caused by the change in the file format that eMusic provides for downloading albums. This version is (internally) quite different to the old one, as it is set up to make it easy to produce customised versions, so that one set of source code can produce both the downloader for Naxos’ Classicsonline service, and the regular eMusic/J.

The most important change in this is that it now supports both .emx files, as well as .emp files. It also now requires Java 1.5 (this is less of an issue now that Java is going properly open source), and is available for five platforms: Linux i686, Linux x86_64, Linux PPC, Windows (32-bit) and Mac OSX (Intel and PPC, but in one package). There were also numerous bugs fixed, mostly thanks to Naxos’s QA people, but nothing earth-shattering.

I also had the lead developer behind eMusic’s new download manager get in touch with me, and he provided me with some information that made this easier than it would have been otherwise, which was good.

Anyway, the new version can be found at the usual location.

Just recently, eMusic updated their download manager to one based on XULRunner, to the outcries of many people on the forums. So I took the work I did for Naxos a while back, and built Windows and Mac OSX versions of my formerly-Linux-only eMusic/J download manager. I’ve had feedback on the Windows version saying that it’s working great for people, which is good. I don’t have a Windows or Mac machine to test either of them on, so I wasn’t terribly confident.

Anyway, they can be found here:

• Windows version
• Mac version

I currently am doing some spare-time work for Naxos (the music label), customising my Java-based, open-source eMusic.com downloader, eMusic/J, to work with their Classicsonline download service. This means taking what was a Linux-only application and making it work on Windows and Mac OS X also. Getting the Linux version was obviously easy, I’d already done that; making a Windows version took a little more time, but most of that was learning how to make EXE files and installers (I’m using Launch4j and NSIS for that). However, making it work on Mac OS X was quite a trial, because this platform decides to do some things totally differently to the others.

The fundamental issue was an incompatibility between SWT, the GUI toolkit I’m using, and the Apple event system. Basically, to make SWT work you need to pass a special option to the JVM: StartOnMainThread. However, as soon as you do this, you lose the ability to catch events for things like “someone double-clicked one of my documents”. So I had the option of having a broken GUI, or no events. Neither of which is a possibility, as opening a particular file is the major purpose of this program. My theorising about what the actual issue is is in this message.

However, Azureus manages to do this, so I knew it was possible. With some help from the Azureus devs on IRC, and staring at undocumented code, I finally have a solution which I’m putting here in the hope that other people don’t spend hours of fruitless searching like I did.

It is possible, with some JNI hooks into the Carbon layer of OS X, to catch the events there and have them passed through to the application. Basically, you include this JNI code, create some callbacks using SWT, sacrifice a chicken and bleed a goat, and all of a sudden your code gets called when someone opens one of your files.

The code that I use is here. If you look at one of the ...Mac.java files, you can see the open doc handler being loaded, and inside that (OpenDocHandler.java), at the bottom of the target object, you have the bit that sends the files to the rest of the program. I don’t understand most of what it does, but it works. If I get around to it, I plan to refactor this and create a fairly stand-alone bit of code that means you can just register your own callback, and get the events without having to modify the handler. That would be pretty easy to do, I just didn’t want to touch it once I got it working. This method can probably be adapted to handle the other events, but I don’t need them so I stripped those parts out. Have a look in OSXAccess.java in the Azureus 2 code if you want to know how to do that.

Once you have this, and someone double-clicks a document type you have registered, you get told about it. Conveniently, you also get an event when your application is opened because someone opened your document.

Note: most of the code there is GPLed as I ripped it from Azureus (and eMusic/J is GPL too), but I think the actual C bit is probably something more liberal, as it was done by IBM and I expect they intend for it to be under something like the Apache licence. But I don’t know for sure, as the original file doesn’t have licence details.

So, hopefully very soon, Classicsonline will have a cross-platform, open-source download manager for its users.

I recently saw mention that Google had released Guice, their internal dependency injection framework. As an experiment, I ported a few parts of the web application I’m working on for work to use it. I’ve never used dependency injection before, and so it was a chance to learn about it too. The executive summary is that it works great. Previously I had a giant factory class handling all the instantiation of singletons (mostly which handle talking to the database), so I would do stuff like:
Configuration.getObjectRegistry().getNoticeHandler()
This worked well enough, but all the static references made testing hard, I couldn’t substitute in my own fake classes at all.

Now, for the classes that I’ve ported to use Guice, in my test case I can create a module that makes it load a bunch of fake classes to simulate what the real ones would do, so I only need to test the one class that I’m looking at. It also means I don’t have to set up database entries for everything that might get touched. I just add a line to the module like:
bind(INoticeHandler.class).to(FakeNoticeHandler.class).in(Scopes.SINGLETON);

The only gotcha I had was that I couldn't get it to inject into the servlet objects automatically. This is because you have no control over their instantiation, the application server handles that all itself. The solution to this is for the class that catches the application loading to store the Injector instance in the ServletContext, and have each servlet object load that and inject the dependencies into itself on init:

@Override
public void init(ServletConfig config) throws ServletException {
	super.init(config);
	ServletContext context = config.getServletContext();
	Injector injector = (Injector) context.getAttribute("injector");
	if (injector == null) {
		throw new UnavailableException("The Guice injector could not be " +
				"found in the ServletContext. It is expected to be named " +
				"'injector'.");
	}
	injector.injectMembers(this);
}

if every servlet extends the abstract class that contains this (and this extends HttpServlet), then it all magically just works.

Over time I plan to port the rest of the application to use this, but probably just as I’m working on those classes. In the documentation it says:

Dependency injection is viral. If you’re refactoring an existing code base with a lot of static methods, you may start to feel like you’re pulling a never-ending thread. This is a Good Thing. It means dependency injection is making your code more flexible and testable.

This is definitely the case, it would be easy to start and just keep following the thread of dependencies until the whole thing was done. However, I’m avoiding that now just due to a) being scared to refactor the whole damn thing at once, and b) I should be spending time on bug fixing and critical features right now. But, it probably won’t be too long before the whole thing is done, as a side-effect of testing.