Difference between revisions of "GSoC Ideas 2008"

From Audacity Wiki
Jump to: navigation, search
(capitalised instances of "audacity". "Provide multi-channel export" might not be quite clear in context of current mechanism for exporting to separate channels. Do we mean a GUI to choose 5:1, 7:1...)
(Multi-Channel needs a mentor to be on this page. Moved to More GSoC Ideas)
Line 79: Line 79:
==Play-Back Enhancements==
==Play-Back Enhancements==
'''Possible Mentors:'''
'''Possible Mentors:'''
* [[DominicMazzoni|Dominic Mazzoni]], Vaughan Johnson, [[User:James|James Crook]]
* [[DominicMazzoni|Dominic Mazzoni]], Vaughan Johnson
Line 116: Line 116:
* Importer is probably easier to do and independent of export. Adding an importer should not be terribly hard to do, at least for mono and stereo files which covers most use cases. No interface modifications needed to do this, and enabling / disabling it at build time is clean and follows other importers.
* Importer is probably easier to do and independent of export. Adding an importer should not be terribly hard to do, at least for mono and stereo files which covers most use cases. No interface modifications needed to do this, and enabling / disabling it at build time is clean and follows other importers.
* Metadata support can be implemented after other parts are complete / working.
* Metadata support can be implemented after other parts are complete / working.
==Multi-Channel Audio support==
'''Possible Mentors:'''
* ?
Audacity is currently only designed with stereo and mono audio in mind. There is a mechanism for exporting tracks from a project to separate channels in a file, but there is no mechanism for panning audio between more than two channels. Given the widespread use of multiple channel audio (5.1 surround, ambisonics etc) it would be good if Audacity could support working with these formats. Adding this support requires a number of separate changes, each of which could be quite far-reaching in the existing Audacity code base:
* Allow arbitrary sized groups of tracks to be linked, rather than just pairs of tracks. This is currently very badly abstracted in the code, so will mean a lot of fixing of existing code to use the new track group interface.
* Create a multi-channel capable panning module to replace the current pan control in feeding mono tracks to a multi-channel output. This must cope with a number of different multi-channel formats, and be extensible in the future for more. Cinelerra may have something suitable for 5.1 as a starting point.
* Provide multi-channel playback in Audacity. Some simple implementations of this exist, but do not use multi-channel mixing of content. The Audacity mixer needs to become multi-channel capable if it is not already, and be linked up to the sound card. Some system for coping if the sound device does not support the Audacity format will be needed (more on platforms with inflexible audio APIs than on those with a plug-in architecture like ALSA where this can probably be done outside Audacity)
* Provide multi-channel export from Audacity. Mixing shared with above, but may need work on exporter modules to provide things like channel mapping control if needed by the format.
* Enable track group support in multi-channel importers, so that multi-channel files come in as a track group not lots of mono tracks as is currently the case. This is probably the simplest section of the work.
* wxWidgets and C++
* Some portions may need knowledge of psychoacoustics for doing 3-D panning control
* access to some multi-channel audio hardware would be advantageous.
'''Early spinoffs from this work:'''
* Track grouping could be done independently of the rest. The same may also be true of a better panning control, and cleaning up the current odd implementation of mono/left/right/stereo tracks.

Revision as of 12:53, 25 February 2008

We have this email address  for Google Summer of Code enquiries. We also discuss our plans on the Audacity developer list, so you may want to subscribe to that too.


Possible Mentors These are, in order, the most likely or best mentors for this project idea.
Skills For nearly all project ideas, wxWidgets and C++ programming are essential. Some projects need additional skills too.
Difficulty 'Easy', 'Moderate' or 'Hard'.

Hard tasks can be made easier by solving a simpler problem. That's a decision that needs to be made early on. 'Easy' problems are lower risk. They are better suited to being done in separate smaller pieces if the going gets tough. So take the 'difficulty' grading with a grain of salt. It's only a guideline of how hard we think the problem is.

Early Spinoffs We regard it as vital that projects have early spinoffs that can be completed well within the time. These early spinoffs help to ensure that the code is useful to us. We don't want to end up with 'almost complete' code that we cannot use!

Below is our current pick of project ideas.

Feel free to suggest your own ideas as well.

  • It would be best to write the first version on More GSoC Ideas.
  • When the idea is well defined and mentors have been found, it can be moved to this page.

Label Track Enhancements

Possible Mentors:

Description: Audacity has flexible Label tracks for annotating sections of the audio. The method for positioning and dragging the labels allows the same kind of labels to easily be used to label points, ranges, and also maintain boundaries between regions by dragging two end points at the same time.

We're looking for proposals for the next stage of enhancements, that integrate them more into the audio editing process. Possibilities to consider include:

  • More operations on labels, such as 'apply effect at labels'.
  • Visual enhancements, such as different icons and colours associated with different kinds of labels.
  • Handling of very large numbers of labels. This requires both optimisations and new visual options.
  • Snapping of labels, so that they position at specified time intervals.
  • New ways to automatically compute labels.

A detailed proposal should make clear the Use Cases for the enhanced labels that are motivating the changes.


  • wxWidgets and C++

Early spinoff from this work:

  • Label tracks to stick to the track above, so that they edit together.

Postfish Integration

Possible Mentors:

Description: Postfish is a p-threads based Linux audio application with uncompromising quality and some unique effects such as 'deverb' which removes unwanted reverb from a track. Currently it can't be used from within Audacity.

Integrating it into Audacity will be a challenge indeed, particularly on the windows side where we anticipate problems with a simple translation to wxThreads. The student will need to be prepared to dive into such code.

We also have to be mindful that Audacity will usually be run on machines with far less processing power than the ideal for Postfish. Postfish does heavy number crunching. Its 'deverb' effect was designed for Dual Xeon 3GHz systems. For its integration in Audacity we want to fall-back gracefully to non-real time mode when necessary.

The Ardor project has a version of jack (Jack Audio Connection Kit) that is able to run under windows. This might be a good way to get Audacity and Postfish working together under Windows, as it opens up other possibilities for Audacity too. An alternative route would use the new plug-in architecture, so that a Postfish bridge is made as an Audacity plug-in.

This is part of the Connected Open Source initiative, aiming to build more bridges between Open Source projects.


  • wxWidgets and C++
  • pThreads
  • Experience with both Linux and Windows would help.

Early spinoffs from this work:

  • Demonstration of a simple real-time echo effect using same thread structure as planned for Postfish integration.

Intuitive cross-fading

Possible Mentors:

  • Matt Brubeck

Description: One of the most common operations people want to do when mixing audio is to smoothly transition between two sound clips. This is commonly called a cross-fade. This operation is technically possible in Audacity now, but it is very clunky, requiring multiple steps and no editability short of undoing the actions and starting again. We are looking for someone to implement a clean, intuitive, nondestructive cross-fade for Audacity. Audacity already has all of the infrastructure necessary to support implementing this operation nondestructively and we already have a clear plan for how it should work. The following webpage has a mockup of what we think the GUI might look like:


This feature, while seemingly small, would represent a huge boost in usability for Audacity. This feature is intimately related to several other UI enhancements that we have proposed: for example, one element of this proposed GUI is that clips "stick" to each other or "snap" into place when you push them together. Such a snap-to behavior would be great in several other circumstances, for example having a track stick to t=0, or to a point that lines up with another track.


  • wxWidgets and C++

Early spinoffs from this work:

  • Ability for all effects to be faded in/out automatically. This can avoid clicks in some circumstances.

Play-Back Enhancements

Possible Mentors:

Description: Audacity lags behind commercial audio software in a number of details of its play back behaviour. Specific enhancements we would like a summer student to provide are:

  • No 'click' on start/stop/loop; At the moment there usually is an audible click when Audacity starts or stops playing a sound, or in iterations of playing a loop. A very short fade-in and fade-out applied only to playback should fix this.
  • Loop play adjusts dynamically to boundaries being moved; Finding the precise boundaries of a sound, for example an unwanted sound to be fixed, can be difficult with Audacity as it currently is. The location of the sound isn't obvious from the waveform. The new option would allow playing the sound in a loop, adjusting the boundaries to find out exactly where it starts and stops.
  • Vari-speed playback; Fast playback of sound allows sections of audio to be located more rapidly. Slow playback allows precise location (on timeline) of sound to be determined more accurately. There is a crude version of this on the 'Transcription Toolbar' - refining it would include allowing the speed to vary during playback without starting and stopping.
  • Drag-playback-cursor whilst playing; This requires changes to both playback and GUI. It is an extension of vari-speed playback and would make locating sound more rapid.
  • Play all 'labels' on the selected label tracks; Labels can be placed on the Audio both manually and automatically. This has many uses, one being the possibility of previewing a recording whilst skipping over periods of silence.


  • wxWidgets and C++

Early spinoffs from this work:

  • The schedule should plan to have some features complete to the 'release candidate' phase by the half way point. This is more useful than progressing all of the features in tandem, and perhaps completing none of them if time runs out.

FFmpeg integration

Possible Mentors:

Description: A patch has been produced in the past to use FFmpeg libraries for importing and exporting audio files in a wide variety of audio formats. This however was against 1.2.x and will require considerable changes to integrate it with current audacity code. There will also be issues surrounding the build system and ensuring license requirements are met when distributing the resulting program.

  • Import needs to decode the imported files into audacity, handling varying channel counts sensibly.
  • Metadata in imported files should be fed into the audacity meta-data handling so it can be stored, edited and used for exported files.
  • A decision is needed on what to do if video files (with and without sound tracks) are presented.
  • Export will need to work out how to provide a user interface to handle choice of codec and container formats.
  • Export should cater for multi-channel output where applicable with more than 2 output channels, using the export routing code already in place.
  • Export needs to write relevant metadata to the exported file from the available audacity metadata and user interface.


  • wxWidgets and C++
  • Must be prepared to work on both Windows and Linux and ideally Mac OSX too.

Early spinoffs from this work:

  • Importer is probably easier to do and independent of export. Adding an importer should not be terribly hard to do, at least for mono and stereo files which covers most use cases. No interface modifications needed to do this, and enabling / disabling it at build time is clean and follows other importers.
  • Metadata support can be implemented after other parts are complete / working.

More ideas at More GSoC Ideas; also the feature Feature Requests page may suggest ideas for a project proposal.