CAITLIN: A Musical Program Auralisation Tool to Assist Novice Programmers with Debugging

Introduction

Program Auralisation

The case for using music to aid debugging is supported by Francioni et. al. (1992), although they felt that a visual presentation was also needed to provide a context or framework for the audio sound-track. Program state was captured as a set of trace data that were subsequently auralised and animated. Jackson et al (1994) have suggested ways in which certain aspects of parallel programs can be auralised, but again the auralisation is of a ‘post-mortem’ nature.

Auralisation projects of note include the InfoSound system (1990) by Sonnenwald et. al., DiGiano et al’s LogoMedia (1992), Jameson’s Sonnet system (1994), Bock’s Auditory Domain Specification Language (ADSL) (1995) and Mathur’s LISTEN system (1993). One stark omission from the existing literature is empirical evidence that program auralisation is actually useful. Preliminary experimentation showed that music can be used to visualise algorithm state (Alty, 1995). In this experiment we gauged reaction to tasks that required the interpretation of musical output.

The first task showed that subjects were fairly accurate at estimating the difference (in semitones) between two musical pitches. The second task required subjects to sketch the perceived shape of short musical sequences. Subjects were generally able to pick up the basic shape being presented. As the experiment used musical sequences generated by a bubble sort the results indicate that music can aid visualisation of algorithm state.

The CAITLIN Project

Our auralisations are deliberately based on musical techniques. Music is an extremely powerful medium for the delivery of large amounts of data in parallel, using techniques such as counterpoint and polyphony. Separate musical ideas can be delivered in parallel without confusing the listener if certain syntactic and semantic rules are followed. It makes sense to investigate whether music can be usefully employed in program auralisations. Other reasons for using music in program auralisations have been considered in earlier work (Alty, 1995), as have some of the arguments against using music (Alty, 1995). One of the more enduring criticisms is that quantitative information cannot be conveyed by sound or music.

The argument is that while most individuals can tell if a note increases or decreases in pitch, only trained musicians are able to determine exact intervals with any accuracy. However, quantitative information can be meaningfully described and presented in terms of its overall magnitude without needing to know its exact, discrete values. For instance, just as an unmarked thermometer allows visual judgement of the relative magnitudes of various temperatures, musical pitch enables aural gauging of the relative values of different data. Nature already provides an acoustic thermometer in the form of the striped ground cricket. By listening to the cricket’s chirps, one can predict ambient temperature (Pierce, 1949);for example, twenty chirps per second equates to a temperature of 88.6 Fahrenheit.

The CAITLIN Pre-Processor

CAITLIN is non-invasive in that it leaves the source program unchanged. The auralisations are effected by adding library routine calls to a copy of the program. The enhanced copy of the source program is compiled to produce an auralised executable image (Figure 1). Because CAITLIN is designed to assist in debugging executable programs and not to help compile code, it will only accept a source program free of syntax errors.

Upon running CAITLIN (Figure 2) the user is presented with a screen similar in concept and layout to that of the Turbo Pascal Integrated Development Environment (IDE). A menu option allows the user to load a source program into memory. The program is then parsed and stored as tokens in memory. After loading, the user can opt—via a menu (Figure 2)—to auralise and then compile and run the auralised program, or musicode.

Auralisation is done at the construct level. A WHILE loop is auralised in one way and REPEAT, FOR, CASE, IF...THEN...ELSE and WITH constructs in others. The user may select, for each construct, the nature of the auralisation to be applied. This is fairly simple-minded, allowing selection of musical scale (e.g., major, minor, etc.), default note length (e.g., eighth note), MIDI channel and instrument. The speed at which the music is heard is controlled by a user-definable tempo variable. All options can be saved to a configuration file.

The auralisation comprises three basic parts for each construct: a musical signature tune (leitmotif) to denote the commencement of the construct, a musical structure representing the execution of the construct, and a signature to signal exit from the construct. The contents of the musical structure within the construct will depend upon the construct’s characteristics. Different constructs have different features that will be represented in various ways. To this end we have introduced the notion of the point of interest (POI). A point of interest is a feature of a construct, the details of which are of interest to the programmer during execution. For example, the IF construct has four POIs:

1. entry to the IF construct;

2. evaluation of the conditional expression;

3. execution of selected statement; and

4. exit from the IF construct.

To enable the listener to distinguish between the POI-1 of FOR, WHILE and REPEAT loops we defined a short signature tune for each construct type. When a program is auralised, the tune associated with FOR statements is inserted prior to each FOR loop, and so on. A construct’s last POI is auralised by playing a complement to its signature tune (such as playing it in reverse).

By defining a program in terms of its points of interest we build up an understanding of how each element and also how the whole program should sound. For example, we know that each FOR loop will be heard as a sequence of

• playing of signature tune, followed by
• repetition of music denoting iterated statement execution, followed by
• playing of modified signature tune.

Experimentation