User:Aldimond

Hi, my name is Al Dimond.

I started working on Audacity because I've used it heavily for my own music projects, and wanted to give back. I remember Audacity crashing a lot and having severe envelope editing problems back when I was working on my 2008 album; I don't remember which version that was, my guess is that Gentoo packaged something from the 1.3 branch that wasn't really ready to go. Despite its problems I stayed with it because it was easy to use and gave me quick access to lots of nice effects (noise removal was invaluable back when I had to record into my old, loud, junky computer).

My major strength as a programmer is finding and fixing bugs. My weakness is starting new things, adding new features. Somewhere in the middle of those is restructuring classes to make it easier to write bug-free code. Here are some things (as of early December, 2009) that I'm interested in restructuring in Audacity, probably in the next development branch after the 2.0 release.


 * Stereo tracks
 * Track groups -- also improve the UI so it's more logical to users
 * AudioIO: currently the listener and meter interfaces cause problems because they aren't designed to handle multiple projects. In both cases we could probably use something like the "listener" pattern (I am not a design pattern guru, but I have read The Timeless Way of Building). Ultimately it would be cool to have multiple projects recording/playing back at once. Think of an Audacity playing into JACK, which routes the stream to some other program that adds some effect, then out of there back into a second, recording, Audacity project.
 * Effects. We duplicate way too much code in our internal effects and see the same bugs over and over. Meanwhile the same bugs only have to be fixed once for all LADSPA effects. Many effects essentially work "in place" on the audio, and there should be an Effect class for such effects that handles all the looping over tracks and clips for these sorts of effects.

And new-ish things I'd like to work on:


 * Better JACK. We should at least maintain persistent connections to audio servers like JACK and PulseAudio (maybe one for each project?). This would probably require significant changes to PortAudio. It would also be nice to have dynamic updates for device availability, since JACK sinks and sources come and go so frequently (this has many other benefits as well, particularly with USB devices)... on the other hand, it might work better for JACK to only allow Audacity to control which server it connects to, and let the rest be handled by a program like qjackctl. I really don't want to duplicate qjackctl in Audacity. Even that would require some PortAudio changes.

I also think it would be a good thing to fix up our build scripts so we could build like: mkdir aud-build; cd aud-build; ../configure; make. That will require some work on upstream packages.