Skip to content
This repository has been archived by the owner on May 14, 2020. It is now read-only.

nx3 • 2. Display object tree(s)

Jonas Nyström edited this page Jan 13, 2014 · 12 revisions

The N-classes* hold the properties needed for describing the score entities, but this is just a "stupid raw material". For example, a NNote might might carry information about three NHeads representing a chord. But it can't perform any calculation about how these noteheads should be formatted, or what resulting rectangle space this formatting will need to occupy in the score layout to avoid collisions with other notation objects.

Because of this need for calculations and representation of the resulting information, the N*-tree is transformed into a display tree, a D-tree*.

Here is a side-by-side overview of the N*-tree and the D*-tree:

DHierearchy

Among the obvious differences is the fact that the D*-tree introduces the concept of systems (a row of bars that fits within the left and right page margins) and pages. The grouping of bars into systems, and systems into pages, are results of the calculations performed by the formatting and layout algorithms - they're not a result of decisions by the user. (This corresponds to how a word processor automatically handles words at line breaks, and adds/removes pages whenever needed.)

There are some other notable differences between the trees - starting from the bottom:

  • the DVoice has a array of IBeamGroup(s), each one representing a single DNotestave (for quarter and half notes) or a group of DNote(s) (beaming together eight and/or sixteenth notes according to the current beamingpattern).
  • the DPart has an array of DComplex. Each DComplex is referencing one or two DNotes (depending on wether the DPart has one or two DVoice(s)) for each occupied note value position in the DPart.
  • The DBar has array of DColumns, each one referencing one or many DComplexes.

TODO!

Do we need DHead class?