Difference between revisions of "GSoC Ideas 2008"

From Audacity Wiki
Jump to: navigation, search
(#10. FFmpeg integration: - more detail on work needed)
(de-hyphenating cross-fade to Connie's preferred crossfade)
 
(64 intermediate revisions by 7 users not shown)
Line 1: Line 1:
The Audacity Developer Team aren't part of Google Summer of Code 2007 but we want to be in 2008 and we are watching what happens in 2007 closely.
+
{{Intro|This page and [[More GSoC Ideas]] contain the ideas that were offered as possible [[:Category:GSoC|Google Summer of Code]] projects in 2008. In the event, five GSoC projects [[GSoC 2008 Projects|ran in 2008]]. |For more information about our current GSoC involvement, see [[GSoC Ideas]] and join our [http://lists.sourceforge.net/lists/listinfo/audacity-devel developers mailing list].}}
  
http://code.google.com/summerofcode.html
 
  
Please help us to get ready for the next round.  It is never too early.  Your ideas and enthusiasm will help us make it happen next year.  You can contact us at this email address: [mailto:[email protected] [email protected]]. 
+
__TOC__
  
If you're looking for a 2007 GSoC project on Audacity, wxWidgets are participating in GSoC 2007 and so are Xiph.org.  We use code from both, so indirectly work on those projects may benefit Audacity.  If you have ideas for a project of that kind that you would like to do, we'd be keen to hear from you and discuss it with you, at the address above.
 
  
This page is mainly for Ideas for projects.
+
==GSoC Ideas==
  
 +
This page represents the pick of our current project ideas. 
 +
{{Hint|Feel free to suggest your own ideas as well!
 +
* It would be best to write the first version on [[More GSoC Ideas]], following the same format. 
 +
* When the idea is well defined and mentors have been found, it can be moved to this page.}}
  
Other pages related to GSoC 2008 are:
 
  
* [[SummerOfCode Planning]] help us get ready for Google Summer of Code 2008.
+
Subheadings for each idea:
* Our proposed [[SummerOfCodeMentor|application]] to Google for mentoring status for 2008.
+
{{Template:GSoC Ideas Key}}
* Our proposed [[SummerOfCodeStudent|application form]] for Google Summer of Code 2008 Students.
 
  
  
= Ideas =
+
<s>
 +
==Label Track Enhancements ''(done 2008)''==
 +
'''Possible Mentors:'''
 +
* [[User:James|James Crook]], [[User:donfede|Federico Grau]]
  
Below is a list of potential projects, but feel free to suggest your own ideas as well.
+
'''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:
  
Note that there are literally hundreds of user-contributed feature suggestions on the '''[[Feature Requests]]''' page. A good project proposal could combine a number of these suggestions into one proposal.  This way of making a proposal makes it particularly easy to specify early spinoffs - which we regard as vital to a successful project.
+
* More operations on labels, such as 'apply effect at labels'.
 +
* Visual enhancements, such as different icons and colors 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.
  
==#1. Audio 'Diff'==
+
'''Skills:'''
''(Suggested by '''James Crook''')''
+
* wxWidgets and C++
  
Ability to compare and align two sound sequences just as one compares text using diff would be a powerful new feature in Audacity.  It would greatly facilitate the combining of sounds from multiple 'takes' of the same trackIt would also be of use to people looking to identify particular known sounds, e.g. repeated themes in birdsong, in a very long recordings.
+
'''Difficulty:'''
 +
* EasyImprovements can be made in small steps.
  
The implementation idea is conceptually simple.  The spectra in two sounds being compared are computed at regular spacings - using existing Audacity code.  A metric for spectral similarity is written.  In the first incarnation it can be a correlation function.
+
'''Notes:'''
  
The alignment (diff) of the two sounds is computed using standard least-distance algorithms, using an adjustable parameter which is the penalty for stretching the sound and the spectral similarity score.
+
* There is a discussion of labelling implementation and the features it might contain at [[Label Track]].
  
The GUI for presenting the alignment could use the existing code that allows a track to be split into smaller chunks that can be shifted around augmented with a 2D similarity 'plot'.  If there is time, an enhanced interface that caters more directly to the two use cases could be provided.
+
'''Early spinoff from this work:'''
 +
* Label tracks to stick to the track above, so that they edit together.</s>
  
'''Early spinoffs from this work:'''
 
* A method for scoring the similarity of two spectra built into audacity. 
 
* A 2D graphical display that will show the similarity of two spectra across the different frequencies.
 
  
 +
==Playback Enhancements==
 +
'''Possible Mentors:'''
 +
* [[DominicMazzoni|Dominic Mazzoni]], [[User:Vaughan|Vaughan Johnson]]
  
==#2. Computed Automation Tracks==
+
'''Description:'''
''(suggested by ???)''
+
Audacity lags behind commercial audio software in a number of details of its playback behaviour.  Specific enhancements we would like a summer student to provide are:
  
In many ways Audacity is just a specialised multi-track chart recorderThis project is to add a new type of track, a track which shows multiple computed automation variablesRather than being stored, these are computed on demand.  The immediate application for these is to give more flexibility in segmenting speechThey can give feedback on where the existing algorithms are proposing to segment a track, allowing fine tuning of the parameters by adjusting the threshold.
+
* 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 isThe 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 rapidlySlow 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.
  
If there is time, the computed automation tracks could be used to control parameters in one or more other effect, not just used for segmenting audio.
+
'''Skills:'''
 +
* wxWidgets and C++
  
Another direction this could be taken in is in improving the transcription processing in Audacity.
+
'''Difficulty:'''
 +
* Moderate.  Easy to vary the difficulty in either direction through choice of what to implement.
  
'''Early spinoff from this work:'''
+
'''Early spinoffs from this work:'''
* Implementation of a thresholding automation track, using an existing threshold slider GUI element backported from Audacity-extra and adding the new compute-on-demand code.
+
* 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.
  
  
==#3. Bridges==
+
==Bridges==
''(suggested by '''Jeremy Henty''')''
+
'''Possible Mentors:'''
 +
* [[User:donfede|Federico Grau]] (for Rivendell); <s>Bartek Golenzo (Octave).</s>
  
One way to grow the feature set of Audacity and at the same time to avoid re-inventing the wheel is to build compatibility 'bridges' between Audacity and other Open Source programs.  Two examples of bridges already supported by Audacity are:
+
'''Description:'''
* Bridge to Octave - Octave is an Open Source program for mathematical analysis and is useful in digital signal processing (DSP).  Audacity has a bridge to Octave that allows Octave to apply effects to Audacity waveforms and to annotate Audacity waveforms with labels.
+
One way to grow the feature set of Audacity and at the same time to avoid re-inventing the wheel is to build compatibility 'bridges' between Audacity and other Open Source programs.  This is an example of making [[Connected Open Source]] a reality.  Two examples of bridges for Audacity are:
* Bridge to Rivendell - Rivendell is an Open Source program for radio station management.  The Rivendell bridges allows Audacity and Rivendell to exchange play-lists.
+
* Bridge to Octave - Octave is an Open Source program for mathematical analysis and is useful in digital signal processing (DSP).  Audacity could have a bridge to Octave that allows Octave to apply effects to Audacity waveforms and to annotate Audacity waveforms with labels.
 +
* Bridge to Rivendell - Rivendell is an Open Source program for radio station management.  The Rivendell bridges already allows Audacity and Rivendell to exchange playlists.  Work on it would improve the integration.
  
 
A proposal for a new bridge should go into some detail as to what features of the other program will be bridged.  Generally the plan should avoid extensive work on the other program, since the point of the project is to extend Audacity.
 
A proposal for a new bridge should go into some detail as to what features of the other program will be bridged.  Generally the plan should avoid extensive work on the other program, since the point of the project is to extend Audacity.
 +
 +
This is part of the [[Connected Open Source]] initiative, aiming to build more bridges between Open Source projects.
 +
 +
'''Skills:'''
 +
* wxWidgets and C++
 +
* Familiarity with Octave or Rivendell or other software being bridged to.
 +
 +
'''Difficulty:'''
 +
* Moderate to Hard.  Student has to get familiar with two programs.
 +
 +
'''Notes:'''
 +
* The Octave bridge is probably too difficult to do without a mentor who is very familiar with Octave, and so now unlikely to go ahead unless we find a mentor for it in the time.
 +
* As we already have active development on the Rivendell bridge, and a mentor committed to it, the focus on the Rivendell bridge will be making it more flexible and a cleaner separation.  Talk with Federico for details.  Done well this will be a model for other future bridges.
  
 
'''Early spinoff from this work:'''
 
'''Early spinoff from this work:'''
 
* A restricted bridge which exposes a smaller part of the functionality.
 
* A restricted bridge which exposes a smaller part of the functionality.
  
 +
<s>
 +
==FFmpeg integration ''(done 2008)''==
 +
'''Possible Mentors:'''
 +
* [[User:Richardash1981|Richard Ash]], [[DominicMazzoni|Dominic Mazzoni]], [[User:Vaughan|Vaughan Johnson]], [[User:donfede|Federico Grau]]
  
==#4. Feature Completion==
+
'''Description:'''
''(suggested by '''James Crook''')''
+
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.
  
Identify a feature of Audacity which is in development CVS but is in some way incomplete.  Project proposal should describe how the feature would be much improved and brought to release candidate readiness.
+
'''Skills:'''
 +
* wxWidgets and C++
 +
* Must be prepared to work on both Windows and Linux and ideally Mac OS X too.
  
Some features we have in CVS that are not yet ready for our stable builds include:
+
'''Difficulty:'''
 +
* Moderate.  (Assuming nothing is done with video and the interface is kept simple).
  
* Transcription ToolBar - The Algorithms for finding word boundaries are rather buggy and slow.   
+
'''Notes:'''
* Themes - Too difficult to use as they stand, not all items are covered, does not allow theming of backgrounds yet.
+
* This is proving far and away the most popular option at the moment.  Unlike audio-diff we can't run more than one of these.  There is a second 'integrating a library' project, the Nyquist one (below).  So far no one has applied for it.  Students may want to consider making at least a place-holder application for the Nyquist project tooThen they have the option of beefing it up later through adding / modifying the comments.
 +
* For students interested in working on the Codecs rather than on directly progressing Audacity, FFMPEG have [http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2008 projects proposals], and so do [http://wiki.xiph.org/index.php/Summer_of_Code Xiph for Speex and Ogg].
  
 
'''Early spinoffs from this work:'''
 
'''Early spinoffs from this work:'''
* To be specified in the proposal.
+
* 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.
 +
</s>
  
 +
==Nyquist (Lisp) update==
 +
'''Possible Mentors:'''
 +
* [[Possible GSoC Mentors|Roger Dannenberg]]
  
==#5. Render-On-Demand==
+
'''Description:'''
''(suggested by '''Tom Moore''')''
+
Upgrade [http://www.cs.cmu.edu/~music/music.software.html Nyquist] support in Audacity to the latest version.
  
Audacity effects are currently 'batch' oriented.  You apply an effect and wait for it to render.  This is appropriate for Audacity which often runs on low spec machines.  Only the simplest effects can reliably be applied fast enough to play them as they render.   
+
Nyquist is a version of the Lisp language built into Audacity.   
  
Render-On-Demand would add an option to return immediately when applying an effect, giving greater responsivenessThe render would be applied later as the effect was playedThere are several complications to achieving this. They include tracking the state of effects that have been partially rendered and dealing gracefully with running out of CPU resources. A project proposal would need to demonstrate a clear strategy for dealing with these issues.
+
'''Skills:'''
 +
* C++.   
 +
* Developing on Linux and Windows.
 +
 
 +
'''Difficulty:'''
 +
* Moderate.
 +
 
 +
'''Notes:'''
 +
* We will also consider other proposals for Lisp work using Nyquist, especially if they will help popularise Lisp and the Nyquist extensions in AudacityIf you choose that route, please contact the {{external|[http://lists.sourceforge.net/lists/listinfo/audacity-nyquist audacity-nyquist mailing list]}} '''before''' putting significant work into your proposal.
  
 
'''Early spinoff from this work:'''
 
'''Early spinoff from this work:'''
* A visual display of the rendering state of an effect, alongside the affected track, rather than a progress indicator in a dialogThis would be used before any effects had been made 'render on demand'You'd have restricted access to Audacity menus and buttons during a renderFor example during a render you'd have the ability to examine the waveform for clipping, but not to edit sound or queue additional effects until the render completes.
+
* Demonstrate the upgrade on one of the two platforms.
 +
* If there are no unanticipated hitches, the project will be easily achievable in the 8 weeksA good project proposal based on this idea should include other improvements for the Audacity Nyquist user tooFor inspiration look at the archives of the audacity-nyquist list at SourceforgeThese would happen in the second half of the project after the basic upgrade.
  
  
==#6. Label Track Enhancements==
+
==Intuitive cross-fading==
''(suggested by '''Tom Moore''')''
+
'''Possible Mentors:'''
 +
* [[User:Vaughan|Vaughan Johnson]], [[DominicMazzoni|Dominic Mazzoni]], [[User:donfede|Federico Grau]]
  
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.
+
'''Description:'''
 +
One of the most common operations people want to do when mixing audio is to smoothly transition between two sound clipsThis is commonly called a [[crossfade|crossfade]].  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 crossfade 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 web page has a mock-up of what we think the GUI might look like:
  
We're looking for proposals for the next stage of enhancements, that integrate them more into the audio editing process. Possibilities to consider include:
+
{{external|http://limpet.net/mbrubeck/temp/cross-fade/}}
  
* More operations on labels, such as 'apply effect at labels'.
+
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 togetherSuch 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.
* Visual enhancements, such as different icons and colours associated with different kinds of labels.
 
* Handling of very large numbers of labelsThis 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.
+
'''Skills:'''
 +
* wxWidgets and C++
  
'''Early spinoff from this work:'''
+
'''Difficulty:'''
* Label tracks to stick to the track above, so that they edit together.
+
* Moderate.  
  
 +
'''Early spinoffs from this work:'''
 +
* Ability for all effects to be faded in/out automatically.  This can avoid clicks in some circumstances.
  
==#7. Postfish Integration==
 
''(suggested by ???)''
 
  
Postifsh 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.
+
==Bugfix Ninja==
 +
'''Possible Mentors:'''
 +
* [[User:Richardash1981|Richard Ash]], [[DominicMazzoni|Dominic Mazzoni]], [[User:Vaughan|Vaughan Johnson]], [[User:Leland|Leland Lucius]], [[User:donfede|Federico Grau]], [[User:James|James Crook]] 
  
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.
+
'''Description:'''
 +
We have several pesky bugs that have been preventing us getting a new stable release out, and many more details of lesser importance that make the program less good than it might be. We could very much use help vanquishing these. Have a look at the [[Release Checklist#Release Issues|priorities on our Release Checklist]] and our [[Release_checklist_not_aiming_for_1.4#Former_Aim_to|list of "aim to's"]] which we currently aren't able to progress.  
  
We also have to be mindful that Audacity will usually be run on machines with far less processing power than the ideal for PostfishPostfish does heavy number crunchingIts 'deverb' effect was designed for Dual Xeon 3GHz systemsFor its integration in Audacity we want to fall-back gracefully to non-real time mode when necessary.
+
This project would have a GSoC student working just on clearing issues, helping us to produce a high quality releaseThis is how established Open Source developers work when they are not adding major new featuresYou'll learn a great deal about working on Open Source, and particularly the way people collaborate to solve problemsThis is a very different project idea to most of the others.
  
'''Early spinoffs from this work:'''
+
The difficulties for this proposal for GSoC are:
* Demonstration of a simple real-time echo effect using same thread structure as planned for Postfish integration.
 
  
 +
* The 'plan' showing what you intend to do - particularly so we can assess whether you have done it and you can get paid.  Sometimes an apparently small issue actually opens up a big can of worms.  The plan needs to have flexibility in it.  One way to do that is with a 'points system' for the issues, where you say something like 'I plan to have 60 points worth of issues tackled by the half way stage, and 100 points worth by completion'.  This allows you to move on from an issue if it turns out to be way harder than was thought.
  
==#8. Intuitive cross-fading==
+
* The second difficulty is convincing us that you can work in this way. You'll need to convince us that you've understood some of the issues on our lists and that you can tackle them.  Show you've understood both the issue and the code involved.
''(suggested by '''Matt Brubeck''')''
 
  
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:
+
The reward is that you would help Audacity tremendously, and be a hero to us!
  
http://limpet.net/mbrubeck/temp/cross-fade/
+
'''Skills:'''
 +
* wxWidgets and C++
 +
* A knack for asking the right questions.
 +
* Comfortable with visiting many different pieces of code in a large project.
  
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 togetherSuch 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.
+
'''Difficulty:'''
 +
* Moderate to Hard.   
  
 
'''Early spinoffs from this work:'''
 
'''Early spinoffs from this work:'''
* Ability for all effects to be faded in/out automatically.  This can avoid clicks in some circumstances.
+
* At least one of the meatier 'P1 or P2 issues' solved.
 +
* At least five smaller 'P3 to P5 issues' finally closed.
  
  
==#9. Play-Back Enhancements==
+
==More ideas ==
''(First two parts suggested by '''James Crook''')''
 
  
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:
+
There are further ideas on our [[More GSoC Ideas]] page. Also see our [[Use Cases]] and [[Feature Requests]] pages (over 200 requests), which may suggest ideas for a project proposal.
  
* 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.
 
  
'''Early spinoffs from this work:'''
+
[[Category:For Developers]][[Category:GSoC]][[Category:Feature Planning]]
* 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.
 
 
 
==#10. FFmpeg integration==
 
''(Suggested by '''Richard Ash''')''
 
 
 
A patch has been produced in the past to use [http://ffmpeg.mplayerhq.hu/ 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.
 
 
 
'''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.
 

Latest revision as of 09:13, 1 May 2018

This page and More GSoC Ideas contain the ideas that were offered as possible Google Summer of Code projects in 2008. In the event, five GSoC projects ran in 2008.
For more information about our current GSoC involvement, see GSoC Ideas and join our developers mailing list.



GSoC Ideas

This page represents the pick of our current project ideas.

Feel free to suggest your own ideas as well!
  • It would be best to write the first version on More GSoC Ideas, following the same format.
  • When the idea is well defined and mentors have been found, it can be moved to this page.


Subheadings for each idea:

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!


Label Track Enhancements (done 2008)

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 colors 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.

Skills:

  • wxWidgets and C++

Difficulty:

  • Easy. Improvements can be made in small steps.

Notes:

  • There is a discussion of labelling implementation and the features it might contain at Label Track.

Early spinoff from this work:

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


Playback Enhancements

Possible Mentors:

Description: Audacity lags behind commercial audio software in a number of details of its playback 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.

Skills:

  • wxWidgets and C++

Difficulty:

  • Moderate. Easy to vary the difficulty in either direction through choice of what to implement.

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.


Bridges

Possible Mentors:

Description: One way to grow the feature set of Audacity and at the same time to avoid re-inventing the wheel is to build compatibility 'bridges' between Audacity and other Open Source programs. This is an example of making Connected Open Source a reality. Two examples of bridges for Audacity are:

  • Bridge to Octave - Octave is an Open Source program for mathematical analysis and is useful in digital signal processing (DSP). Audacity could have a bridge to Octave that allows Octave to apply effects to Audacity waveforms and to annotate Audacity waveforms with labels.
  • Bridge to Rivendell - Rivendell is an Open Source program for radio station management. The Rivendell bridges already allows Audacity and Rivendell to exchange playlists. Work on it would improve the integration.

A proposal for a new bridge should go into some detail as to what features of the other program will be bridged. Generally the plan should avoid extensive work on the other program, since the point of the project is to extend Audacity.

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

Skills:

  • wxWidgets and C++
  • Familiarity with Octave or Rivendell or other software being bridged to.

Difficulty:

  • Moderate to Hard. Student has to get familiar with two programs.

Notes:

  • The Octave bridge is probably too difficult to do without a mentor who is very familiar with Octave, and so now unlikely to go ahead unless we find a mentor for it in the time.
  • As we already have active development on the Rivendell bridge, and a mentor committed to it, the focus on the Rivendell bridge will be making it more flexible and a cleaner separation. Talk with Federico for details. Done well this will be a model for other future bridges.

Early spinoff from this work:

  • A restricted bridge which exposes a smaller part of the functionality.

FFmpeg integration (done 2008)

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.

Skills:

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

Difficulty:

  • Moderate. (Assuming nothing is done with video and the interface is kept simple).

Notes:

  • This is proving far and away the most popular option at the moment. Unlike audio-diff we can't run more than one of these. There is a second 'integrating a library' project, the Nyquist one (below). So far no one has applied for it. Students may want to consider making at least a place-holder application for the Nyquist project too. Then they have the option of beefing it up later through adding / modifying the comments.
  • For students interested in working on the Codecs rather than on directly progressing Audacity, FFMPEG have projects proposals, and so do Xiph for Speex and Ogg.

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.

Nyquist (Lisp) update

Possible Mentors:

Description: Upgrade Nyquist support in Audacity to the latest version.

Nyquist is a version of the Lisp language built into Audacity.

Skills:

  • C++.
  • Developing on Linux and Windows.

Difficulty:

  • Moderate.

Notes:

  • We will also consider other proposals for Lisp work using Nyquist, especially if they will help popularise Lisp and the Nyquist extensions in Audacity. If you choose that route, please contact the audacity-nyquist mailing list  before putting significant work into your proposal.

Early spinoff from this work:

  • Demonstrate the upgrade on one of the two platforms.
  • If there are no unanticipated hitches, the project will be easily achievable in the 8 weeks. A good project proposal based on this idea should include other improvements for the Audacity Nyquist user too. For inspiration look at the archives of the audacity-nyquist list at Sourceforge. These would happen in the second half of the project after the basic upgrade.


Intuitive cross-fading

Possible Mentors:

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 crossfade. 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 crossfade 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 web page has a mock-up of what we think the GUI might look like:

http://limpet.net/mbrubeck/temp/cross-fade/ 

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.

Skills:

  • wxWidgets and C++

Difficulty:

  • Moderate.

Early spinoffs from this work:

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


Bugfix Ninja

Possible Mentors:

Description: We have several pesky bugs that have been preventing us getting a new stable release out, and many more details of lesser importance that make the program less good than it might be. We could very much use help vanquishing these. Have a look at the priorities on our Release Checklist and our list of "aim to's" which we currently aren't able to progress.

This project would have a GSoC student working just on clearing issues, helping us to produce a high quality release. This is how established Open Source developers work when they are not adding major new features. You'll learn a great deal about working on Open Source, and particularly the way people collaborate to solve problems. This is a very different project idea to most of the others.

The difficulties for this proposal for GSoC are:

  • The 'plan' showing what you intend to do - particularly so we can assess whether you have done it and you can get paid. Sometimes an apparently small issue actually opens up a big can of worms. The plan needs to have flexibility in it. One way to do that is with a 'points system' for the issues, where you say something like 'I plan to have 60 points worth of issues tackled by the half way stage, and 100 points worth by completion'. This allows you to move on from an issue if it turns out to be way harder than was thought.
  • The second difficulty is convincing us that you can work in this way. You'll need to convince us that you've understood some of the issues on our lists and that you can tackle them. Show you've understood both the issue and the code involved.

The reward is that you would help Audacity tremendously, and be a hero to us!

Skills:

  • wxWidgets and C++
  • A knack for asking the right questions.
  • Comfortable with visiting many different pieces of code in a large project.

Difficulty:

  • Moderate to Hard.

Early spinoffs from this work:

  • At least one of the meatier 'P1 or P2 issues' solved.
  • At least five smaller 'P3 to P5 issues' finally closed.


More ideas

There are further ideas on our More GSoC Ideas page. Also see our Use Cases and Feature Requests pages (over 200 requests), which may suggest ideas for a project proposal.