Music Player - Needs

[RISHABH GUPTA]

hello,

Is the discussion taking place on   some other mailing list ?

thanks,
rishabh

On Wed, Aug 5, 2015 at 7:32 PM, Ing. Konrad Renner <
konrad.renner at kolabnow.com> wrote:

> That sounds like good plan ;-)
>
> Am 05.08.2015 3:43 nachm. schrieb Andrew Lake <jamboarder at 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 at 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 at kde.org
> >> _______________________________________________
> >> kde-multimedia mailing list
> >> kde-multimedia at kde.org
> >> https://mail.kde.org/mailman/listinfo/kde-multimedia
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia at kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20150808/43a86239/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia