This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Design for a Music Player

Tags: None
(comma "," separated)
User avatar
alake
Registered Member
Posts
591
Karma
3
OS

Re: Design for a Music Player

Wed Feb 24, 2016 7:31 pm
See https://community.kde.org/KDE_Visual_De ... sic_Player in the "scenario" section for a list of functions. Holler with any questions.
ochurlaud
KDE Developer
Posts
62
Karma
0
OS

Re: Design for a Music Player

Thu Mar 03, 2016 11:39 am
@alake: I read that already. What I would like is already a kind of API functions that we must implement

Anyway: I added the TagLib dependency: I'll soon write the first importation functions. I first won't allow any metadata modification.

The plan is:

1) Sucessfully import tracks based on tags.
2) Query the library for some tracks
3) Have a minimal QML skin
4) Implement playlists
5) Play tracks
6) Modify metadata + LastFM connection
7) Work with external media (MTP, IPods...)

Last edited by ochurlaud on Wed Apr 13, 2016 7:39 pm, edited 2 times in total.
ochurlaud
KDE Developer
Posts
62
Karma
0
OS

Re: Design for a Music Player

Thu Mar 03, 2016 4:44 pm
Hey there!

Could you please review the src/model folder to see if the track/artist/album architecture makes sense to you.

What is missing? What should be changed? When this is defined, I can begin to work on my point 1) (see above).

You can directly find the code here: https://quickgit.kde.org/?p=scratch%2Fo ... rc%2Fmodel
ripper17
Registered Member
Posts
46
Karma
0
OS

Re: Design for a Music Player

Thu Mar 03, 2016 5:03 pm
From the top of my head and in no particular order:
  • What happens with albums that are compilations with various artists?
  • What happens with albums with more than one CD (e.g. Pink Floyd "The Wall" - 2 CDs)
  • Especially in classical music, one CD might contain more than one "piece" by one composer, e.g. Mozart, W.A.: Piano Concertos Nos.20, 21, 25 & 27 (2 CD's) - is there a plan to handle classical music (I saw composer and conductor, but only on a track-basis?)
  • Should the album contain more paths to e.g. booklets (PDF?) and back-cover?

On a side note:
Talking about classical CDs reminds me: I've always wanted to have a music player that handles classical music better. I listen mostly to modern stuff, but at times I like my concertos or operas just as well. However, I'm yet to find a music player that gives me an option to filter/search by composer (for the more advanced listener maybe also filter/search by conductor, lead soloist (which could be singer, violonist, pianist...), orchestra...)
I know that this might be out of scope (especially initially) since the majority of users probably won't need this, but it would be nice if this could be kept in mind in order to remain flexible enough to maybe later add support for this.


openSUSE 13.2 x64, Platform Version 4.14.X, Kubuntu 14.04 (LTS), Platform Version 4.13.X
ochurlaud
KDE Developer
Posts
62
Karma
0
OS

Re: Design for a Music Player

Thu Mar 03, 2016 5:13 pm
Thanks for this first constructive feedback... I'm looking forward to more of them!
Just to highlight what I did, according to your points....

For classical music
[*] the composer is a track attribute, and conductor as well. To me it makes more sense because a lot of classical music discs are sorts of compilations. Feel free to propose a better way to handle this.
[*] Several CDs: Albums have a disk-number attribute. We can then merge the two albums in our user interface. I think it's not an issue.
[*] Compilations: In which case is it not handled by artist (a track attribute) / albumartist (an album attribute) ?
[*] More paths? Why not, but I think that we should focus first on the usual and then add complexity. So: first the cover.

[*] About your last point, I had an idea: maybe we can have a table that connect tracks with a collection of keys-values that are chosen by the user. Would it make sense to you?
ripper17
Registered Member
Posts
46
Karma
0
OS

Re: Design for a Music Player

Fri Mar 04, 2016 7:41 am
ochurlaud wrote:[*] the composer is a track attribute, and conductor as well. To me it makes more sense because a lot of classical music discs are sorts of compilations. Feel free to propose a better way to handle this.

I think this is a bit of a tough one and I don't have a solution for it: Yes, classical music discs are often some kind of compilations, however, on those compilations often 3 or 4 tracks belong together. Let's take a look (e.g.) at a disc-set with all piano concerts by Mozart:
[*] There are 27 piano concerts distributed to 10 discs
[*] Disc 1 e.g. has concert #5 (Tracks 1-3), #9 (4-6) and #12 (7-9). This kind of stuff really happens, probably because of track-lengths the concertos are often mixed in no particular order - I even have a collection which spans one concert on 2 CDs (so concert #10, track 1 is on CD 3 and tracks 2-3 are on CD 4)

How would the grouping work? I think from a user POV the most important stuff is that
a) It's from Mozart
b) it's piano concert Nr X (= "Album"?)
c) further refinements like conductor, orchestra, soloist etc.

I'd say the user is completely uninterested in the CD "compilation" (#5, #9, #12) in this case. Could this be handled as three albums instead?

I know that we are kind of limited by IDv3 here, too, I just wish we weren't... And of course even if we weren't limited, the issue of "tagging" is another problem because even MusicBrainz is lacking a really good tagging strategy for classical music last time I checked.

ochurlaud wrote:[*] Several CDs: Albums have a disk-number attribute. We can then merge the two albums in our user interface. I think it's not an issue.
[*] Compilations: In which case is it not handled by artist (a track attribute) / albumartist (an album attribute) ?
[*] More paths? Why not, but I think that we should focus first on the usual and then add complexity. So: first the cover.

Sounds all good to me.
ochurlaud wrote:[*] About your last point, I had an idea: maybe we can have a table that connect tracks with a collection of keys-values that are chosen by the user. Would it make sense to you?

I didn't quite understand this idea, sorry.


openSUSE 13.2 x64, Platform Version 4.14.X, Kubuntu 14.04 (LTS), Platform Version 4.13.X
ochurlaud
KDE Developer
Posts
62
Karma
0
OS

Re: Design for a Music Player

Fri Mar 04, 2016 7:53 am
ripper17 wrote:
ochurlaud wrote:[*] About your last point, I had an idea: maybe we can have a table that connect tracks with a collection of keys-values that are chosen by the user. Would it make sense to you?

I didn't quite understand this idea, sorry.


So ID3v2 let you add custom tags. So we can allow the user to add these custom tags (solist, and so on).

In the program database we can have a table like this:
Code: Select all
+-------------+-----------------+-----------------+
|track_id     | key            | value            |
+-------------+-----------------+-----------------+
| 2           | "First Violin" | "John Doe"  |
ripper17
Registered Member
Posts
46
Karma
0
OS

Re: Design for a Music Player

Fri Mar 04, 2016 8:03 am
OK, that sounds good - or maybe it could be integrated in Baloo? Should there be a predefined set of keys (with the ability to add more)?


openSUSE 13.2 x64, Platform Version 4.14.X, Kubuntu 14.04 (LTS), Platform Version 4.13.X
ochurlaud
KDE Developer
Posts
62
Karma
0
OS

Re: Design for a Music Player

Fri Mar 04, 2016 3:56 pm
ripper17 wrote:OK, that sounds good - or maybe it could be integrated in Baloo? Should there be a predefined set of keys (with the ability to add more)?



I have no idea of how baloo works.... But when we'll be at this stage, of course it should be considered.
User avatar
lazyit
Registered Member
Posts
125
Karma
0
OS

Re: Design for a Music Player

Sat Mar 05, 2016 10:26 pm
Tonight trying Gnome I discovered this new player, it looks fantastic, excellent design, minimal and with all you need!
This is as it should be a modern music player, I think ...
https://gnumdk.github.io/lollypop-web/
I do not know if any of you have tried it, but it looks very interesting
konradrenner
Registered Member
Posts
10
Karma
0

Re: Design for a Music Player

Tue Mar 22, 2016 9:44 pm
ochurlaud wrote:
ripper17 wrote:OK, that sounds good - or maybe it could be integrated in Baloo? Should there be a predefined set of keys (with the ability to add more)?



I have no idea of how baloo works.... But when we'll be at this stage, of course it should be considered.


Hi, I think integration with Baloo could be reached quite easy because Baloo reads tags/ratings/comments direct from the extended file attributes. So e.g. a user rates a song with 4 stars, the music player could store this information in the xattr of the file and Baloo will grab it automatically (and vice versa).

For details please read this blog post from Vishesh Handa: http://vhanda.in/blog/2014/07/tagging-your-files/
ochurlaud
KDE Developer
Posts
62
Karma
0
OS

Re: Design for a Music Player

Sun May 15, 2016 4:21 pm
Hi,

I'm currently implementing the player part of the music player.

I wasn't able to make QMediaPlayer work so I moved to libvlc. Now, if libvlc is a dependency, it might be better to stick with it, and remove the TagLib dependency.

Any input on this?
danielmaurer
Registered Member
Posts
5
Karma
0
OS

Re: Design for a Music Player

Wed Aug 03, 2016 11:34 am
Any news about the Music Player?
ochurlaud
KDE Developer
Posts
62
Karma
0
OS

Re: Design for a Music Player

Wed Aug 03, 2016 1:34 pm
Hi, I worked on it. The project is put on hold until Akademy (beginning of september) where we'll have a workshop to finish specifications. Some code tests have been done already, but the structure will greatly change after Akademy (it was just a proof of concept).

I'm additionally quite busy with another project those days: but feel free to help on specs.
User avatar
psifidotos
Registered Member
Posts
86
Karma
0
OS

Re: Design for a Music Player

Sun Oct 23, 2016 6:45 am
Hello,

I dont want to downgrade the effort for a new kde music player from scratch...
I would just like to give my opinion concerning the fact that there out there very good Qt5/QML applications that are struggling for supporters and developers and which I think they could be a fantastic fit in Plasma 5 with some adjustments...

From any music player I have tried, the winner for me is Yarock:
https://seb-apps.github.io/yarock/

it is fresh, modern, Qt5 only and I had the following small conversation with its developer:
psifidotos wrote:Fantastic player!!!
I would wish only for a bigger involvement from the kde community...
It could really shine as the default music player for Plasma 5...

SebAmar - developer wrote:Hi, thanks for your feedback. I'm glad you appreciate. Maybe one day, kde guys will be interested....

which I personally think it is very positive response...

For a video player, the winner is by far Bomi Player
https://bomi-player.github.io/

it is fantastic! fresh, modern, Qt5/QML UI...
the only problem is that is not very active currently, something that the kde community could help a lot I think!!

thanks again for all the efforts!!!

regards,
michail


Bookmarks



Who is online

Registered users: bartoloni, Bing [Bot], Google [Bot], Sogou [Bot]