Re: metadatabase

On Sun, 2003-10-19 at 11:08, David Hough wrote:
> On Fri, 17 Oct 2003 20:21:51 -0400, Ed Sweetman <[email protected]> 
> wrote:

[snipped]

> As far as I can tell your implementation dosen't provide a simple way of 
> viewing the entire expanded playlist as a single flat list which is a view 
> that will be needed. Personally I think the list should be represented by 
> a map of URLs with a tree path as the key, something like this quick 
> example:
> 
> class Playlist {
> 	std::vector<std::string> base_list;
> 	std::map< std::vector<uint32_t>, std::string > expanded_list;
> 	
> 	void generate_expanded_list();
> 	void read_children(std::vector<uint32_t>& parent_path, 
> std::vector<std::string>& urls);
> };
> 
> The base list would be the list of original URLs for the playlist, and the 
> expanded list would be a list of tracks that were expanded from the base 
> list. This way you can do simple random access to tree by just reading the 
> URL associated with a path from the map, and the playlist manager can move 
> through the playlist using an iterator on the map.

This is a start, but I see trouble.  The base playlist is the top level
set of unexpanded URL.   The expanded list is the full tree.   
There doesn't seem to allow  access to the simple set of
a sublist or is that what read_children does?

Also I don't think it a good idea to try to keep a map of what
are essentially iterator values to the elements.   Let's try to model
what we have: a tree of playlists.   Each node is playable item,
some nodes are expandable.   We then provide access to the tree
using whatever path structure make sense.

> The UI could read the base urls and then get specific children from the 
> expanded list using the read_children function. This way the UI would 
> always be in sync with the playlist as it would be reading the children 
> directly from the playlists own expanded view.
> 
> This interface does provide both a tree view of the playlist and flat 
> view. The flat view would just be the std::strings in the map, and the 
> tree view is implemented by having a tree path asssociated with each url. 
> I haven't got around to writing an example implementation of this class, 
> but I would expect that the algorithms needed wouldn't be that 
> complicated.

Again I think the data structures should model the concepts more
closely.


class playlist {
    std::list<url_t>   m_urls;
    // Simple functionality on a flat playlist (wrapper for list)
};


class playlist_tree_iterator ;    //vector of  indexes 
class playlist_tree  {
    playlist   m_root;
    // Path based routines.
    insert (playlist_tree_iterator  path, url_t) 
    erase (....)

    playlist&  root_playlist()
    plalist_tree_iterator currentItem();
};

All the machinery for dealing with recursive playlist would be maintained
in the playlist tree.   The editor would probably often need to only deal with 
the simple playlist (the UI would choose which is the current simple playlist).
The player would see playlist_tree as a set of simple playlists and 
playlist_tree_iterators.

I would like to be able to say something like:
 playlist_tree a;
 vector<url_t> list;
 copy(a.begin(), a.end(), inserter(list, list.begin()));
which would give a flat list of urls in the vector.


We also need to expand the concept of random play mode in the player.  Let's say
I have recursive playlist made up of albums of artist X.   I want the 
albums to play in random order but not the songs or vice versa.  
Each level in the hierarchy will need some sort of play mode
in the player.  
But I digress..


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



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com