Re: Playlist requirements

On Mon, 20 Oct 2003 17:58:26 -0400, Ed Sweetman <[email protected]> 
wrote:


....
>>> Ok, so I start with my requirements:
>>>
>>> r1. there shall be a list with songs that can be played.
>>> r2. it shall be possible to add songs to the list.
>>> r3. it shall be possible to remove songs in the list.
>>> r4. the list shall be independent of the ui
>>> r5. the ui shall be informed about changes in the list
>>> r6. it shall be possible to randomize the list (I don't need a random 
>>> play as long as I can shuffle the list)
>>
>>
>>  r6.1 it shall be possible to switch back to a unrandomized list while 
>> maintaining current position in playlist (equivalent of turning random 
>> play off while listining to a playlist)
>
>
> random playback and shuffle are two different things.  Random playback 
> makes no changes to the actual list, shuffle does.  This is not my 
> creation, it's just what it is. Random playback would simple choose the 
> next song not by it's position but by random values.  Shuffle 
> re-arranges the tracks but continues on in playback mode by order.
>
> The playlist manager should be able to handle both situations.  With 
> possible reversal of shuffle mode handled by by the UI since all it 
> would do is tell the playlist manager to reload the last saved copy of 
> the list and that's all the playlist manager would do too, no sense in 
> making that a function of the playlist manager.


That sounds resonable, perhaps we should also specify the ability to have 
different random modes, e.g. pick random albums, not tracks, or whatever. 
So I propose this

r6 It should be possible to pick a random node of a specific type from the 
playlist
  r6.1 It should be possible to automatically do this when picking the next 
track
  r6.2 It should be possible be possible to sort the playlist in this manner


>>> r7. the player shall use the list to determine the next song to be 
>>> played.
>>> r8. it shall be possible to save the list
>>> r9. it shall be possible to load the list
>>> r10. different formats for the playlist shall be supported
> by format for the playlist, do you mean how it's physically laid out in 
> the file or how you create the dynamic playlists in the manager?  I'm 
> fairly sure everyone uses a flat list these days.  The only other type 
> of support i can imagine is automatically asssuming lines not beginning 
> with a comment char or some protocol:// are file://
>
> r11.  It shall be possible to dynamically generate lists
> r12. It shall be possible to manipulate the list in all means required 
> by the player and any functionality used in components of the player.


This seems rather generalised, what means/functionality specificly are you 
talking about?


>>> Playlist item requirements
>>> r101. the URL shall be the unique identifier of an item
> Not possible.  Two items can have the same URI, i say URI because URL 
> refers to just world wide web links, URI is all encompassing to the 
> whole :// string thing.  This is just not something that is possible 
> unless you make it a rule that two tracks cannot be in the same playlist 
> and that doesn't sound like good playlist handling.
>
> r101.  The item will be identified by 2 indexes.  The first index is the 
> index of the branch the item is in, the second index is the index that 
> the item is in that branch. There is no reason why the UI needs to talk 
> to the playlist manager by human readable strings.


This suggests that you can only have one level of child urls, or by index 
do mean an index that can specify being anywhere in a tree structure 
including multiple parents? How about:

r101. Items should be identified by a single index that represnts a 
location in a tree type structure. e.g. a tree path


>>> r102. the meta data of the item shall be determined on demand
>>> r102.1 meta data of items with the same URL shall not be doublicated
.......
> so
>
> r102.2 No data shall be duplicated.
>
>
>>
>>
>>  r103. items should be able to change depending upon the contents of 
>> music catalog (i.e. dynamic playlist)
>
> Items change ? Dynamic playlists are simply a means to direct the player 
> to another list, in effect, inserting a list in positions where the tag 
> is. The changing items part i believe you are referring to is how the UI 
> handles them.
>
> r103.  Playlist items should be able to reference other playlists 
> inline.  (i.e   dynamic playlists)


What I meant by this was if the database changes, I add some tracks to an 
artist for instance, and I'm also currently listining to a playlist that 
has the url for that artist in, I want the playlist to automatically 
reflect this without me having to tell it too. I shouldn't have to click 
refresh playlist or whatever and then have the entire playlist 
regenerated. This would probably mean that the database would have to 
inform the player when it changes, but thats a technical issue which 
should be sorted out later.


>>
>>> Music catalog requirements
>>> r201 ?? I don't need such a thing.
> I see no point in having a music catalog if the playlist manager is 
> written correctly.  In essence the music catalog would be the UI to the 
> playlist Manager.  nothing more.

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. Having the 
metadata stored in memory with the playlist or however its done just over 
complicates things. We should sort this out later though, once we've 
sorted out the requirments

> if this is the name for the UI to the playlist.

How about having a seperate section for implementation requirements for a 
playlist UI

Playlist UI requirments
> r201.  No direct manipulation of the playlist manager's list allowed.
> r202.  Only playlist functionality directly related to the aspect of the 
> UI shall be implimented in the UI. All non-ui specific functions belong 
> in the playlist manager.
>

What I imagine is meant by the Music catalog is basically the interface to 
the database(or whatever source it comes from) of metadata. Hence my 
previous requirements below,


Music Catalog Requirments
>>
>>
>>  r201. Metadata about URLs should be cached
>>  r202. It should be possible to read metadata from various sources
>>  r203. Metadata should only be read from an external source on demand
>>  r204. It should be possible to do searchs on cached metadata
>>
>>
>>> Ok, that is just the start. Other can continue with the list.
>>>
>>> BR,
>>> Ralf


-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


-------------------------------------------------------
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/