James Crook is one of the lead developers on Audacity, though never as active in actual coding as he would like..
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.
- User:James pages, most recent edits first
- User:James pages
- Build Scripts: Spring Cleaning the build scripts | Talk:Developing_On_Windows | User:James/Building_on_Ubuntu | Building_On_Mac.
- Automation: Automation_Project | Images in Manual | Automation Project Progress | pages for the printed manual
- Big Proposals: DarkAudacity | Proposal TrackPanel Evolution | Proposal Audacity 4 Blind | Proposal Audio Diff | Proposal MultiButtons | Proposal Smart Help | Proposal Source Separation | Proposal Structured Audio | Proposal Team Tools | Proposal Unitary Project
- Tracker Proposals: Generally these are much smaller projects, and they are mainly here to track and refine a feature request. Proposal Monitoring On | Proposal Easy cfg Reset | Proposal new Zoom Toolbar | Proposal Play at Speed | Proposal Safe Project Overwrite | Proposal Clip Navigation | Proposal Label Enhancements | Proposal Label Track Info
Our top issues
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.
(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.
Using this space as a scratch pad...
- (from Gale) Open sound control panel from within Audacity.
- (from Gale) Sample rate info on sample rate sensitive failure dialogs. Sample rate info/setting and duration on export dialog.
- (from Gale) Wave colours configurable, independent of theme.
- (from Gale) Track/Clip info list dialog, rather like the label's dialog. Re-use MediaInfo source code?
- (from Gale) Hi-DPI. Double ThemeCache.png height/width as first step.
- (for Gale) eXo and discourse feature-requests trial info.
- (from Steve) Record-Beside should record into empty tracks, if any are available (Steve's workflow).
- (from Federico) CAN have two Audacities using process explorer and deleting "Mutant \Sessions\1\BaseName\audacity-lock-Federico Miyara"
- (for Peter) Automate screenshot capture.
- (for Peter) Automate spider diagram.
- (for Roger/Chris) Cat-nip for researchers.
- (from Bill) Better spectrogram peaks.
- (from MC Sharma) Robot soundz.
- (for Sam) Tell Sam about md5file.com/calculator ?
- (ask Paul) Follow up - Paul's version of gcc and configure options?
- (ask Buanzo) Follow up - Wikimedia installation for Spanish/Portuguese?
- VI users - announce highest levels of sound from meter.
- We need to compile wx3 ourselves under linux, to enable accessibility and apply patches. Should we just disable the new ASSERTs?
- FIXME TRAP_ERR review - do something about the results of this.
- Review TODOs
- Apple developer cert.
- Microsoft developer cert.
- Memory leak from timer diags. What was that really caused by?
- Multi buttons
- Meter space-saver.
- Linux compile instructions need update and rationalisation.
- Patching instructions need consolidation and write up.
./configure CXXFLAGS="-std=gnu++11" --without-lv2 --without ffmpeg
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.
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!
- On the front page we have a table with the flags of the different countries and the languages Audacity has been translated into.
- The plug ins page lists types of plug-ins such as Nyquist, Ladspa, Vst, Vamp.
- 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):