Hints on GSoC Participation 2021
The GSoC timeline has application period begins 29th March.
[[1]]
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.
Contents
Compiling Audacity
A good place to start is by compiling Audacity.
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 [4]
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.
- You should also look at, for example, FindClipping.cpp
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.
- Have a look at this recent post on the Audacity forum.
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.
- This post on the forum shows another use of scripting
The forum post may suggest other possible improvements to the scripting feature that could be implemented during GSoC.
