Planet SoC

It’s nice to be somewhat ahead of the roadmap that I gave myself, especially since all kinds of problems that I hadn’t thought about are cropping up. However, I finally have the analysis portion of the plugin more or less ready to go, despite a few bumps along the way related to threads and subprocesses. Those are pretty much ironed out thanks to the help of Jonathan Matthew and my mentor Philip Van Hoof, and I learned a fair bit along the way. That’s what this GSoC thing is all about, right?
One thing that took me a while to decide was how to control the song analysis. It is a fairly processor intensive and time consuming process, so I didn’t want it to just run whenever, but I didn’t think it deserved its own toolbar button. I settled on a pop-up window that runs when Rhythmbox starts if it detects that the library is out of date (from a gconf key). It looks like this:

This blog is not abandoned. Ok, there is a lot of spider webs here, but I didn’t forget it exists =P
My GSoC project had some advances in the past weeks, but not as fast as I wish. But now, my university activities are finally finished, and that means no preocupations with calculus, physics, mechanics and any other of these boring stuffs that will make me an engineer.
Hey, I’m going to Istanbul! Everything confirmed. See you at GUADEC!

Google Summer of Code
Lots of activity around F-Spot lately. As there’s a number of people very curious about what I’m doing, I’ve made a small screencast providing a sneak preview.

In the screencast I first highlight the old editing tools below, which are quite hidden. I then show you how the new tools will be implemented.

Click for screencast (Ogg Theora)

The UI is still very basic, as my GTK+-fu isn’t all that strong.

F-Spot performance enhancements
At the same time, both Stephane Delcroix (my mentor, who should really blog more!) and me are working on big patches to improve F-Spot performance. Expect a much smoother experience soon!

Its quite clear from the various discussions related to DVCS that there isn’t going to be one clear winner for the choice of VCS for Gnome; everyone wants to use their favourite DVCS. So here’s an idea, why not allow them to?

Its quite clear from the various discussions related to DVCS that there isn’t going to be one clear winner for the choice of VCS for Gnome; everyone wants to use their favourite DVCS. So here’s an idea, why not allow them to?

After playing around with several variations on the Marsyas MIREX 2007 feature extraction algorithm, I’ve come to a very subjective and unscientific conclusion. I will be using the basic algorithm with two slight modifications: I’m downsampling to 11250 Hz to increase the speed of analysis, as various studies indicate that this does not significantly affect accuracy, and I am using a 50 ms analysis window with 50% overlap (hop size of 512 samples and window size of 1024), as opposed to Marsyas’ original 0% overlap.

Finally the libsoylent API draft is available. After another week of discussion, I think it covers most of the functionallity the API should provide and also some interesting background information and implementation detail. I’m really looking forward to comments, ideas, suggestions for improvement and also criticism .
Last week, besides enhancing the libsoylent API draft, I also focused on two other things: creating a detailed schedule for the rest of GSoC and getting my hands dirty with coding.

I’ve recovered from last week’s stupidity (and started using version control!), and I believe I’ve got a feature extraction program that works. Yay! Now comes the drudgery: trying to find the optimal combination of speed vs. accuracy. This basically consists of running batches of songs through the feature extractor using different parameters (sampling rates, length of song segment analyzed, analysis window sizes, etc) and then comparing the results.

I’m not particularly superstitious, but I can’t say that I look forward to the rest of the day, given what happened at midnight.
Coding officially began 3 weeks ago. Last night I finally came up with a piece of code that I felt was deserving of “initial check-in” to my project page. In order to do this, I wanted to move everything out of my working directory except for the source code, but I made series of terrible mistakes. First of all, the working directory shared its name with the executable. Secondly, I chose to move everything that I didn’t want checked in to svn to the next directory up. End result? The directory containing my source code was overwritten by the executable. Or at least, it tried to overwrite it, and choked, and now both of them are gone. Since it was overwritten rather than deleted, I couldn’t find a way to recover it (anyone know any magical methods?).

Last week I put all my effort in the libsoylent API. I started thinking about the API design weeks ago, but now I gathered all my notes and assembled them into one big document, made some diagrams and worked out the API in more detail. The person and the addressbook objects are mostly done, while groups still need a bit of work. All in all it seems like a good base to get started. Currently me and my mentor are discussing the whole draft, and I will publish the API as soon as we are done.
After I had a feeling that the API looked solid enough, I started to get my hands on the “base-code” of libsoylent, i.e. adding the main classes and GObject stuff and making everything compile and work with stubs. I also added a simple “test-suite” that can easily be extended to test certain functionality of libsoylent.
libsoylent is in the Soylent SVN trunk. If you’re interested, you can check it out at: