Difference between revisions of "Hints on GSoC Participation 2021"

From Audacity Wiki
Jump to: navigation, search
(Telegram -> Discord.)
(Proposal boiler plate comments.)
Line 32: Line 32:
  
 
* The dlls will have names with u and ud in them.  ud is for debug.  You want the debug ones - and ideally both.
 
* The dlls will have names with u and ud in them.  ud is for debug.  You want the debug ones - and ideally both.
 +
 +
 +
== Proposals ==
 +
 +
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.
  
  

Revision as of 12:50, 22 March 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 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.

CmakeAudaciy.jpg

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


Proposals

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.


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

MixerBoardDark.jpg

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.