Where music is going
I'm going to make a bold prediction here, hold on to your hats! I'm going to predict that the next music player I buy will have more storage than the one I have now. I'd bet even the one after that will have more than that one!
While that prediction isn't groundbreaking, thinking about it lead me down an interesting path. I, like probably a lot of people, got onto the bandwagon of ripping my CDs to MP3s pretty early. It was exciting to have my whole collection of music on my hard drive (portable players were pretty rare back then) and compared to my computer speakers the quality was amazing! After doing that, I was then at the point of realizing that I needed to do it again. Things like reliable tagging made it so most of the files weren't useless, but I would get better results by just starting from scratch. So I did.
I then realized that I never want to do this again so I needed to rip all my music into a lossless format, but no player could hold all that data, at least not yet. In turn that forced me to realize that over time storage will probably grow faster than the amount of music I'm interested in, but the variable I can adjust is quality. So I can build a bunch of 96 kbps MP3s for my phone and keep 256 kbps OGGs for my laptop. And, eventually, everyone will just have those flac files I originally ripped. Whew, now getting from A to B.
I decided that I needed to make a Makefile for a few different reasons:
- Make handles the idea of transformations pretty easily, so the idea of a transformation between flac and another format would be simple to express.
- Make already tracks which jobs are complete by looking at the file times and which files are created. This would make it easy to rip new CDs as only the new files would be re-encoded.
- Make can parallelize the whole thing for me to work on my dual-core processor. nice make -j 2
- If I quit half way make will delete the half built files and allow me to pick up where I left off.
$ find . -name "*.flac" -exec rename "y/ /_/" {} \;
Which is a small one line operation to find all the files ending in .flac and replace all the spaces in their name with underscores.
Here is the Makefile and the small shell script that I'm using to do the conversion (mostly stolen from a forum thread I can't find now). Everything is grossly hardc oded, but it works great for my situation. My situation includes putting both of these in the Flac folder and wanting to put all the MP3s into the ../mp3 folder. Currently it only builds MP3s at 96 kbps. Good luck, hopefully my collection will be encoded in a couple of days.
posted on Tue, 30 Dec 2008 at 21:29 | permanent link | 4 Comments
Where are my messages?
One of the improvements that we worked on for the Intrepid release is building a combined applet with the fast user switching, session management and maintaining instant message status. I'm happy with how this turned out. I'm planning on continuing the messaging story in Jaunty.
An interesting aspect of messaging on the desktop is that while you can get messages, and get a notification of their appearance, you still may want to respond to them. Currently every messaging app you run provides this through it's own icon into the notification area. Many people I know have both Pidgin and XChat icons in their notification area routinely. Besides the fact that both of these work significantly differently, they also are very different visually providing the appearance of clutter in the panel.
How do we fix this? I think that a reasonable approach is to consolidate them into what I'm coining as a "messaging indicator." The goal of the messaging indicator is provide a simple and clean way for messaging apps to provide the notification to the user that other people are trying to talk them while not having to put something in the notification area. The notification area is evil. Here's a simple use case done as an SVG mockup:
The diagram is simple, and that's a really good thing. Here we're seeing a IM message coming in. The notification disappears into the messaging icon and the message can be found underneath that icon. Nothing complex, but it allows the user to know that all of their messages are a single tidy place and there is only one graphic required on the panel for all messaging.
What is a message? It's really easy to over reach with the idea of what a message is. One could say: "Apparmor is messaging me that I can't edit that file." While that sentence is correct, it's important to note that users don't agree. So my goal is limit this indicator to messages sent from other humans to the human using the computer. Now I need to go and fight some feature creep.
posted on Thu, 11 Dec 2008 at 20:01 | permanent link | 8 Comments
Saving the world one uW at a time
I'm here at UDS and joined a session between the kernel and desktop teams talking about power. Like all of such sessions the kernel team thinks that the desktop should fix all the problems and vice versa. At their suggestion, I took an action item.
One of the features of GTK+ is that it provides two timeout functions: gtk_timeout_add and gtk_timeout_add_seconds. The difference is much more important than not having to add a "* 1000" in one and not the other. The important thing that the second function does is that it tried to group wake-ups to ensure that the program wakes up as little as possible. This is never perfect, but it's a small thing that can help to save some power and reduce the number of wake-ups.
So I looked through the Ubuntu main archive to figure out how many applications use the more precise function, but just pass in several seconds as the parameter. I figured this would be a few apps, and I'd submit a couple patches, then I could go back to blaming the kernel team for all our problems. There are more than a couple packages. There are a lot of packages. The results of the grep and a cleaned up list of packages that are likely to have easy fixes.
I realize now that I can't do this by myself, the only hope is to document how to fix it.
So if you'd like to help save a little power on your machine, follow these instructions.
- Take one of the packages in the list above and find it in the package repository (instructions).
-
Branch it:
$ bzr branch http://package-import.ubuntu.com/x/xproject/jaunty localfix -
Find the instances that might be causing the problem.
$ rgrep timeout_add * -
Commit and build a package:
$ bzr commit -m "Saving the world"
$ dch -i
$ debuild - Test it on your system, make sure things still work reasonably.
-
Generate a patch:
$ bzr diff -r ancestor: - Submit it upstream!
posted on Wed, 10 Dec 2008 at 15:28 | permanent link | 14 Comments