Note: This is a rant…

I have been developing for gedit since around 2006 (this is 2.14). I would not say I’m the most active developer at all times, but the fact is that gedit is almost solely being developed by volunteers (we see little to none contributions from financed developers). This is of course true for many open source projects. gedit seems like a simple enough little application, but it’s still quite extensive.

Our normal development cycles are relatively uneventful. We introduce a small set of new features, fix some bugs, etc. We also always try to ensure that current HEAD of development is “stable”. This means that I have always used current HEAD in a production environment, that’s right, production! This means it gets a lot of testing, because it is the application I work with most every day. We are not usually early adopters of new technologies, which helps this level of stability.

This changed with GNOME 3.0. We decided we would try to adopt to the changes as early as possible, so that in the end we actually have gedit ready to be shipped. This meant however, amongst other things, the following:

• A lot of work to port from “old” technologies (gconf – gsettings, pygtk – pygi)
• Half of the time I’m just trying to get jhbuild to work again
• gedit is continuously broken due to API changes or broken dependencies
• No real testing because it’s unusable in a production environment
• Regressions are almost inevitable
• No real change for end users!

Now, I of course understand also the advantages of trying to get this to work, but it has been largely demotivating for our little team. To illustrate a bit the impact of this, I had git crunch some numbers on our development cycles.

On this plot you can see the sum of all added and removed lines (excluding translations) over all commits in a particular development cycle. As you can see, we have seen a significant increase of activity in this cycle. Of course, not all of this can be attributed to GNOME 3.0, but there is an undeniable effect. If we zoom in to the last two development cycles, we can see who the person is that we really need to thank:

That’s right, Ignacio is clearly our hero! Anyway, I just want to point out that this cycle has been particularly hard for application developers, especially those that try to adopt early so that they are actually ready by the time GNOME 3.0 lands. And then to think, for the end user, there will be basicly no change at all…

P.S. Note that if you apply a simple COCOMO to this (you take an “organic” type of project, for 80 KLOC (which is probably an overestimation, but still)), you get some 20 months of volunteered work done by a team of 12 for this cycle… wow…

There was however one thing that I wanted to implement that left me a bit puzzled. I wanted to control the volume of each channel of an audio file independently. The why is not really important. My first thought was to use the “volume” element. It implements the GstMixer interface, which supposedly could be used to control independently the volume of each of the channels. Easy enough, right? Wrong… Even though the volume element implements the mixer interface, it does not actually implement the part where you can control the volume of each of the audio channels. If you look at the mixer track, you just see one channel.

So what can you do? It turns out that what you need to do is to take your audio, deinterleave the multichannel audio into single multiple mono channels. Then to put a volume element of each of those mono channels and finally to interleave those channels again. Even though this is maybe still relatively simple, it took me quite some time to figure it out. Anyway, here is the pipeline that would do this:

gst-launch-0.10 -v filesrc location=audio.wav name=src ! decodebin ! deinterleave keep-positions=true name=d interleave name=i ! autoaudiosink d.src0 ! queue ! volume volume=0.5 ! i.sink1 d.src1 ! queue ! volume volume=1 ! i.sink2

This would play the file “audio.wav” with the left channel at 0.5 and the right channel at 1. Note that I had to put keep-positions to true on the deinterleave element (although I don’t know exactly why, it seems to have something to do with the pulsesink element: #657457.

Since I’m a gstreamer newbie, please let me know if there is something I misunderstood about all of this, or if there is a better way to do what I want.

Today I decided I was up for something more, so I went from Lausanne to Geneva and back, which totals at around 120 to 130 km (give or take, the route on the map is not exactly how I went and I didn’t track GPS and also don’t have a km counter) in 6 hours. I must admit that the last 30 or so kilometers where pretty hard on me (since I’m really just a beginner) and I also did it with a mountain bike (I’ll hopefully have a racing bike soon). Anyway, my legs are burning quite nicely. More cycling!

View Larger Map

I’m looking for a nice piece of software that will assist me in my recently revitalized guitar playing activities. What I would like is really just a tool for my convenience in playing along with songs that I like. Therefore I’m looking for the following features:

1. Load an MP3
2. Load/edit corresponding tablature
3. Be able to slow down the song (without changing the pitch of course)
4. Be able to silence/muffle the guitar part of the song
5. Have a nice interface, not something that looks like Win 3.11

As you can see. It’s really not that much. In addition, the following I would consider a bonus:

1. Figure out/specify tablature timing with regard to the song and show where in the tab the song is while playing
2. Integration with GNOME where possible
3. Searching for tablature
4. Automatic tablature extraction from a song

Anyone knows about some open source project that has at least the 5 features listed at the top?