Re: [Muine] part support [patch]

[Jorn Baayen <jbaayen gnome org>]

On Wed, 2005-05-04 at 17:33 -0500, Jeff Garrett wrote:
> First, I should say I like muine a lot.  Thanks for all the work.  I
> thought the patch [4] might be interesting to others.  Below is the
> justification & details.
> 
> Thanks again,
> Jeff
> 
> A large part of my music collection is classical music, with the various
> parts/movements split up into different tracks.  This gets ugly (and
> overwhelming) in the Muine playlist, each title being so long.  [Imagine
> trying to find the start of Beethoven's Symphony No. 5, given that
> you've got all of Symphonies 1 - 9 in the playlist, 3 or 4 movements a
> piece, and almost all of the information is exactly the same except for
> one measly number.  Obviously that is extreme, but I still find it hard
> to find the "starts" of things when I load many songs into the playlist
> and each have a few parts.]
> 
> So I made a quick hack to support the PART tag (see [1]).  It now looks
> more sane (screen shot [2]).  If the song has no PART tag, it displays
> as before
> "<b>$title</b>\n$artists"
> in the playlist window.  If it has a PART tag and is the first song, or
> is not a part of the song that comes before it, it will display
> "<b>$title</b>\n$artists\n    $part"
> If it is a part of the song before it, it just displays
> "    $part"
> (It seems better to use \t than some amount of spaces, but for some
> reason this didn't indent uniformly...  see [3].  Why?)
> 
> In the Add Song window, if a song has a part, it gets displayed as
> "<b>$title $part</b>\n$artists"
> (which is as much as was there before)

Cool. However, a bit too messy to enter stock Muine. What I propose
instead, is grouping parts together as tracks. How does that sound ?

Basically, what it would need is Song objects to have an array of
filenames, instead of just one filename associated to them. The album
construction code could then merge songs into one when necessary.
The Player object would need to be updated to on eos, before actually
emitting eos to the rest of the world, check if there are any more files
to be played from the same Song.

> Also, I find it easier to find things sorted by artist, then discname in
> the Add Album window.  [I'm more likely to know my CDs of Liszt's
> transcriptions of Beethoven's Symphonies are titled that, than that it
> is performed by Konstantin Scherbakov.]  This doesn't affect very much
> (one can always search), but the sort used to seem more random and now I
> can find more easily what I look for.   Anyways, the patch below also
> contains this 1-line "fix".

Hmm, where do you have composer information stored? If in the artist
tag, it should be sorted by composer -> seems more useful (to me
anyway), than by album name. If I want to hear some P�, I go look
under 'p', because I don't remember what my albums are actually called.


Cheers,

Jorn


> 
> Bugs/limitations:
> I only implemented reading the PART tags for the ogg vorbis files.
> It only compares Title and /first/ Artist to determine if it's the same
> song.  It really should compare all artists.
> Some funny business seems to happen when songs are removed.
> My code is ugly/hacky.
> Since some songs now get more screen space, there might be some
> usability issues (different sized targets).  I do think there is a
> positive tradeoff here, as previously there was too much information
> (Symphony this or that) drowning out the specifics.
> 
> [1] http://www.gophernet.org/articles/vorbiscomment.html
> [2] http://www.math.uchicago.edu/~jgarrett/code/shot-part.png
> [3] http://www.math.uchicago.edu/~jgarrett/code/shot-indent.png
> [4] http://www.math.uchicago.edu/~jgarrett/code/muine.diff
> 
> _______________________________________________
> muine-list mailing list
> muine-list gnome org
> http://mail.gnome.org/mailman/listinfo/muine-list