Help wanted to evolve KDEs music players

[Wolfgang Mader]

On Monday 03 August 2015 11:33:54 Ing. Konrad Renner wrote:
> Am 2015-08-01 17:14, schrieb Vishesh Handa:
> > These are just some of the cases. Often the solution is just to roll
> > your own thing.
> > 
> > Also, I liked having my own database in Jungle and Koko, as they could
> > then store the data explicitly how they want, and create relevant
> > indexes. In Koko, I eventually made Baloo optional. Specially since
> > Baloo has not been (yet?) ported for the Plasma Phone.
> 
>  IMHO when a new software is "created/designed for Plasma" it should
> integrate tight with other parts of the environment. Because it is
> designed for this special desktop environment, the goal is not that it
> is used with this other fancy desktop environment (do the GNOME devs
> care if GNOME music integrate well on the Plasma desktop?). It should
> feel like "all was made of one piece". If the software is not
> "created/designed for Plasma" one can be aware that this software maybe
> does not integrate well.
> 
> E.g.: I import some pictures with a "Plasma picture editor app" from my
> camera, rate the files and attach the tag "holiday". Some days later I
> want to present my "holiday" pictures friends, but the pictures should
> have minimum rating of 3 stars (because I don't want to show my friends
> pictures which are "not so good"), with the "Plasma picture viewer".
> Maybe a year later I want to find all "holiday" pictures from 2014 and
> 2015 with the "Plasma file browser", so that I can burn them on a disk
> for backup.
> 
> The same is true for a Plasma music application: if it uses its own
> system for ratings, a possible new "Plasma multimedia application"
> cannot use this informations and so a user has to define them for each
> application. And I think the user will not be satisified, if he has to
> create the same ratings for the same files, in each application he uses.
> 
> 
> I think to reinvent the wheel for each application cannot be the goal.

IMHO, apart from the technicalities, there are two points of view. One is, 
that a local music player is obsolete in this highly connected world. The 
other is to argue, that playing whatever music one owns should be easy and 
pleasant. My point of view is that the opposite of a local music 
player is not spotify and friends, but a self hosted multimedia collection 
e.g. encoded CDs. Thus rendering a well-done local music player which connects 
to all my self hosted media properly an appreciated piece of software. 
Especially if it embraces different form factors and connects multiple 
devices.


Persona
Mia is a member of a research group at university. She writes code in R and 
sends it to the cluster of her department. She works on Linux and enjoys the 
freedom to set up her system to her liking as well as the freedom to decide 
where here private data goes.
At home she runs a small server which servers pictures and music to her local 
network via samba. She listens to this music on her smart phone when cooking 
and she hooks her notebook or tablet up to the stereo to enjoy her music in 
the living room. She is technical, but when it comes to recreation, she likes 
things to just work.


The vision
I think, that this discussion is perfect in time given the announcement of the 
plasma phone. I wish for an application that is great to use on a notebook, a 
tablet, or a phone and is able to access all the music that lives on my own 
storage. Moreover, multi devices running this application should play nice 
together, such that remote control is possible or the plasma phone can turn 
down the volume of the music on the tablet connected to the stereo when a call 
happens.


How to access data?
The discussion on the list so far showed, that it is to be avoided to let 
feature by feature sneak in. Thus, I would suggest to access data via kio. 
Whatever fancy mechanism we want to add in the future, the heavy lifting can 
be done in kio. Moreover, everyone using kio benefits from these extension. 
E.g., if at some point spotify decides to open up their access, I guess that a 
spotify-kio should be possible in principal. However, I would not try too hard 
to access such services. We can not beat (or even play with) them in their own 
yard, for they decided to wall it. I also think that using kio is not a 
limitation for the user experience. All music should be presented in the same 
way, irrespective of its origin. Therefore, no special treatment for music 
coming from source A or B is needed and kio should serve this task well.


Device interplay
While it is possible to leverage networks like jabber to find devices, for a 
start I would stay withing the local network and do something along the lines 
of kdeconnect. In fact, I would integrate with kdeconnect, for I would not 
like to pair my devices more than once for different services. (I must admit 
that I do not know a lot of how kdeconnect does its thing, though.) Once 
devices in the same network know of each other they can interact. It should be 
possible to control the music played on the notebook or the table from the ui 
of the smart phone, but also all other combinations are useful. E.g., if Mia 
works at her notebook and has her phone plugged to the stereo, she wants to 
change the song or album right from where she sits. Or, if she takes a call 
and her tablet is the music source, the sound volume should go down 
automatically. (Maybe it would even be possible to stream the audio of the 
call to her stereo, but this is beyond this project, I guess.)


Summary
IMHO, it would be great if this new music player would target self-hosted 
media and the multi-device scenario which becomes feasible with the 
announcement of the plasma phone. My general take on this is, that especially 
applications from the entertainment area like music, film, or images viewers, 
should not be applications for the desktop, but for the plasma universe. With 
plasma running on different form factors it is much more likely for users to 
have more than one plasma powered device, and all these devices should play 
together with as little hassle as possible.

Taken this idea further, it could lead to a device-connection layer (maybe a 
framework) which can be used by all applications interested in such a 
mechanism.

I hope I have not kicked over the traces.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20150803/f88aad14/attachment.sig>
-------------- next part --------------

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<