Playlist Navigation (was: Queue Manager)

[Seb Ruiz]

On 9 February 2010 22:38, Marius <furt at gmx.de> wrote:
> on Monday 08 February 2010 22:20 Bart Cerneels wrote:
>> On Mon, Feb 8, 2010 at 22:00, Seb Ruiz <ruiz at kde.org> wrote:
>> > Whilst I am not against the feature (I wrote it in 1.4), we did
>> > explicitly remove the queue manager for Amarok 2.x. I can't remember
>> > the exact reasoning, except that it was deemed overkill and
>> > unnecessary in the face of culling features.
>> >
>> > Has there been any change in direction in this regard, and do the core
>> > Amarok team regard the queue manager as a worthwhile and reasonable
>> > feature to implement, regardless of who does the work?
>> >
>> > --
>> > Seb Ruiz
>>
>> Nope, I personally still think it's useless feature creep that will
>> only increase the complexity of the  playlist.
>>
>
> While I don't know about the previous discussion on the queue concept, I think in its current state amarok needs a queue manager. I guess we agree, that the user should be able to define which track or tracks are played next - be it because he personally likes them, or they are wishes by listeners (at a party), or whatever. If he is able to do that, he should be able to change that list of queued tracks.

This is the extent of the functionality of the queue manager from Amarok 1.4

>
> Furthermore he should be able to compose sets of tracks and easily play both
> whole sets (random or ordered) and single tracks from a set in a defined order.

I don't see any reason why we should support such a feature.  This is
introducing an increased complexity (which even I struggle to
understand) to a feature which was always intended to be bare bones.
The Amarok team was split over implementing queueing - so we settled
on a simplistic implementation; we wanted to avoid the playlist within
a playlist paradigm which can be so confusing.

>
> One way out of this is a queue manager. But additional thought brought me to a
> new idea: if we had a way to use a non-random current playlist *and* still be
> able to play saved playlists in random order, the need for queue concept would
> be totally superseded. You could simply drag the tracks to be played next
> behind the currently playing track.

this is what the dynamic playlist is.

>
> For that we would need a dynamic playlist which plays tracks from a saved
> playlist in either random or non-random order (*wah*, we have way to many
> things called playlist :) ). Ideally, this dynamic playlist could easily be
> "programmed" by rightclicking on an existing saved playlist and select
> something like "play now".

Much like in Amarok 1.4 - a dynamic playlist could be seeded by a
smart playlist (with random ordering or what not)

>
> Additionally we have the problem, that the current playlist tends to become a
> mess of random tracks, like the desktop of older windows distributions, which
> makes navigating and ordering quite hard. That is because for anything you do
> with saved playlists, you need to put tracks on the current playlist. You
> can't drag tracks directly from the collection to a saved playist, but have to
> go the indirection through the current playlist. It's also rather hard to drag
> tracks from one playlist to another if you have many playlists or playlists
> with many tracks. If you want to create a new saved playlist, you even have to
> clear the current playlist, drag the desired tracks for the new saved playlist
> on it and save it - that's obviously not possible while playing another set of
> tracks.

So the solution here isn't a queue manager, but rather to allow drops
onto the playlist browser.


> Summing up, amarok in its current state needs a queue manager.
> If we polish the handling of saved playlists, the queue concept is rendered
> useless. To achieve that, we need an easy way to access and navigate through
> saved playlists and an easy to use dynamic playlist, which plays tracks from
> saved playlists.

I think this may be contradictory - you say that Amarok needs a queue
manager, but then say that queues are redundant with better saved
playlists.

Maybe you have missed the *simplest* case for queueing, which is
indeed why it exists:
   "There are many tracks in the playlist, which are played in random
order. On the spur of the moment, I see or think of a track that I
would like to hear next, and want to continue randomly afterwards."

> A decent saved-playlists-browser would be cool, probably with the possibility
> to open one or more playlists in a new window and drag tracks between them,
> the current playlist and the collection.

I doubt this would get implemented (see the topic on Feature Creep)


-- 
Seb Ruiz

http://www.sebruiz.net/
http://amarok.kde.org/