[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-multimedia
Subject: Re: Music Player - Needs
From: Andrew Lake <jamboarder () gmail ! com>
Date: 2015-08-08 17:15:18
Message-ID: CAKFiHE9fFKJzaoEbA5RNbBjaQSDNxvk9aXoYFvDKxnsttip07A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
So let's keep working at this so we can have a clear vision.
Local library - Honestly, if a modern music player can't show and play the
music you have on the same machine it is running on, I think we really
shouldn't call it modern. :-) To me this is an essential function. It
doesn't need to have uber-fancy, library management functions. But offering
basic functions to browse and play music by Artist, Album, Genre is
essential I think.
Just playing a music file - Since there is little distinction between a
music file and an audio file, I'd be fine with this being a secondary
feature. Easily supported, but perhaps without making it a primary feature
of the design.
Playing streams - With all the off-device sources of music today, it sorta
seems like we can't walk away from this one. I think we would need to flesh
out a little bit more what this music player would bring to the party.
1. Do we try to support the big popular online services? Access and
playback through our UI (which probably means api access) or just provide
an Online Music Bookmarks style feature that opens the online services in
an embedded webpage for these online services?
2. Do we focus on free/open standard style services? Might provide some
kind of principled approach to online streaming. Downside is the perfect
being the enemy of the good.
3. Internet radio style streaming or online music library streaming? I
think we have open standards for the latter, not so much the former.
Any other fundamental ideas for what this music player should or should not
be?
As the discussion progresses, I'll update the vision that was previously
captured here:
https://community.kde.org/KDE_Visual_Design_Group/Music_Player#Music_Player_Vision
Hope this helps,
Andrew
On Sat, Aug 8, 2015 at 8:51 AM Olivier Churlaud <olivier@churlaud.com>
wrote:
> I think there is no further discussion.. Maybe check the forum (*)
>
> * https://forum.kde.org/viewtopic.php?f=285&t=122273&
>
>
> Le 08/08/2015 16:37, RISHABH GUPTA a écrit :
>
> 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
>>
>
>
>
> _______________________________________________
> kde-multimedia mailing listkde-multimedia@kde.orghttps://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">So let's keep working at this so we can have a clear \
vision.<div><br></div><div>Local library - Honestly, if a modern music player \
can't show and play the music you have on the same machine it is running on, I \
think we really shouldn't call it modern. :-) To me this is an essential \
function. It doesn't need to have uber-fancy, library management functions. But \
offering basic functions to browse and play music by Artist, Album, Genre is \
essential I think.</div><div><br></div><div>Just playing a music file - Since there \
is little distinction between a music file and an audio file, I'd be fine with \
this being a secondary feature. Easily supported, but perhaps without making it a \
primary feature of the design.</div><div><br></div><div>Playing streams - With all \
the off-device sources of music today, it sorta seems like we can't walk away \
from this one. I think we would need to flesh out a little bit more what this music \
player would bring to the party. </div><div>1. Do we try to support the big popular \
online services? Access and playback through our UI (which probably means api access) \
or just provide an Online Music Bookmarks style feature that opens the online \
services in an embedded webpage for these online services?</div><div>2. Do we focus \
on free/open standard style services? Might provide some kind of principled approach \
to online streaming. Downside is the perfect being the enemy of the \
good.</div><div>3. Internet radio style streaming or online music library streaming? \
I think we have open standards for the latter, not so much the \
former.</div><div><br></div><div>Any other fundamental ideas for what this music \
player should or should not be?</div><div><br></div><div>As the discussion \
progresses, I'll update the vision that was previously captured \
here:</div><div><a href="https://community.kde.org/KDE_Visual_Design_Group/Music_Playe \
r#Music_Player_Vision">https://community.kde.org/KDE_Visual_Design_Group/Music_Player#Music_Player_Vision</a><br></div><div><br></div><div>Hope \
this helps,</div><div>Andrew</div></div><br><div class="gmail_quote"><div \
dir="ltr">On Sat, Aug 8, 2015 at 8:51 AM Olivier Churlaud <<a \
href="mailto:olivier@churlaud.com">olivier@churlaud.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
I think there is no further discussion.. Maybe check the forum (*)<br>
<br>
* <a href="https://forum.kde.org/viewtopic.php?f=285&t=122273&" \
target="_blank">https://forum.kde.org/viewtopic.php?f=285&t=122273&</a></div><div \
text="#000000" bgcolor="#FFFFFF"><br> <br>
Le 08/08/2015 16:37, RISHABH GUPTA a écrit :<br>
<blockquote type="cite">
<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>
<div><br>
Am 05.08.2015 3:43 nachm. schrieb Andrew Lake <<a \
href="mailto:jamboarder@gmail.com" target="_blank"><a \
href="mailto:jamboarder@gmail.com" \
target="_blank">jamboarder@gmail.com</a></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" target="_blank"><a href="mailto:teo@kde.org" \
target="_blank">teo@kde.org</a></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" target="_blank"><a \
href="mailto:teo@kde.org" target="_blank">teo@kde.org</a></a><br>
>> _______________________________________________<br>
>> kde-multimedia mailing list<br>
>> <a href="mailto:kde-multimedia@kde.org" \
target="_blank">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" \
target="_blank">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>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
kde-multimedia mailing list
<a href="mailto:kde-multimedia@kde.org" target="_blank">kde-multimedia@kde.org</a>
<a href="https://mail.kde.org/mailman/listinfo/kde-multimedia" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-multimedia</a> </pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
kde-multimedia mailing list<br>
<a href="mailto:kde-multimedia@kde.org" \
target="_blank">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> \
</blockquote></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