[Feature]: implement queuing such as is done in the Spotify app about amperfy HOT 22 CLOSED

This looks really interesting and helpful. I think I will add this feature soon.

from amperfy.

Thank you for this in depth description. This feature is really nice. I think the time to implement this is quite high. I add this to the feature list.

from amperfy.

Waiting is implemented with these two commits: f02233b 2c31d0a

Currently only songs and podcast episodes can be added to the waiting queue via a right swipe.

from amperfy.

I renamed it to "Next in Queue" with be933d8

from amperfy.

1. is currently not implemented, you are right.
After my vacation I will implement 1. and 2.a).

from amperfy.

Would you still like a more in-depth description of the spotify behavior? I can try to do a little write up on what exactly happens when and how.

from amperfy.

Yeah I think a in-depth description would be nice.
I was thiniking of simply adding the song to the player as next song to play.

from amperfy.

In spotify you have a user queue and what I'll call a context queue a third
element of spotify's queuing system is the current song. The queues can
be seen in this screenshot, the text of
spotify itself is not that important and in Dutch but you might be able to
understand it just fine if I'm to believe the domain of the email address
on testflight, hello neighbor! :)

Current Song

The current song, can be mutated by the following three actions:

1. Action c1: A song which is played manually because of user interaction
   i.e. clicking on a song, shuffling a playlist, album etc.
2. Action c2: The following song in the user queue
3. Action c3: The following song in the context queue

Context queue

The context queue is mutated by action c1 and c3. Action c1 changes the
whole context queue depending on what the context of the manually selected item
is, e.g. an album, artist, playlist, genre (which don't exist in Spotify but
I'd imagine it should be part of this list in Amperfy) and others. Action c2
obviously just pops the top item of the user queue which then becomes the
current song. Action c3 is the same but will only occur whenever the user
queue is empty.

User queue

This is what makes the Spotify queuing system special and very nice to use in
my opinion.

The user queue is only mutated by the following actions:

1. Action u1: The user queues a song in one of two ways:

   1. The user swipes a song to the right such as can be seen in this screenshot, the song will then be appended to the user queue which is FIFO by default instead of the default LIFO of apple's queuing system.
   2. The user rearranges the order of the user queue or adds new songs from the context queue to the user queue by grabbing the handlebars as indicated by a red circle/ arrow in this screenshot

2. Action u2: The head of the queue becomes the current playing song, this occurs together with action c2.

3. Action u3: The user can wipe the whole user queue using a button which can be seen in this screenshot with a red circle around it, the button text says: "Erase queue".

As you can see all of these actions require manual interaction of the user. Changing the current playing song and context queue don't mutate the user queue.

Why is this so handy? Well say that I want to have a nice queue of songs before stepping into my car, so that I won't be distracted by choosing music to play while driving, I queue some songs but I'm not sure whether I'd want to play song X. When using the apple music app it's game over, I can't play the song since it will wipe my queue, I can only queue the song play it and then decide whether I like it. In Spotify you can play the song without having to worry about changing the user queue since you can change the current song without mutating the user queue.

In the Apple Music app there's no separation between the user queue and context queue which I think is insane. If I'm queuing songs it means just directly playing some genre, artist or album didn't suit my needs and I didn't have a playlist which fits the occasion either. If I wanted to use the context queue I wouldn't have used the user queue anyways! It seems that in the apple music app queuing is seen as an extension of playlists while in Spotify it serves as another mechanism for when no playlist or context is appropriate.

I hope this was somewhat of an in depth explanation instead of unclear ramblings but if anything is unclear I can add details.

from amperfy.

I am currently working on this feature and I have some questions regarding the behavior.

As example please take a look at the following picture:

There we have the red songs 1, 2 and 3. Currently the songs "Example Artists - Good Morning" is playing.
What is the expected behavior when I press on song red 2?
(a) Is song red 1 removed from the user queue without playing? => song red 2 is playing and the user queue displays song red 3
(b) Is song red 2 prioritized higher? => song red 2 is playing and the user queue displays songs red is 1, 3?

An other important question: What happens with songs from the user queue if they have been played?
(a) They are simply removed and are not displayed in the Player anymore?
(b) They are displayed in the played previous section (same behavior as regular played songs)?

Should the swipe to the right also be available in the Popup player view or only in the library views (songs, playlist details, ...)?

How to name the section names? Currently the section names in the PopupPlayer are "Previous" and "Next". How are the new sections should be named (there are now three sections or two if no song is in the user queue)?

• "Previous", "User Queue"/"Waiting Queue", "Continue after Queue(???)"

from amperfy.

Do artists/albums/playlists have the right swipe too?

from amperfy.

Just tried it out on Spotify, apparently they don't. But I think that could actually be a very nice improvement. They do allow you to queue the artist or album via one of those circles with three dots in them menu's. But I could really think of a ton of cases where this would be a lot nicer, think of queuing multiple albums whole because you'd like to listen to the whole album, in spotify this would take five taps and swipes in total, one simple swipe would be a lot faster!

from amperfy.

Could you please give me some feedback about the implemented behavior?
Behaves it as you expect it to be?

from amperfy.

Hi sorry for the delay. There are a few things I think could be polished. In short I think it would be nice to be able to queue everything, including artists, albums, genres, directories and playlists in the same way you queue songs. I also think the wording of the queue could be a bit better, I rather like the way spotify did it:

What's particularly nice about this queue is that it also shows you the context of what is playing next.

Would you like me to create new issues for these improvement suggestions or extend on them here?

from amperfy.

continued here: #85 (comment)

First of all a few definitions (because I noticed I use a lot of words of which the meaning isn't clear):

• Non user queue: the queue which isn't queued by the user but can be set by the user using the Play all button.
• Context: the context where from a song is playing which can be an artist, album, the Songs tab in the Library screen, genre, directory and playlist.

I forgot about a big one: automatic context switching of the non user queue. The context is changed whenever a user manually taps on one of the possible contexts enumerated above. Automatically switching the context would replace the Play all button and make the context switch implicit. As far as I can think of this reduces the amount of clicks needed to get the queue like you want it quite a lot and works really well together with a user queue since the user queue never changes context (it doesn't have one either). It would furthermore then be possible to replace the Play all button with a shuffle button (the functionality of the play all button is replaced by simply clicking the first song in a context). This further reducing the amount of taps needed to shuffle which currently takes two taps. Two taps isn't that much but for some users like me who mostly shuffle certain playlists these two taps add up, with a shuffle button it would only take one.

Here's an example use case to show how automatic context switching reduces the number of taps needed. If a user wants to play all songs in a playlist which come after certain song in a playlist what you'd have to do at the moment is add the whole playlist to the queue, open the queue, scroll down to the song (which can take quite some time if you've got a big playlist) and tap on the song. If I counted correctly this takes 4 taps excluding the scrolling needed to find the appropriate song in the queue.

If the context of the non user queue changed automatically you'd be done by clicking on the song in the playlist, thus only requiring one tap.

Again, I can open another issue for this and can think of more use cases if you're not quite convinced yet. Let me know what is best for you.

from amperfy.

I agree, everything should be queueable. I will add this for the next release.

The complete context switch/ "play all" behavior is a lot more effort that I will not implement till the next release.
I am also not quite convinced about this context mechanism.
The naming of the queue makes sense if the player context is implemented.
Your explanation was good and I think I have now a better understanding of your request.
Could you take your explanation above and open a new feature request?

Are there any other suggestions regarding the current "waiting queue" implementation?
Should the waiting queue still be renamed?

from amperfy.

referencing #34 (comment)

The naming of the queue makes sense if the player context is implemented.
Are there any other suggestions regarding the current "waiting queue" implementation?
Should the waiting queue still be renamed?

I think it would still be a good idea to rename the user queue from Waiting Queue to Next In Queue, if automatic context switching is implemented the context could always be added to the non-user queue. Even more so, Spotify desktop does the same and doesn't indicate the context.

from amperfy.

Did you get time to test this feature in beta v1.1.0?
I am interested to hear if there are any bugs or adjustments needed for this feature.

Is the behavior correct if a song from a new context is played?

from amperfy.

As of now it seems there are some bugs in the new queueing system, there seem to be some weird interactions between queued songs and the context queue.

If I for instance queue a song to the user queue and press play on a playlist the expected behavior would be that the playlist would start playing and the queued song would be played after the current song if I skip to the next song. Currently however the queued song is played when pressing the play button.

Another example is if I queue something to the user queue (or something which had previously been queued in the user queue is playing) pressing play on any other song doesn't work.

I'll pay closer attention and figure out what is happening exactly, I'll try and see if I can figure some more out by looking at the code as well. Since it's not completely clear to me currently whether these behaviors and functions are bugs or if you meant to implement them like that. So for now I think it's best to leave this issue open and resolve other potential bugs in new issues.

from amperfy.

OK thank you for your feedback.
Your mentioned bugs are currently intended behavior.
Here my questions regarding these edge cases.

1. assumption: there are some songs in the user queue.
   user action: the user presses on a song in playlist.
   expected behavior: the context queue gets replaced with the playlist of the pressed song. The pressed song gets immediately played. The context queue (previous and next) are according to the position of the pressed song in the playlist. The user queue is directly placed below the now playing pressed song (the next song which will be played is the first song of the context queue).

2. assumption: currently a song from the user queue is playing
   user action: the user presses on a song in playlist.
   behavior question: now playing song and context queue should behave like 1). What happens with the previously playing user queue song: a) it gets removed. b) it gets added to user queue again as the first item (it will be next song to be played)

The above describe scenarios should behave the same if the play button is pressed in a playlist (the first song of the playlist is the "pressed" song). Are the describe scenarios correct?

from amperfy.

Is 1. currently implemented? It doesn't seem to be in the current version on testflight. But the behavior described in 1. is exactly what I meant in my proposal.

1. Play a song from a playlist, i.e. don't queue it but play it directly by clicking on the song.
2. Queue a song from the same playlist to the user queue, called song A.
3. Press on another song from the playlist, called song B, now song A starts playing while song B was expected to start playing.

In regards to 2. I think a is most logical, given that when a song is playing already it is not part of any queue anymore. If I did want it to be part of the user-queue I shouldn't have skipped to it in the first place or should queue it again.

In short I think a currently playing song should not be part of the user queue. I suppose this should simplify the current logic for queuing quite a bit as well.

from amperfy.

Is the queuing behaviour now correct?

from amperfy.

It seems so yes, although there might be some edge cases but in general the functionality is very very good so it isn't noticeable if there are. I'll open a new issue if I find another bug. Thanks a lot for implementing this :)

from amperfy.