Re: Playlist requirements

David Hough wrote:
> On Sun, 19 Oct 2003 19:52:36 +0200, Ralf Engels <[email protected]> wrote:
> 
>> Hi,
>> seems like I started a big discussion with my mail about the database.
>> I have a proposal. One shortcomming of the open source development is 
>> that it doesn't use some kind of process.
>> I want to propose something.
>> Let's collect this week all requirement that we have for the playlist. 
>> Just send your requirements and we will collect them at the end of the 
>> week.
>> Maybe Kristian can filter them on Friday.
>>
>> Next week we will fill it out with hard technical requirements (e.g. 
>> Playlist class needs search)
>> and after that make the required changes.
>> In this way we can be sure that we all agree what we want, and that 
>> nothing will be forgotten. Additional we only needed things will be 
>> kept. Code that we don't need any more can be removed.
> 
> 
> 
> I agree, this seems a reasonable way to go about creating a new 
> playlist/metadata structure in a well designed way. Lets wait until we 
> have a full and agreeded upon specification before we go about working 
> out how to implement it. So here's some quick ideas from me:
> 
> 
>> 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.


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

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

>> 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
This is something that would occur in the database.  Linking the 
playlist to single occurrances of a metadata object would be cpu 
intensive as it would have to scan a list of metadata objects already 
created everytime a URI was added and check counters to a metadata 
object everytime a URI was removed from the list.  That's something like 
O(n) complexicity, if not worse.

Yet, we cant have so many copies hanging around in a playlist that 
references other lists that reference back on the same files over and 
over.  So i propose this.

When creating the list, the playlist manager creates a single flat list 
of all streams 1 instance only. It then has a vector of pointers and 
creates the playlist as it's supposed to be just pointing back to the 
elements of the first list whenever needed.  The player reads from this 
pointer vector list and inserts and deletions are only inserts of 
pointers when the stream already exists and such.  Once a real playlist 
item on the flat list has a reference count of zero it's removed.

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)



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

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

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.



> 
> 
>  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 OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54