[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Music Player - Needs
From:       "Ing. Konrad Renner" <konrad.renner () kolabnow ! com>
Date:       2015-08-05 14:02:30
Message-ID: ab4c3c30-8f14-4430-9e81-bc829ea098ac () email ! android ! com
[Download RAW message or body]

That sounds like good plan ;-)

Am 05.08.2015 3:43 nachm. schrieb Andrew Lake <jamboarder@gmail.com>:
> 
> Good points Teo. I don't think a decision has yet been made, or even a strong bias \
> towards to starting from scratch. In fact I think the bias is toward \
> reusing/building on existing code. What is not yet clear is *which* code base to \
> use in light of the goals of the music player. Having worked on Bangrang, I'd be \
> sincerely and entirely happy if the collective decision is to take advantage of \
> Amarok's code base, or Juk or anything else. What matters is that we ensure that \
> whatever it is built upon is sustainable for the folks involved. 
> I'd offer that we probably have enough to go ahead and start refining the vision of \
> what this music player is supposed to be, flesh out any lingering questions about \
> intended functions, then with that done, continue a more detailed discussion about \
> which existing codebase, if any, would best serve those needs. 
> Hope this helps,
> Andrew
> 
> 
> On Wed, Aug 5, 2015, 4:13 AM Teo Mrnjavac <teo@kde.org> wrote:
> > 
> > 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@kde.org
> > _______________________________________________
> > kde-multimedia mailing list
> > kde-multimedia@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-multimedia
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia


[prev in list] [next in list] [prev in thread] [next in thread]