Hints on GSoC Participation 2021

From Audacity Wiki
Revision as of 09:39, 14 March 2021 by James (talk | contribs) (Header.)
Jump to: navigation, search
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 hints on the projects for 2021.
For information about our future plans and about Audacity software development, please join our developers mailing list
Related article(s):

The GSoC timeline has application period begins 29th March.

So the idea is to work on a proposal to submit. The work with the code is so that when writing the proposal you know more about how much work is involved, what is going to be easy, what is going to be hard. Also we have it that people need to have compiled Audacity to be considered.

Fixing Audacity bugs is not too important - for getting into GSoC for Audacity. Being able to make changes in the area(s) of code relevant to your project is important. If you have worked with the Audacity code that will/should show in your proposal - and that is good.

You will have more confidence about what you can do in the GSoC time, and so will we.

Compiling Audacity

A good place to start is by compiling Audacity.

  • You can find audacity on Github: [1]
  • For building on Windows: [2]

If compiling is not working, ask here on this Telegram.

On Windows you should be compiling wxWidgets as a DLL, i.e. SHARED=1, and we want the Debug version. If you have problems with lrint, you are compiling the release version, and you need to make this change to get Release version to compile [3]

Specific Projects

Spectral Editing Tools

You should get familiar with how the existing spectral editing works, and especially the code for the user interface.

A project proposal should include information about how you plan to represent and modify the data.

Source Separation

You should be looking at what choices of existing source separation software there are, that can be used in Audacity.

Try making some small changes to it. That way you will learn what kinds of things are involved in modifying Audacity code.

The actual evaluation of the project will be based on what you do during GSoC.

In evaluating a proposal, we'll be looking for good outcomes for users. So for example we are likely to prefer a known high-quality source separation over a basic proof of concept demo.

Should the solution be some kind of python program, invoked by Audacity, or should it be all C/C++? Roger might decide that what is needed is a solution in C/C++ alone, where a model produced in python has generated the coefficients.

A lot will depend on choices about flexibility (for experimenting) and benefit for users. How to balance the two? A researcher wants flexibility to experiment. A user wants the best results and least computation time. It's probably not possible to have both.

Mixing Desk


You should look at MixerBoard.cpp and try making some small changes, to get an idea of how much work is involved.

This screenshot of the mixer board is using the existing Audacity dark theme, and the pictures for each track have been picked up from the track names. The Mute and Solo buttons have been replaced by an M and an S in preparation for making the display narrower.

In your proposal, you should consider what users need from a software mixing desk. Use the internet to find out what features are important. Look into the Audacity code enough to see whether those features would be hard or easy for you to do in the time. It may be that improvements to the mixer board could lead to changes elsewhere in Audacity for consistency.

Python Testing

For a project proposal, as well as compiling Audacity you should also have experimented with running the existing test scripts.

The forum post may suggest other possible improvements to the scripting feature that could be implemented during GSoC.