Re: Playlist requirements

David Hough wrote:
> 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?
It's not generalized.  Any manipulations dealing with the list need to 
be in the playlist manager.  It's a wire range of functions but that's 
the point.


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

No it doesn't.  Kristian used a similar approach.  Mine just cuts the BS 
with the URI resolution.  All branches off the "trunk" are indexed, in 
fact the trunk is merely index 0.  In the trunk eventually if it has a 
branch, will be a playlist pointer, pointing to the correct position in 
the vector of branches that the sublist is located at.  And so on.  The 
first index represents which element of the vector of branches to start 
our query from.  Then the second index asks where in that branch our 
actual query is.

your actual playlist would then be something like

0 - - - - - X
1 - - - X - - -
2 - - - - - X - - - -
3 - - -

where -'s are streams and X's are links to a sublist Your first index 
would then be 0-3 and the second would correspond to a position in that 
list.  In this way we can uniquely map all streams in the entire 
playlist with two numbers without having to traverse the entire list or 
any of the list for that matter.


> r101. Items should be identified by a single index that represnts a 
> location in a tree type structure. e.g. a tree path
wont work with sublists.  A single index means very combersome inserts 
and remove procedures.


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

This would require polling a directory.  Something that would be built
into the method that handles those types of URI's.  It would also require
the UI to figure out the playlist has changed.  This is something that
would probably end up being a dirty hack in the current incarnation of zinf


> 
>>>
>>>> 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
The playlist does not know. It is separate. The UI has no need
to communicate directly to the metedata manager and the playlist manager 
has every need to communicate with the metadata. So we make it that way.
The Metadata is still controlled by an independent class, it's just 
coded so the playlist manager is the only class that can mess with the 
metadata.  This means the UI only has to talk to one object interface, 
the playlist manager, instead of arbitrating it's playlist how it sees 
fit, rendering it from metadata or not and deciding which URI's in the 
playlist match to which metadata. We can take care of all of that with 
less layers and less copied data by having the playlist manager control 
it all.  The playlists however, are completely independent from the 
metadata.  The metedata is rather a child object of the playlist manager 
in the same way that the playlist is.  Both are closely related and used 
in similar function and this is required for efficient uses of your 
query functions based on metadata.


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

This would be my metadata manager and it has no user interface as i 
stated above.  All of your requirements are in one way or another 
addressed by it though.

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




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