The Fugue

Ruby-taglib works great on Debian. Grab Mahoro (which also looks very handy) and follow the instructions. Then grab ruby-taglib and do sudo ruby setup.rb.

The only thing to watch out for is that ruby-taglib requires the C bindings to taglib, which are in a separate debian package. You want libtagc0-dev, not just libtag1-dev.

Taglib is extremely cool, and is going to assist me in reorganizing my music collection. I'll try to remember to bore you with the details once I'm done.

I had a hankering to organize my music collection, so I went out on the prowl again. I came across The GodFather and had gotten excited enough to try it out when I realized it was a Windows program. It just goes to show I'm not used to 'shopping' for freeware that is useful to the masses, that I automatically assumed a program with a cool name and icon must be a Linux project. (Although, the icon farm at the bottom should have tipped me off)

I was feeling real adventurous, so I wandered over to the MusicBrainz website to check on the status of Picard. Picard looks like a very cool program, or at least one worth trying out, but I have not yet succeeded in getting it to work, which brings us to the subject.

The problem is dependencies. Picard relies on very specific versions of programs and libraries, most of which are not in Debian. I gather from the INSTALL file that they're not in any distro. Add to that stale instructions and build errors in some of the dependencies (perhaps due to the stale instructions), and you have a real nightmare. Picard is still in development, so I can understand that easy installation is not yet on the radar, but I have to wonder how he expects people to use this program when he is done. Is he expecting development to take long enough that distros will catch up with the dependencies? Will he distribute statically-linked binaries? What about Windows users (his primary target, thus far) that aren't used to command lines and compiling stuff?

I think we simply have different philosophies, and I'm not saying his is wrong. I just was thinking about it and decided to blog it. If I am writing something that I'd like people to use, I go out of my way to minimize dependencies. My rule of thumb is, if it's in Debian testing or stable, I'm pretty safe. (Insert dinosaur jokes here.) This isn't always possible, especially when using less-mainstream languages (e.g. ruby) or libraries (e.g. a lot of audio stuff). It becomes even harder when you want to use cross-platform GUI toolkits, but hopefully that will stabilize soon. But then I see projects like Picard which are living on the bleeding edge and I see that my philosophy is not the same one held by others. I can only hope it works out for them, and that eventually I can run the software they produce.

I ran across the Gizmo Project today. It warms my heart. Now that I have cultivated your curiousity, Gizmo is what Skype should have been. In other words, Gizmo is Skype with standard open protocols. (SIP, to be specific)

It was easy to set up Asterisk, and I have bidirectional Asterisk-to-Gizmo communications. The one caveat is that I can't seem to call my Asterisk box from my Asterisk box via Gizmo. I'm not sure why that is, but aside from testing that wouldn't be all that useful so I'm ok with it.

My only complaint is some clown stole the username I prefer. So, on Gizmo I guess I go by hans_fugal (17476265435). Give me a call! Or, at least, give my monkeys a call.

My MIDI controller (read keyboard) is an M-Audio Radium 61. I love it. Although it has standard MIDI jacks, I use the USB connection for computer use. It works great in linux, with the hotplug scripts from http://usb-midi-fw.sf.net.

That is, it did work great until udev decided to replace hotplug.

I like udev, I really do. I liked devfs too. I like superior technical solutions, so although I had no issues with devfs, I welcomed our new dynamic /dev overlords. But udev seems bent on world domination, and seemingly has no desire to maintain compatibility with previous configurations or older kernels. This would only be annoying, except as a Debian user I also have to deal with Marco d'Itri's attitude if I have a problem. Sigh

udev decided that hotplug was unnecessary and that it should do hotplug's job. That's fine with me, really, but I just wish I had a little more warning and a little bit better instructions on migrating my configuration. There, I've ranted, and the rest of this entry will be technical details on what I did to get my Radium working again.

The problem was simple, if not simple to diagnose: the firmware wasn't getting loaded. The solution was not so simple. There's lots of posts on the web about loading firmware with udev, but most of them give a udev rule that looks like this:

ACTION=="add", SUBSYSTEM=="firmware", RUN+="/sbin/firmware_helper"

There's two assumptions here that will do you no good if you're trying to get your midisport firmware loaded: udev has no reason to think this device has a firmware to be loaded, so SUBSYSTEM=="firwmare" will never be matched. Secondly, /sbin/firmware_helper does not get distributed by Debian (but it wouldn't do you any good if it did).

Luckily we can rely on the good ol' midisport_fw script that we used before, we just need to make a udev rule for it. Here is the rule for my keyboard:

$ cat /etc/udev/rules.d/013_midisport.rules
ACTION=="add", SYSFS{modalias}=="usb:v0763p1014d0001dcFFdscFFdpFFic*isc*ip*", RUN+="/usr/local/sbin/midisport_fw"

Let's dissect this. ACTION=="add" means match when the device is being added. SYSFS{modalias} means match when modalias, found in sysfs, matches. This will likely be unique for your keyboard, or at least for your model of keyboard. You can do cat /sys/bus/usb/devices/1-1/1-1:1.0/modalias to get this. You will need to replace 1-1 with the appropriate identifier in your situation: watch syslog when you plug in the keyboard to discover it. Finally, we tell udev to run the midisport_fw script.

For the udev smarties reading this: if you use idProduct and idVendor instead of (or in addition to) modalias, the script will be called thrice, and only the middle instance is wanted. However, the other two will fail to run and so the net effect is two more lines in syslog complaining about an unknown product.

And finally, if your keyboard is recognized by the ALSA sequencer after loading the firmware, but no MIDI is sent, and you see the following in syslog:

kernel: usb_submit_urb: -28

Try using a different USB physical configuration. e.g. unplug other things from the hub, or bypass the hub, etc. I spent hours fighting udev (so I thought) when in reality the problem was an overloaded USB hub. Incidentally, -28 is -ENOSPC (No space left on device), which is why I chased firmware issues with udev for so long.

And finally, here's what a normal, working plug of my keyboard looks like in syslog:

Nov 21 07:15:20 falcon kernel: usb 1-1: new full speed USB device using uhci_hcd and address 2
Nov 21 07:15:20 falcon /usr/local/sbin/midisport_fw: load /lib/firmware/midisport//MidiSportKS.ihx for 763/1014/1 to /proc/bus/usb/001/002
Nov 21 07:15:25 falcon kernel: usb 1-1: USB disconnect, address 2
Nov 21 07:15:26 falcon kernel: usb 1-1: new full speed USB device using uhci_hcd and address 3
Nov 21 07:15:27 falcon kernel: usbcore: registered new driver snd-usb-audio

I was convinced that the iRiver iFP 795 was the player for me. Then I literally stumbled across a post on a web forum somewherer that said if you think you like the iFP 795, you really want a Samsung YP-MT6X. I decided to investigate that claim, and from where I sit it seems to be true. The YP meets all my criteria: OGG, long battery life, USB mass storage. It does this better than the iFP, too. The iFP supports OGG, but apparently there's some minor glitches with it including heavier battery consumption and clicks between songs. The Samsung also puts in a little plug for OGG in their manual, rather than just a footnote on some technical specs page. Samsung claims 42 hours, vs. iRiver's claim of 40 or so, and the reviewers say they got close to 40, whereas the iRiver reviewers say they were really only getting 20 or 30. The Samsung is USB mass storage out of the box, but the iRiver requires a firmware upgrade.

Apparently earlier firmware of the Samsung player had some issues with navigation, but those have been cleared up. The Samsung looks better, in my opinion. It's classier and not a weird shape with weird protrusions. The Samsung manual reads slightly better, too. So the Samsung looks just a bit better in almost every way, and is $10 cheaper in most marketplaces.

The odd bits where the iRiver has an edge: the YP-MT6X records voice to WAV, which means it's pretty worthless for long recordings. It records FM and line-in to mp3 though... maybe a future firmware will let you choose mp3 for voice recording. The iFP also has a limited FM recording timer. It's only one timer, so it wouldn't be incredibly useful (although I could make sure never to miss cartalk again), but it is something.

While I'm talking about my iBook, I should mention that I have fallen in love with iTerm. It was a rocky road to satisfaction though, so don't give up too soon. The trouble I had was getting Terminus to look good (1.2 on the horizontal spacing), getting it to pay attention to the changes I made to the default colors, terminal, etc., terminal emulation issues (but not nearly as many as Terminal.app), and that annoying bounce when something is new behavior.

Get the CVS version. No bouncing, and I suspect better behavior with remembering settings. You might need to nuke your iTerm settings when upgrading to get things to work smoothly (they tell you how on their site). The rest is to be persistent and believe that it will do its best to disappoint you. With that attitude you should successfully configure it to your liking. Some of the more annoying problems with Terminal.app are gone in iTerm, but only when you choose rxvt as the TERM setting. Who knows, that might even work in Terminal.app. It also seems faster and seems to use less memory (a very noticeable thing on my 256MB iBook!).