Re: Playlist requirements

Kristian Kvilekval <[email protected]> Sat, 25 Oct 2003 15:13:19 -0700
Newsgroups gmane.comp.audio.zinf.devel
Message-ID <1067119998.25758.7.camel@krispc>
On Sat, 2003-10-25 at 11:46, David Hough wrote:
> On Sat, 25 Oct 2003 17:55:26 +0100, Robert Hart <[email protected]> 
> wrote:
> 
> > On Sat, 2003-10-25 at 18:40, David Hough wrote:
> >
> >> I still believe that the metadata interface should be seperate from the
> >> playlist/playlist manager as there is no reason why the playlist needs 
> >> to
> >> now any metadata about any url, apart from its child urls.
> >
> > I'm confused, you talk about the playlist being able to sort/randomise
> > according to things like "Album", "Artist", (and by inference) date,
> > genre, etc.
> >
> > Yet at the same time you seem to be saying that the playlist wont "know"
> > this information....
> >
> Thats a very good point. I hadn't considered exactly how such a randomise 
> feature would be implemented. The point I was trying to get across though 
> was why cache metadata in the playlist memory structure, when its much 
> easier and uses less memory to just read it from the database/metadata 
> catalog when its needed. And if you're just going to read the metadata on 
> demand (usually on demand of the UI, although in the point you made it 
> wouldn't always be from the UI) why confuse the playlist manager interface 
> by having external functionality that has very little to do with playing a 
> list of URLs.
> 
> So, I was probably wrong to say that the playlist manager never needs to 
> know this information, however just because it may actually need it 
> internally occasionaly, does not mean that it should be used to provide 
> the metadata interface.


I suggest keeping the static state of the playlist (the list of URL's)
different from the dynamic state of the playlist player i.e. the 
current index, playmode (repeat etc), randomize, etc.   

The basic functionality common to all playlists is the list of
urls functionality.     The next level of functionality is the 
ability to interpret recursive playlists.  And finally, there
is the dynamic level or the player playlist functionality.   

The UI is probably interesting in the base/recursive level.
While the player would have all sorts of other information.

I see a hierarchy of playlists types or even keeping the 
player (dynamic) info in the player itself.

-- 
Kristian G. Kvilekval
email:[email protected] office:(805)893-4276 http://www.cs.ucsb.edu/~kris



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/