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/