From Audacity Wiki
Revision as of 18:13, 3 December 2020 by James (talk | contribs) (Update.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

James Crook is one of the lead developers on Audacity, though never as active in actual coding as he would like..

  • I've a particular interest in using Audacity for foreign language learning. I'd love to see Audacity being used to prepare language material in a structured fashion. This could then be loaded onto an mp3 player which has modified firmware, or onto a smart phone, so that the audio lesson can become more interactive. The same kind of techniques could be used in preparing audio material for the blind or for people with dyslexia.
  • My day job is in electronics. It has in the past been in bioinformatics (fast DNA sequence data mining), telecoms (optimised TCP/IP stack, X25...), power industry (industrial control), computer animation (educational), OS verification (two ESA satellites) and broadcast television. Currently I write commercial software for designing ICs, (FPGAs).
  • Hobbies (aside from programming): body work, playing football and science fiction.

I live in Dublin, that's in Ireland.
James dot k dot crook at gmail dot com.

Some Interesting Pages

[[ToDo: Everything]][ bugs]

<chart>Some data</chart>

Audacity Page Rank

FossHub Page Rank



I'm looking at several initiatives to ensure the future success of Audacity. The most imminent is Google Summer of Code 2009 our current push to get a stable version 2.0 released untangling the track panel, and providing a new one as a plug-in.

Thinking About

  • Done.png VRuler Changes to reduce risk of accidentally-stuck-in-VZoom.
  • Done.png Merge Ext menus, and update docs.
  • Done.png Scrub->Seek in ext menus.
  • Done.png Update Flags to Snow Wolf's i18n template.
    • Done.png Add Croatian to i18n template.
    • Done.png Update mw2html to handle i18n template.
  • Done.png Regenerate many images for manual.
  • ToDo.png Update compiling instructions.
  • ToDo.png Regular interval labels also generating spans.
  • ToDo.png Label dragging fixed back to how it was designed.

Like to See

  • ToDo.png Use Extension Cargo if we move our bugtracker off Bugzilla. Maybe use it anyway?
  • Done.png Three requests in with Buanzo:
    • Done.png What-is-That subdomain for Audacity
    • Done.png Ban a regular spammer from audacity-devel.
    • Done.png Upgrade this wiki to same as manual wiki (want ParserFunctions)
  • ToDo.png ExportAs menu item, to save project and continue.
    • ToDo.png Overwrite-project option when saving to existing name.
  • Done.png Scrubbing engine used on varispeed play
  • ToDo.png Possibility of monitoring always-on
  • ToDo.png Noise removal optional-extra parameters.
    • ToDo.png Protocol (i.e. instructions) for setting noise removal.
  • Done.png Website updated to new theme.


  • Scrub ruler off by default.


  • Google WaveNet
  • ISSE
  • Multi-Core or Web-GL processing.
  • Super fast SSD for desktop
  • All-In-One file.

My Pages

Our top issues

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.

James' Notes

Using this space as a scratch pad...

  • ToDo.png (from Gale) Open sound control panel from within Audacity.
  • ToDo.png (from Gale) Sample rate info on sample rate sensitive failure dialogs. Sample rate info/setting and duration on export dialog.
  • Done.png (from Gale) Wave colours configurable, independent of theme.
  • ToDo.png (from Gale) Track/Clip info list dialog, rather like the label's dialog. Re-use MediaInfo source code?
  • ToDo.png (from Gale) Hi-DPI. Double ThemeCache.png height/width as first step.
  • ToDo.png (for Gale) eXo and discourse feature-requests trial info.
  • ToDo.png (from Steve) Record-Beside should record into empty tracks, if any are available (Steve's workflow).
  • ToDo.png (from Federico) CAN have two Audacities using process explorer and deleting "Mutant \Sessions\1\BaseName\audacity-lock-Federico Miyara"
  • Done.png (for Peter) Automate screenshot capture.
  • ToDo.png (for Roger/Chris) Cat-nip for researchers.
  • ToDo.png (from Bill) Better spectrogram peaks.
  • ToDo.png (from MC Sharma) Robot soundz.
  • Done.png (for Sam) Tell Sam about ?
  • Done.png (ask Paul) Follow up - Paul's version of gcc and configure options?
  • ToDo.png VI users - announce highest levels of sound from meter.
  • ToDo.png We need to compile wx3 ourselves under linux, to enable accessibility and apply patches. Should we just disable the new ASSERTs?
  • ToDo.png FIXME TRAP_ERR review - do something about the results of this.
  • ToDo.png Review TODOs
  • Done.png Apple developer cert.
  • Done.png Microsoft developer cert.
  • ToDo.png Memory leak from timer diags. What was that really caused by?
  • ToDo.png Multi buttons
  • ToDo.png Meter space-saver.
  • Done.png Linux compile instructions need update and rationalisation.

Ubuntu Compiling

./configure --with-lib-preference=Local,System

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+: 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.

Future GSoC Plans

We've found that GSoC has been a lot of work, and that in the time we could have got more coding done by the mentors doing it themselves. If we do it again, our focus has to be on using it to get better at bringing new people into Audacity, not just on what gets done during GSoC. If we do it again, I think it would be good to 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.

  • 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 future GSoCs 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.

We are now doing more code reviewing than we used to. 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 plug-ins 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.


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


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):