Blog Without An Important Name

I meant to post this here a while back, but kinda forgot to. Anyway, on Monday last week I finally submitted my thesis. The title is “The Impact of Representation on the Evolution of Genetic Algorithms.” Now I just need to sit back and wait until the examiners get it, mark it, and probably send me corrections to make prior to it being accepted. I’m going to try for the August graduation, but that is perhaps a bit too hopeful unless the marking happens faster than I expect it will.

Unfortunately, the plans for work I had lined up in the Netherlands didn’t pan out due to the immigration system there making it very difficult for a relatively small company to get a work permit for a foreign employee. As such, I’m still looking for work, although I have enough here to tide me over for as long as I need it. That said, I’m definitely looking to get out of Dunedin, and ideally New Zealand, in the relatively short term. So if you have any ideas, let me know!

For now, I have my regular work, which I’m doing fairly short hours on right now, and a contract job for Naxos (again) upgrading their version of eMusic/J to match their new requirements. It’s good work, and the improvements will flow back into the normal version. It’ll be nice to finally get another release of that out the door, it’s been on something of a hiatus while I finished the thesis.

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!

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

(Update: try the eMusic/J homepage for the latest version on all platforms.)

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’ve just put out an 0.20 release of eMusic/J. This fixes an issue that appears only on some JVMs (in this case, it seems to be Blackdown) where System.getenv(String) isn’t supported. However, it doesn’t fail gracefully, no…it throws an Error (not just an Exception even).

See these Sun bug reports for details. I think that in Java 1.5 they put it back in, and GCJ seems to handle it OK too, which is why I hadn’t noticed it in my testing. Good thing too, I think removing it to be a very short-sighted decision. It’s more ‘pure’, but so much less practical for real world things that I can’t believe they actually took it out at all.

Users of eMusic/J 0.19 don’t need to upgrade (and won’t be prompted to), nothing else has changed. This is just to help new users.

After several months of not getting around to it, I’ve finally put out a new version of eMusic/J. There aren’t a huge number of changes in this one, but there is one that will be significant for new users: it no longer requires Sun Java, any 1.4 Java environment will do the job. Thanks to Retroweaver, eMusic/J can be run in a completely Free Software environment. And, as a more practical benefit, no more jumping through hoops to get the right version of Java installed, and then recognised as default by the system. I’ve tested it on GCJ 4.1 (which comes with Ubuntu) and there was no noticable difference.

I hope that this gets me closer to being able to do a native build, and have it run without a Java runtime at all. However, despite running it just fine, GCJ is unable to compile it (even compiling the bytecode – the source is still 1.5, which I expect it to choke on anyway). If anyone has experience with this kind of thing, please let me know!

Here’s the changelog:

• Added ‘User Manual’ option in help menu, which opens a browser (by
  default Firefox, this can be changed by using the ‘undocumented’
  browserCommand option in the prefs file.) - this should have been there some time ago, but I kept putting it off, planning to try using JDIC to do it. However, JDIC doesn’t provide a 64-bit build, and I don’t yet have one of those machines myself to build it on. So I did it by hand.
• The update dialogue now offers to open a browser to the application homepage - as above
• Updated SWT to stable 3.2 build - a recent SuSE update has killed SWT for a few people. Hopefully this fixes it. Unfortunately, I can’t test it.
• Added option to automatically remove completed downloads from the downloads list. This happens 30 seconds after it finishes. - I don’t see much point keeping a list of completed downloads at the top of the screen, you’re normally just interested in the ones that have finished. So now, completed ones go away after 30 seconds (this can be turned off)
• Builds now use retroweaver to gain JDK1.4 compatibility. This means it works with GCJ, and probably other open JREs. - probably the most important change, but the one that current users will (hopefully) notice the least

Don’t delay! Go get yours today!