Alexander Kojevnikov | Blog

Spek 0.3 Released

Spek 0.3 is out, just 2 days after the previous release. This version includes the following features and fixes:

Rulers in Spek

Spek 0.3 source code tarball and the Windows installer can be downloaded here.

Published: 2010-05-17

Tags: gnome spek

Spek 0.2 - now works in Windows

Spek now has a fully functional Windows port! The installer bundles GTK+, GStreamer and all their dependencies, you don't need to install anything else.

Screenshot of Spek running under Windows 7

I also moved project hosting over to Google Code so Spek now has a full-fledged bug tracker. The source code is still hosted on Gitorious.

If you are tired of starting up monstrous applications like Adobe Audition or Audacity just to check a file's spectrogram, give Spek a shot!

Published: 2010-05-15

Tags: spek gnome

Introducing Spek

I just released version 0.1 of Spek -- a little program that shows spectrograms of audio files. Spek is written in Vala and uses the standard GNOME stack: GLib, GTK+, Cairo and GStreamer.

Spectrogram of a FLAC file

Spectrograms are used to analyse the quality of audio files, you can easily detect lossy re-encodes, web-rips and other badness by just looking at the spectrogram.

This version of Spek doesn't do much apart from showing the actual spectrogram and allowing to save it as a PNG image. However, I plan to add a bunch of features before releasing version 1.0:

You can download the tarball from the project's website. To build and run:

% tar -xjvf spek-0.1.tar.bz2
% cd spek-0.1
% ./configure
% make
% src/spek

Or sudo make install to have it installed.

Contribute

The code is available on Gitorious. I really need and will appreciate help in these areas:

Why Vala?

I initially wanted to write Spek in Haskell to practice the language after reading The Haskell School of Expression (generously sent to me by Jorge). However, after writing a bit of code I realised that all the functional goodness of Haskell is not used at all because Spek is simply a bit of glue between GTK+ and GStreamer, with very little code of its own. Also, the prototype's executable size of 14+ MiB didn't help much in convincing myself that Haskell was a good pick for this project.

I was left with C and C#. The latter didn't feel like a good idea for the same reasons: I wanted something lightweight for this small little app, C# would require a lot of dependencies. Also, while I really like C# as a language and Mono/.NET as a platform, I wanted to try something new for a change -- I already use them full-time on my day job and when hacking Banshee.

I wrote very little C/C++ code since late 90's, now I know why I didn't miss it much -- it's so incredibly verbose! After a few hours I gave up, decided to do some research and found Vala :)

The impression so far is hugely positive. Vala still has a few rough edges but nothing too bad and not work-aroundable. If you are tired of using C for your GTK+ applications, definitely give it a try!

Published: 2010-05-10

Tags: gnome spek

xmonad ⋙ metacity (mod GNOME)

xmonad is an elegantly minimalist and lightning fast window manager for X written in Haskell. I wanted to play with it for a long time: I'm using two 24" monitors and so have to spend a fair bit of time re-sizing windows and moving them around. A tiling window manager like xmonad takes care of this; in addition you can control all aspects of window placement with the keyboard alone.

The good news is: xmonad plays really well with GNOME. You can keep your GNOME panels, themes, desktop backgrounds, etc – xmonad just replaces Metacity leaving everything else intact.

The bad news is: I should have tried it earlier.

A few notes about xmonad set up and usage:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Xmonad
Exec=/usr/bin/xmonad
NoDisplay=true
X-GNOME-WMName=Xmonad
X-GNOME-Bugzilla-Bugzilla=XMonad
X-GNOME-Bugzilla-Product=xmonad
X-GNOME-Bugzilla-Component=general
X-GNOME-Autostart-Phase=WindowManager
X-GNOME-Provides=windowmanager
X-GNOME-Autostart-Notify=true
/desktop/gnome/session/required_components/windowmanager
xsetroot -cursor_name left_ptr
import XMonadimport XMonad.Config.Gnome main = xmonad gnomeConfig
import XMonad
import XMonad.Config.Gnome

main = do
  xmonad $ gnomeConfig
    { terminal    = "gnome-terminal"
    , modMask     = mod4Mask
    , focusFollowsMouse = False
    , borderWidth = 2
    }
import XMonad
import XMonad.Config.Gnome
import XMonad.Actions.Submap

import Control.Arrow
import Data.Bits
import qualified Data.Map as M

main :: IO ()
main = do
    xmonad $ gnomeConfig
         { terminal = "gnome-terminal"
         , focusFollowsMouse = False
         , borderWidth = 2
         , keys = addPrefix (controlMask, xK_m) (keys gnomeConfig)
         }

addPrefix p ms conf =
    M.singleton p . submap $ M.mapKeys (first chopMod) (ms conf)
    where
    mod = modMask conf
    chopMod = (.&. complement mod)

After using xmonad for 2 days I must say I'm a convert. The keyboard short-cuts feel very natural, it's not difficult to see the influence of vi. Moving a window to another screen or to another workspace (did I mention workspaces are per screen, which is a really neat feature), switching between workspaces, switching windows, changing layouts, etc... is just a short-cut away.

And as a bonus point, I now have a good reason to become more familiar with Haskell – it's a very nice language.

Published: 2009-10-18

Tags: gnome haskell xmonad

Updated Play Queue In Banshee

Banshee 1.6 will include an updated Play Queue extension. The changes are already in git master, here are a few teaser screen-shots:

Play Queue in Banshee

Played tracks are not removed from the queue but are shown as greyed out. You can play them again if you want, drag and drop to the back of the queue, delete, etc.

Play Queue Preferences

The number of played tracks to show can be changed from the preferences dialogue.

Fill By option

You can also ask Banshee to automatically update the queue using any shuffle mode (including the new by rating and by score modes). The number of upcoming tracks can also be changed in the preferences.

Fill From

The tracks are taken from the entire library or from any play list.

Refresh and Add More

If you don't like what has been added, you can refresh the upcoming tracks. Or you can add more of them (thanks Sandy!)

Manually added tracks

Tracks added manually are treated differently from those that had been added automatically. When adding, they are inserted to the front of the queue but after other manually-added tracks.

After refresh

Also, they are preserved when you refresh the queue.

That's about it. If you like what you saw you can try the git master version. Otherwise just wait until 1.6 is out, it shouldn't take too long.

Published: 2009-09-23

Tags: banshee gnome

New shuffle modes in Banshee

New shuffle modes Next version of Banshee will introduce two new shuffle modes: by rating and by score. In this post I will explain how they work since the modes can be a bit confusing.

In the random shuffle mode (aka shuffle by song), every track has an equal probability to be selected. For example if our library contains 1,000 tracks, each of them will be chosen with probability

Pt = 1 ÷ 1,000 = 0.001

But what if we want some tracks to be played more often than others? Say we have 100 favourite tracks and want to play each of them three times as often as any other track? In probability terms this can be written as

Ps = 3 × Pt

where s are our favourite tracks and t – the other 900 tracks in the library. Because the sum of all probabilities must be equal to one, we have

100 × 3 × Pt + 900 × Pt = 1 → Pt = 1/1,200

To chose the next track, we can pretend that our library contains 1,200 songs and pick one at random. If the track number is ≤ 100 × 3, we randomly select one of the 100 favourite songs, otherwise we take one of the 900 remaining songs.

If the library is partitioned into n slots, each containing Ci tracks, we will have

i=1,n Ci ⋅ wi ⋅ P1 = 1

where P1 is the probability of selecting a track from the first partition, and wi tells how frequently tracks from the i-th partition should be selected compared to the first one. That is Pi = wi ⋅ P1

Numbers wi are called weights and by changing them we control how often the songs from different slots are played. For example, we could pick a number (lets call it β) and require that songs from the second partition are played β times as often as the songs from the first one, songs from the third β times as often as the songs from the second, and so on. That is, wi = βi-1

For ratings, we have 5 partitions – one for each rating. We could also put all unrated songs into the 3-rd partition (to treat them as songs with 3 stars) so that our entire library is partitioned. Now a good question is what to use for β?

If we take β=1, all songs will have an equal probability to be selected. Note that it's exactly the same as the shuffle by song mode. If we take β=2, songs rated 5 will be played twice as often as songs rated 4, and so on.

In Banshee we use β = φ ≈ 1.61803, also known as the golden ratio. This number has an interesting property:

φn = φn-1 + φn-2

In terms of ratings, it means that songs with 5 stars will be played as often as songs with 4 and 3 stars combined, and so on.

In the shuffle by score mode, the songs are partitioned into 20 slots, first slot for the songs scoring 1…5, second – for 6…10, and the last – for scores 96…100. We also put songs with no score into the 10th slot (46…50).

We cannot use φ for β because this time we have much more partitions – the songs with low scores would be hardly ever played. To keep scores behaving similar to ratings we need to scale the weights:

β = φ¼, wi = φ(i-1)/4

Hope that wasn't too tangled and I promise next post won't include a single formula :)

Published: 2009-09-21

Tags: banshee gnome

Vertical panel in GNOME, 15 months later

Fixed vertical panel I'm happy to report that the subject is mostly fixed.

Window List: bgo#86382 has a working patch, it's not perfect (read comments 140, 141 and 145) but fixes the problem.

Notification Area: bgo#531371 also has a patch which works really well.

Quick Launch: My fix is included in version 2.12.6 of the applet.

Main Menu: The ugly arrow (bgo#562247 and bgo#564903) can be removed by setting "has-arrow" to FALSE in gnome-panel/panel-menu-button.c

Keyboard Indicator: bgo#591515 is not yet fixed. A quick and dirty hack is to comment out the entire switch statement in GSwitchitAppletUpdateAngle() function from gswitchit/gswitchit-applet.c

I'm using a GNOME desktop with all these fixes daily and I'm quite happy with it. You can get my customizepkg files for Arch Linux from GitHub; read how to use them in the previous post.

Published: 2009-09-06

Tags: gnome linux

Vertical panel in GNOME

UPDATE 2009-09-06: Read the follow-up post

I've been playing with various desktop GNU/Linux distributions last couple of months. I'm not exactly a newbie to Linux, I have been administering a VPS box for a hobby project for several years now, but I never managed to play with it on a desktop.

So I did. And I must say I'm very impressed. Last time I checked (FreeBSD 4 back in 2000), FLOSS desktop was mostly a geek toy, these days it is ready for the average user.

I will spare the overview of the distros that I tried, as well as my take on the KDE vs. GNOME flame war for another post, here I want to talk about one particular annoyance that I really want to see fixed.

You see, these days it's hard not to have a wide-screen monitor sitting on your desktop. They are great for watching films and playing games but this comes at a cost -- you end up with fewer vertical pixels.

Vertical space is much more important for most other tasks I do on the computer, be it browsing the web, coding or writing blog posts. And the only way to maximise it is to move the everlasting task bar sitting on the bottom of most operating systems to the left or right of the screen.

Vertical layout in Vista Vertical layout in KDE This is how it looks like in Vista and KDE. I know it takes some getting used to, but it's worth a few days of slight disorientation. And I'm not the only one who thinks so.

The vertical layout works great in XP, Vista and KDE, but not in GNOME. I want to list here all open issues along with the links to the GNOME bug database. I guess we have all these issues because not many GNOME developers are using the vertical layout, or even aware of the benefits it can give them. I hope this post will help it, even if only a little bit.

Vertical layout in GNOME Window List: The list of open windows is arguably the most important piece of information sitting on the panel. And the most terribly behaving in vertical layout.

First of all, the height of the window list applet is fixed, meaning the list doesn't occupy all available vertical space.

Second, the height of the buttons that represent the open windows, stretches to fill the entire applet. The buttons should have a fixed height that depends on the font used in the buttons.

Third, after you open a few windows, the list splits to two columns and becomes irresponsible to mouse clicks. This is the most annoying bug of the three.

These issues are documented in bug 86382 that was open back in 2002! The bug has a patch, but it looks like it's not perfect either.

Notificatioin Area: In vertical layout the notification area wastes a lot of space by placing one icon in a row. It also uses different sizes for different icons, some are really huge, e.g. 128x128. It should instead use a flow layout for icons and use the same size for all of them. This is described in bug 531371.

Quick Launch: The quick-lounge applet had a bug that made it nearly impossible to use on a vertical panel (see bug 531358). It's fixed now in the trunk, hopefully it will be integrated into the next GNOME release.

There are other related annoyances (see bug 428943 and Ubuntu idea #1906) but I can live with them if the above issues are resolved.

Published: 2008-06-08

Tags: gnome linux

« Page 2 / 2