[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-multimedia
Subject: Re: Music Player - Needs
From: RISHABH GUPTA <rishabh9511 () gmail ! com>
Date: 2015-08-08 14:49:25
Message-ID: CAB9YDnXDqrq_csHXjQGBFujevezitjV1DUa70GTG1bKFAiBMhQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@kolabnow.com> wrote:
> 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
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>hello,<br><br>Is the discussion taking place on some other \
mailing list ?<br><br></div><div>thanks,<br></div><div>rishabh<br></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 7:32 PM, Ing. \
Konrad Renner <span dir="ltr"><<a href="mailto:konrad.renner@kolabnow.com" \
target="_blank">konrad.renner@kolabnow.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">That sounds like good plan ;-)<br> <div class="HOEnZb"><div \
class="h5"><br> Am 05.08.2015 3:43 nachm. schrieb Andrew Lake <<a \
href="mailto:jamboarder@gmail.com">jamboarder@gmail.com</a>>:<br> ><br>
> 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.<br> ><br>
> 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.<br> ><br>
> Hope this helps,<br>
> Andrew<br>
><br>
><br>
> On Wed, Aug 5, 2015, 4:13 AM Teo Mrnjavac <<a \
href="mailto:teo@kde.org">teo@kde.org</a>> wrote:<br> >><br>
>> On Wednesday, August 05, 2015 12:06:18 Olivier Churlaud wrote:<br>
>> > Hi,<br>
>> ><br>
>> > I read all the ideas that came up on this mailing list. I just want \
to<br> >> > sum up what I found interesting and the question that it raised \
for me.<br> >> > I don't explain or say that what I mean is true, but if \
I have this<br> >> > questions, maybe some other have it..<br>
>> ><br>
>> > *Local library - Amarok ?*<br>
>> > As Myriam said, Amarok is not dead and is slowly beeing ported to \
KF5.<br> >> > Amarok was one of the huge assets of KDE and is quite good. \
IMOH it<br> >> > lacks the possibility to create playlists (but this might \
be corrected<br> >> > by contributing to the project) and the support of \
network library. I<br> >> > think that if we want to create a music player \
that plays the local<br> >> > library, we'll be in conflict with an \
awesome software, which might need<br> >> > a refresh but this can be done \
by people interested in Amarok. (And then<br> >> > of course all the \
Clementine, Rhythmbox.... are already present and<br> >> > quite good).<br>
>> ><br>
>><br>
>> This is exactly what I suggested at the beginning of that thread. To put \
it<br> >> plainly, Amarok has some issues. For instance, I strongly dislike \
Amarok's UI,<br> >> even though I'm partly responsible for it. However, \
there are many hard<br> >> problems that Amarok developers solved very well, \
after many years of learning<br> >> and work.<br>
>><br>
>> I don't fancy myself a veteran, as there are people who have been doing \
music<br> >> players for much longer, but I do have some years of craftsmanship \
on Amarok<br> >> and Tomahawk under my belt, and with those bits of experience \
I'm a bit<br> >> surprised that some developers seem so happy to rush into \
a full rewrite.<br> >><br>
>> *Good* collection management is hard. *Good* metadata management is \
really<br> >> hard. Backends have their quirks. Then you need at least some web \
services,<br> >> for metadata and covers as a minimum, because you can't \
realistically have a<br> >> modern music player by just whipping the \
llama's ass like it's 1997. And all<br> >> of that is just the minimum \
viable functionality to get started, before even<br> >> thinking of delivering \
a product that adds some extra value on top of what the<br> >> competition \
does.<br> >><br>
>> Don't want to work on an old codebase? Fine, that's a reason for \
starting from<br> >> scratch. It's important to have fun when you're a \
volunteer, and old code is<br> >> often not fun at all. I understand and \
support that. I like fun.<br> >><br>
>> Don't feel like adapting to years of Amarok team practices and lore? \
That's<br> >> another reason for starting from scratch. Creative control is \
fun, and an<br> >> added bonus if you're a volunteer. Sometimes starting \
anew is the best way to<br> >> get traction. I understand that too.<br>
>><br>
>> I'd be happy to see any work being done on awesome music players, even a \
new<br> >> one from scratch. But even with knowledge of the Amarok codebase and \
the<br> >> dragons that lie within I find it really hard to believe that \
building on<br> >> Amarok's strengths and throwing away the bad stuff could \
be technically harder<br> >> than starting from scratch.<br>
>><br>
>> For me in a perfect world this would be a discussion on how to<br>
>> reboot/refresh/rebrand Amarok (or Bangarang, JuK, Clementine, ...). \
It's<br> >> completely fine if the reasons for starting anew aren't \
technical, but at the<br> >> very least, while preserving the fun, novelty and \
creative control of starting<br> >> from scratch, I suggest the new developers \
take a look at what Amarok is doing<br> >> with collections and metadata.<br>
>><br>
>> "We want to start from scratch for maximum creative control and \
fun" is a good<br> >> rationale. Go for it. We need this kind of \
get-things-done approach in KDE.<br> >><br>
>> "We want to start from scratch because it's technically impossible \
to build on<br> >> top of Amarok" makes no sense to me.<br>
>><br>
>> Cheers,<br>
>> --<br>
>> Teo Mrnjavac<br>
>> <a href="http://teom.org" rel="noreferrer" \
target="_blank">http://teom.org</a> | <a \
href="mailto:teo@kde.org">teo@kde.org</a><br> >> \
_______________________________________________<br> >> kde-multimedia mailing \
list<br> >> <a \
href="mailto:kde-multimedia@kde.org">kde-multimedia@kde.org</a><br> >> <a \
href="https://mail.kde.org/mailman/listinfo/kde-multimedia" rel="noreferrer" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-multimedia</a><br> \
_______________________________________________<br> kde-multimedia mailing list<br>
<a href="mailto:kde-multimedia@kde.org">kde-multimedia@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-multimedia" rel="noreferrer" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-multimedia</a><br> \
</div></div></blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic