-
-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extended queue UI #92
Comments
I can add this. Simple as adding a header item and updating the item moving logic.
This sounds like a good idea. The best balance between retaining the current sensible "only show the next items" while still allowing someone to play from the next loop.
I'm planning to add a like button to the side of the song name/artist name/album name UI elements. As for a sleep timer, that doesn't really benefit my usage. The biggest candidate for a companion is perhaps a "cast" button, but I have no idea how that would work. I'll put that idea on ice for now.
Sadly there are too many touch events in the queue by itself to implement this in a nice way. I've tried to do it before, and what would happen is the following:
These are some really good suggestions. After I try to tackle some of the technical debt [Notably #72], I'll try to work on this. My current plan will be the following:
|
Thanks! as for the next queue cycle, as long as you have repeat queue on, it should just put played songs from this queue at the end, so the queue stays the same after any amount of playback.
as for next cycle items not being editable, that's okay and probably simpler ux 👍 |
Yeah, that's what I'm going to do. Seems the most straightfoward.
That would probably require me to keep a separate copy of the next queue, which is not great. I'll think about it when I get to it.
The only difference between no looping and looping is simply whether Auxio continues playing once the queue loops. For the sake of consistency, the next queue cycle will probably always be the current queue. |
If this is ever implemented, could it be optional? I suppose its somewhat of a niche issue, but if you're planning something like a DJ set it can be helpful for a shuffle to persist. Ideally, this consideration would be reflected by allowing queues to be saved, but even then (especially if the queue has new music) it's not always clear that a shuffled queue is worth saving before you've heard it. |
interesting. 1) why would you use auxio as your dj software lol? 2) how is one shuffle better than another one? |
I thought I've already ruled out re-shuffling the queue like that? It would be a bit of a technical nightmare, and besides, if you wanted to re-shuffle the queue you could just turn the shuffle button on and off. |
fair enough. that's kinda what i've been doing with other media players so far, just tapping the shuffle button twice. |
I wouldn't, sometimes it is helpful to listen to music before chucking it into a mix. You've never been inspired by a jolly good shuffle?
You don't always know what order you want ahead of time (hence shuffle 😜 ). The idea is being able to capture what the shuffle did and revisit it later. This could also be done by manual seeding, but I guess most users wouldn't want that either (ignoring the pain of implementation). |
So, would you guys be okay with queue editing becoming a toggle? Basically, you would have to click an edit button to put it into an editable mode, and then once you are done, you would confirm or drop your changes. I say this because it would make gapless playback feasible (for internal technical reasons that are hard to describe), and also reduce the internal complexity of the new queue UI (I could remove the next loop and current playback items in the edit mode, so I don't have to deal with how those items react to queue edits) |
like, you would need to click an edit button before you're able to drag and drop queue items? |
Yeah, on the Toolbar. Then you would have to confirm the edits. This is to ensure that I'm only regenerating the internal player's queue once for a group of edits, compared to a bunch of times like it currently would be. |
that's reasonable, but now i'm already reaching my finger to the top of the phone for queue and the i'd have to reach to click edit and confirm/discard again. |
or, don't save the queue edits and regenerate until either you go back from queue view, or a new song starts playing. |
I could use a FAB, actually. Only issue is how to handle saving/discarding edits, which are two distinct actions. The latter idea though is just asking for state issues however. As a side note, this would actually benefit me a little, as sometimes I accidentally remove items I don't want to remove with a stray swipe. Separating the modes then is actually somewhat practical. |
Huh, I never realized that. I thought Material Design 3 actually forbade multiple FABs in one screen, but I guess not. I'll see what I could feasibly do here. One issue with this idea is consistency, as I think #93 will be Toolbar-based, and I would prefer consistency regarding that. I'll test out these ideas when I actually get to doing all of these reworks. |
Sure. This is my idea:
This seems to be the most coherent way to do this. Even better, it might make that "swipe up to queue" idea finally work. All those weird touch events from dragging items are now in their own mode, in which I could just disable swiping until the edit mode ends. |
okay nice, i won't really discard queue edits anyway most of the time. this is good 👍 |
Quick thing @KraXen72. While the swiping behavior is feasible now, I don't think it will arrive with the resolution of this issue. This is mostly because I want to bundle it with a bunch of other ideas I have with the playback UI 1 (Mostly #94, liked songs with #36, and maybe equalizer support). Assuming that I add another "destination" from the main playback UI (See: Equalizer), it would be far more likely that the swipe gesture would be configurable, hence it might take more time to implement. It would also be nothing like the existing swipe gesture so that I can make the UI a little cleaner, which also requires me to make a brand new implementation. Sorry for making you hold out this long for what is very much an inferior UI flow. There is just a lot I am working on. Footnotes
|
Sorry for not making myself clear @KraXen72. You're right in that I'm trying to go for quality over quantity. As for the mockup, my idea behind it was driven by trying to increase information density and remove some of the non-standard text styles that I use, while still retaining the amount of information that existed prior. I will probably create a feedback thread when I actually start work on it. |
Hi, just wanted to chime in that I would also love to see the current and previously played songs in the queue and to be able to tap on a song in the queue to play it. I think once these are added this app will be better than simple music player in basically every way. Thank you, oxygen, for your work on this app! |
Add the ability to jump to arbitrary points in the queue. This comes at the cost of the long-press option to move items, since they simply cannot co-exist without visual issues.
Some updates on this. I'm planning to ship the following in the next version:
As for previous queue items, I'm holding that off until a later version. I'm having issues with the design we agreed upon, so I have to figure out another way to implement it. |
nice, thanks for update! |
This comment was marked as outdated.
This comment was marked as outdated.
Turns out all I needed was a day to do everything I said in the last comment. The new queue design should arrive in 2.6.0, assuming all goes according to plan. output.mp4 |
looking really good! otherwise really clean! i like it |
My logic is that since the queue sheet does not go fullscreen like the playback view, it doesn't need to remove it's tint. I also like the visual separation from the queue and the currently playing item. |
Another update: I implemented the ability to see the previous items in the queue. Note that only items considered "Next up" can be edited. All items can be played however. screen-20220730-093702.mp4Every change you requested should arrive in the next version @KraXen72. I really hope there isn't some insane issue with this. |
thanks a ton for implementing all of this !! good work 👍😄 |
No problem. I mean, it did cost me around 2 weeks of my life of staring at google code, screaming at my computer every time I encountered some idiotic design choice, and patching the material design library TWICE to get seemingly simple behavior working, but I the result was worth it I guess. |
Is your feature request related to a problem? Please describe:
problem:
Describe the feature you want to implement:
the queue view is slighly confusing at the moment:
it doesen't show songs that were played/full queue if repeat queue is on.
this could be remedied by 2 ways:
the queue button is hard to reach:
Why do you think this will improve everyone's usage of Auxio?
Due Diligence:
The text was updated successfully, but these errors were encountered: