Define the problem
	A) layout of a score given the logical structure of the music
	B) an amanuensis
	C) horizontal dimension only - - staff, stem direction, and beams determined by user
	D) user control over line breaks
	E) sectional justification 
Define the data structure
	A) the score
		1) a linear sequence of events
		2) more than one note per event
		3) virtual "voices"
		4) each note knows what staff it falls on
		5) a note's position is determined by the event it belongs to plus a delta
	B) the sheet
		1) switching staff types
		2) switching clefs
		3) switching keys
		4) mapping from one dimension to two
Overview of the algorithm
	A) re-sync the voices
	B) scrunch the score down as tight as the user specifies
		1) within each event;
			a) determine how each chord should be layed out
			b) determine how the notes and chords should be layed out
			c) determine how the accidentals should be layed out
			d) determine how the dots should be layed out
		2) between events:
			a) determine the minimum distance based on graphical considerations
			b) determine the minimum distance based on voicing considerations
				0) as specified by user
				1) within a single voice
				2) between metrically aligned voices
				3) between non-metrically aligned voices
	C) put the maximum number of measures on each line and stretch
		1) "hide" unnecessary key and clef switches
		2) determine the length of the next line
		3) decide the minimum number of measures (modulo user constraints and sheet switching)
		4) what if minimum number is zero? (put on two lines)
		5) stretch out the measures to fit
	D) decide how many lines to put on each page

	This paper describes an algorithm to specify the layout of a musical score.  By "layout" we mean the placement of elements of music notation on a two dimensional grid in accordance with the conventions established for music over the last few centuries.  The algorithm determines the horizontal spacing between notes, makes sure that each line has an integral number of measures, and decides how many lines should appear on each page of the resulting score.  The user is responsible for specifying how many staffs should be on each line, which staff each note should appear on, which way the stem of each note should go, how high each beam should be placed, and what the tilt should be for each beam.  The user may optionally specify where he would like lines to break and approximately what density he wants. 
	In 1980 Severo Ornstein and I set out to write Mockingbird, a hightly interactive music notation editor designed to aid the composer capture and edit his musical ideas.  Our main focus was on producing a useful tool.  Because of this, we deferred working on the more intriguing problems of music recognition and automatic score layout until the basic fascilities had been completed.  Our philosophy was that no automatic program would ever be 100% successful.  Consequently, there would have to be some user facilities to correct errors that the program produced.  And as long as we had to have facilities to correct errors, we might as well develop a full-blown set of facilities that allowed the user to produce any sort of score he wanted.
	Suppose we call a "score" the representation for a piece of music that appears on a sheet of paper; notes, staffs, beams, and all.  Mockingbird divides a score into two data structures: a linear structure that contains all of the musical elements of a score, and a two dimensional structure that represents the sheet of paper.