Music Literacy and the Preschool Hacker

The purpose of this paper is to establish a background context for considering the design of a programmable computer musical instrument geared towards young children who have not yet necessarily acquired reading or writing skills. Such a background should help address several questions. Is it necessary for preschool children to have complicated tech toys? What interfaces are workable? What educational goals does such a technology purport and how does that influence design? How does one measure the success of the design?

The literature examined in this review includes selections from the extensive research on music education, auditory cognition as well as the surprisingly smaller published corpus on children and computers. The works considered, or ignored, are in no small way telling of my motivations for such a project. By way of contrast, I'll start with an explanation of what that motivation is not. That motivation does not include the belief that very early exposure to computers is imperative to cognitive development or successful navigation of our computer rich culture. There are just too many anecdotes from well educated and computer savvy people whose favorite childhood toys were “snail shells and sticks” or “a pail, a shovel and a pile of sand” to believe that. Indeed, many fundamental concepts of computational science, such as sorting algorithms or combinatorics, can be easily demonstrated and modeled with a deck of cards, a few wooden blocks or even interpretive dance. My motivation does not include the advancement of computer assisted learning (CAL). CAL has become nearly synonymous with expository teaching in which the program holds the student's hand while walking her or him through a series multimedia demonstrations, peppered here and there with the supposedly requisite testing. The design goals of CAL are largely to emulate the functionality of human instructors and as such can be considered programs of economy, an economy that should be regarded with leeriness. Finally, the motivation is certainly not the creation of marketing opportunities for embedded systems by their inclusion in well known and time tested toys. These artifacts may very well have educational uses, but I don't take the position a priori that the sand on the beach offers less pedagogical opportunity than the silicon in a logic chip.

But indeed young children may offer an excellent opportunity for economizing education! When talking with secondary school educators in the United States, one of the largest challenges heard again and again is that of discipline in the classroom. I recently attended a teacher training workshop in the US where the local middle school principal conducting the class was completely uninterested in seeing the lesson plans we had drawn up as homework. She explained to us that in the real world a class would never allow us the opportunity to present our lessons and then proceeded to instruct us on the use of nerve pinches, apparently all legal in her school district, for subduing out-of-control pupils. Some educators, notably Leon Botstein, have made arguments that high school and biology are in fact at odds with one another. High school students are sexually mature, their bodies are telling them they are adults while school continues to handle them like children by denying them significant roles in defining problem domains or, alternatively, meaningful independence through entry into the economy. As unruly and hyperactive as a group of four year olds may seem, unlike their sixteen year old counterparts, they're less likely to have a car, a cell phone, a date, concealed weapons or illicit drugs-- in other words, they're disciplinary bargains.

Long before Noam Chomsky gave us transformational generative grammar, educators, linguists and psychologists have been amazed by children's ability to bootstrap themselves into competent use of their native language. Children's intelligence is easily underestimated by measures of their volume of knowledge. Children are indeed naïve in that their experiences and testing of the world is still sparse. The total amount of content on board is less than they will enjoy after years of perception and interaction. However, this assessment can unfairly prejudice the designer into building unnecessarily simplistic educational tools. The child's mind is evidently quite intelligent when it comes to learning. To paraphrase Seymour Papert (or Jean Piaget), children are born epistemologists. The mind is ready to receive complex information about the world and to begin the daunting task of organizing that stimuli into mental models. For instance, research in auditory cognition suggests that humans may be at their best for differentiating sounds during their first twelve months of life (for instance see Patricia Kuhl and Helen Neville's comments in the PBS documentary “The Child's Brain: Syllable from Sound). If that's the case, is it more fruitful to expose the developing musical intuition of a crib bound infant, the consummate captive audience, to the monotony of “hot cross buns” and “Mary had a little lamb” or to the intricate quarter tones of an Indian raga or harmonies of modal jazz? Failing to provide suitably complex models of the world to young children is analogous to buying high and selling low, a missed opportunity.

Giving children a head start with computers is of less concern than providing the right start at whatever age. Somewhere, probably during the early 80's and the realization that windowing systems and networks were where the windfalls of the computer industry would lay, the computer took a wrong turn from being a tool to being an entertainment system. By the mid 90s the microcomputer may have finally met the masses, but instead of going into the toolbox along with the hammer, the screwdriver and the indespensible roll of duct tape, for many it's just another companion to the sofa and a bag of chips. The sort of exposure proposed ahead is one in which the relationship between computer and user is clear, the computer is the tool. The microcomputer is an accessory to the scissors, white glue and construction paper. It's a device for creative expression and for model building, the sort of models we as students build to test and debug our intuitions.

The approach of introducing children to the computer by way of an understanding of its “low level” operation exposes a final motivation. Writing software for children is also an opportunity to deconstruct the computer for adults. Many adults, more than comfortable with their word processor, email and web browser, might feel no small amount of apprehension if suddenly asked to try to understand some c/c++ code. But the same adult would likely have little trouble following the thread of a LOGO program and in turn might just gain a better understanding of a device they use daily. I'm often countered on this point with the insistence that life is just too complicated for us to understand how everything works, “I don't want to know how, I just want to know that it does.” The problem with this reasoning is that if one doesn't take the opportunity to understand the machine for themselves, at least to some basic levels, someone, possibly someone with an ulterior motive, will do it for you... at a cost (ie. imagine the unscrupulous auto mechanic who charges $150 to change a burnt out fuse!) When chopped into the right sized bites, computers aren't really all that complicated. Computers are now very pervasive. It's worth a little effort to understand a device you are likely sit in front of hours every day.

When evaluating ideas for new toys a likely first step is to ask, “what is appropriate for this age level?” This is a fair question in light of the physical safety of a toddler. Does the device have swallowable parts? Knives, propane torches and high voltage devices for use in the bathtub should be quickly edited out. But what about design appropriate to cognitive developmental stages?

Experimental psychologists, particularly the oft-cited guru Jean Piaget, have left us with a hierarchy of well defined mental development stages. For instance, a pre-conservationist child will often confuse that a change in dimension does not necessarily correspond to a change in volume such as when a liquid or collection of is poured from a short wide container into a tall narrow one. Even upon counting the marbles out both before and after the transfer, pre-conservationist toddlers are likely to confuse the taller flask as having greater volume. Repetition of this experiment across economic, geographic and cultural boundaries shows a great consistency in results and points to a transition sometime around the fifth year of growth. (For a description of similar experiments involving the volumes and weights of maleable balls of clay, see Piaget and Bärbel Inhelder's The Child's Construction of Quantities published in 1941.) As the child matures, these sorts of boundaries often become fuzzier. (Papert) For instance, combinatorics is rarely handled correctly before age 11 or 12 and often is never mastered even by adults either formally or intuitively. Papert suggests that this finding, even cross culturally, has more to do with the wealth of models involving numbers available but the relative poverty of models involving systems-- a poverty that certainly could be changed in a computer rich culture if software doesn't take every last pain to hide computational mechanisms deep under the covers.

Similarly, recognition of developmental stages shouldn't become a design trap. It's important to keep in mind that children should be provided with a rich and complex environment against which to test their developing mental models. It may in fact require many revisions of their mental models before they “get it right” with the “real world.” Providing accurate virtual models will aid in that iterative debugging process. Providing those models ubiquitously assures that the models are available when the child needs and is ready for it.

Music provides numerous well known and seemingly aberrant exceptions to the idea of development stages. The Mozart family offers at least two examples, Wolfgang and his slightly older sister Nannerl. Mozart, who was playing minuets by four and the same year attempted to write his first concerto, surely had a solid sense of time, space and volume? The considerably less well known Nannerl was no slouch either and accompanied her brother on the harpsichord while performing for royalty while she was still only eleven years old. Perhaps prodogies can be dismissed as the rare biological oddities, or even shown to be not that deviant from the immutable stages as we think. Their father, Leopold who had himself published a widely used text on violin instruction in 1756, certainly liked to stress their uniqueness as the children started their professional performing careers somewhat as novelty items (Fischer). During the twentieth century another violin instructor, Shinichi Suzuki made it his life's work to turn out child musical prodigies by the hundreds of thousands. Although his often stated goal was “to turn out good citizens,” his unyielding belief was that the ability to play Bach or Vivaldi on the violin by the age of five or six (and sometimes younger) was an excellent first step in that direction.

Suzuki grounds his theories, although perhaps less rigorously than the typical linguist, in the child's amazing ability to learn their native language during their first several years of life completely without aid of standard classroom pedagogical tricks. What is known in North America as the Suzuki Method is in fact called by Suzuki the “Mother-Tongue Method.” In essence, he sees the key factors of this bootstrapping as the child's innate ability to learn predicated by exposure and repetitive practice. Suzuki posits that even difficult pieces of classical music are no more challenging than the formation of a wide range phonemes and their correct association with morphemes and broader semantical categories by the neophyte speaker. A strategy of teaching music that is similar to that of learning language should produce superior results.

Suzuki is careful to differentiate between an innate ability to learn and an innate talent for music, the latter of which he strongly disbelieves. That supposedly tone deaf children also have tone deaf parents is not evidence of a genetically inherited trait but rather that the child, expert at differentiating tones, copied their parent's poorly rendered lullaby to the exact pitch. He goes on with an example of remedying this situation. A common error in singing a major scale is for a child, or adult, to produce fa a full tone higher than me; although it is in fact only a semitone higher. His cure is repitition. The incorrect fa cannot be undone, but if it was learned from 5000 incorrect examples, he would have the child replace it with 6000 renderings of a new and correct fa. His schools in Japan are called “Talent Education” and unlike the similarly named magnet schools in the US, are built upon the notion that every child is capable of a high degree of performance, not an elite few.

Suzuki does advocate exposing neonate infants to complex pieces of music. The exposure is characterized not by diversity but by repetition and the claim that a melody heard everyday for months by the newborn will be a melody that will belong to that person for life. Research has since been done to support this claim (Grublin).

Many contemporary educators lament the role parents either choose or are capable of playing in their own child's education. The Suzuki method directly addresses this lament in that the lessons, initially, are not for the child but rather for the parent. Children are not given an instrument until the parent has mastered a piece first, albeit a simple one. The theoretical justification given by Suzuki is one of motivation. The child wants to do what the parent is doing, particularly if it looks fun! The notion of 'fun' is echoed in later work by Papert in a critique of math education. He points out that the math teacher who tells a student “math is fun” is quickly perceived as a deceitful liar. The student is well aware that on the teacher's off hours, he or she is doing anything but running through textbook problems calculating sums and perfecting long division. After the parent has mastered their first piece and the child has asked to play the instrument, instructing the child directly on the instrument may proceed.

Suzuki himself was the product of a fortunate environment. For instance, while a student in Germany, he had the good luck of introduction to one Albert Einstein as his host adviser, regularly attending concerts and dinners with the physicist. Suzuki's family owned what was one of the planet's largest violin factories in Nagoya, Japan. Started by his great grandfather as “a side business for a poor samurai,” the initial focus was building three stringed samisens. Suzuki spent many years working in the violin factory and was well acquainted with physical rendering of the instrument before it struck him that he should learn to play it and, in fact, did not start his own study of musical performance until the age of seventeen. But this relation with the construction of the violin provides another clue to the designer. Suzuki proved that any child could learn to play a complex piece of classical music soulfully, but certainly a child of three or four years could not play a full sized instrument. Access to the violin factory gave Suzuki the necessary know-how to construct instruments a fraction of their adult sized versions.

Arguably, Seymour Papert and his colleagues at MIT's Artificial Intelligence Lab of the 70s did a very obvious thing with their invention of the LOGO programming language. Like Suzuki and his violins, Papert had access to considerable know-how about the construction of a computer language. Also like Suzuki and his miniature violins, Papert's group simply created a programming language that was correctly scaled to its young audience. This scaling, however, was not at the expense of the core features of well known imperative and functional programming languages like C or LISP.

Early LOGO was simply a structured programming language with which the young programmer could manipulate built in functions or create their own functions to direct its now famous turtle. The turtle took a number of forms but most often as a triangle that would follow the program's commands to sketch out an image on the screen. Another form of the turtle was a rolling robot that could similarly sketch the drawing on a large sheet of paper laid out on the floor. Three examples of LOGO source code are provided below:

The first SQUARE procedure explicitly instructs the turtle to sketch out a square with sides of length 100. The second version of SQUARE introduces a loop and the third SQUARE an argument to control the length of the square's sides. These subroutines are reentrant and can be used recursively thus allowing the sketching of the intricate and repeating geometric patterns that have come to define a large body of computer art, both visual and sonic.

The creation of a kid scaled programming language may seem obvious, but Papert, himself a former protogé of Piaget, is careful and thorough to ground his design choices in theoretical justification. True to the art of software marketing, LOGO was offered up as a saner alternative to BASIC and its morasses of numbered lines and “goto” statements. ¹ The addition of subroutines provides at least two important lessons to the young programmer, lessons that extend well beyond the task of software development. First, the subroutine demonstrates that large problems can be broken down into smaller simpler problems. Second, subroutines greatly facilitate the important step of debugging by helping isolate blocks of potentially troubled code.

The debugging step is key. Papert argues that what kids are naturally good at is figuring out how to learn. They're good at it, and with the right education, they can get even better at it. Almost all debugging, even with the aid of compiler errors or debugging software, invariably involves strategies. An often used strategy, and my favorite, is to first narrow down the location of the possible problem and then, if the error is not immediately obvious, to try an experiment by altering the code and retesting the program. Development of strategies for solving problems is one facet that makes LOGO an education tool of wider importance than that of developing competent software engineers. Furthermore, it reinforces an important lesson soundly missed in the more traditional “expository teaching followed by exam” pedagogy. Getting the “right” answer is almost always an iterative process.

LOGO, at least in its inception, is mathematical flavored with a strong emphases on solving geometric problems, even if that geometry is sketching a flower or a house. Surely, math education was an important concern to a group of MIT based engineers, but the choice of geometry to introduce math and programming concepts is no accident. Drawing an image is a problem domain that is easy for the student to define themselves, an important step in Papert's strategy. The drawing does not have a wrong or right answer, but it does have an answer that the student will be more or less happy with and if less happy, one that will encourage debugging, evolution and growth. When the student defines the problem domain, the correct answer is also unknown to the teacher. The teacher no longer plays the role of dupe, playing dumb to cajole a response from their pupil, and instead becomes a bona fide collaborator in the discovery process.

Geometry may play a deeper role by helping the students model complex and abstract mathematical concepts through their already well developed sense of proprioception, ie. keeping track of their body in space. Both Papert and Suzuki underscore that intuition is not to be mistrusted and that intuition has unfortunately developed a bad reputation by playing the scapegoat that leads us to incorrect conclusions through its faulty operations. Intuition also needs development and should be regarded as an important ally in our understanding of the world. Suzuki uses the Japanese term kan when discussing intuition. Papert borrows the additional term syntonicity from clinical psychology. The turtle is syntonic in that its body offers a congruency to the young programmer's body. For instance, the programmer can easily pace out on the floor the same square they are trying to instruct the turtle to draw on the screen.

This argument echoes one made by many music instructors, particularly regarding development of an intuitive sense of rhythm. Dance and other physical play to music may provide a much quicker and sounder path to understanding rhythm than sedate analysis of meter and duration in musical notation. (Aronoff) Indeed, many common song structures share their format with a typical play session of a group of children. The energy of the group builds and builds, each child playing off the energy of the others until they can no longer sustain it and collapse, mercifully for their adult supervisors, into a calmer rest state. (Sheehy)

LOGO is still alive and well today. It has seen a number of commercial directions, particularly MicroWorlds® Inc of Montreal. Although the MicroWorlds® version includes all of the windowing bells and whistles that have come to define computer interfaces, basic LOGO is still available and in fact preferred by some educators. Although students apparently enjoy MicroWorlds®, classic LOGO's relative sparseness is not necessarily a turn-off. One teacher, who gave her students the option of using classic LOGO or the MicroWorlds® version had only 3 of 14 students choose MicroWorlds®. (http://el.media.mit.edu/logo-foundation/pubs/logoupdate/v4n1.html#classic, accessed March 2004) The robotic turtle has been reborn in LEGO® programmable bricks where the programmer may create control code in LOGO at the desktop which can then be downloaded into a robot built from the bricks. LEGO® has productized the programmable brick as LEGO® Mindstorms which uses its own visual programming language called RCX. (http://mindstorms.lego.com, accessed March 2004)

Many versions of LOGO include built in functions for creating sounds. Turtle geometry can be replaced or even combined with these tone functions to change the goals from sketching to composing music.

This will produce a tone of 262 Hz for half a second. Another procedure that might be implemented is settempo:

to startup
make "a 881
make "b 988
make "c 523
make "d 587
make "e 659
make "f 698
make "g 784
make "c2 1047
make "rest 0
end

to play :song
if empty? :song [stop]
if empty? bf :song [stop]
tone thing first :song first bf :song
play bf bf :song
end

There are two procedures here. The first essentially creates aliases between frequencies of a diatonic scale and their commonly known names in traditional music notation. The second procedure, play, provides a way to chain notes together:

which will play the e for a third of a second, the c for two thirds of a second and finally the g for half a second. The argument to play is a list, similar to the lists used in lisp. The first frequency and duration is passed to tone, producing the sound, while play calls itself recursively with the remainder of the list.

These examples demonstrate a strategy that closely ties the programming to traditional music notation and theory both by naming the notes and through the use of music terminology like allegro. Gusdial noted that the adults and children in his class who had had some music training generally started their programming endeavors by creating well known melodies that the student already knew on another instrument. Those with less formal training were more likely to invent a novel melody. Not unlike tape looping or repetitive use of samples characteristic of much electroacoustical classical or techno music, students quickly made the leap to create their own subroutines which wrapped multiple play commands. These wrapper functions could be linearly mixed and matched to reuse motifs.

After several classes, Gusdial had the class compose without the frequency-to-note name aliases and instead directly passing frequency values to the play function. He noted that the compositions “sounded bad much more often,” but that they were also “much wilder.” Some students preferred using the finer control of direct numeric manipulation of frequency values and continued to use this technique throughout the class. Indeed, direct frequency manipulation much more closely models many instruments such as fretless string or brass instruments and certainly fretted instruments or hammered instruments like a piano require tuning within a continuum of frequencies. Direct frequency manipulation is also much closer to the way the computer is often used in more advanced electronic music programming, eg. Max/MSP or CSound. Many composers find little reason to convert the numbers streaming from signal generators to music notation and many bypass intermediary representations like MIDI all together.

In our examples thus far we have seen how musical tastes will affect the teaching methods and the instructional tools. If one's goal is to play Bach or Handel, then familiarity with musical notation and traditional western music theory built upon scales, harmonies and subdivision of measures is key. Were Stockhausen or Cage the driving model, then an emphasis on concepts driving sound manipulation might be better stressed. Students might be encouraged to push the timbral range of their instruments and to consider the overall architecture of the composition more than the structure of any given melody. Many of us have come to expect, largely through the influence of jazz, blues, rock and roll and their historical antecedents, spontaniety in the music we play and listen to-- spontaniety usually affected through improvisational play between collaborating instruments.

In his University of Michigan LOGO and music classes, Gusdial comments that it's impossible to have ten students programming sounds on ten different computers in a single room before those students start to realize that the sounds are mixing, both harmoniously and cacophonously. On their own accord, students grouped their machines into ensembles and made efforts to coordinate their programs, not through network sockets and remote procedure calls, but in the open air of the classroom.

Tina Blaine has made collaboration and improvisation cynosures of her design work in digital musical instruments and interactive theater. Where Papert raises the importance of debugging in building one's education, Blaine and Brenda Hargar take up the cause of the student's confronting of an open ended problem:

In a group improvisation, the best and most sincere work is presented when participants are humbled by their task and aware that they might encounter failure. Only when the knowledge of failure is present does the work become honest and allow creativity to be unleashed. (Blaine and Hargar)

The failure, of course, derives much of its value in light of its evaluation and the subsequent opportunity to try again. Collaboration is an important skill to practice in and of itself.

Most children, at some point, engage in spontaneous music making. A baby's babbling may very well be early efforts at spontaneous composition and some have gone so far as to transcribe babbling into musical notation in an effort to provide a framework for analysis. (Moog) These transcriptions point to two modes of babbling: speech babbling and a more melodic babbling. Although speech babbling usually precedes music babbling, music babbling precedes the first use of words. Older toddlers may copy songs they have heard without prompting and certainly we are all familiar with children turning an ordinary conversation into sing-song mockery. Blaine's museum installations seek to provide a forum that encourages musical play. Inspired by African drumming circles and their popular North American counterparts that often seem to form almost spontaneously on sunny Sunday afternoons in many city parks, Blaine and her team created the Jam-O-Drum and Jam-O-Whirl. (Blaine and Forlines, 2002)

The Jam-O-Drum,a permanent exhibit at the Experience Music Project in Seattle, is a group instrument that resembles a large round table. Stations situated around the table are equipped with a MIDI drum pad embedded on a turntable disk. In addition to the sounds that may be created by striking the drum or turning the disk, these actions control graphics that are projected onto the table.

One configuration of the Jam-O-Drum is “Freeform Improvisation” where an underlying musical track is playing at all times to “provide an atmospheric and rhythmic musical reference.” (Blaine and Forlines, 2002) When coupled with a vibrant graphics output, this configuration proved to hold users' attentions the longest. Yet, it also became the most cacophonous as users focused on their own performances. A second configuration emulates a call and response (or more dimuntively labeled “Simon Says”). A virtual call is given by the computer. Each performer is then prompted in turn to respond. The Jam-O-Whirl, an exhibition developed for Zeum in San Francisco, seeks to further encourage cooperation at the Jam-O-Drum by posing a graphical problem that can only by solved by coordinated musical playing amongst the circle's participants. In one game, the playing field consists of a labyrinth projected onto the table surface whose concentric circles must be aligned through the playing of the drums and turntables in order to successfully navigate projected moving circles.

Blaine's designs seem to have proved themselves by the sheer enthusiasm of their users. However, their complexity and cost will probably be limiting them, at least in these forms, as museum installations used by any one child only on the occasional rainy day outing. The designs do provide hints for more humble and ubiquitous incarnations. Improvisational music such as in jazz or an Indian raga may be spontaneous but is not unstructured. Providing a loose set of rules and expectations as well a framework for the creation via games may work well at drawing in the player to that place where risk taking, failure and learning exist harmoniously.

At this point it is time to start shaping the design for a new instrument. Any design, however, should only be considered a starting point. Just as a youngster may not get their first LOGO drawing of a house or a flower quite the way they intended, this designing is conceived as an iterative process to be paced by experimentation, reflection and adjustment.

Having previously and succinctly stated what the project does not intend, finally it's time to reveal what it does intend. The instrument should give both young children and adults a glimpse of the low level handling of a computer. This isn't to say that they need to worry about gates, registers or buses, but that they begin to appreciate and command the same toolbox that professional software developers use to construct the software we love (and hate) to use daily. I would also like to build a serious musical instrument. Ideally, the instrument contains most of the familiar features that are expected of adult computer/programming musical instruments. The instrument, being constructed on a device with memory persistence, should be an instrument that encourages experimentation. And, the design should introduce models of sound that can provide a lifetime of utility.

Before giving more specifics on our incipient design, it is worthwhile asking what the computer is as an instrument? Of course, the computer, whether desktop, rack mounted or embedded, has very likely not ceased its evolution nor arrived at any final form as a musical instrument. Some future software approaches may provide wide open options for sound manipulation. Or they may be very restrictive such as limiting frequencies to scales associated with a certain style or tradition. Therefore, the following analysis tries to be accurate by being very broad.

The computer is like a fretless instrument. It can produce any frequency, including frequencies beyond human hearing (but handy when composing for elephants, dogs and dolphins). The computer goes beyond a fretless instrument in that its timbral range is also sliding. In other words, to state the obvious, the computer is a synthesizer. Not all synthesizers are computers, for instance analog synthesizers, and not all computer synthesizers are all that flexible, such as wavetables and granular synthesis. Ideally, we would like to give complete control of timbral possibilities to the young musician programmer.

The computer is like any other linear instrument. It can be used to serially chain notes together to create a melody or rhythym. Notes (or frequencies if one prefers) can be added to create chords, ie. polyphonies. Furthermore, like the two hands of a pianist or the many hands in a band or orchestra, the computer can simultaneously keep track of many melodic threads that are rendered concurrently.

The computer is a non-linear editor. Chunks of a composition can be reused simply and quickly: mixed, duplicated, folded, reversed, moved, phased, etc... The studio engineer, who always saw themselves as an integral part of the band anyway, can now step right up on stage and strut their stuff real time.

The computer can manipulate patterns at a high level to produce sounds under far less immediate control of the musician. For instance, so called smart instruments are programs that build upon the improvisation of another performer with a combination of pattern recognition, stochastically generated sounds and bounding limits. A “smart” algorithm can be used much like an effects box. For instance, the box may “trade fifths” with a musician by analyzing what the other performer has just played and then playing back a similar, but not identical, set of measures. Smart instruments are sometimes noted to be “not so smart” since the musician often adjusts their own level of subtly to coerce the effect. An analog example of such a manipulation is heard when Jimi Hendrix turns to face his stack of Marshal amps. The resulting feedback resonance is not entirely under Hendrix's control, but not beyond it either.

It's likely that a trial implementation will start with the first point, that the computer can string notes together into melodies, harmonies and rhythms. A second stage of design should quickly follow to enable the first and third points. A more functional implementation allows the user to both synthesize their own timbres in one direction while working with whole clips of a song in the other. Smart instruments are not an initial design goal. However, it would be interesting to test whether such an effect would prove confusing to the neophyte computer musician or quickly put to creative use It could even help facilitate interest in the instrument by allowing composition of denser sonic environments with far less work. Certain a priori decisions are likely to be made within the program anyways that edit the music in an effort to sound better by avoiding common “untowards” or “accidentals.” An example of this is given in Guzdial's work above in his choice to limit the students, initially, to a diatonic scale.

The computer is shifty as an instrument. Software written even four or five years ago likely won't run on the OS/Windowing system du jour. However, what will not change is that the computer is a number machine. Before hitting a DAC, the signals are streams of numbers-- numbers that can be added, subtracted, multiplied, etc... After the DAC, the composition is bona fide sound waves. For instance, periodic waves have long been recognized as being well modeled by the Fourier series, an infinite sum of sinusoids or complex phasors, and will likely be modeled similarly long into the future.

At the composition level, whether one is reading the notation of an 18^th century symphony or editing Hip-Hop in a typical sound editor, the representation is that of a two dimensional graph and in both cases the domain is time. The range, of course, differs with the former being that of pitch and the latter amplitude of the signal. Less frequently manipulated by the high level user are frequency domain representations like pitch histograms, or the mixture of frequency and time in the two dimensional spectrogram. These three dimensions-- amplitude, time and frequency-- recur again and again. An early exposure to these measurements should serve the digital musician well no matter how hardware or software evolves. And they can be introduced quite early without their complex symbolic explanations.

Fortunately, like the early LOGO turtle, each of these mathematical ideas have corresponding geometric representations. Even complex phasors are simply drawn as circles. Our design will use these basic geometric building blocks in the construction of sounds and songs. It's certainly not necessary to explain complex phasors to a four year old via imaginary numbers and power series. The association of sound with the periodicity of traveling around the perimeter of a circle may be an invaluable association when years later a student is finally let in on the big secret that sinusoids are only related to triangles by coincidence and that circles are where their real utility is realized.

Our design will try to utilize these geometric representations, circles and graphs, that will likely both transcend time and discipline.

Novel computer music controllers seem to provide a wild and creative outlet for many engineers. Designs have included merely modified analog instruments like the Squeezevox, a modified accordian used for modeling the human voice or the Jam-O-Drum discussed above. (Cook)(Blaine) Another interesting approach is transmogrifying everyday artifacts into digital instruments such as the the digital tapshoe or a café table whose flatware controls percussive sounds and tape loops (called the “Fillup Glass” by Perry Cook's group). (Cook) This design reinforces the adage that music should be part of everyday experience.

When designing interfaces for a younger audience, some engineers have attempted synergisms with common children toys, for example the teddy bear, which makes for one expensive rough rider indeed. More abstractly, less suggestive and of wider application are MIT Media Lab's Squeezables. Although not specifically designed for children, they share the teddy bear's properties of softness and a lack of sharp edges. The Squeezables are intended to be part of a multiplayer instrument activated by force sensitive pressure sensors inside the hand sized hacky sack like balls. To be used by children, the size would have to be significantly reduced, maybe beyond the point of the bag's ability to accommodate the sensor. The Squeezables could be a nice addition to a large installation piece or could find use as architectural fixtures.

The initial design will almost certainly be housed in a desktop computer. First, this allows for the most rapid development. Quickness is important if one is to take an iterative design and test, redesign and test approach. Second, the desktop already has massive market penetration, so we should be able to easily recruit testers who have the correct equipment. Third, children often see their parents using the computer and are regularly drawn into playing with the machine such as exploring the keyboard and looking for changes on the monitor.

In keeping with the theme of scaling the instrument, I propose experimenting with a simplified keyboard. A simplified keyboard can be constructed from a normal keyboard by overlaying a template that is held in place with tongues slotting into the grooves between keys. Keyboard bindings can be changed at the application level. Cheaply, a 101/104 key keyboard can be reduced to a ten or twelve key keyboard. Keys can be distinguished with color and shape. For instance, different colors might correspond to different timbres. One key, showing an icon of linked triangles could produce a sawtooth wave; staggered squares, square waves; etc...

When children arrive in kindergarten, they often have widely varying reading and writing skills. Some children, for instance those in a bilingual household, may arrive writing complete sentences in two (or more) languages while others, sadly, have barely seen the English alphabet. For sure as one attempts to extend a music programming tool to younger and younger children, it becomes less likely that they will be able to write.

Drawing is another story. Several programming language researchers and the MicroWorlds® versions of LOGO have made attempts to ease the entry into programming by enabling more free form drawing. (Sheehan, 2000) Sometimes this design decision is regarded, even by its inventors, as an unfortunate compromise. However, in our case, written language is not an option.

Psychologists and music teachers have long paired music listening with drawing. Jeanne Bamberger makes an attempt to classify types of musical understanding into two camps, motif versus metric, based on her interpretations of fourth grader drawings of their musical compositions. In her analysis, drawings of one group tend to depict pictorial themes in groups spread throughout the drawing. These groupings, claims Bamberger, correspond to motifs in the music. The metric camp's drawings appear to have some sort of invisible time axis in their drawing where one event proceeds another. Bamberger's extrapolation of these tendencies to two modes of thinking seems somewhat arbitrary and perhaps more telling of how she understands music than the musical cognition of the students. Why not attempt to classify the drawings into three camps, or four or more? Still, this remains a keen observation and the point that no single approach defines all the students reminds the educator of the importance of some flexibility.

Music teachers also turn this exercise around, using simple doodles to introduce the students to musical notation. Like onomatopoeia where a word's meaning is linked by its phonemes and the sound which the word represents, these “scribbles” often mimic physical qualities of the sound. A tightly drawn squiggle with frequent changes in direction and a dark heavy line might be used to represent sounds with lots of frequencies and a fast tempo. (Meyer-Denkmann, 1977)

Our proposal is to turn this act of drawing and music making around yet again. In other words, the initial design will attempt to create a drawing and image manipulation tool that can be used to compose music. One could introduce a set of symbols, like musical notation, for manipulation. The first approach suggested here is more gestural such as the line drawn on paper by the swing of an arm or the bowing of a violin. In an effort to allow the tool to grow with the musician as well as to compare different strategies, three levels of complexity could work either cooperatively or independently. Without yet giving specifics, which aren't necessarily worked out anyway, some proposed levels are:

Evaluation of computer music instruments is tricky. Suzuki had an advantage in that his goals are well defined, eg. play a piece Bach and get the notes and timing correct as it's written on the sheet music. Violin instruction also benefits from centuries of a stable instrument design. Certainly evaluation needs to be carried out with real end users. However, it could be easy to condemn the software for failure even if the error is in fact in its presentation. In both Suzuki's Talent-Education and LOGO, the teacher and/or parent play an important role in becoming acquainted with the tools. This current software is not intended as CAL seeking to replace adult mentors, be they school teachers or parents. Neither is the computer meant to replace traditional instruments and there's nothing stopping the two from playing together. Success could depend on commitment by parents and teachers.

Conversely, some novel instruments test over very short time frames, even a single afternoon. The children seem entertained and the programmers throw up their arms in victory. The expense of a computer based instrument, both in hardware and software, warrant that they prove themselves useful long enough to justify costs.

The short term goal should be that students compose interesting pieces of music, sonic sculpture and or sound effects. What is interesting is up to them and their developing cultural values. It's hoped that the students are entertained while working on their music and, finally, that students can create increasingly complex pieces (or even simple pieces representing more complex ideas) as they gain experience with the tool.

Longer term goals include facilitating an introduction to geometrical and mathematical ideas central to modeling sounds as well as aligning the relationship to the computer as a creative tool for entertainment and not merely a conduit for broadcast media.

Quantifying success of these goals could be accomplished by testing. However, if there's one thing that hasn't been stressed in this paper, it's testing. Testing as it often occurs in school will not be part of the evaluation. Testing such as that done by cognitive scientists or experimental psychologists may be more appropriate. The instrument might even prove useful as a vehicle for testing children's cognition, such as concepts of time and space. However, most papers rely primarily on observation and that will likely be my approach as well. Observation conducted over several months with a genuine commitment to a group of students such as a preschool group or kindergarten is likely to be ideal. There's probably little reason to maintain the children in the role of “other” and their comments and criticisms may provide the best clues for feature modification. In fact, the more features the children can modify themselves, the more successful the design. Every feature is up for scrutiny and open for modification.

Programmable computer musical instruments offer a wealth of opportunities. Some of these opportunities are musical in that the computer is an instrument that provides a greater degree of timbral control than possibly any other instrument. As an instrument the computer also allows sonic manipulation at a variety of levels. Synthesis, melodic composition and song structure are all easily modified. Thanks to memory persistence, a feature again found in almost no other instrument, the computer provides a nice platform for experimentation. The computer musician can iteratively correct a composition until they are happy with the results. Furthermore, by working directly with numeric and graphical representations of sound, students have an opportunity to better understand the phenomena's physics, an understanding certainly transferable to other musical instruments.

It would be wonderful to find that children enjoy to use their programs for their own enjoyment, or even better, with a group of their peers. But, it's unreasonable to expect to introduce complex ideas and have them be completely and instantly self-revealing. Kids can program in LOGO, but they don't spontaneously understand its syntax or understand its libraries. Start simple. As the children expand the scope of their projects, let them find the need for more advanced “syntax” and additional libraries. Indeed one of our hopes is that by working with their kids, the tools will instruct adults too-- since not everyone's parents happen to be Steve Reich or Donald Knuth.

Finally, we hope the design, only described here in terms of boundaries and goals, should meet several criteria. It should be flexible enough to grow with the child, ie. it should have a low floor but a high ceiling. It should present concepts in a manner that will outlive any one software implementation. And it should provide a sense of empowerment for the child-- a means to explore and consummate creative urges as well as providing an important step to mastering a ubiquitous artifact of contemporary life. The literature on computer interface design for preschool children is thin. More than anything, the design suggested here will, from the implementer's point of view, need to be easily modified. It's model too is expected to undergo substantial evolution as it's put to the test with a far more demanding crowd than hypothetical kids.

Aronoff, Frances Webber. Music and Young Children. Holt, Rinehart and Winston. Toronto. 1969.

Bamburger, Jeanne. The Mind behind the Musical Ear: How Children Develop Musical Intelligence. Harvard University Press, Cambridge, MA. 290pp. 1991

Blaine, Tina and Forlines, Clifton. Jam-O-World: Evolution of the Jam-O-World Multi-player Musical Controller into the Jam-O-Whirl Gaming Interface. Proc. of the 2002 Conf. on New Instruments for Musical Expression (NIME-02). Dublin, Ireland. 2002.

Blaine, Tina and Harger, Brenda B. Creating a Level Playing Field: Improvisational Play and Collaboration in Education. http://www.jamodrum.net/publications.html (accessed March 2004).

Cook, Perry. Principles for Designing Computer Music Controllers. Proc. of the 2001 Conf. on New Instruments for Musical Expression (NIME-01). 2001.

Drake, Carolyn and Penel, Amandine. Learning to Play Music: Rhythm and Timing. Ravue PArole. 9-10, pp 49-62. 1999.

Fischer, Hans C. and Besch, Lutz. The Life of Mozart. Macmillan, Toronto. 1969.

Gindling, Jim, Ioannidou, Andri, Loh, Jennifer, Lokkebo, Olav and Repenning, Alexander. LEGOsheets: A Rule-Based Programming, Simulation and Manipulation Environment for the LEGO Programmable Brick. IEEE (WHERE???). pp 172 – 179. 1995.

Grublin, David. The Child's Brain: Syllable from Sound [videorecording]. PBS Home Video. 2001.

Kusunoki, Fusako, Sugimoto, Masanori and Hashizume, Hiromichi. Symphony-Q: A Support System for Learning Music in Collaborative Learning. CSCL, Boulder, CO. 2002.

Malbrán, Silvia. The Development of Pulse Synchrony: An Exploratory Study of Three Year Old Children. Bulletin of the Council for Research in Music Education. 147, p109-115. Winter 2000/2001.

Meyer-Denkmann, Gertrude. Experiments in Sound: New Directions in Musical Education for Young Children. Universal Edition (London), London. 52pp. 1977.

Papert, Seymour. Mindstorms: Children, Computers and Powerful Ideas. Basic Books, Inc., NY. 230pp. 1980.

Sheehan, Robert. Lower Floor, Lower Ceiling: Easily Programming Turtle-Graphics. 2000 IEEE Intl. Symp. on Visual Languages. Seattle, WA. 2000.

Sheehy, Emma D. Children Discover Music and Dance. Teachers College Press, Columbia University. New York. 207pp. 1968.

Suzuki, Shinichi (translated by Waltraud Suzuki). Nurtured by Love: A New Approach to Education. Exposition Press, NY. 121pp. 1969.

Thornburg, David D. Beyond Turtle Graphics: Further Explorations of Logo. Addison-Wesley, Menlo Park, CA. 1986.

Weinberg, Gil and Gan, Seum-Lim. The Squeezables: Toward an Expressive and Interdependent Multi-player Musical Instrument. Computer Music Journal. 25:2, pp. 37-45. 2001

Ventura, David and Mase, Kenji. Duet Musical Companion: Improvisational Interfaces for Children. Proc. of the 2003 Conf. on New Interfaces for Musical Expression (NIME-03), Montreal, Canada. 2003.

1 I first programmed in the early 80s with BASIC, not LOGO. The most likely reason is that I lived in a community whose number one employer was IBM. LOGO enjoyed much of its early success on the first Apple computers, a rare sight in my school district.

2Some versions of LOGO have a “toot” function that takes frequency and duration as arguments and returns a tone via the sound card. (Thornburg)