GSoC Ideas 2019
|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|
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.
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.
- 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.
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||
|Architecture|| Audacity classes often mix data (nouns) and functions (verbs).
||More interface flexibility and fewer special cases.||
|Maths|| Find ways to code Audacity at a higher more mathematical level.
||More Audacity functionality for less code.||
|SCONS or CMake||Fix and document our build system||Less time wasted on build-system gotchas.||
|An RTL Language||Get Audacity working well with a Right-To-Left language.||Support for Hebrew or Arabic||
|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.||
|Hard Test Automation||
|Test||Identify the hardest things to test automatically, and propose and implement solutions.||Increased confidence in hard to test areas.||
|User Interaction||Fix our various (User) Stuck-in-a-mode Issues.||Fewer traps for the unwary in our GUI||
|SQL||Offer SQLITE as a BlockFile alternative.||Problem with fragmented projects gone.||
|Machine Learning|| Offer GUI enhancements for working with machine learning
||Text-to-Speech and Speech-To-Text GUI support.|| Present a plan that shows:
|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.||
|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.||
Smaller tasks that give familiarity with code. These are much smaller than a GSoC, but still useful to Audacity team.
|'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
||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:
||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.|
See Release Checklist for an understanding of what we need to do...