Proposal: generalize playlist concept - short version with pics

[Bart Cerneels]

On Sun, Jan 11, 2009 at 5:54 PM, Pavel Shved <pavel.shved at gmail.com> wrote:
> Hi again.
>
> Thanks to Bart and Mark for help and forcing me to reword the proposal.
>
> ***
>
> As many developers noticed, what actually amarok plays is a queue of
> tracks.  But the playlist is an array of tracks.  The array concept does
> support random jumping here and there, but the queue concept does not.
>
> This concept clash leads to many hacks and lack of logic in development
> and visualization of such features as random track/album selection,
> queuing, `stop after'--with support of properly handling "Previous
> track" button pressing.
>
> One part of proposal is to make amarok play Queue instead of Playlist,
> the Queue being painted in separate window/widget and allowing
> interaction with user (i.e. enqueue track by explicitly dragging it to
> Queue widget ).  Tracks are pushed to Queue from Playlist
> (sequental/random playback of static playlist) or from Collection
> (dynamic playlist).  This proposal is not new and had been discussed
> already.
>
> (the following, i believe, is my original proposal)
>
> It's fairly obvious that Queue contains the same items that Playlist
> does.  We can note that--as containers--these concepts do not differ at
> all.  The only difference is that amarok picks new tracks from singleton
> Queue and something else pushed tracks to this Queue from other locations.
>
> The way how it pushes tracks to Queue is going to be visualized via
> selection in menu or toolbar: as `random' option being selected, for
> example.  I propose to rework it:  we'll add an item to the end of queue
> instead; like that:
>
> Queue:
> +-----------------------------+
> |     Track 1                 |
> +-----------------------------+
> |>>>  Track 2                 |  <--- currently playing
> +-----------------------------+
> |     Track 3                 |  <--- next track picked via factory
> +-----------------------------+
> | +++ Pick random track from  |  <--- special `factory' track.
> | +++ playlist  (97 left)     |
> +-----------------------------+
>
> When Track 2 finishes playing, amarok starts playing next track from
> queue.  It also takes one track from factory for user's convinience:
>
> Queue:
> +-----------------------------+
> |     Track 2                 |
> +-----------------------------+
> | >>> Track 3                 |  <--- now playing this
> +-----------------------------+
> |     Track 4                 |
> +-----------------------------+
> | +++ Pick random track from  |  <--- special `factory' track.
> | +++ playlist  (96 left)     |
> +-----------------------------+
>
> At the end, after factory yields its last track, it disappears and
> playback stops.
>
> We can introduce several factory tracks:
> 1) Pick random track from playlist;
> 2) Pick next track from playlist;
> 3) Pick track from collection according to bias;
> 4) Pick next track from playlist according to bias;
> 5) (Pick no track and) Force playback stop.
>
> But now we can notice that Queue doesnt have to contain only one factory
> track!  So we can set Queue to pick 100 tracks from playlist and then
> play whole collection, press play and enjoy.
>
> Queue:
> +-----------------------------+
> | >>> Track 1                 |  <--- picked from playlist by factory
> +-----------------------------+
> | +++ Pick random track from  |  <--- special `factory' track.
> | +++ playlist  (99 left)     |
> +-----------------------------+
> | +++ Pick random track from  |  <--- another special `factory' track.
> | +++ collection (infinitely) |
> +-----------------------------+
>
> With ability to customize factory upon clicking it, it will allow users
> to have nice visualization of what is going to be played and control of
> it; programmers will have cleaner concepts.
>
> By the way, couple of paragraphs ago i said that Queue and Playlist
> contain same items.  Playlists can contain factory tracks as well.
>
> Other features are useful.  For example, party mode:
> Queue:
> +-----------------------------+
> | >>> Track 1                 |  <--- picked by factory
> +-----------------------------+
> | +++ BIAS:                   |  <--- special `factory' track.
> | +++ 50% from Playlist 1     |
> | +++ 50% from Playlist 2     |
> | +++ (199 tracks left)       |
> +-----------------------------+
>
> For futher details, why it's cool, as well as for other details, refer
> to ADHD version in one of previous threads.  Queue is called genlist or
> `generalized playlist' there.
>
> Pavel.
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>

I understand what you want do do now. I even see the benefits.

This in fact looks a lot like what I had in mind a year ago for
Meta::Playlist and the way those would interact with The Playlist (on
the right). Your "factory" tracks are my Meta::Playlist. It's the
superclass for RandomPlaylist, BiasedPlaylist, PodcastChannel, ...

I since then let go of the idea to let the queue "Observe"
Meta::Playlists for changes and add tracks according to that. Because
it would get very complicated, very soon. Also the TrackNavigators
were introduced then and it worked. I was to busy to contribute at
that time.

But a tabbed playlist is also not something I feel I want to see
introduced in Amarok 2 any way. Looking at unchanged Playlists can be
done in the PlaylistBrowser. Perhaps that is an option in your
proposal.

Bart