Help wanted to evolve KDEs music players

[Harald Sitter]

Ahoy ahoy, ramblings ahead!

On Thu, Jul 30, 2015 at 12:42 PM, Stefan Derkits <stefan at derkits.at> wrote:
> This music player should not replace Amarok or other great Qt-based
> music players like Tomahawk or Clementine, as their feature set is much
> bigger than this new music player should ever have.

^ this
One of the great regrets and failures of Dragon Player was that it
went from the original vision of the simplest of video players to I
don't even know what. It now plays audio cds don't you know...

I think jlayt put it best:
> Personally, I've been thinking most of kdemultimedia needs to die in
> the KF5 era, people are no longer interested in maintaining the code,
> much functionality is close to obsolete, and far bigger, better
> standalone projects have media playing well covered.

sandsmark and sebas at least support this assertion as they use
streaming services and hardware players.

And as sebas said:
> Building what's basically an MP3 player today seems like going back to the
> past.

All of this I agree with. If we want to build something that is still
relevant in a couple of years I'd not hold on to the idea of building
a feature rich *local* music player with collection. It's a
substantial effort tech-wise and probably becoming pointless since the
rise of smartphones and tablets and their numerous cloud streaming
services which are just so much more convenient.

Now with that in mind I do not think that the present user stories or
visual design line up with the expectancy that a possible new player
is *not* going to replace (that is: feature wise excessively compete
with the existing ones). Looking at the user scenarios I see profound
overlap with all major features of Amarok and Clementine and to a
lesser degree Tomahawk (this one actually is pretty unique in terms of
how it integrates with the internet). So I do not think what is layed
out actually reflects what we want here.


To solve this I think three very central question need to be answered
very precisely before doing anything else.

1. How many people will actively commit to working on this as their
*main* project?
2. What does the primary target audience of Plasma even need?
3. What do the contributors want to actually have in the end
understanding their own time constraints?

The first question is extremely relevant. One person could implement
the existing design to meet all scenarios. It will have substantial
shortcomings though and long term would likely require too much
investment from one person to work out. As this thread shows everyone
has their own corner case requirements they want to put on the table
and just fighting out what gets even considered is extremely demanding
and pretty much an endless fight.

Assuming we design a player for Plasma rather than just a good music
player in general, I am also not convinced that the design we have is
in fact what the target audience needs as far as Plasma personas are
concerned. [1] Carla owns 3 devices that can play music, I doubt she'd
faff around with syncing up local music files when she probably can
afford a subscription to spotify, apple whatever or google music (same
for the currently used Susan persona FWIW since she even likes to
share music a lot). Raj is a different story though, I'd be inclined
to argue that instead of spending money on a sub he'd much rather
pirate music so he needs local playback if he wants to enjoy music ;).
Food for thought.

Lastly I think contributors need to be on the same page with regards
to where the product should go long-term and this needs to be messaged
properly through the UI and also in promo effort. No one wants another
frankenDragon that has a new maintainer every year and has worse
feature scope creep than systemd.


There are a million features one can put in a music player. At the end
of the day the million features won't make it a good player though.
Being reliable and smart about its core functionality will. And in
terms of the being reliable thing, less is usually more.

[1] https://community.kde.org/Plasma/Workspace_Sprint/Personas

HS