15 Dec 09
19:23

FuckingAudacity video up

Audacity GUI performance from Michael Takezo Chinen on Vimeo.

Audacity is an open source sound editor. I modified the code so that the sound playback depends upon the physical memory state of the program. Because the memory is dependent upon the user interaction, the user interface (buttons, menus, etc) as well as the structure of user-driven processes (effects, importing files, etc) become a part of the sonification process. The noisy quality of the sound is due to the fact that chunks of uninitialized memory are continuously sent to the audio output.

This recording was done with a point and shoot camera, so the audio quality is not so good, but it gives you an idea of what I’m trying to do.

The program is called FuckingAudacity. How to go about building it and programs like this will be up shortly.  This basics of this process are quite simple and can be attached to other open source programs as well.  I will try to document this along with how to attach portaudio to a program if it doesn’t have sound i/o, allowing pretty much any c/c++ open source program to having fucking versions.

This process has actually been quite helpful for finding bugs (and fixing them,) because the performance aspect makes for more extreme use cases.  For example, I fixed a bug that existed in 1.3.10 where pressing play in a second project while another was already playing would cause the audio glitch and stop.  This process also has a healthy result  It is introducing me to more code, and thus more devel mailing lists/communities.   For example, I’ve also been playing with SuperCollider in a similar fashion.

If you are interested here a some related projects that I know of:

Shintaro Miyazaki’s work sonifies computer processes externally:

algoRHYTHMS everywhere Version 0.2 from Shintaro Miyazaki on Vimeo.

These two other projects were on slashdot：
http://www.codesounding.org/indexeng.html
http://cessu.blogspot.com/2008/09/have-you-listened-to-your-program-today.html

  It’s interesting that they attach sonification data to MIDI and some meter, which is a pretty specific sonification scheme.  One of them uses valgrind, which I am interested.  Unfortunately it doesn’t seem to work so well on my 5 year old computer for GUIs.  But I want to find a way to work with a debugger that allows hotfixing/live program analysis (e.g. the call stack) as an extra layer of performance.

Comments