Skip Navigation.
Section 0

The Apple II/Rhodes Chroma Interface

By Bob Moog

The following article is being reprinted with permission from Keyboard Magazine, September 1982. Thanks to Christopher Now for providing a copy of the article and the image scan.

My last few columns have been leading up to some simple programs to control several parameters of a monophonic or modular synthesizer simultaneously with a personal computer like the Apple II. We're working on these programs right now, and I should be ready to present them to you in a column or two toward the end of the year. In this and my next couple of columns we will have a look at the features and the limitations of some related synthesizer-computer systems that are already 'up and running.'

Several computer-based synthesizer systems were on display at the June NAMM show in Atlanta this year. But the only one that I heard actually produce a complete piece of music was the Rhodes Chroma, connected to a standard Apple II through an interface card and software package designed and supplied by the Rhodes engineering department. The Chroma-Apple system 'played' a Sousa march in which each of the voices was independently programmed. The complete system, which represents an investment of ten or so kilobucks, has professional-level sound quality and offers many programming, composing, and editing features that are currently available only on computer music systems costing two to five times as much. Although this system is in an early stage of evolution, it appeared to me to be as useful to a typical working musician as any other Apple-based system that I've seen.

The Chroma-Apple system playing Sousa at NAMM last June [1982].

I had an opportunity to talk to Philip Dodds about Rhodes' program to develop computer interfaces for the Chroma. Phil was ARP's director of engineering for a good many years. When CBS took over the Chroma project from ARP, Phil and his crew were set up as the Fender/Rogers/Rhodes research and development facility for synthesizers and related instruments. Many of you have seen Phil in the movies. He played the ARP Player in Close Encounters of the Third Kind.

Phil explained that the Chroma was developed from the start with computer interfacing in mind: "We call the Chroma a Music Terminal, because all of the information put into it by the musician-user is accessible to the host computer, but the instrument has enough intelligence of its own to operate in a variety of modes without the assistance of an external controller. The digital portion of the Chroma (and that includes just about everything except the sound chains themselves) is organized around a single buss, through which all commands to set up the voices, and all performance information from the keyboard and other control interfaces, flows. This buss is directly accessible through a simple interface circuit, which means that anything a performer does can be conveyed to the computer, and any of the Chroma's parameters of any of the voices are directly accessible by the computer."

The Chroma's control interfaces (player controls) include a keyboard that is both velocity- and pressure-sensitive, two panel levers which may be assigned to bend any of the voice parameters, the main 'parameter knob' [slider] on the front panel, two footpedals, and two footswitches. The outputs from all of these devices appear (in sequence) on the Chroma interface buss, and are accessible to the computer. Rhodes has prepared some basic software to implement a polyphonic sequencer. Under this program, all control interface outputs are recorded in real time and stored in the computer's memory. Thus, when the sequence is played back, it is possible for all of the player's moves to be replicated. This means not only key depressions but key velocity, footswitch closures, and key pressure, panel lever, and footpedal variations.

In terms of amount of information transferred and stored, that is, number of bytes per musical event, here are the implications of this capability: A switch closure can be represented by one or two bytes -- the address of the switch. The time of the switch closure can be represented by two to four bytes. Thus, a sequencer that records a typical performance (one or two dozen notes per second) on a non-touch-sensitive keyboard must handle no more than a hundred or so bytes per second. The rate of information flow from a velocity-sensitive keyboard is not much more, because a key's velocity is measured once when the key goes down, and therefore adds only one more byte per note to the information flow. Similarly, the actuation of footswitches adds very little to the information flow -- a byte or two each time a switch is depressed. A typical Apple equipped with 48K of semi-conductor memory can easily handle this much information flow. Under these conditions, several minutes of keyboard performance can be read into the computer before the memory fills up and a 'dump' to a disk or other mass storage medium becomes necessary.

When continuously variable control signals, like those from panel levers, footpedals, and the pressure outputs of the keys, are recorded, the situation becomes quite different. In recording continuously-variable controls, you must record a control signal many times a second, whenever it is changing. For instance, suppose one key is depressed and you're varying the pressure on that key to shape a note's brightness. If we assume that one byte will specify the pressure at an instant of time (and even that may not be enough), and that the sampled pressure signal must be updated at least ten or twenty times per second if we are to avoid hearing steps in the brightness change, then we have increased the information flow to something between 25 and 50 bytes per second per key. A rapidly moving keyboard performance, with pedals and panel levers in use, could produce an information flow of as high as 1,000 bytes per second, and could load up the computer's memory in well under a minute.

"When it comes to recording and processing digital representations of continuously varying control voltages," Phil pointed out, "the Apple itself is the limiting factor. What we need is 'multitasking capability,' the ability to transfer data from semiconductor memory (RAM) to disk while other data is pouring into or out of the computer, or is being processed. There are accessory cards for the Apple that can do that, but we do not have the necessary software yet. We are also looking to more powerful personal computers, like the new IBM or the DEC personal computers, that are capable of multitasking without the addition of extra accessory hardware."

More about Rhodes' approach to computer interfacing as well as a discussion of the work done by other synthesizer manufacturers, in my next column.

Moog's October 1982 column briefly reviews some of the information in the preceding article, talks about other manfacturers' efforts in this area, and mentions Sequential Circuits President Dave Smith's initial ideas for what soon became the MIDI standard.