I am a big fan of trace output for debugging – my trace logs often read like Russian novels. This is great for viewing an application as a whole, but can be overly cumbersome to wade through when I need to isolate a single bit (or stream) of data. After exhausting an array of prefixes (asterisk, underscore, and the like) to make my logs easier to visually parse, and outputting to tabbed log fields to trace multiple threads simultaneously, I still needed a way to quickly (temporarily) separate the info I needed now from the volumes of unrelated (but useful) log data. I suppose I could have solved this problem by creating yet another field to catch specifically flagged trace data, but this would log the same data (at least) twice, to different fields – “General information I need” and “Specific information I need right now”. What I really wanted was another way to view my data, another channel for application feedback. A common technique that I often use is placing a graphic/stroke/number onto a particular timeline/keyframe. This works well for visually tracking states of Movie clips, but is much less effective for tracing code. So, after ruling out visual feedback, the solution was immediately clear – SOUND!

Sound can rise above the sea of information generated by traditional visual feedback methods like trace() and tell you exactly what you need to know. A well placed ‘tic’ or ‘ping’ can give you great insight into the efficiency and flow of your application, similar to the way a good mechanic can diagnose engine trouble by ear. When a function you are working on fails, your app can simply state in the voice of Hank Hill “That boy ain’t right!” Taken a step further, each Class could have its own voice, making it easier to identify where the feedback is being triggered.

There are certainly a number of ways to implement audio for testing. For instance, you can create a ‘playSound’ function that when triggered creates an instance of the Sound class and attaches a specific sound from your library. Or, you can go ‘old school’ and create a ‘testSounds’ Movie clip with a variety of sounds on labeled keyframes along the timeline, then simply trigger the sounds with ‘testSounds.gotoAndStop(“mySound”)’. Even older still, you can go medieval and drop sounds directly into clips or the main timeline if that’s what it takes to get the quick and dirty feedback you need.

Bottom-line: Debugging with sound is actually quite easy to do and can be an extremely useful tool in the debugging process. The technique uses one or more bits of sound (generally in a Movie clip) to deliver audible feedback for debugging a Flash application. The various sounds are triggered along with (or in place of) more traditional ‘trace’ statements sent to your output window.

BTW, a good source for royalty-free (cc) sounds is The Freesound Project.