Closed GregJohnStewart closed 1 year ago
This would require basically rewriting the entire plugin and isn't something I plan to tackle.
mopidy-pidi
and pidi-display-pil
and pidi-display-st7789
are all very specifically geared toward just displaying album art and not an entire UI, and mopidy-raspberry-gpio
is just a generic plugin for making buttons control an action in Mopidy. All of that would have to change to be application specific in order to make this work.
I know it's not quite the tiny-little-music-player-UI you're loking for, but Prev/Next should already work for playlists.
If someone wants to build a Mopidy frontend to accomplish this, then they're of course welcome to try! But, alas, I only have so many hours I can put into each of our products.
There was an attempt at this called pirateplayer but I couldn't get it to run. I'm trying to code up a real basic MPD client. Certainly this is challenging but I can see a way of cycling through playlists with previous/next if the playlists have already been defined in MPD.
If anyone recalls the early MP3 players before the iPod some of the iRiver UI's had big icon based menus.
A menu system multiplies the number of buttons, if I have 10 screens I've created 20 functions from 2 buttons.
My ultimate goal would be to have playlists of radio stations, like rock, talk, sport and get wifi hotspot off my phone. So at some point if need to click over a playlist with mpc. Combined with a podcast downloader onboard that when running MPD update it would go fetch the latest of the subscribed podcasts to a directory for when there's spotty connections, such as in the car or traveling.
To that end what I'm thinking of would need some playlist navigation. Note any ideas that could help guide me here.
I did some basic looking around at stuff that would be considerations for a good user experience.
Dim or sleep the backlight if no button presses after timeout to save power.
Limit the number of different screens to 7
Keep button location consistent.
Have a predictable and learnable flow
Most important screens first; volume, playback and playlist.
Distill information to most needed
Make use of scrolling text in particular for radio/podcasts
A home screen that displays IP address if player idle.
A screen that allows the running of mpd update and/or podcast update.
Samba share access to the MPD music and playlist directories.
Button consistency. If top right is used for positive actions to skip forwards it should also be able to be assigned play/pause. If bottom right is used negatively for stop it could also map to mute, poweroff and skip back.
I would opt to drive local media selection based on playlists or favorites. If I think about 1,000's of songs I might have listened to a curated list on my Creative Zen as opposed to scrolling down a sorted list of everything. Sort by artist or album can be tricky if trying to get to ZZTop, genre in general can be unreliable based on tagging. There could be a basic machine learnable thing such as recently played (keep the mpd load in a sqllite table) or recently added (which should be possible via a Linux command).
https://medium.com/@flannerykj/the-evolving-interface-of-the-mp3-player-a77b3db39232
https://usabilitygeek.com/7-user-interface-guidelines-for-designing-watch-apps/
I think it is extremely limiting to not have a way to select media directly from the board, and require the web interface. I'm using the headphone amp, and wish to use it as an mp3 player but sadly that's fairly inconvenient when the web interface must be used.
I would think 4 buttons could be enough to accomplish this, all I am asking for is selection of what's playing. Maybe hitting two at once would put it in a 'selection mode'?