One of my early interests in “the computer hobby,” as it was called in the 1970s, was music composition and synthesis. My homebrew 8008 system (October 1974) was immediately paired with a Walsh-function waveform generator and top-octave synthesizer, and as those early heady years passed I turned my attention often to music tools.
This article fell out of my desire to play the piano, and was inspired by the scarcity of polyphonic keyboard solutions (synths of the day only produced one note at a time). The circuit responds to any key’s change of state by transmitting the note value and an on/off bit to custom software in the host computer. The photo above shows the keyboard and interface with my Cromemco Z-2D, along with grumpy Katherine (photo by Douglas Fowley, 1978).
It was not long after the successful implementation of a hardware chromatic tone and envelope generator for my system that I began to wish for a method of playing music that would be somewhat less cumbersome than tune encoding with the ASCII keyboard. The ability to store a melody by defining all the notes and then allowing the computer to perform it was worthwhile, but without some technique for spontaneous interaction the system could hardly be called an instrument. A music keyboard was clearly called for.
I obtained a 61 note (5 octave) organ manual from the Kimball Organ Company for about $75, and considered the interface task in depth. Among the primary perfor- mance specifications for the design were:
- Polyphonic capability (not limited to single notes)
- Undiscernible response delay
- Very low processor overhead
The last of these requirements precluded the use of a software scan, which would have reduced hardware to its simplest form, and the need for polyphony called for either a bit map interface or a multiplexer with its own memory. To simplify the software as much as possible, the latter approach was selected.
A note should be inserted here about the touchy subject of software simplification. An argument frequently heard in the world of the microprocessor is that everything should be done with the program. If the processor in question is a dedicated controller, then by all means, all the work that can be reasonably handled by the program should be so assigned. However if the processor is at a higher level of system abstraction, it may be more efficient to delegate certain repetitive tasks either to hardware or to another microcomputer. There is no convenient generalization defining the tradeoff, but in cases where software complexity gets out of hand due to the presence of a fairly mundane but demanding task, some parallelism is usually called for. In the specific case of the music system, keyboard scanning and envelope generation can impose such a burden that the ability to simultaneously do complex real time data manipulation is lost.
Thus, optimization of the keyboard interface design was undertaken with the system considerations given uppermost priority, and the result is shown in figure 1. The 61 key switches of the manual are scanned completely every 5 ms, and with each step of the scan the position of the presently addressed key is compared with its last known position, which is stored in a 256 by 1 memory segment. If there is no difference, the scan proceeds, but if the key has changed state, the processor is interrupted with the binary value of the key in question along with a direction bit, and the corresponding memory location is changed to reflect the new status of the keyboard. The scan is suspended until the information is accepted by the computer. In this fashion, any combination of simultaneous key depressions and releases, at any practical speed, will result in a series of asynchronous “change of state” notices to the processor, which remains ignorant of interface function at all other times. The software maintains a list of keys currently depressed, and deals with them appropriately.
Construction, of course, should follow the usual procedures required of random logic interfacing. Cables between the board and the processor should be kept short, with intervening grounds between the handshake lines. The keyboard shown in photo 1 consists of simple normally-open contacts; their noise is filtered by the resistor-capacitor (RC) networks shown in the schematic. Any remaining bounce may be trimmed out by adjusting the clock rate, which is nominally 12.5 kHz. There is one light emitting diode (LED) on the board to provide a visual check of operation: “Key In Progress” is lit between the data available signal and the acknowledgment signal.
The circuit concept is directly expandable to accommodate many more inputs, with the memory and counter capable of addressing up to 256 points. This interface concept would be quite at home in many industrial control environments, as well as anywhere a large number of contact closures must be observed.
In the music system shown in photo 1, the keyboard interface has provided the much needed flexibility in the interactive utilization of the instrument. The “feel” is not unlike that of a standard electronic organ, and with the available processing horsepower taken into consideration, the unit is a composer’s delight. From teaching applications (where the human must correctly repeat “by ear” a computer generated phrase) to the support of creative effort, an efficiently integrated polyphonic keyboard is an essential link between artist and computer.
Comments and Footnotes
I received $162.50 for the piece.
Corrections: In the schematic, the chips labeled 7473 should be 7493 (counter). Also, the labeled pinouts of the 74151s should read, left-to-right: A B C (11 10 9) instead of: B A C (10 11 9).
This article was reprinted in the Byte Book of Computer Music (1980)
In the old file for this article, I discovered a note from Barry Klein, asking permission to use the design in his Electronic Music Circuits book.
A searchable PDF of this article may be downloaded.
Another one of my music-related pieces from the same epoch: Fractal Music Composition
You must log in to post a comment.