First let's consider the issue of speed. Clearly, 31.25 Kbaud will become too slow soon if it is not already. But how fast should it be?
One idea is that it could be any speed. Some UARTs are able to detect the speed of transmission and adapt automatically. This way, speed could grow as needed and as the technology was able to keep up. This argument is curiously reminiscent of arguments to the same effect made by the manufacturers of computer terminals in years past. In the beginning, everyone said, "terminal networks do not have to run any faster than a fast typist can type." So the initial baud rates ranged from 11 to 15 characters per second, comfortably beyond this range and comfortably within prevailing technological limits. However, then came word processors. As text editing programs became smarter at getting the computer to do more work with fewer keystrokes, users started wishing they could see the re sults more quickly too. The baud rates went up. And they are still climbing. Rates of 9600 baud are now common, with much higher rates not far behind. What drove the increase was not faster typing, but the greater bandwidth required by powerful text and graphics editors to drive the display. To my mind this neatly parallels the situation with MIDI: even if we assume that the current rate is sufficient for performance capture (the analog of typing speed), it will certainly not long be sufficient for computer control of synthesizers (the analogy to driving the display)as users become smarter at getting more music from less performance. The real result of this laissez faire attitude in the development of computer terminal networking was that it suffered decades of accretions and kludges as it grew, resulting in a kind of anti-standard. Is this what we want for music?
An interesting alternative was proposed spontaneously on the floor of the MIDISOFT-84 conference, alluded to above, by Guruprem Khalsa. He invited the attendees to consider estimating the bandwidth requirements that will be needed at some point in the future, then identifying some technology which would allow us to achieve that bandwidth now. This would resolve the issue of throughput in a way that would satisfy everyone for that period of time, freeing us to focus on the task of using that bandwidth instead of being drained by the subtask of retrofitting as data rates evolved. Gordon Moore, one of the founders and current chief executive officer of Intel Corp., presented a formulation that has since become known as "Moore's law" as a way to estimate growth in the electronics industry. It states that for year y,
, that is, complexity will double every year from 1960, which was the year he proposed it. If we were to update the year and apply that to MIDI, we might have 
In 12 years the bandwidth requirement would be on the order of 12 Mbytes/sec. This is a comfortable rate using current networking technology. It can be objected that the technology to run at these rates will be more expensive and for the current purposes of MIDI would not be warranted. Cost is a powerful argument when considering the economies of largescale manufacturing. But is it ultimately economical to live with a serious flaw that weakens the standard?Another attendee at the MIDISOFT-84 convention, Charles Goldfarb, questioned the nature of MIDI coding. To explain his position, we need another lesson from the history of word processing and terminal technology. In the beginning of computer terminal technology, the ASCII code (American Standard Code for Information Exchange) was developed with Teletype technology in mind. Some codes were reserved for control of (then state of the art) Teletype machines, such as line feeds, form feeds, carriage motion, and simple communications protocols. It quickly became apparent that document preparation could be done more easily with a macro language embedded in the text that condensed the complicated control codes required to do anything useful into simple mnemonics. Eventually it was noticed that this approach was not device-independent since the mnemonics themselves still referred to device specific actions. Transferring the document to a different printing system required substantial alteration of the document. It became clear that what was really needed was a way to describe page layout in the terms of the formal structure of the document, rather than in terms of the actual structure of the printer, leaving the job of achieving this structure for any given printer to a document compiler. This resulted in the development of high-level document compiler programs such as troff and
. Standards for representing document formatting, such as SGML, are emerging to consolidate this area. Goldfarb suggests that we can ask the same thing about MIDI: is its collection of codes targeting the wrong thing?While this analogy between MIDI and terminal technology is suggestive, it is not complete. By design, MIDI codes represent the performed structure of music. This is a higher level than coding for synthesizer parameters, and a lower level than representing the formal structure of the music. MIDI is to a small degree already device-independent, since the encoded performance does not carry with it a specific meaning as to the sound the resulting synthesizer is to make. It is perfectly adequate for MIDI synthesizers to communicate MIDI codes; a higher level representation is not needed here.
However, the picture changes when we consider how we should represent music made on MIDI synthesizers in a computer memory. Here, we will indeed make the same mistake with MIDI that was made for document preparation unless we develop representations which can express the formal structure of music. A good example of a hierarchical data structure for music can be found in the work of William Buxton (1980). To this end, Goldfarb has recently broached the subject of developing a standard for music databases through ANSI. A meeting was held in Palo Alto in May of 1985 to the end of establishing an ANSI study group to consider this problem.
A problem with MIDI is that it resists attempts to abstract it further. Speaking at a panel on MIDI during the 1984 ICMC in Paris, Buxton pointed out the confusion in MIDI between a network and a data structure. For him, basic to fixing MIDI is separating the structure of the information being communicated from the structure of the network. As it stands, they are inextricably linked, which means that the one can't be changed without the other.