Re: [Muine] Re: Muine (!) Relicensing

On Tue, 2005-01-11 at 12:03 -0800, Tamara wrote:
> > > Splitting off "MusicManager" and "MusicPlayer" would *reduce* the size
> > > of Muine and make it *simpler*. It would also be a plus for Beagle as
> > > well as RB. I would be doing it for the reason of simplification and
> > > reducing bloat.
> > 
> > It would only take out the few hundred line Player.cs, not something I
> > would call a considerable reduction ..
> Um... no. It would remove all the metadata, GStreamer, and Xine code
> from libmuine as well. Managing the Song and Cover Databases would
> move as well as Amazon Cover / CoverGetter stuff. It would split Muine
> in two.

You want to move the DB stuff as well? There's even less point there ...
RB has much higher requirements for DB than Muine. Muine just uses a
very, very simple and light gdbm database to do the job- using the same
monstrous DB backend as RB uses would slow things down.

(Also - The xine and our own metadata code will be obsolete soon.)

> > Yea, but either way, it is bloat for something that is already way
> > simple. I mean, basically all we need to do for GStreamer playback is to
> > create a 'playbin' element. Why should this 'playbin' element be
> > embedded in all kinds of fluff, and thereby creating regressions for all
> > the using apps as well? (non-instant depausing (see later in this mail)
> > is the first to spring to my mind)
> Because it would manage all music playing on a system. The app would
> request a list of songs from MusicManager, the user would select one
> and request the MusicPlayer play it. Also, MusicPlayer would
> dynamically switch between Xine and GStreamer support.

Way over the top is my opinion, as you know by now. :)

> > > It wouldn't send that much data over D-Bus anyway, just status changes
> > > and exceptions. You wouldn't have to update it every second or
> > > anything like that.
> >
> > > > The "MusicPlayer" would have to be quite sophisticated for starters,
> > > > because you need to support having more than one stream open at a time
> > > > (for instance one from muine paused, and one from your-random-other-app
> > > > playing, for instance). Etc.
> > >
> > > You wouldn't need more than one stream open at a time. If the user
> > > wants to play two song simultaneously (e.g. mixing), then MusicPlayer
> > > would be not the right place to do that.
> > >
> > > Starting playing in one app would pause it in the other. To resume,
> > > the app would just send the play request and the position to start
> > > playing at.
> > 
> > Yea, I know that seems possible in theory. But in practice it is very
> > hard or impossible to seek back to *exactly* where you left off in the
> > case of VBR files, and it's not exactly responsive if you have to open
> > and decode the file first.
> Couldn't we just use a file offset? I admit I don't know that much
> about music files...

You can't just do that, because in the simplest case you first need to
read the file's header. In a VBR case, you need to know what the bitrate
at that point is. In a chained ogg case, you need to know what part you
are in with what samplerate, etc.

> > Really, as every app has their own playback requirements, it is much
> > better for them to talk to GStreamer in their own way. For instance, an
> > internet radio player will have much different requirements from a
> > regular player.
> > 
> > I've been working a little on an iradio player in the spirit of Muine,
> > and the thing I'm thinking of doing is sending a signal to the bus,
> > something like "MusicStartedPlaying". Which the other app would pick up,
> > and subsequently pause their stream.
> But it would make good sense for the multitude of normal music players
> to share a common backend. A change occurring in one might as well
> propagate to the others. Therefore a user would just use the front-end
> of her choice (panel applet, small app like Muine, more robust app
> like RhythmBox) and not have to remanage her music in each program.

Having the same user use different music playback apps is definetely not
the kind of user Muine targets. 


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