Hints on GSoC Participation 2021

From Audacity Wiki
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 Discord.

  • 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]
  • When choosing where to put wxWidgets and audacity, do not have any spaces in the path names. That will confuse the scripts.
  • When using cmake, if wxWidgets is not found, you need to specify the wxWidgets_LIB_DIR and the wxWidgets_ROOT_DIR in the Cmake gui (scroll to the end). It's as well to check that the dlls are actually at the LIB_DIR path you specify.


  • The dlls will have names with u and ud in them. ud is for debug. You want the debug ones - and ideally both.


Proposals can be submitted via Google's GSoC interface from 29th March. We encourage you to submit early, as proposals can be revised based on comments from us. There won't be time for comments by us and revisions if you submit close to the deadline.

Here are some boilerplate comments we might have:

  • 'Please be clearer about what your new code will do for users.'
  • 'Have you looked at feature X already in Audacity?'
  • 'Where is the timeline?'
  • 'No, a project that only delivers anything useful at the very end of it isn't going to work'.

If your proposal is just a cut and paste from our ideas page, it won't get very far.

Your project timeline doesn't have to be super detailed, but it must show exams/internships/holidays that you plan to take during the 10 week coding period, or other known significant calls on your time, and you must distinguish between what you are planning to achieve by the mid term evaluation from what you plan for the part after. We look for a project plan that delivers something of some value to our end users by the mid term. That is an insurance for both you and for us. Planning for everything to come together only by the end of the project is too high risk.

The projects we've proposed are seed ideas. They are to get you thinking. They give an idea of what areas different mentors will be mentoring. Once you look into any one of those, you will start to see opportunities and difficulties, and that in turn feeds into your proposal. If you stay too close to the seed idea, your proposal won't stand out.

  • Here is an example of a proposal, giving an idea of how long the proposal should be.
    • That project proposal was for a longer GSoC. This years is 175 hours over 10 weeks - so don't be as ambitious as that one.
  • We want clarity about which deliverables will be by the mid term evaluation.
  • It is important not only to tell us *what* you propose, but *how* you propose to do it. If you show no knowledge of Audacity code structure, interfaces, how to think about modularity and abstractions, then we will not have much confidence you can deliver.
  • It's OK not to have all the answers. It's better to show us that you understand the questions. E.g. if there are tradeoffs and design alternatives, we would rather you show some understanding than pick (guess?) the choice we might make.

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. See comments on understanding tradeoffs above.

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.

We have started a discussion with several experts in the field, so you don't have to be a source separation expert, and we certainly do not plan to develop source separation from scratch. It's more important to identify one or more candidate source separation libraries and show a good understanding of what might be required to integrate it with Audacity.

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. An important question your proposal should answer should be 'What improvements to scripting do you plan to make'?

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

This is what the image making script used to produce: Automation Images. We upgraded the yellow text, and that now appears in a rounded box. That's fine. But nowadays some of the labels come out wrong, with no text in them. This bug is reported on in Bug 2684.