User:James

I'm looking at several initiatives to ensure the future success of Audacity. The most imminent is Google Summer of Code 2011 our current push to get a stable version 2.0 released.

Large Projects
Projects with more than 2^31 samples (just over 13.5 hours at 44100 Hz) will not re-open correctly. Higher sample rates mean proportionally shorter times - so just over 6 hours at 96,000 Hz. We know the cause, and do intend to address this bug.

Silenced audio
(Rare) Re-opening the project, audio that was there previously is silenced. We think when this happens it is down to a problem the previous time Audacity ran. It's a problem we want to hear about so that we can get to the bottom of it.

 Errors saving a project or the autosave file, suggesting the disk may be full or not writable when there is no such problem (if this happens, try exporting the audio as WAV)  Unwanted renaming or moving of .au files within the project; multiple or duplicated .aup files or project folders appearing within the same project  Unexplained crashes or corrupted audio. 

Please let us know whenever you see this problem. Are there any steps you took when the project(s) were previously open that could enable us to reproduce the problem? We believe having multiple projects open at once, having projects open in file manager programs or having a long project with many tracks are among the causes.

Errors on re-opening a project
(Rare) Projects reopen with any of "Missing Audio Data Block File(s)", "Problems Reading Sequence Tags" or "Orphan Block File(s)" errors being reported.

If you see these errors, we recommend choosing the options to "Treat missing audio as silence" or "Continue without deleting" the orphans. To avoid the damage caused by this problem, also export a project as wav when closing audacity. Then if the audacity project gets broken you at least still have the wav file.

We have put a lot of work into trying to fix this problem, but as our developers have not had this problem themselves we're not convinced that the changes we have made have fixed it. If you get this problem, reporting it to our feedback address, just as for the previous problem, will help us to understand the problem and fix it.

=Stable Release=

As of February 2012 we are finally closing on a stable release grade Audacity to supersede the 1.2.x line. The entire 1.3.x line consists of betas, starting with the important feature of multiple clips on the same track. Perhaps the best indicator that we are getting closer to a stable release is that we have switched from doing 'bleeding edge' 1.3.x betas to now having betas which only have the features enabled which the stable release would have.

We're now delivering Audacity in a modular fashion. This is an important change which should allow us to keep a stable Audacity core with new experimental features in plug-in modules. We can hope that stable releases will be able to be more frequent.

Although 2009 through 2011 were dominated by bug fixing we made significant other progress too. The bundled help is at last a comprehensive text pulled from the completely re-written and extended on line Audacity wiki manual. We also have a plug-in (in beta) that can script Audacity - an often requested feature and one that will also allow us to more easily do automated testing of Audacity.

=Recruitment Drive=

We need a recruitment drive. We need more programmers, each doing somewhat less, new ideas, new directions. It's needed to keep the project vibrant. It's particularly true of a project that supports multiple platforms, Linux, Windows, Mac. We also need more people with the skills needed for testing, people who think out of the box.

In 2008 we participated in Google Summer Of Code. If you're in an organisation that applied to GSoC and didn't get it, I'm more than happy to give details of what we did that we feel helped us get accepted - and to share our experiences to date.

In 2008, possibly related to our involvement in GSoC, in addition to our students we also got more interest from graduates doing audio research projects using Audacity. Clayton Oatey joined as a new committer, adding SBMS functionality, and George Fazekas has been in contact about extensions he's been working on to Chris Cannam's VAMP.

2009: Two of our five GSoC 2008 students still active. Mentor burnout in the whole group, or just the increased desire to get that 2.0 stable release actually complete and released lead to a much reduced level of volunteers to be mentors in 2009. We pitched to focus on bugfix projects, with fewer students, and that's exactly what we did. Our users need a new stable release.

As well as GSoC 2009 students adding and fixing new code, in 2009 we also had some very welcome additions from new contributor, Philip Van Baren. We received a significantly faster FFT implementation written by him - without the licensing issues that prevented us using FFTW. We also had an important fix and enhancement of functionality to the TruncateSilence effect, which had previously prevented podcasters from using it successfully.

2010-2012 (inclusive): Didn't apply for GSoC. We need a critical mass of mentors willing to commit to mentoring, and also we need to be out of bug fix mode, for the project to be sufficiently fun for the students. We need our plug-in API to mature a bit more too. We think we made the right call in these years.

=GSoC 2013 Plans=

It may be too early to talk of GSoC 2013, but I'd like to float some ideas. I think it would be good to again participate and take 3 or 4 students, but for safety, to avoid an Audacity that we cannot release without a great deal of work, make it a requirement that big new code features be developed as plug-in modules. That of course relies on us having made some good progress on modularity in 2012.


 * We should start thinking very seriously about co-operation with other projects. For example there are opportunities for collaboration with Blender, CLAM, Inkscape and Rockbox.  If we each start benefiting from each others development efforts it's like getting a lot more development resources.
 * We should look at ways that GSoC projects can reduce the barrier to entry for new participants. At the moment there is a steep learning curve to be able to contribute anything at all to Audacity.
 * We need to strike a balance between bug-fixing and new features. I'd like 2013 to have both the openness to new features of 2008 and the progressing a release that the 2009 bugfix focus gave.

=Code Review=

One of the comments from both our GSoC 2009 students was that the code's internal documentation was patchy. Both students would have preferred clear well written code to sometimes tangled code with good comments, but where the code is tangled comments would certainly help new people to get up to speed and get involved.

In 2010 we already are having a lot more code reviewing. Rather than always producing a separate code review document the plan instead is often to review through comments in the actual code. Rather than writing 'use a subroutine here' or 'change the naming of these to be consistent' it's quicker and simpler for an experienced reviewer just to make those changes. Larger changes can remain as comments. Having moved to google SVN we have the Rietveld reviewing interface, and are using that to some extent. However as consensus builds on the kinds of change that are fine to just make straight away we'll move over more and more to review-and-change in one step.

Some things already found in review:


 * Efficiency 1: using arrays of pointers to small objects rather than using an array of small objects.
 * Efficiency 2: using Prefs to look up a value repeatedly, rather than looking it up once and caching.
 * Efficiency 3: Repeated mallocs and frees that could be avoided.
 * Code that does not take account of the bitrate correctly allowing closer envelope points than the developer intended.
 * Complex case-by-case code where a different way of looking at the cases much reduces the number of cases to consider.
 * Deeply nested ifs that can be reduced by inverting the logic in some places.

The comments left in the code should make it easier for people new to the code to understand it. They also give relatively small 'todos' which can be done in odd moments, rather than larger tasks that might take days. The plan is to do more reviews in future so that the older code gradually gets clearer and easier to work with.

=Improving this Wiki=

I'd like this wiki to be a lot more visually appealing. Of course it's not just the visuals. I'd like the content to be better too. Good visual appeal is an important step. It gives the message that we take updating the wiki seriously and encourages more visitors to participate. The beauty of wiki is that anyone can contribute. Even small corrections and improvements help.

Tables of information help to break up wiki text. To help promote tables on audacity wiki, I'm building a list of possible tables that we already have or can have in the future. Improved formatting of tables and images in them can help too. Let's make this wiki sing!


 * Internationalisation
 * On the front page we have a table with the flags of the different countries and the languages Audacity has been translated into.
 * Plug-ins
 * The plug ins page lists types of plugins such as Nyquist, Ladspa, Vst, Vamp.
 * Libraries
 * Audacity uses many libraries, libmad, libvamp, portmixer, portaudio...
 * Key Developers
 * Vaughan, Martyn, Michael, Leland... Possibility of a table with brief information about each, when they joined, why they joined, the day job, what music they like.
 * Audacity Translators
 * Companion to the 'internationalisation' page, but listing the active translators, the languages they speak, first version they translated....
 * Audio Formats
 * Wav, mp3, Flac....
 * Built with Audacity
 * Variants on Audacity, such as Thinklabs, Umixit, Cleanspeech...
 * Test Sounds
 * Tone, Chirp, Square wave, Sawtooth, Beat frequencies. Each with images and spectrum, downloadable audio file and instructions on how to make it in Audacity.

Orphans
A few pages I started I've linked to here to avoid them becoming 'orphans':


 * Comparative Analysis
 * Storm Botnet

Experiments
I'm working on:
 * A page on wikimedia installations with graphics That's particularly user editable graphics from within the wiki. The comparison table shows some of the different options.  I'm also using the sandbox to try out graphics for ratings of bugs and reviews.
 * A test page where I try out some templates.
 * A possible new format for the release checklist. If we use this we would have one bug per page, but would still see a list of all bugs through using 'transclusions'.  Extensions to mediawiki (semantic wikimedia bundle) could make the maintenance of related pages automatic - the gather but not the scatter of The Ideal Bugtracker.
 * Bug Pages (now less relevant because we are using bugzilla for bugs):
 * Top Usability Issues - to capture possible changes in Audacity to enhance usability.
 * Top Squished Bugs - one bug per release.