-
Notifications
You must be signed in to change notification settings - Fork 2
GSoC:2011 Proposed projects
The following ideas are hints at possible projects that we would like to see in XMMS2. We also welcome new ideas warmly, so please feel free to suggest your own! If you are interested in working on GSoC 2011 with us, please drop by the IRC channel to ask any questions or details, we'd be glad to discuss the projects with you before you even start writing your proposal!
This is where you get the chance to implement that really cool music-player related idea that has been brewing in your mind. It may be some funny interface, a crazy effect, a revolutionary way to handle collections, or something different. Surprise us! We love new ideas!
- Language: Depends
- Level: Depends
- Mentor: Depends
Rockbox is the super cool F/OSS firmware for your music player. It stores its metadata in an ondisk format called TagCache. This project would be to split the TagCache code from Rockbox out into a library, and then write a service client that given the mount point of a rockbox device and the name of a collection would merge that collection to the player. It should hopefully support updating the TagCache on the device, but that can also be done by having the device sync itself. It should also support removing all songs from an arbitrary collection from the device.
- Language: C
- Level: Medium
- Mentor: N/A
Stream and browse spotify songs (probably worth taking a look at Despotify).
- Language: C
- Level: Medium
- Mentor: N/A
One of the most requested features is a cross-fade plugin. Right now cross-fade is not possible since effects (and all xform elements) are re-created for each song. Also the interface for enable and manage effect xforms is very clumsy. This SoC task is divided in three tasks. 1) create persistent xforms 2) revisit the effect configuration and 3) create a crossfade plugin. This project could also investigate passing data in frequency domain in xform chain (see this ml thread). The following bugs are related: 908, 820 and 2008. I think one of the great outcomes of this project would be that except cross-fade there should be a easier way to configure, enable and chain effects. This project has been run as a GSoC project before, but has not reached the maturity required to be merged, so there might be ideas to salvage.
- Language: C
- Level: Hard
- Mentor: N/A
New formats like AC3 and DTS supports multiple channels. XMMS2 is technically prepared for this but without any decent support in the output plugins. The task will be to get full multiple channel support in XMMS2 for the PulseAudio, alsa and oss output (bonus if CoreAudio also supports it!). There have been attempts at doing this before, but none of the attempts have ever finished. This would also include updating the format converter to be able to resample multichannel songs to different numbers of channels, and perhaps also surround filters from stereo to multichannel for the really nutty students.
- Language: C
- Level: Hard
- Mentor: N/A
The Service Clients concept has been around in the XMMS2 world for quite some time. There is even a reference implementation available. The project would be to bring this reference implementation into shape and integrate it with our generated IPC framework. The API might also need some clean up, analyze it and point out pros and cons in your proposal.
- Language: C
- Level: Medium
- Mentor: N/A
Currently XMMS2 has some basic random play facilities. It would be nice to do smarter random play, taking for instance the music taste of the user into account. See Smarter Playlists for a more extended description.
- Language: C, any
- Level: Medium
- Mentor: Possibly Nesciens
Mac OSX is a different kind of beast than most other unixes, this also means that it needs some extra integration. We are looking for a student that could help further the XMMS2 integration with MacOSX. Primarily the product will be a build system that build all of XMMS2's dependencies so that it can be distributed as a self sustained APP on a DMG. Something also needs to install a symlink in /usr/bin for the command line client which should be loaded from within the .app. The XMMS2 build system should also be updated to produce a framework for xmmsclient, xmmsclient-cocoa and xmmsclient-glib. Integration with media buttons (play, next, etc), listening to signals when computer goes to sleep (to pause music), automatic import of the iTunes library would be nice. It would also be cool if the XMMS2 dock app had support for updating the configuration, at least in a simple editable table view. A good hand with waf and Objective-C is a merit.
- Language: Python/Objective-C/C
- Level: Medium to Hard
- Mentor: N/A
A previous GSoC brought us our vision of generating lots of boring code in the IPC layer. Currently code to work with the protocol is generated for the server side and has been in use for the past year with great success, but the client side is still not generated. This task could involve updating all our client libraries, or just a few, with the priority to generate the C-based client library.
- Language: C,Python,Ruby,Perl,C++
- Level: Easy to Medium
- Mentor: N/A
As it's hip to write applications in JavaScript these days it would be nice if we had a client that exposes the XMMS2 API as a JSON/REST service. This has been reimplemented in quite a few clients already, but never in a way meant for being reused. A proposal would discuss the technical difficulties in making a good JSON/REST-API (for example how to treat broadcasts, signals, bindata), and what kind of problems might appear (namespace issues etc), what HTTP verbs fits where etc. This client would preferably be generated with the help of GenIPC, either build time, or on the fly. This does not overlap with the previous task.
- Language: Any (preferably Python), JavaScript (demo app, and library if JSON/REST service is not enough)
- Level: Easy to Medium
- Mentor: N/A
Content is available under GNU Free Documentation License 1.2 unless otherwise noted.
- Community
- Development