User:James

From Audacity Wiki

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.


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




Contents

[edit] Stable Release

As of February 2010 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. Even so, we'll be doing well to actually release a sufficiently well tested 2.0 stable version by the end of the year.

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 was 'year of the bug fix' 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.


[edit] 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.

In 2007 we missed out on Google Summer Of Code. At that time I was naive about how much preparation would be needed to be ready for GSoC. I put together a short factual application for Audacity to be a mentoring organisation, suggesting that we take on just one student to get the hang of it. With the huge numbers of downloads we have, I thought we'd be a shoe in. I was wrong.
In 2008 our approach was a lot more professional. We put in plenty of preparatory work between then and March 2008, mostly behind the scenes. And it paid off. We were accepted as a mentoring organisation in 2008. 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 made the difference - and to share some of 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.

[edit] GSoC 2011 Plans

It may be too early to talk of GSoC 2011, 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 2010.

  • 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 2011 to have both the openness to new features of 2008 and the progressing a release that the 2009 bugfix focus gave.


[edit] 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 throughout 2010 so that the older code gradually gets clearer and easier to work with.

[edit] 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
    • Dominic, Vaughan, Leland... Possibility of a table with brief information about each, when they joined, why they joined, the day job, what music they like. May need to lock this page.
  • 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.

[edit] Orphans

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

[edit] 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.
  • Recently started:
Retrieved from "http://wiki.audacityteam.org/wiki/User:James"
Personal tools