-- [Ivy]<Maxwell>Mockingbird>MockingbirdNotes.tioga
-- some notes on the forthcoming paper
-- Last edited by: John Maxwell on: September 9, 1982 12:36 pm

Goals:

* Help someone who wants to build a music editor
* Explain our design philosophy (subtly).

Historical vs. Clinical style:

A historical paper would guide the reader step by step through the process of designing Mockingbird. If this were well-written, it might be entertaining. However, Mike says that most people aren't interested in how things came into being. They want the salient facts. It is our job to distill out the important points, not the readers.

Outline:

HISTORY & CONTEXT:
Why us? What is PARC? etc.
GOALS & PHILOSOPHY:
Help the composer. A music notation editor! It can't be that hard.
DESCRIPTION:
Mockingbird from the user's point of view.
IMPLEMENTATION:
Data structure. motivated by free mixture of pianoroll and standard notation.
Designing user interfaces.
Flexibility.
Building a framework.
FEATURES: (Appendix)
Not worth mentioning in the main paper.
What we don't have implemented. No time.

Second paper:

If there is enough time and interest, I could write a separate paper explaining how the layout all works. It is surprising that this works at all. I bet a lot of people would be interested in it. I would discuss accidental placement, note-head placement, layout, justification, and pagination. This seems fairly straightforward.




IMPLEMENTATION
Goals: a data structure for playing, editing, and displaying. Includes measure lines, etc.

The data structure is very important
Violations of structure:
In SMN, beams, measures break around lines and pages. Can't anticipate all violations.
pianoroll: really unstructured.
Simple invariants:
logical synchronisity. (Some violations in graphical display)
compare with voice biased data structure.
preservation of order (exception: justification).
linear vs. two dimensional. Factor out paging information.
Correlations:
position on page
beats from beginnings
seconds of playing time.
THE METAPHOR
linear structure with syncs
data structure for the page.
Separate data structure for beams, ties, and chords
ties notes together
Consequences of data structure:
Ease of programming algorithms
Ease of display on the screen
Ease of playing.
(what about text? lyrics? markings on notes? octava didn't fit well)
Extensions.





GOALS & PHILOSOPHY
It was our goal to help the composer. Boy! Does he need help! While writers have advanced into the computer age with sophisticated word processors, composers and copyists are still back in the stone age with pen and ruler. The composer doesn't even have the equivalent of the writer's typewriter. It has been estimated that whereas a minute of speech takes six minutes to transcribe, a minute of music requires an entire hour to write down.
It's not that the plight of the composer has been callously ignored. (History of attempts? Full scale graphics, looseness of notation, speed requirements, etc.)
It was recognized early that the computer was the obvious solution. Severo wrote a paper in 19xx describing how a music notation editor might be implemented on a graphics terminal. Unfortunately, the software available was neither fast enough nor sophisticated enough for work to produce anything useful. Progress had to be postponed until high resolution graphics matured.

DESIGN OF THE DATA STRUCTURE
Music notation is fairly loose. When the notation available is insufficient, the composer will make up a new mark. Composers often stretch the existing notation to encompass new ideas. For example, not all measures add up to the given time signature. (more examples) Since our goal was to capture a wide range of music, we wanted a data structure that was flexible. This was very important since once chosen, data structures are hard to change.
(Description of sequential data structure. Explanation of "syncs". Indirection to the current position. How do voices fit in? Mixing of notes and events such as measure lines. Mixing pianorolls and complete scores. A separate sheet. Mapping back and forth. Most operations work on the data structure directly.)
After working with this form of music for a while, we observed a number of additional advantages that hadn't been obvious at first. One was that the data structure was tolerant of inconsistent data. Another was that new operations were easy to code. Finally, operations that interacted with the data structure were efficient. (Give examples to motivate the latter two.)