Re: Introducing Muine, Rhythmbox in 2.8 and other things

On Fri, 2004-05-07 at 07:25, Jorn Baayen wrote:

> The reason I started to design Muine is simple. The iTunes model works
> relatively well, but it has issues, the most prominent one being
> queueing music not working transparantly and smoothly. 

I think there are at least two kinds of people; the "album picker" kind
and the "DJ" kind.  The album picker people (like me) generally just
pick a song, artist or album to play, and when it's done, pick another. 
Or just leave the player on shuffle.  Rhythmbox works pretty well for
them, I think.  The DJ people really want to queue up songs or albums,
and as you say, Rhythmbox doesn't work very well for them.  I would note
that it still can work - you can create a playlist and drag and drop
things in there.  But for the DJ people, Muine is probably far more

> With Muine I have
> tried to design an interface that accomodates a music library,
> transparant queueing, easy "xmms jump to-like" access to songs and
> albums, and soon grouping[2] music transparantly. Whether this has
> succeeded is of course debatable, but I am very interested in feedback.

I think it's unquestionable you succeeded in your goal.

> There are a couple of outstanding issues too:
> - CD ripping. It would be great to have a standardised place where to
> store music (~/Music or something), where sound-juicer would dump its
> ripped files by default and where Muine would pull its music from by
> default.

Yes!  We should really standardize this for GNOME 2.8, especially since
sound-juicer won't use Bonobo, and D-BUS isn't currently planned for

> - Internet radio

I've been thinking about this recently.  Some people have suggested
internet radio should be broken out of Rhythmbox in the past too.  But I
think to do so would be to mostly miss the point of Rhythmbox.  The idea
is to be "the" music playback program.  When you want to play music
(whether that's local, CD-ROM, or internet radio), you launch "Music
Player" (Of course Rhythmbox currently fails in that it doesn't play
CDs, but it shouldn't be too hard to add).

Having separate applications for all these things is clean in one sense,
but it's also weird in another.  Like right now, both Rhythmbox and the
GNOME CD player have tray icons.  If we broke internet radio out into a
separate application, would you then have three tray icons?  If we only
had one, which application would it apply to?

You also have large chunks of redundant UI among all three.  

> - Full-blown tagging
>   Full-blown tagging, including Musicbrainz support, replaygain
> calculation and all that in my opinion belongs in a separate app
> designed for the task. 

For musicbrainz, doing stuff like conflict resolution, you really do
need a separate application, I agree.

> - Visualization
>   This belongs in a separate application, or xscreensaver module or
> whatever. 

For Rhythmbox, I think it makes sense to do visualization.

> This app could read data from a sound server.

Well, we need a good one of those first :)

> There has been talk about proposing Rhythmbox for GNOME 2.8.  I'm not
> sure it is a good idea to include *any* music player in the desktop
> release.  Something that plays music files, like totem, is a must in my
> opinion, but a full-blown music player is not something everybody will
> use.  I mean, having a full blown music playback application in an
> office workstation seems a little out of place.  

I think music playback should be regarded as a pretty crucial feature of
the desktop nowadays.  GNOME isn't just targeting office workstations,
keep in mind.  And even there, I think music playback is pretty

> Other than that Rhythmbox has its usage problems which are
> extremely hard if not impossible to fix properly

For some people, yes.

>  (I've been trying for
> more than a year), and I'm not sure shipping an iTunes clone (not
> entirely of course, but basically) in the core desktop is too good for
> GNOME's image.

Well, we didn't exactly invent things like web browsers, file managers,
calculators, text editors, or email programs either :)

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]