-
-
Notifications
You must be signed in to change notification settings - Fork 200
Why Are These Features Missing?
One of the reasons I built Auxio was out of frustration with other FOSS android music players, which had too many features, frustrating UI/UX flaws, or both. Thus, I (OxygenCobalt) am incredibly apprehensive towards certain functionality that I consider to be far too detrimental to the app experience to be implemented.
As a result, I only tend to work on features that:
- Benefit everyone's use, including myself. This allows me to make sure the features remain working and usable long-term.
- Are in line with Auxio's purpose as a music player. This avoids scope creep and unmaintainable complexity.
- Will not be an unstable technical nightmare if implemented. This improves the app's longevity.
The following is a list of some of the most commonly requested features that will not be implemented. A full list can be found here.
Adapted from #19:
Lyrics require severe technical complexity, far too much to maintain myself given that I will not use it. For example:
- How do you switch between the lyric and playback views? Can't put a button anywhere without obscuring something (like the cover), violating design specifications (3+ buttons on the toolbar). Hiding behind a gesture wouldn't work, and trying to haphazardly cram it next to the shuffle button or shove it in the queue bar also don't really work. This has to be done right, otherwise it's clunky and unusable UX. Does it scroll properly? What happens when you rotate the device? What happens when the bottom sheet needs to restore it's state? What about the queue? Is it jittery? Does it stop syncing the moment you even slightly poke it? Do you have to add another toggle to switch from sync or unsync?
- How are you getting the lyrics? Lyrics come from crazy sources, much of them non-free, and in formats that are nearly impossible to reconcile. Unsync/sync lyrics tags, LRC files, proprietary timestamp formats, rapid-fire timestamps, raw file embeddings inside the file, and so on.
- How does the code actually integrate? Is it in a service? Is it extending ExoPlayer? How should it slot in next to PlaybackStateManager and ExoPlaybackStateHolder and PlaybackViewModel and MediaSessionServiceFragment? How does it handle asynchronously loading tasks? How does it slot in with music loading? Are you caching lyric tags? This is only a fraction of what needs to be considered large-scale.
- How are you synchronizing live lyrics? It has to be exact timing, the position on the seekbar is updated not as often as you think. That means you need to interface and extend ExoPlayer. You also have to make sure all of the state is properly hoisted upwards so that the UI reflects it and wont break if you rotate, navigate, swipe the bottom sheet, scroll around, click on other components, open it after a warm start, restart the app, if a playback state restore fails, etc.
Yes, Lyrics are that complicated. And I won't use it personally, so it will just rot over time and break more and more. Clunky and broken huge-scope features like lyrics tend to kill open-source music players. I have enough to deal with as-is.
All a folder structure does is encode music metadata informally. As a result, every single folder-based library is a snowflake, with their own user-defined format. It could be Artist/Album/Songs, or perhaps it's Album/Discs/Songs, or Genre/Songs, or just a plain pile of songs. Song file names themselves are a fractal of different formats, anything from Artist_Album_Song.mp4 to Disc.Track.ogg. This more or less necessitates me to tack on an entire generic file manager to the app. I can't slip by with a partial feature that's simpler. To work for everyone, I must do everything.
So, let's say I just go for it. I bolt on a generic file manager onto the app. The thing is that a generic file tree would need an entirely different UI flow compared to the rest of the app. In this case, instead of a different-screen navigation flow, I need a chip-based progressive navigation flow to make back/forth navigation easy.
This is so insanely difficult I can't even begin to think about how to structure this, it requires me to tack on another complex component into the home view. This is a view with a collapsing toolbar, a view pager, two bottom sheets, a selection system and a dynamic FAB. Usually on Android the interactions between components are so busted that you wind up with like O(n!) issues where n is the amount of cross-interacting UI components. It just doesn't work. Sure, I could cut corners and make folders act like any other music object with their own detail view. And then get endless issues as people ask for me to add a chip view like a file manager, since frankly the corner-cutting solution really just isn't the right UI to use for a folder tree.
Since I will never use the folder view, this functionality will progressively rot and break over time since I will not be able to reasonably test it in daily use. You cannot meaningfully unit test UI in Android with the amount of absurd behavior that goes on it. For a reasonably good experience you more or less need to manually test it by dogfooding your own work.
And this is the start. As time goes on, I'll get more feature requests for small tweaks to accommodate the endless library shapes. Perhaps "please turn these file names into track/disc numbers" or "merge these artist folders together" or "I want these folders to play as a whole group". Now I either have to deal with a limited folder view or heap on additional complexity in my music loader to deal with these edge cases. More issues, more bugs, more edge cases, more unmaintainablility.
This also does not include what could happen in the future. It's already a nightmare enumerating file trees with the current storage APIs, and Android could very well force me into a new system offering only a flat list of files. Google is moving away from the file system as a usable folder-based structure, and so this feature could easily simply become untenable one day.
Huge-scope unstable features like these could land Auxio in the same position as Retro Music or Phonograph, in which the shifting sands of the android platform make long-term maintenance functionally impossible.
This is what I mean when I say that folder based libraries are incompatible with a tag-based music player. It's an entire new dimension of complexity. I already have around 5000 lines of non-UI business logic dedicated to just managing tag-based libraries. And tags are much more limited in complexity and variation than folder libraries.
I'm sorry I can't support an in-demand feature like this, but I prioritize long-term app survival over feature count.
Programs should do one thing and do it well. A Tag Editor is an adjacent, yet much different program than a music player. Trying to graft on a Tag Editor to Auxio would simply take away time to focus on music playback and not even result in a good tag editor. In line with this, I've thought about making a kind of companion tag editor app to Auxio, but I haven't found much motivation for such given that desktop tag editors work just fine, not to mention the dismal state of editing the filesystem on modern android.
I would personally recommend Beets, Picard, kid3, or Ex Falso for editing tags. There's also Automatag if you have to edit tags on your phone.
This isn't added because it's a potential slippery slope. Adding a toggle between two styles results in someone asking for a third, and then a fourth, and then a fifth, and so on. Eventually I would end up with my attention split across 10 radically different UI styles that all don't work well. Instead, I keep my attention focused on making one playback layout as good as possible, resulting in a much better UX overall. This does not rule out customizing parts of the playback view, but even those are kept limited for the reasons outlined prior.
Not only do I not get any use from scrobbling, last.fm is a non-free network service that I do not want this app to connect to in the first place. In general, I don't want to implement any connectivity features unless Auxio becomes a music streaming client, which is unlikely as it stands.
This is for the same reason as alternative playback layouts. As a single developer, it's better to hone in on a single widget layout & theme than split my attention across 10 widgets or countless subtle widget options. Given the convergence of widget styles on Android 12+ in particular, I further restrict the theming to make sure the widget adequately blends in with the rest of the system UI.
Algorithmic recommendations can be neat, but I am also not a tech company with a whole team of AI researchers. Most "For You" pages implemented in FOSS music players simply fake the recommendations through a random number generator. This is absolutely absurd and nothing but a useless screen you skip past to get to the music library you actually want.
Again, the needs of an Equalizer and the needs of Auxio are too different to combine into a single app without both becoming in-adequate. Auxio does have support for external equalizer support, such as through the (highly recommended) Wavelet.
I don't really like listening to music when I go to sleep, as it's usually too active to allow me to relax. I find the nature sounds provided by apps like Noice to be much nicer.
Auxio is not really equipped to play audiobooks and podcasts, and I don't want to add features that accommodate such, given that it would distract from the app's purpose as a music player.
Crossfading actually is impossible with ExoPlayer as it currently stands, as it completely breaks the timeline model (Where does one song end and another start?).
I usually know what I've just added to a library, and what songs I've been playing the most. You can sort by date added, however.