ï~~This design had to take into consideration all the little tasks that the
program would have to accomplish in a day's work. The first job was to take input
data, in a variety of forms, and transform it into a common representation. Input
could come from three different sources: DARMS code, MIDI strings, and a screen
editor. Then this data had to be "fleshed out"; that is, in each case, there would be
insufficient data to generate printed music. This is more the case with MIDI input,
where one is presented only with the note-on, note-off timings from the synthesizer;
but even in the case of DARMS code, such things as articulation and accidental
placement, stem direction and length, and beam slant are not usually determined by
the input. Next, horizontal justification, which is accomplished using the same
algorithms and adjustment factors as used by plate engravers, still is a little
complicated, since notes must be treated as single, distinct objects at the
algorithmic level, yet later on must be examined from the point of view of their
constituent components, such as flags, accidentals, dots, and so forth, at the
adjustment level. These spatial relations had to be preserved in such a way that the
movement of a note and all of its constituents could be accomplished simultaneously
or separately, as the need arose. Then, the structure had to allow page formatting
such that the placement of the staff did not alter the relations of the characters
within it; further, the positions of the various elements in the staff had to be
quickly accessible, for purposes of collision-avoidance. At the same time, when other
sorts of operations were performed on the data, such as transposition or rhythmic
alteration, the strictly musical characteristics of things like note position,
accidentals, durations, and ties had to be immediately available. Finally, the user
had to have the capability of editing any aspect of the graphic features of the page,
whether or not the end result made any sense to the program.
Such a structure, it turned out, was a pretty tall order.
Why DARMS?
I began work on the data structure in 1981, while at the Institute for
Sonology, then in Utrecht. After having created a fairly complete model for storing
notes and their elements, I met with Leigh Landy of the University of Amsterdam, who
had participated in the design of DARMS. He pointed out some of the more elegant
solutions offered by DARMS to problems I had been wrestling with, and I agreed to
take a serious look at the language. Although I had known of DARMS for some years, I
had never had a discussion about it with anyone so intimately involved with it; thus,
I had failed to appreciate much of its potential. After a fairly careful perusal,
during which it became clear that DARMS could represent most of what I wanted it to,
I yielded to my natural laziness and decided to use the ready-made article,
abandoning my home-brew system.
The decision to use DARMS as an input medium was made on the basis of its
flexibility, specificity and, with the number of defaults available, its speed of
entry. However, another aspect of this venerable antique (now over 20 years old) came
to light with use. It turns out that, in order to have so many abbreviations and so
much flexibility, an input language must have also a deep and complex underlying
structure. This structure is what the defaults, abbreviations, and flexibilities are
hung on. To be an accurate representation of a page of music, the underlying
structure must be, in an unambiguous way, a parallel representation of the underlying
structure of the printed page; thus, it must represent the music itself to exactly
312
1987 ICMC Proceedings
0
