Music Player - Needs

[Teo Mrnjavac]

On Wednesday, August 05, 2015 12:06:18 Olivier Churlaud wrote:
> Hi,
> 
> I read all the ideas that came up on this mailing list. I just want to
> sum up what I found interesting and the question that it raised for me.
> I don't explain or say that what I mean is true, but if I have this
> questions, maybe some other have it..
> 
> *Local library - Amarok ?*
> As Myriam  said, Amarok is not dead and is slowly beeing ported to KF5.
> Amarok was one of the huge assets of KDE and is quite good. IMOH it
> lacks the possibility to create playlists (but this might be corrected
> by contributing to the project) and the support of network library. I
> think that if we want to create a music player that plays the local
> library, we'll be in conflict with an awesome software, which might need
> a refresh but this can be done by people interested in Amarok. (And then
> of course all the Clementine, Rhythmbox.... are already present and
> quite good).
> 

This is exactly what I suggested at the beginning of that thread. To put it 
plainly, Amarok has some issues. For instance, I strongly dislike Amarok's UI, 
even though I'm partly responsible for it. However, there are many hard 
problems that Amarok developers solved very well, after many years of learning 
and work.

I don't fancy myself a veteran, as there are people who have been doing music 
players for much longer, but I do have some years of craftsmanship on Amarok 
and Tomahawk under my belt, and with those bits of experience I'm a bit 
surprised that some developers seem so happy to rush into a full rewrite.

*Good* collection management is hard. *Good* metadata management is really 
hard. Backends have their quirks. Then you need at least some web services, 
for metadata and covers as a minimum, because you can't realistically have a 
modern music player by just whipping the llama's ass like it's 1997. And all 
of that is just the minimum viable functionality to get started, before even 
thinking of delivering a product that adds some extra value on top of what the 
competition does.

Don't want to work on an old codebase? Fine, that's a reason for starting from 
scratch. It's important to have fun when you're a volunteer, and old code is 
often not fun at all. I understand and support that. I like fun.

Don't feel like adapting to years of Amarok team practices and lore? That's 
another reason for starting from scratch. Creative control is fun, and an 
added bonus if you're a volunteer. Sometimes starting anew is the best way to 
get traction. I understand that too.

I'd be happy to see any work being done on awesome music players, even a new 
one from scratch. But even with knowledge of the Amarok codebase and the 
dragons that lie within I find it really hard to believe that building on 
Amarok's strengths and throwing away the bad stuff could be technically harder 
than starting from scratch.

For me in a perfect world this would be a discussion on how to 
reboot/refresh/rebrand Amarok (or Bangarang, JuK, Clementine, ...). It's 
completely fine if the reasons for starting anew aren't technical, but at the 
very least, while preserving the fun, novelty and creative control of starting 
from scratch, I suggest the new developers take a look at what Amarok is doing 
with collections and metadata.

"We want to start from scratch for maximum creative control and fun" is a good 
rationale. Go for it. We need this kind of get-things-done approach in KDE.

"We want to start from scratch because it's technically impossible to build on 
top of Amarok" makes no sense to me.

Cheers,
-- 
Teo Mrnjavac
http://teom.org | teo at kde.org
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia