Difference between revisions of "GSoC Ideas 2019"

From Audacity Wiki
Jump to: navigation, search
(Sub cats.)
m (James moved page GSoC Ideas to GSoC Ideas 2019: Ready for GSoC 2021.)
 
(11 intermediate revisions by the same user not shown)
Line 3: Line 3:
  
 
__TOC__
 
__TOC__
 +
 +
==Executive Summary==
 +
 +
We have 11 seed ideas in the green table, for this years GSoC.
 +
* These focus on the benefit we want from your work. 
 +
* You will need to provide the detail, and convince us you have the skills to develop the chosen seed idea into a full completed tested project.
  
 
==Introduction==
 
==Introduction==
Line 15: Line 21:
 
==Idea Seeds==
 
==Idea Seeds==
  
{{note|In past years we provided pretty well fleshed out proposals as starting points, and expected applicants to provide more.   
+
{{note|In past years we provided pretty well fleshed out proposals as starting points.
: We found that some students just echoed our proposals back to us, making it hard for us to tell if the student had any knowledge or interest.   
+
* We expected applicants to provide more.   
: This year we are providing seed ideas.  They ARE fairly well worked out by us, BUT to apply with one of these ideas you will need to do some work too.
+
* We found that some students just echoed our proposals back to us, making it hard for us to tell if the student had any knowledge or interest.   
 +
This year we are providing seed project ideas.  They ARE fairly well worked out ''by us'', BUT to apply with one of these ideas you will need to do some work too.  That's the 'show us you can...', though you are welcome to find other ways to show us that you can do the project.
 
* To grow the seed you will need to hunt through our code and read [[Proposals]] on this wiki.
 
* To grow the seed you will need to hunt through our code and read [[Proposals]] on this wiki.
 
* We have a [[For Developers|developer]] section on this wiki with information to help you find your way around.
 
* We have a [[For Developers|developer]] section on this wiki with information to help you find your way around.
Line 24: Line 31:
  
 
</noinclude><includeonly>
 
</noinclude><includeonly>
* These two tables come from [[GSoC Ideas]] where there is a discussion of how to interpret them.
+
* These three tables come from [[GSoC Ideas]] where there is a discussion of how to interpret them.
 
</includeonly>
 
</includeonly>
'''Personality Matrix'''
+
==Personality Matrix==
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
! !! Low Risk !! Big Payoff  !! Notes
+
! !! Icon !! Profile !! Catch Phrase !! Mentor BOLO
 +
|-
 +
| Refiner
 +
| {{personality|Refiner}}
 +
| Lower risk, on core components.<br>Safe incremental improvement.
 +
| "Steady as she goes"
 +
| Good progress early on.
 
|-
 
|-
| '''Core'''
 
| Refiner
 
 
| Miner
 
| Miner
| Big Payoffs tend to come with higher risks that the project not succeed
+
| {{personality|Miner}}
 +
| Higher risk, and on core components.<br>Possibly big payoff. 
 +
| Hoping to 'hit gold'.
 +
| Good fallback, if main plan does not work out.
 
|-
 
|-
| '''Fun'''
+
| Explorer
| Explorer
+
| {{personality|Explorer}}
| Magician  
+
| Fun, low risk changes, away from core.
| Core work tends to be harder and on older code, and less fun than work on the new edges.
+
| We'll find the route.
 +
| Useful spin offs, early on.
 +
|-
 +
| Magician
 +
| {{personality|Magician}}
 +
| Fun, higher-risk-of-failure work, away from core.<br>Possibly radical transformation. Possibly big payoff.
 +
| Abracadabra!
 +
| Tangible benefits to project at Mid-Term, to keep project rooted in reality.
 
|}
 
|}
  
  
  
'''Seed Project Ideas'''
+
==Seed Project Ideas==
{| class="wikitable sortable"
+
 
! Name
+
In a GSoC proposal, a key element is the 'Show us You can'.  We need to be convinced you have what it takes to complete the project successfully.
! Personality Type
+
 
! Risk / Reward
+
{| class="wikitable sortable" style="background-color:#ccffcc;"
! Core / Peripheral
+
! style="background-color:#bbccbb;" | '''Name'''
! Idea
+
! style="background-color:#bbddbb;width:150px;" | Personality Type
! Desired Outcome
+
! style="background-color:#bbddbb;" | Speciality?
! Show us you can...
+
! style="background-color:#bbddbb;" | Idea
 +
! style="background-color:#bbccbb;" | High Level Benefit
 +
! style="background-color:#bbddbb;" | Show us you can...
 
|-
 
|-
| Nouns and Verbs
+
| style="background-color:#bbddbb;" | Nouns and Verbs
| Refiner
+
| {{personality|Refiner}}
| Low-Risk
+
| Architecture
| Core
+
| [https://doxy.audacityteam.org Audacity classes] often mix data (nouns) and functions (verbs).   
| Audacity classes often mix data (nouns) and functions (verbs).   
+
* Propose and, after approval, implement specific refactoring that enhance the distinction.
* Propose and implement specific refactoring that enhance the distinction.
+
| style="background-color:#bbddbb;" | More interface flexibility and fewer special cases.
| Code that can be better combined combinatorially
 
 
|  
 
|  
 
* Show us which classes would benefit most from this and say why.
 
* Show us which classes would benefit most from this and say why.
 
|-
 
|-
| Redux
+
| style="background-color:#bbddbb;" | Redux
| Miner
+
| {{personality|Miner}}
| Big-Payoff
+
| Maths
| Core
+
| Find ways to code Audacity at a higher more mathematical level.
| Find ways to code Audacity at a higher more mathematical level - that are 100% compatible with our existing code.
+
* These changes must have measurable benefits, such as reducing code size, or providing more options with the same amount of code.
| More Audacity for less code.
+
| style="background-color:#bbddbb;" | More Audacity functionality for less code.
 
|
 
|
 
* Show us where we have repetitive code that could be reduxed.
 
* Show us where we have repetitive code that could be reduxed.
 
|-
 
|-
| Build Systems
+
| style="background-color:#bbddbb;" | Build Systems
| Explorer
+
| {{personality|Explorer}}
| Low-Risk
+
| SCONS or CMake
| Fun
+
| Fix and document [https://github.com/audacity/audacity/blob/master/Makefile.in our build system]
| Fix and document our build system
+
| style="background-color:#bbddbb;" | Less time wasted on build-system gotchas.
| Less time wasted on build-system gotchas.
 
 
|
 
|
 
* Explain to us what would change with the new system.
 
* Explain to us what would change with the new system.
 
|-
 
|-
| WIT
+
| style="background-color:#bbddbb;" | RTL
| Explorer
+
| {{personality|Refiner}}
| Low-Risk
+
| An RTL Language
| Fun
+
| Get Audacity working well with a Right-To-Left language.
| Enhance the (MIT Licensed) WIT system that we use in-house.
+
| style="background-color:#bbddbb;" | Support for Hebrew or Arabic
| Better tools for developers and support.
+
|
 +
* Show us which classes would benefit most from this and say why.
 +
|-
 +
|-
 +
| style="background-color:#bbddbb;" | WIT
 +
| {{personality|Explorer}}
 +
| Integration
 +
| Enhance our homegrown (MIT Licensed) [https://wit.audacityteam.org WIT system] that we use in-house for easing test, production of images and documentation.
 +
| style="background-color:#bbddbb;" | Improve our web-based tools for developers and support.
 
|
 
|
 
* Spell out how the enhanced system would save us more time or enable us to do more with the same effort.
 
* Spell out how the enhanced system would save us more time or enable us to do more with the same effort.
 
|-
 
|-
| Hard Test Automation
+
| style="background-color:#bbddbb;" | Hard Test Automation
| Magician
+
| {{personality|Magician}}
| Big-Payoff
+
| Test
| Fun
+
| Identify the hardest things to [https://github.com/audacity/audacity/blob/master/scripts/piped-work/docimages_regression_tests.py test automatically], and propose and implement solutions.
| Identify the hardest things to test automatically, and propose and implement solutions.
+
| style="background-color:#bbddbb;" | Increased confidence in hard to test areas.
| Increased confidence / perfection in Audacity.
 
 
|
 
|
 
* Show us something you could do in this line.
 
* Show us something you could do in this line.
 
|-
 
|-
| Bear Traps
+
| style="background-color:#bbddbb;" | Bear Traps
| Refiner
+
| {{personality|Refiner}}
| Low-Risk
+
| User Interaction
| Core
+
| Fix our various [[ToDo:_Unstick_'Stuck_In_a_Mode'|(User) Stuck-in-a-mode Issues]].
| Fix our various (User) Stuck-in-a-mode Issues.
+
| style="background-color:#bbddbb;" | Fewer traps for the unwary in our GUI
| Simpler less sticky GUI
 
 
|
 
|
 
* Organise the bear-traps showing your preferred option for fixing each.
 
* Organise the bear-traps showing your preferred option for fixing each.
 +
* Fix one to show you can.
 
|-
 
|-
| BlockFiles
+
| style="background-color:#bbddbb;" | BlockFiles
| Miner
+
| {{personality|Miner}}
| Big-Payoff
+
| SQL
| Core
+
| Offer [https://www.sqlite.org/index.html SQLITE] as a [https://doxy.audacityteam.org/class_block_file.html BlockFile] alternative.
| Offer SQLITE as a BlockFile alternative.
+
| style="background-color:#bbddbb;" | Problem with fragmented projects gone.
| No more fragmented projects.
 
 
|
 
|
 
* Show where it would slot in to existing code.
 
* Show where it would slot in to existing code.
 
|-
 
|-
| Wavenet
+
| style="background-color:#bbddbb;" | Wavenet
| Magician
+
| {{personality|Magician}}
| Big-Payoff
+
| Machine Learning
| Fun
 
 
| Offer GUI enhancements for working with machine learning  
 
| Offer GUI enhancements for working with machine learning  
* This is for researchers more than for end users.
+
* Aim to entice researchers.  They plug in ML feature detectors etc, and don't have to write GUI.
* The features DO need to have relevance to ordinary users too.
+
* The GUI enhancements MUST have relevance to ordinary users too.
| Text-to-Speech and Speech-To-Text GUI support.
+
| style="background-color:#bbddbb;" | Text-to-Speech and Speech-To-Text GUI support.
 
| Present a plan that shows:
 
| Present a plan that shows:
 
* What GUI features would be provided, and why.
 
* What GUI features would be provided, and why.
 
* How GUI would be developed and tested.
 
* How GUI would be developed and tested.
 
|-
 
|-
| Error Analysis
+
| style="background-color:#bbddbb;" | Error Analysis
| Refiner
+
| {{personality|Refiner}}
| Low-Risk
+
| Cause Analysis
| Core
+
| Find patterns in [https://bugzilla.audacityteam.org/report.cgi?x_axis_field=priority&y_axis_field=bug_severity&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= the kinds of bugs we report].  Implement measures to fix categories of errors, and avoid them in future.
| Find patterns in the kinds of bugs we report.  Implement measures to fix categories of errors, and avoid them in future.
+
| style="background-color:#bbddbb;" | Whole error categories identified, and preemptively fixed.
| Issue avoidance.
 
 
|
 
|
 
* Do a small part of it already.
 
* Do a small part of it already.
 
|-
 
|-
| Headroom
+
| style="background-color:#bbddbb;" | Headroom
| Explorer
+
| {{personality|Explorer}}
| Low-Risk
+
| Metering
| Fun
+
| Design and implement measures that monitor and report on headroom, rather than as now, detecting failure when it happens.
| Rather than detecting failure when it happens, design and implement measures that monitor and report on headroom.
+
| style="background-color:#bbddbb;" | Measurements of leeway, and hence earlier warnings.
| Earlier warning of issues.
 
 
|
 
|
 
* Set out a plan of what you would measure, and where in the code you would measure it.
 
* Set out a plan of what you would measure, and where in the code you would measure it.
 
|}
 
|}
 
<noinclude>
 
<noinclude>
==Past GSoC Ideas==
 
  
{{ednote|These will all move to [[More GSoC Ideas]]}}
+
==Familiarisation Tasks==
  
Subheadings for each idea:
+
Smaller tasks that give familiarity with code.  These are much smaller than a GSoC, but still useful to Audacity team.
{{Template:GSoC Ideas Key}}
 
  
 +
{| class="wikitable sortable"
 +
! Name !! Description
 +
|-
 +
| 'true/false' synonyms.
 +
| Many functions have bool parameters.  A function call like DoUpdates( mMessage, true, false, false ); is not self documenting.  Fix it.
 +
|-
 +
| Coding standards
 +
| Apply Google's C++ coding standards to the naming of variables in the main code.
 +
|-
 +
| WAV formats
 +
| The method for setting sub options in WAV file output is not very discoverable.  Propose and implement a fix.
 +
|}
  
==Your Proposal==
 
'''Possible Mentors:'''
 
* TBD
 
  
'''Description:'''
 
We've found that the best proposals come from students who are passionate about some feature that they want to make happen in Audacity.  We're very positive about suggestions.  Bear in mind that if it is a big new feature it will almost certainly need to be in a plug-in.  You'll need to have something that is usable by the mid term.  To be sure of that you might be best off scaling a big proposal down a little and adding to it smaller pieces such as bug fixes and refinements to existing features which you are sure of having done by the mid-term.
 
  
'''Skills:'''
+
==Pure Feature Project Ideas==
* wxWidgets and C++
 
  
'''Difficulty:'''
+
In the past we thought GSoC was about new features.  We weren't entirely wrong.  Applicants for GSoC are welcome to pitch pure feature project ideas to us.  The problem is that it is extremely hard to complete a new feature to release ready standards in the time of a GSoC.  We do need the work that GSoC students do to be ready for release.  Hence our new focus on seed projects.  If you do propose a feature project, you must plan to have it demo-ready by the mid term.  Taking a new feature from demo-ready to release ready can easily take half of the GSoC time.  We are proposing that big features be implemented as plug-ins.  That way the risk to you and us is reduced.  There is lower risk of them destabilising core Audacity.  We also have the option of releasing an experimental plug-in that is not quite ready for mainstream use by millions of users.
* Easy, Moderate or Hard depending on your proposal.
 
  
'''Early spinoffs from this work:'''
+
{| class="wikitable sortable" style="background-color:#ffffcc;"
* To be specified in the proposal.
+
! style="background-color:#ccccbb;" | '''Name'''
 
+
! style="background-color:#ddddbb;" | Difficulty
 
+
! style="background-color:#ddddbb;" | Idea
==Oscilloscope Mode==
+
! style="background-color:#ccccbb;" | High Level Benefit
'''Possible Mentors:'''
+
! style="background-color:#ddddbb;" | Show us you can...
* [[User:James|James Crook]]
+
|-
 
+
| style="background-color:#ccccbb;" | Oscilloscope Mode
'''Description:'''
+
| Medium
Improvements to scrolling and zooming behaviour for close up work.  In particular in Oscilloscope mode the 'play' or 'record' line will stay still and the wave form scroll past.  At high zooms this will only look good if the section to show with each refresh is chosen carefully, picking up in some easy to compute way on some regularity in the audio sounds.  Some performance improvements in drawing the graphs would help make this mode possible on lower powered machines.
+
| Improvements to scrolling and zooming behaviour for close up work.  In particular in Oscilloscope mode  
 
+
* {{done}} <s>The 'play' or 'record' line will stay still and the wave form scroll past.</s>  
'''Skills:'''
+
* At high zooms this will only look good if the section to show with each refresh is chosen carefully, picking up in some easy to compute way on some regularity in the audio sounds.   
* wxWidgets and C++
+
* Some performance improvements in drawing the graphs would help make this mode possible on lower powered machines.
* Understanding of how oscilloscopes 'trigger'.
+
| style="background-color:#ccccbb;" | Gives users better insight into their audio.
 
+
|
'''Difficulty:'''
+
|-
* Easy to Moderate. 
+
| style="background-color:#ccccbb;" | Audio Diff GUI Plug-In
 
+
| Hard
'''Early spinoffs from this work:'''
+
| 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 track. It would also be of use to people looking to identify particular known sounds, e.g. repeated themes in birdsong, in very long recordings.  
* This would no way be enough on its own for a complete proposal. A viable proposal would have multiple parts, and some features would need to be usable by end users by the mid term.
 
 
 
 
 
==Audio Diff GUI Plug-In==
 
'''Possible Mentors:'''
 
* [[User:James|James Crook]]
 
 
 
'''Description:'''
 
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 track. It would also be of use to people looking to identify particular known sounds, e.g. repeated themes in birdsong, in very long recordings.  
 
  
 
We proposed implementing [[Proposal_Audio_Diff|Audio Diff]] including a GUI for it as a project idea for GSoC 2008.  It was the most challenging of the ideas offered then.  This year the focus is on the GUI side of audio diff.  An existing audio diff algorithm could be ported or a very very simple one used as a demonstrator.  The key extensions are in the ''interface'' so that diff becomes a useful tool.  The interface will probably need to extend what we already do with multiple clips on one track.  It is likely there will be a 'dotplot' display mode and an 'alignment' display mode.
 
We proposed implementing [[Proposal_Audio_Diff|Audio Diff]] including a GUI for it as a project idea for GSoC 2008.  It was the most challenging of the ideas offered then.  This year the focus is on the GUI side of audio diff.  An existing audio diff algorithm could be ported or a very very simple one used as a demonstrator.  The key extensions are in the ''interface'' so that diff becomes a useful tool.  The interface will probably need to extend what we already do with multiple clips on one track.  It is likely there will be a 'dotplot' display mode and an 'alignment' display mode.
 
+
| style="background-color:#ccccbb;" |  Paves way for cutting-edge remix feature.
'''Skills:'''
+
|
* wxWidgets and C++
+
|-
* Familiarity with some diff algorithm
+
| style="background-color:#ccccbb;" | Vowel Quadrilateral Plug-In
 
+
| Moderate/Easy
'''Difficulty:'''
+
|
* Moderate to Hard.
+
The vowel quadrilateral is one step in making Audacity more useful as a tool for [[Proposal_Languages_Ecosystem|foreign language learners]].  Long term we want to make Audacity part of a language learning eco-system.  The vowel-quadrilateral project would also act as a driver for creating a real plug-in architecture for Audacity.  Part of the project would entail converting some existing features, such as the karaoke display and cleanspeech into plug-ins.  The project could be expanded to involve some collaboration with RockBox to work on mark-up of audio for language learners.
 
+
| style="background-color:#ccccbb;" | Helpful to language learners.
'''Early spinoffs from this work:'''
+
|
* 'alignment mode' complete and usable by end users at the mid-term.
+
|-
 
+
| style="background-color:#ccccbb;" | Custom Developer Tools
 
+
| Moderate
==Vowel Quadrilateral Plug-In==
+
| The key ingredient in this proposal is software that make Audacity developers more effective.  This is seen as being of strategic importance to the future of Audacity.  Some possibilities include:
'''Possible Mentors:'''
 
* [[User:James|James Crook]]
 
 
 
'''Description:'''
 
The vowel quadrilateral is one step in making Audacity more useful as a tool for foreign language learners.  Long term we want to make Audacity part of a language learning eco-system.  The vowel-quadrilateral project would also act as a driver for creating a real plug-in architecture for Audacity.  Part of the project would entail converting some existing features, such as the karaoke display and cleanspeech into plug-ins.  The project could be expanded to involve some collaboration with RockBox to work on mark-up of audio for language learners.
 
 
 
'''Skills:'''
 
* wxWidgets and C++
 
* Must develop on both Windows and Linux.
 
 
 
'''Difficulty:'''
 
* Moderate. 
 
 
 
'''Early spinoffs from this work:'''
 
* Karaoke and cleenspeech mode as plug-ins. Preferences panel supporting plug-in preferences.
 
 
 
<s>
 
==Custom Developer Tools==
 
'''Possible Mentors:'''
 
* [[User:James|James Crook]]
 
 
 
'''Description:'''
 
The key ingredient in this proposal is software that make Audacity developers more effective.  This is seen as being of strategic importance to the future of Audacity.  Some possibilities include:
 
  
 
* Collaboration with wxFormBuilder to make a theming tool for easy changing of the skin of Audacity.
 
* Collaboration with wxFormBuilder to make a theming tool for easy changing of the skin of Audacity.
* Collaboration with Melange team to improve Melange as a developer support tool based on the very specific needs of Audacity.
+
* {{done}} <s>Enhanced built-in screenshot tools for documentation.</s>
* Enhanced built-in screenshot tools for documentation.
 
 
* Enhancements to Doxygen output modes so that we can present more relevant and more dynamic information about Audacity architecture to potential developers.
 
* Enhancements to Doxygen output modes so that we can present more relevant and more dynamic information about Audacity architecture to potential developers.
 
+
| style="background-color:#ccccbb;" | Faster / Easier development.
'''Skills:'''
+
|
* wxWidgets and C++.  Possibly GAE and python too, or PHP depending on project details.
+
|-
* Prior experience on project(s) of similar size to Audacity.
+
| style="background-color:#ccccbb;" | Hierarchical Track Panel
 
+
| Moderate
'''Difficulty:'''
+
| An experimental start has been made on this, but it needs to be taken a lot further.  The key feature is to have a tree-like structure for a project with sub-mixes within the tree.  The developer will need to break the TrackPanel class into smaller classes to get this level of flexibility.
* Hard. 
+
| style="background-color:#ccccbb;" | Better for users with many audio tracks.
 
+
|
'''Early spinoffs from this work:'''
+
|}
* One new tool that is already useful at the half way stage. 
 
</s>
 
 
 
==Hierarchical Track Panel==
 
'''Possible Mentors:'''
 
* [[User:James|James Crook]]
 
 
 
'''Description:'''
 
An experimental start has been made on this, but it needs to be taken a lot further.  The key feature is to have a tree-like structure for a project with sub-mixes within the tree.  The developer will need to break the TrackPanel class into smaller classes to get this level of flexibility.
 
 
 
'''Skills:'''
 
* wxWidgets and C++
 
 
 
'''Difficulty:'''
 
* Moderate to Hard.
 
 
 
'''Early spinoffs from this work:'''
 
* To be specified in the proposal.
 
  
  

Latest revision as of 22:22, 18 February 2021

Google Summer of Code (GSoC) is Google's program for promoting Open Source Software development. Audacity was a mentoring organization for five students for Google Summer of Code 2008, and mentored two students in 2009. This page contains our ideas for suitable projects for 2019.
For information about our future plans and about Audacity software development, please join our developers mailing list
 
Related article(s):


Executive Summary

We have 11 seed ideas in the green table, for this years GSoC.

  • These focus on the benefit we want from your work.
  • You will need to provide the detail, and convince us you have the skills to develop the chosen seed idea into a full completed tested project.

Introduction

The Audacity audio editor is downloaded around 18 million times each year. It's a large, mature and clearly popular open source project. In 2008 and 2009 we participated in Google's Summer of Code, with 5 students in the first year and 2 in the second. If we participate in 2019 we will likely try to mentor two students, so that we can give them enough attention that they have both challenges and every chance of success.


In many ways Audacity has 'grown up' between 2008 and now. We've become more quality conscious. We've become more aware of both the need to and how to bring on new developers. Because of this we've changed what we ask for in project proposals. Your project proposal *must* be presented as a collection of smaller features each of which is useful in itself. It's no good proposing one single big change which can't be trialed by end users during the GSoC period. A mix of smaller related features - along with related bug fixes is good. If your proposal is different to that, if it can't be broken up into smaller useful pieces, if it does not include any bug fixing, or if the pieces are not related and working as a whole, you'll have more trouble convincing us that it will be successful.
We *expect* incremental development, with near-daily check ins to GitHub of work in progress, and work that is ready enough that your mentor can easily try it out. In return, mentors will be available to guide and give feedback. We work by email, not IRC nor video chat. It's what works for us.

Idea Seeds

In past years we provided pretty well fleshed out proposals as starting points.
  • We expected applicants to provide more.
  • We found that some students just echoed our proposals back to us, making it hard for us to tell if the student had any knowledge or interest.

This year we are providing seed project ideas. They ARE fairly well worked out by us, BUT to apply with one of these ideas you will need to do some work too. That's the 'show us you can...', though you are welcome to find other ways to show us that you can do the project.

  • To grow the seed you will need to hunt through our code and read Proposals on this wiki.
  • We have a developer section on this wiki with information to help you find your way around.
  • You will need to compile Audacity, and show that you can code.


Personality Matrix

Icon Profile Catch Phrase Mentor BOLO
Refiner
Refiner.png

  RISKIER / SAFER
  CORE / EDGE

Lower risk, on core components.
Safe incremental improvement.
"Steady as she goes" Good progress early on.
Miner
Miner.png

  RISKIER / SAFER
  CORE / EDGE

Higher risk, and on core components.
Possibly big payoff.
Hoping to 'hit gold'. Good fallback, if main plan does not work out.
Explorer
Explorer.png

  RISKIER / SAFER
  CORE / EDGE

Fun, low risk changes, away from core. We'll find the route. Useful spin offs, early on.
Magician
Magician.png

  RISKIER / SAFER
  CORE / EDGE

Fun, higher-risk-of-failure work, away from core.
Possibly radical transformation. Possibly big payoff.
Abracadabra! Tangible benefits to project at Mid-Term, to keep project rooted in reality.


Seed Project Ideas

In a GSoC proposal, a key element is the 'Show us You can'. We need to be convinced you have what it takes to complete the project successfully.

Name Personality Type Speciality? Idea High Level Benefit Show us you can...
Nouns and Verbs
Refiner.png

  RISKIER / SAFER
  CORE / EDGE

Architecture Audacity classes often mix data (nouns) and functions (verbs).
  • Propose and, after approval, implement specific refactoring that enhance the distinction.
More interface flexibility and fewer special cases.
  • Show us which classes would benefit most from this and say why.
Redux
Miner.png

  RISKIER / SAFER
  CORE / EDGE

Maths Find ways to code Audacity at a higher more mathematical level.
  • These changes must have measurable benefits, such as reducing code size, or providing more options with the same amount of code.
More Audacity functionality for less code.
  • Show us where we have repetitive code that could be reduxed.
Build Systems
Explorer.png

  RISKIER / SAFER
  CORE / EDGE

SCONS or CMake Fix and document our build system Less time wasted on build-system gotchas.
  • Explain to us what would change with the new system.
RTL
Refiner.png

  RISKIER / SAFER
  CORE / EDGE

An RTL Language Get Audacity working well with a Right-To-Left language. Support for Hebrew or Arabic
  • Show us which classes would benefit most from this and say why.
WIT
Explorer.png

  RISKIER / SAFER
  CORE / EDGE

Integration Enhance our homegrown (MIT Licensed) WIT system that we use in-house for easing test, production of images and documentation. Improve our web-based tools for developers and support.
  • Spell out how the enhanced system would save us more time or enable us to do more with the same effort.
Hard Test Automation
Magician.png

  RISKIER / SAFER
  CORE / EDGE

Test Identify the hardest things to test automatically, and propose and implement solutions. Increased confidence in hard to test areas.
  • Show us something you could do in this line.
Bear Traps
Refiner.png

  RISKIER / SAFER
  CORE / EDGE

User Interaction Fix our various (User) Stuck-in-a-mode Issues. Fewer traps for the unwary in our GUI
  • Organise the bear-traps showing your preferred option for fixing each.
  • Fix one to show you can.
BlockFiles
Miner.png

  RISKIER / SAFER
  CORE / EDGE

SQL Offer SQLITE as a BlockFile alternative. Problem with fragmented projects gone.
  • Show where it would slot in to existing code.
Wavenet
Magician.png

  RISKIER / SAFER
  CORE / EDGE

Machine Learning Offer GUI enhancements for working with machine learning
  • Aim to entice researchers. They plug in ML feature detectors etc, and don't have to write GUI.
  • The GUI enhancements MUST have relevance to ordinary users too.
Text-to-Speech and Speech-To-Text GUI support. Present a plan that shows:
  • What GUI features would be provided, and why.
  • How GUI would be developed and tested.
Error Analysis
Refiner.png

  RISKIER / SAFER
  CORE / EDGE

Cause Analysis Find patterns in the kinds of bugs we report. Implement measures to fix categories of errors, and avoid them in future. Whole error categories identified, and preemptively fixed.
  • Do a small part of it already.
Headroom
Explorer.png

  RISKIER / SAFER
  CORE / EDGE

Metering Design and implement measures that monitor and report on headroom, rather than as now, detecting failure when it happens. Measurements of leeway, and hence earlier warnings.
  • Set out a plan of what you would measure, and where in the code you would measure it.


Familiarisation Tasks

Smaller tasks that give familiarity with code. These are much smaller than a GSoC, but still useful to Audacity team.

Name Description
'true/false' synonyms. Many functions have bool parameters. A function call like DoUpdates( mMessage, true, false, false ); is not self documenting. Fix it.
Coding standards Apply Google's C++ coding standards to the naming of variables in the main code.
WAV formats The method for setting sub options in WAV file output is not very discoverable. Propose and implement a fix.


Pure Feature Project Ideas

In the past we thought GSoC was about new features. We weren't entirely wrong. Applicants for GSoC are welcome to pitch pure feature project ideas to us. The problem is that it is extremely hard to complete a new feature to release ready standards in the time of a GSoC. We do need the work that GSoC students do to be ready for release. Hence our new focus on seed projects. If you do propose a feature project, you must plan to have it demo-ready by the mid term. Taking a new feature from demo-ready to release ready can easily take half of the GSoC time. We are proposing that big features be implemented as plug-ins. That way the risk to you and us is reduced. There is lower risk of them destabilising core Audacity. We also have the option of releasing an experimental plug-in that is not quite ready for mainstream use by millions of users.

Name Difficulty Idea High Level Benefit Show us you can...
Oscilloscope Mode Medium Improvements to scrolling and zooming behaviour for close up work. In particular in Oscilloscope mode
  • Done.png The 'play' or 'record' line will stay still and the wave form scroll past.
  • At high zooms this will only look good if the section to show with each refresh is chosen carefully, picking up in some easy to compute way on some regularity in the audio sounds.
  • Some performance improvements in drawing the graphs would help make this mode possible on lower powered machines.
Gives users better insight into their audio.
Audio Diff GUI Plug-In Hard 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 track. It would also be of use to people looking to identify particular known sounds, e.g. repeated themes in birdsong, in very long recordings.

We proposed implementing Audio Diff including a GUI for it as a project idea for GSoC 2008. It was the most challenging of the ideas offered then. This year the focus is on the GUI side of audio diff. An existing audio diff algorithm could be ported or a very very simple one used as a demonstrator. The key extensions are in the interface so that diff becomes a useful tool. The interface will probably need to extend what we already do with multiple clips on one track. It is likely there will be a 'dotplot' display mode and an 'alignment' display mode.

Paves way for cutting-edge remix feature.
Vowel Quadrilateral Plug-In Moderate/Easy

The vowel quadrilateral is one step in making Audacity more useful as a tool for foreign language learners. Long term we want to make Audacity part of a language learning eco-system. The vowel-quadrilateral project would also act as a driver for creating a real plug-in architecture for Audacity. Part of the project would entail converting some existing features, such as the karaoke display and cleanspeech into plug-ins. The project could be expanded to involve some collaboration with RockBox to work on mark-up of audio for language learners.

Helpful to language learners.
Custom Developer Tools Moderate The key ingredient in this proposal is software that make Audacity developers more effective. This is seen as being of strategic importance to the future of Audacity. Some possibilities include:
  • Collaboration with wxFormBuilder to make a theming tool for easy changing of the skin of Audacity.
  • Done.png Enhanced built-in screenshot tools for documentation.
  • Enhancements to Doxygen output modes so that we can present more relevant and more dynamic information about Audacity architecture to potential developers.
Faster / Easier development.
Hierarchical Track Panel Moderate An experimental start has been made on this, but it needs to be taken a lot further. The key feature is to have a tree-like structure for a project with sub-mixes within the tree. The developer will need to break the TrackPanel class into smaller classes to get this level of flexibility. Better for users with many audio tracks.


More Ideas

See Release Checklist for an understanding of what we need to do...