From Music Player Daemon Community Wiki

[edit] Main plans

• Language: C++
  • question: what are the reasons for using C++ instead of a higher level scripting language like ruby or python?
  • answer: When using a scripting language you always need an interpreter for this language, which adds additional overhead. Maybe someone wants to use MPD on a minimal or embedded system.
  • Rebutal:'Then why not use C, if you want embedded system or minimal support you can save quite some using just plain C.'
  • C++ over C troll: C++ provides various advantages over C beside object-oriented design, which include the STL and their safe containers which are just *the* stuff lacking in C. And there's not much use for those (unsafe) pointers, because you have references that fit the job perfectly, with easier to use semantics.
  • Then why not Objective-C ? it also comes whith every gcc-implementation and afaik is embeddable. C++ itself is a popular but rather harsh OO-aproach. To quote Alan Kay: "When I invented the term Object Orientation, I did not have C++ in mind" source
  • Suggestion: D language main page C to D translation
    • D actually does what everyone here wants, OO for the pointer haters, pointers where OO isn't applicable, many useful extra's that C++ doesn't have that you will find in Python and the like.
• Make everything OO
  • I'd be careful with that "everything" business. Not everything lends itself to OO. Use OO when/where it is appropriate, which is in many places, but certainly not *everywhere*. -- mackstann
• Use threads (will allow much more flexibility for what we want to do)
• Plugin architecture w/ a python interface for scripting
  • did you looked at embedding a Ruby-Interpreter? It's much easyer/nicer then to embed python. Here is a small example (2K) -- jonas
  • I'd suggest using Lua: it is easy to embed and extend, performs well, and is really lightweight (150-250 kB of code, depending on config). In comparison Python is bloated...
    • I'd recommend against using Lua. I just replaces Lua with Python in my gnome-hearts game. The problem with Lua is that it is neither forwards nor backwards compatible. I.e. you cannot run Lua 5.0 scripts on 5.1 or vice versa. Quite a few Linux distributions package Lua in such a way that you cannot install multiple versions of Lua at the same time (e.g. Suse). This leads to problems. You can only use Lua if you import the Lua source into the MPD source. You cannot depend on the liblua supplied by the OS. On top of that, the Lua-C interface is not very nice. Python-C is much nicer to work with. I don't know about Rudy though, so don't consider this a pro-Python recommendation but just an anti-Lua recommendation.
  • I'd recommend against a plugin architecture alltogether and improve the client API to have notifications. What are some examples of plugins that couldn't be done as a client?
    • input plugins (http://, file://, daap://, lastfm://, ...), decoder plugins (mp3, aac, flac, ogg, ...), effect plugins (equalizer, reverb, voice-removal, ...), output plugins (alsa, oss, icecast, gstreamer, ...). Also usermanagement, database backends, etc. could be done as plugins. -- jonas

• Playlists
  • Allow creation of playlists* on the fly
  • Allow attaching a playlist to an audio device or stream
  • Playlist plugins to get different types of playlists
• Queue Playlist
  • Traditional MPD v1 playlist
• DB
  • Lots of flexibility in design / have different db plugins
  • Configurable metadata
  • Enough flexibility for good stats, and rating
  • DB types
    • SQL (also sqlite)
    • FS (probably no metadata for this one)
    • traditional MPD v1 db
    • iTunes filesystem and xml database. Having this means mac (and I suppose windows) can rsync thier music collection to thier backup server, and be able to play the back up in mpd! -- mpd-email:diroussel.xsmail.com --

[edit] Other suggestions

• keep memory footprint and cpu as low as possible for embedded systems, make it work with busybox, integrate an xml/rpc interface
• integrate icecast ability
• Support for track segments in playlists: The ability to add a playlist entry that plays from 1:30 to 3:43 in track doe.ogg (gapless and precise). (Or even better, support for such segments in the database so you can create them once and then just add them to the playlist at anytime.) see madplay --start=TIME skip to begin at TIME (HH:MM:SS.DDD)--time=DURATION: play only for DURATION (HH:MM:SS.DDD)
• allow storing albums in .ZIP archives (uncompressed or fastest compression), may use the zziplib for fully transparent access to the archive... (think this is good for playing archived music albums collections)
  • Not a music player's job. I believe it's better to be implemented in a more appropriate place - the filesystem (using FUSE or whatever fits the task). --random visitor.
    • Unfortunately implementation in a "more appropriate place" is still lacking. There is FUSE and AVFS but it's not what you want. AVFS requires you to mount the whole filesystem somewhere, not that much a problem. But the problem is, you cannot really build the database of tracks in archives because you actually have to append "#" to the name of your archive to see what's inside - that's something MPD wouldn't know to do. (eg. "album1.tar.gz#/"). Reading ZIPs and other archives has been implemented in some music players (xmms, foobar2000) and so far it has apparently been the best working solution. --another random visitor.
      • xmms is hardly an example to follow. if it needs to be implemented anyway, it should be implemented where it belongs and not where it doesn't. --ya random visitor
• streaming of single files and current audio output
• split MPD to 3 parts
  • music player for different formats with gapless playback & crossfade with simple song queue (something like advanced mpg123)
  • media database
  • playlist
• More options in crossfader, such as fade up, fade out times. This is because radio segues frequently have the next song start at full volume, not fade up over the previous song. MPD would be the best tool for internet radio then.
• learning of playlists: whenever a song is played in full length it is rated up, when it is skipped it is rated down. Highly rated songs should be played more often in shuffle mode.
  • What about implementing an algorithm something like IMMS? -- CoderGnome
  • Seconded - "IMMS" is the feature I am missing most in MPD, but not only for playlist learning, also for collecting data on which songs I always press "skip" so I can delete them altogether, and which songs I like most (so I might want to put on my mp3 stick) -- Erich
  • Agree. imms support would be nice. --MiR
    • I'm currently working on implementing the IMMS plugin for MPD. Stark
    • It seems a more generic way to implement such a thing is to just add a single weighting number to each playlist entry; then clients could take care of ranking according to whatever criteria, and generating or modifying playlists based on that. 129.74.64.45 19:56, 25 April 2008 (UTC)
• Rating per User like it was done by mserv. (if nothing in the queue) mserv can be configured to semi-randomly play the music which has the best rating from all the logged-in users. this would be wonderful in the office for example. description in german --epic

• Make the playback of single files possible, i.e. files which are not (yet) in the database.
  • and add them to the db, move them to a music dir if possible
• Support for Audio CD playback.
• Add support for audioscrobbler's feature "Recommendation" - appends songs that are similar to the one playing at the moment (this is the perfect exemple for a plugin feature ;) <--can also be done as a client ;)
• Brief user suggestion: how about a function for a client to register approval/disapproval of songs? This could be useful for a shared-workspace server to learn what the audience likes in that location. Moreover, you wouldn't have to resort (as suggested above) to skipping a song to register your individual taste, as it could potentially not be disliked by others in the vicinity. --jc
• active monitoring of archive folders, perhaps? I update my files frequently, and having to manually re-scan every ten minutes is a hassle. - H
  • cron it—unlink
  • or better, fam it.
    • fam would be best, but it should be optional
    • I don't think fam is suitable here because of one level limitation. Maybe inotify will suit better.
• Use SQLite [1] for DB backend? Is a lot faster than Mysql/Posgre, it's SQL and it's embeddable on small devices.
  • Please provide references for such a statement.
    • You can found speed informations [here.] See also [this link] to choose if it's appropriated for mpd
      • Non-ancient speed comparison is in the SQLite wiki.
  • SQLite will be easier to configure for 99% of users and faster for most of them. I don't think performance is any concern for 99% of users anyway. Suggest use SQLite as default: advanced users (you know who you are) can use Postgres/MySQL if they need that extra boost.
• Use of GStreamer [2] for audio playback?
  • I think that would be VERY wrong, since it would drastically increase the dependencies, making MPD very undesirable in an embedded environment (or even on a lightweight desktop).
    • GStreamer is used in embedded devices, like cell phones. Perhaps not such a bad idea after all.
    • I also put in a vote for gstreamer. I'm currently using mpd on the Maemo platform on a Nokia N800. If it uses gstreamer, it could use the device dsp as opposed to now where it's using the CPU ([1]).

• Support for "generic items" on playlists? I mean, the possibility to add "Random Rock Song" to the playlist, something like "pick one from this db query". It would be useful for "radio like" playing.

If no one else does this by the time inotify is stable I will get the patches out there to facilitate this in MPD 0.x 1.x --avuton

• Classical/Jazz music causes troubles for tagging and databases. In the DB and playlists, consider a few things about classical music:
  • The usual Artist/Album/Track hierarchy doesn't often apply, or at least is not logical in all searches.
  • The "artist" and the "composer" are almost always different, and may not be the same for all tracks on an album.
  • It rarely makes sense to specify a single artist; any of the following (and probably others) might apply:
    • Soloists (one or more)
    • Conductor
    • Name of an ensemble (an orchestra, for example)
    • Individual members of a small ensemble (which might also be named)
    • At least some of the above is actually covered by the vorbis comment [2] spec. I think MPD actually currently supports most of these tags, even in multiples, but I have yet to find a client which does! I am also not convinced that the tag set is ideal (I note that MPD supports a composer tag, which the vorbis document suggests should use the artist tag).
  • A single work often comprises multiple movements, which are almost always encoded as individual files (since they are separate tracks on the CD). It would be nice to have the option of treating the whole work as a single entity. For example, when playing in random mode, I might like to hear all of a violin concerto and not just the second movement.
    • This gets even worse if one follows the tagging conventions described in these vorbis comment recommendations [3] [4], since the TITLE field for all movements of the work will be the same, with the text differentiating the movements delegated to the PART field (and the ordering possibly defined by the PARTNUMBER field) - since those fields are ignored by MPD the only way to tell the difference between the tracks is the tracknumber on the CD, and even that might fail on large works (eg full-lenth oratorios and operas) which may span multiple CDs (depends if the client handles the TAG_ITEM_DISC field sanely). Fixing this properly would require changes to all the clients as well (and doing it properly would probably half-solve the parent issue; solving it for real probably involves adding a whole extra level of metadata to avoid tracks from different recordings of the same work being falsely identified together); I am tempted to simply insert a hack in the comment parsing code to construct the MPD title tag as the concatenation of these tags if they exist (something like TITLE part PARTNUMBER: PART).
  • More thought might reveal other issues.
• Use XMPP as communication protocol.
  • 'Real' jabber clients like Psi, tkabber or gajim could talk to mpd based on service discovery. Of course there would also be dedicated clients.
  • MPD would act as a contact displaying current song in its status message etc.
  • Maybe one could rate songs via pubsub.
  • It would probably better to do that as a plugin so you don't have to run a server or have internet access but basing the core protocol on xmpp seems elegant to me. (BartVB: People are working on a zeroconf/rendezvous/bonjour implementation that doesn't need a server for XMPP communication. Also a lot of stuff is going on in the RDP/VoIP department, that would be ideal for streaming).
  • I think it would be very nice to work with the XMPP task force and other (streaming) audio servers on this. It would be great if some common base API in XMPP could be established. This would make it possible to write clients that work with a variety of servers, not just MPD. This would boost the number of clients that can be used with MPD greatly. MPD specific features could be added as extensions to that common base API.
• add possibility to save the currently playing stream.
• Windows NT port? (port mpd to win32 and run mpd as a windows nt service) I think it would be very intresting for all those people who have to use Windows NT 5.x (i.e. for playing games)
• Crossfade now ? e.g. have the ability to *gracefully* switch to next song before current song has finished. Currently 'next' command directly switches to next song without fading.
• Specific security options, the current four (read,add,control,admin) are quite general. E.g. one could allow a user to only click next or previous but not pause or stop.
  • couple this with the per-user track ratings from above for a real torture device! :D
• More scripting freedom by allowing user to set commands to be run upon certain events, e.g. new song starting, end of playlist reached, songs added to playlist etc.
• Tagging mechanism, allowing free tagging. Could even replace Playlists by making all Titles having one Tag one Playlist.
• Move database stuff into a client. DB client feeds daemon with playlists/songs and handles search queries. It would allow flexibility to have e.g. a filesystem based DB and use find command for searches or a full MySQL DB, whatever you want.
• keep personalized radio automation in mind as killer use case, don't make it yet another bloated mp3 player such as XMMS or winamp, but improve the client server solution with a modularized API and support of more web based standards and services. remote control and unattended (headless) mode are the killer features of mpd. REST-api, smartplaylist (imms, audioscrobbler), jingle inserts, schedule based playlists (ical), and variable cue/fades - make it the busybox of audio.