Pleeeaaaaase… It’s not acceptable, really…
Note: This is a rant…
Pleeeaaaaase… It’s not acceptable, really…
Note: This is a rant…
I wanted to write a little post on what it means for application developers to try to get ready for GNOME 3.0. Many people might already realize what I try to outline here, but I think it’s still good to show. This will be specifically about gedit (naturally), but I think it will apply to any applications trying to survive in the storm that is GNOME 3.0.
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:
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…
Recently I wanted to use gstreamer to add some very basic audio support to an application. I just used the playbin element to play audio files and added some logic to control volume (easy enough with playbin since you can just set it directly) and looping a sound N number of times (which is also easy enough, since you can just watch EOS on the pipeline, seek to the beginning and play again).
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.
I saw some posts on pgo recently on cycling, so I thought it would be a good occasion to do the monthly or so blog. Cycling is something very natural where I come from (which is flatland), but since it’s literally flat everywhere there is not that much to it. For instance, I used to have a bike with no gears, and you break by peddling backwards. This is not really the case where I live now (which is Switzerland, Lausanne). So, in order to get a bit into shape (and loose some kg’s) I started to do some more cycling here, mostly short trips of 2 hours max, but with quite a bit of climbing (at least for me :)) which is nice!
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!
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:
As you can see. It’s really not that much. In addition, the following I would consider a bonus:
Anyone knows about some open source project that has at least the 5 features listed at the top?