GSoC/Ideas

The SuperCollider dev community would love to mentor some students in Google Summer of Code projects, so here are some ideas for projects that would be (a) really cool, (b) appropriate for a GSoC student, and (c) super-useful to the whole world.

Other crazy ideas welcome: SuperCollider is a really cool environment for all sorts of audio/music stuff, so we're sure you can come up with some blue-skies ideas that we've never thought of.

License: SuperCollider is released under GPLv2+, so students will need to publish their code under a compatible license (preferably, the same license).


 * Students please feel free to contact us using the SuperCollider mailing lists (sc-users, sc-dev)
 * SC folks please feel free to add/amplify ideas on this page. Google requires each idea to include "rated difficulty and with required skills", and ideas should also have potential mentors too. Remember that the project should be a nice chance for someone to develop some good coding skills and experience.

Flexible documentation system
At present SuperCollider's help documentation is maintained as HTML files, which is nice and easy and cross-platform but has various drawbacks (namely: rendering differences in different platforms; lack of semantic structure; clumsy WebKit HTML). At the SuperCollider Symposium 2009 the developers sketched out an approach with documentation stored in a structured back-end format which would generate HTML and other formats as required, and with a structured editor for better docs editing/maintenance.

The student may wish to propose/research which technology to use for the structured data, although the mentors do have some ideas ;)

(As background reading, it would be extremely useful to have a good look around at how other projects store/structure/generate their documentation.)


 * Rating: medium
 * Skills: database skills

SuperCollider on Android
Work has begun on porting SuperCollider's audio synthesis engine to android (SuperCollider-Android). This is at an ideal stage for a student with good C/C++ skills and an urge to develop cool audio stuff for the up-and-coming platform...


 * Rating: medium-to-difficult
 * Skills: C/C++/Java, linux

SuperCollider on iPhone
SuperCollider has already been ported to iPhone. That means there's potential to create some cool custom apps that use the SuperCollider language and/or SC's amazing audio engine, or plugins that make use of the hardware (e.g. an accelerometer-based gestural synthesiser...?).


 * Rating: medium
 * Skills: C/C++/ObjC, iphone/mac

More Faust+SuperCollider integration
Faust is a language and system for designing audio plugins, then compiling them as plugins for various types of infrastructure. It can already generate SuperCollider plugins (great!), but maybe it would be nice to be able to call Faust from within SuperCollider language: for example, use SuperCollider to design a synthesis process, then "export"/"translate" that into Faust so that it can turn into efficient multiplatform DSP code.


 * Rating: medium
 * Skills: DSP, object-oriented and dataflow programming experience would be helpful

Preferences system
SuperCollider language contains many features, some implemented in C/C++/Obj-C primitives, and some implemented purely in SuperCollider language code. Increasingly, there's a need for a user-preferences system, and not one programmed in SC script (why? so that preference data can be used even before the class library is loaded, e.g. which paths to search for SC classes, or whether to load class additions). However we also need to be able to get/set those values from SC script, which is easy enough to do by adding a primitive for this purpose.

I'd suggest that it would be good to look at how other established open-source systems implement preferences, and maybe use some existing infrastructure. It would need to be a cross-platform, lightweight infrastructure. Or you might find it better to create a simple infrastructure from scratch.

Preferences would probably be some kind of key=>value structure, able to store preferences which are numerical, string, multiple, optional, etc...


 * Rating: easy
 * Skills: C/C++

Just-in-time audio plugins (LLVM)
SuperCollider's audio server uses C/C++ plugins to define the basic units, and "SynthDefs" and other things specified from the SC language to define the overall flow of signals and processes. It would be really cool if it was possible to write some code in SuperCollider language that would use LLVM technology to just-in-time create plugins for the server, so as to enable flexible super-efficient audio processing and other stuff.


 * Rating: difficult
 * Skills: C/C++, LLVM experience if poss

scplug: SuperCollider's audio synth as a browser plugin
SuperCollider's advanced audio synthesis engine is incorporated as a browser plugin (in alpha dev stage). Some work is needed to take this concept and turn it into a smooth cross-platform reality.


 * Rating: medium
 * Skills: C/C++, Qt4 a definite advantage.

Extending Machine listening facilities
SuperCollider includes some musical machine-listening tools such as a pitch tracker, key tracker, timbre analysis etc, but there are always more algorithms to build, explore, and improve. Examples of missing facilities include a chord detector, polyphonic pitch detector, predominant f0 extractor for complex audio tracks (detecting lead lines), sensory dissonance model, and more.


 * Rating: medium (to difficult depending on research frontier for automated music transcription and music information retrieval)
 * Skills: C/C++, Digital Signal Processing

scvim: Enhancements for the SuperCollider vim environment
Help get scvim to a state where it has all the features of the default sc editor, maybe more?
 * Finalize the SCVim document class.
 * Dynamically process help documentation [unhtml/unrtf on the fly].
 * scvim for mac osx native (instructions at the mailing list).
 * Make the install process easier.


 * Rating: medium
 * Skills: scripting: ruby, vim.

Other (half-formed) ideas

 * scgraph is really cool but fairly new - there must be a fun project in that area?
 * If you have a Pandora then compiling sc for pandora should be an interesting thing to do...
 * Something with jscEclipse (SuperCollider from within eclipse)
 * Something with PsyCollider (SuperCollider python interface)

Application template
If you're a student thinking of applying, here is the set of questions we'd like you to answer:

(1) BASIC INFORMATION:

(1.1) Your preferred email address

(1.2) What are you studying, subject, level and school?

(1.3) What country do you live in, and at what times are you most likely to be available for communication (using e.g. email or IRC)?

(1.4) Do you have other commitments for the summer period? Do you plan to take any vacations? (If yes, when?)

(1.5) Why do you want to participate in summer of code?

(2) EXPERIENCE:

(2.1) What programs/software have you worked on before?

(2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

(2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

(2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

(2.5) Have you worked with real-time music/audio software before? (eg supercollider, or puredata...) What have you done?

(3) COMMUNICATION SKILLS:

(3.1) English is the project's working language. Describe your fluency level in written English.

(3.2) What spoken languages are you fluent in?

(3.3) Are you good at interacting with other developers and musicians? Our community is friendly, but has a variety of people with very different backgrounds (e.g. musicians with very little programming background).

(3.4) Are you good at sorting useful criticisms from useless ones?

(3.5) How autonomous are you when developing? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't satisfy?

(4) PROJECT:

(4.1) Which project would you like to do? (Either a project from our ideas list, or one of your own.) If it is your own idea, please describe the project and specifically what you expect to achieve.

(4.2) Why did you choose this project?

(4.3) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

(4.4) Include as much technical detail about your implementation as you can

(4.5) What do you expect to gain from this project?

(5) PRACTICAL CONSIDERATIONS:

(5.1) Are you familiar with any of the following tools/languages? Please state which ones.


 * Subversion (used for managing source-code)
 * C/C++ (used for building supercollider synth and language)
 * Objective-C (used for supercollider app on mac)
 * build environments (eg cmake/autotools/scons)

(5.2) Which tools do you normally use for development? Why do you use them?

(5.3) What programming languages are you fluent in?

(5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail.