Scorelib consists of two main sets of classes, one to manage individual SCORE items, and another to manage collections of items. The diagram on the left shows the relations between these classes: one set for dealing with a single SCORE item (colored light blue), and the other set that manages multiple items (colored purple). The three main classes to use directly are ScoreItem, ScorePage, and ScorePageSet, while the others are used to deal with lower-level maintenance and abstraction. The ScorePageSet class is used to organize multiple pages; the ScorePage class is used to manage a single page; and ScoreItem manages a single SCORE item.
For individual items, the primary class is ScoreItem which inherits either ScoreItemEdit or ScoreItemBase, depending on whether or not you want to keep track of the edit history of the parameters. ScoreItemBase and ScoreItemEdit are not typically used directly, and instead hold low-level maintenance of the parameters.
The ScoreItemEdit class is used to keep track of changes to the parameters to facilitate undo/redo for interactive applications. The ScoreItem class may inherit from either ScoreItemEdit or directly from ScoreItemBase. This is controlled at compile time by defining the SCOREITEMEDIT preprocessor variable. The Scorelib makefile that creates the compiles code library compiles all code twice: once with ScoreItem inheriting from ScoreItemEdit and a second time with ScoreItem inheriting from ScoreItemBase. The library files lib/scoreeditlib.a and lib/scorelib.a are created respectively for the two inheritance cases, and you can link program to the one containing the desired behavior. Light-weight and batch-processing programs should link to scorelib.a, and interactive programs should link to scorelibedit.a.
The ScorePageBase class contains numerous helper classes used to coordinate relationships between individual ScoreItems contained on the page. These classes are not accessed directly, but are used to facilitate efficient higher-level manipulation of the items. The main helper classes for ScorePageBase are:
- DatabaseChord: keeps track of all notes sharing a common stem.
- DatabaseBeam: keeps track of beams and notes attached to the beam.
- DatabaseP3: keeps track of items by horizontal position on each system of a page.
- InfoPrint: stores page printing parameters and also calculates distances on the page in physical units and pixels.
- InfoStaff: used information about staves on the page, such as how they are grouped into systems.
- InfoAnalysis: is used to keep track of analysis dependencies. For example, analysis stored in DatabaseP3 classes first require systems to be identified. This information is used to automatically calculate information needed for higher-level groupings.
The ScorePageSet class consists of two organizing hierarchies. The primary ones is by page, and a secondary one is by segment. Segments consist of groups of systems which may span multiple pages, and may only include a subset of systems on a particular page. Typically segments are used to define movements in a work, and they contain a fixed number of instrumental parts.
A schematic of the page organization within ScorePageSet is shown on the right. Pages are two-dimensional arrays of ScorePage objects. Each printed page is held in a ScorePageOverlay object which consists of a list of ScorePage objects. Each ScorePage in a ScorePageOverlay object is intended to be displayed on the same page. Use of the overlay system is dependent on the implementation. It can be used to store analytic markup, variants, ossia, older versions of the page, etc.
The dual hierarchy of the ScorePageSet can be seen in the following figure. A musical score will be stored as printable pages within an array of ScorePageOverlay objects. A secondary array of ScoreSegment objects marks the begin/end of musical segments on the pages. Segments may represent full works, movements of works, or subsections of movements. In the following figure, the page segmentations are from page 0 to the middle of page 2 for the first segment, from the middle of page 2 to the end of page 3 for the second segment, and page 4 for the third segment.
The ScoreSegment class keeps track of parts and how they are assigned to staves on ScorePages. A ScoreSegment object contains a list of SegmentPart objects. SegmentParts each contain a list of AddressSystem which locate the staves for each part in the score. The AddressSystem two dimensional list of system addresses. When a part contains more than one staff, additional system addresses will be given on a row in the AddressSystem list.
The ScorePageSet class contains a list of ScoreSegments that in turn consists of a list of SegmentParts, which is a list of the instrumental parts in the segment. Each SegmentPart contains a list of AddressSystem objects that keep track of the staff assignment for each system for the instrument. The schematic below shows the relationship between these classes: