NIFF 6a.2 Notation Interchange File Format 8/20/98 Contents Acknowledgements Chapter 1 - General Discussion Introduction Bibliography Logical Structures Physical Structures Measurement Units and Coordinate System Timing Representation Chunks , Lists , Forms and Tags The Setup Section Miscellaneous Chapter 2 - Symbol Relationships Chapter 3 - Elements and Values Lists Chunks Setup Section Chunks Data Section Chunks Header Chunks Symbol Chunks Tags Appendix A - C Header File (this is a separate file). Acknowledgements The NIFF project began in February 1994 with a meeting between technical people representing three major music notation programs and three music scanning programs. The group's goal was to define a new standard format for exchange of music notation data, which everyone agreed was long overdue in the industry. With the publication of this document, the goal is now on the verge of fruition. The people at the first meeting included Lowell Levinger, Steve Keller and Mike Ost of Passport Designs, publisher of Encore; Leland Smith of San Andreas Press, publisher of Score; Randy Stokes of Coda Music Technology, publisher of Finale; Chris Newell and Wladek Homenda of Musitek, publisher of MidiScan; Nick Carter, author of SightReader, an unpublished music scanning program licensed to Coda, and myself, author of NoteScan, which is licensed to and published by TAP Music Systems/MusicWare. Passport and Coda agreed to provide funding, Musitek to supply a PC for the project and San Andreas Press a copy of Score for reference. We agreed that I would research and develop the format as Technical Coordinator, and Chris Newell of Musitek would provide support as Administrative Coordinator. A contract was signed to this effect in June of 1994. I got approval from the original participants to widen the scope of the project by asking for input from other individuals experienced in music notation software. The list of advisors has continued to grow over time, so that by now contributions to the design of the format have been made by many people representing a broad spectrum of interests including music software companies, music publishers, composers, engravers, and researchers in computer science and musicology. In January of 1995 Coda decided to withdraw from the process. Shortly thereafter, Mark of the Unicorn, Twelve Tone Systems, Opcode Systems, and TAP Music Systems/MusicWare agreed to replace Coda as financial sponsors. I'd like to thank Dave Kusek of Passport Designs, Robert Nathaniel of Mark of the Unicorn, Greg Henderschott of Twelve Tone systems, Chris Halaby of Opcode Systems, and Roger McRae of TAP Music Systems/MusicWare for their financial contributions. Alan Belkin, Professor of Music at the University of Montreal, has provided extremely useful technical and musical advice throughout the project; he is known as Special Advisor to the project. Dave Abrahams of Mark of the Unicorn has given very generously of his time and has made many essential contibutions to the format's design. Other major contributors have included all of the individuals at the original project launch meeting, and Norman Reid (whose experience with DARMS has proven invaluable), Mark Walsen (especially helpful on symbol relationships), Severo Ornstein, Don Byrd, Phil Sours of Twelve Tone Systems, Tom Hall of A-R Editions (who provided me with a DARMS manual), Eleanor Selfridge Field of the Center for Computer Assisted Research in the Humanities (CCARH), Don Williams and Dave Scoggin of Opcode Systems, Raymond Bily of Midisoft, Bill Holab of G. Schirmer (who provided some complex published scores which have been useful as a reference), Daniel Dorff of Theodore Presser, John Cerullo and Tom Johns of Hal Leonard Corporation, John Forbes of Boosey & Hawkes, Robert Schuneman of E.C. Schirmer, Bill McCann of Dancing Dots Braille Music Technology, and Steven Newcomb of Techno-Teacher (who has cooperated in planning a linkage between NIFF and SMDL, the upcoming ANSI standard music description language). A number of other individuals also contributed useful ideas. Richard Karpen of the University of Washington Center for Advanced Research Technology in the Arts and Humanities (CARTAH) has provided an Internet ftp site to make the specification, technical discussions and test files available electronically. Thanks are due to Mike Brockman of TAP Music Systems/MusicWare for putting me in touch with him. In addition to the sources listed in the Bibliography, I relied heavily on the reference manuals for San Andreas Press' Score, Mark of the Unicorn's Mosaic, TAP Music Systems' Nightingale and Coda's Finale, while designing NIFF's features. In particular, the Chord Symbols chunk was taken almost directly from Mosaic, and the Guitar Grid and Harp Pedal Symbols almost directly from Score. I would also like to give special thanks to Chris Newell, who has been an amiable and useful colleague on this project. Cindy Grande, Grande Software, Inc. NIFF Technical Coordinator August 31, 1995 Chapter 1 - General Discussion Introduction NIFF is a file format designed to allow the interchange of music notation data between and among music notation editing and publishing programs and music scanning programs. Its design is a result of combined input from many commercial music software developers, music publishers, and experienced music software users. Background. The lack of an accepted standard format for music notation has for years been a source of great frustration for computer musicians, engravers and publishers. Numerous attempts have been made in the past to create a standard format. The effort resulting in NIFF is different for several reasons: 1) Many of the major forces in the commercial music software industry - and several of the largest music publishers - have shown a remarkable willingness to cooperate in the design of NIFF. 2) Commercial music scanning programs are a recent addition to the software market. They require a common language with notation programs to avoid the enormous loss of detail that occurs when translating through MIDI files. Music notation is a complex language. Like a natural language, it is always changing, it is at times ambiguous and/or redundant, and can be used in many different ways by different people for different purposes. Because of these qualities, it is impossible to create a perfect computer model for music notation. The original sponsors of the NIFF project recognized these limitations, and set a more reasonable goal: to create a practical, useable format in a short time frame. NIFF project participants have agreed that a solid, workable solution, even if it excludes some unusual situations, is preferable to no solution. The NIFF planners considered adopting as the standard an existing published format such as DARMS or Score, but decided against it. The designers of DARMS had somewhat different goals from NIFF's. Score, although extremely comprehensive and appropriate in scope, was somewhat unwieldy due to its age and development history. Another possibility considered was the ISO/ANSI standard HyTime and its associated music standard known as SMDL, but SMDL was not yet complete at the time the NIFF project got underway. [As of the date of publication of this specification, a European Community music library project currently underway will result in a bridge between SMDL and NIFF.] A general strategy was chosen as follows: model NIFF's feature set on Score's, organize the data as systematically as possible, and use the most current file format conventions. During the development of the format, additional more specific goals have been established. Some useful functional features of DARMS have been incorporated as well. The NIFF structure can accommodate full music publishing systems, simpler music display systems, logical definition languages like DARMS, and music scanning programs. Even sequencers can be writers of NIFF files, since the most rudimentary NIFF file has little more notation information than a MIDI file. NIFF allows representation of the most common situations occurring in conventional music notation, while making provision for software developers to define their own extensions to handle the more unusual situations. It allows inclusion of Encapsulated PostScript (EPS) files and fonts to allow interchange of features not otherwise defined in the format. Extensibility, Flexibility, and Compactness Extensibility is an important goal. Even the complete NIFF specification cannot be an exhaustive catalog of music notation features. A high priority has thus been given to structuring the data in ways that minimize the pain of future enhancements. NIFF is also designed be flexible, to accommodate the differences between the programs and users it will serve. An effort has been made to keep files as compact as possible, since NIFF files will likely be transmitted electronically over low-bandwidth lines. Logical, Graphical and Performance (MIDI) Data Researchers Severo Ornstein and John Maxwell found that the computer representation of music notation has three distinct components only partially related to each other: logical, graphical, and performance (MIDI) information[5]. NIFF designers have found it useful to further subdivide the graphical information into page layout and non-page layout information. The only information that NIFF absolutely requires is the logical kind. NIFF is structured as a page-ordered format, but can accomodate writing programs without access to page layout information and systems like DARMS, which allows even non- page-layout graphical information such as stem direction to be absent. When complete graphical information is present in a NIFF file, the reading program can decide between 1) observing the page layout and other positioning information, 2) ignoring graphical information in favor of its own defaults, or 3) some intelligent combination. When any graphical information is absent from a NIFF file, the reading program is expected to provide its own intelligent defaults. It is recommended that the user of the NIFF writing and reading programs be given as much control as possible. The user should decide the level of detail stored in the file by the writing program, and the degree of freedom used in interpretation by the reading program. NIFF allows thorough linking of MIDI data and notation. Illegal Notation Elements There is no such thing as an "illegal notation element" in NIFF. That is, there is no requirement for the data in a NIFF file to "make sense." A reading program should expect occasionally to find data that is not compatible with its own range of acceptable usage. When an unknown or unacceptable element is encountered, the program should either ignore it or do the best it can with it, in order to create a valid file in its own internal format. RIFF The NIFF format follows the design rules of the Resource Interchange File Format (RIFF) structure from Microsoft. In RIFF files, related data items are grouped into "chunks", and related chunks can be combined into "lists." Chunks and lists include their own length within their structure. RIFF files are designed to be upwardly compatible, that is, amenable to future enhancements. A RIFF file and each of its lists and chunks can be variable in length. A logical definition is required for each RIFF format, to identify which elements are required or optional at each level and the order in which the elements may appear In NIFF, an additional type of data item known as a "tag" has been defined as an integral part of the format. Tags are used for adding optional elements to the required part of a chunk. Although not part of the standard RIFF design, tags can be described within RIFF's logical definition language. RIFF is a binary format, but it is possible to describe a complete RIFF file with an ASCII representation. A structured notation system for representing RIFF files in ASCII is presented in the Microsoft Windows Multimedia Programmer's Reference[4]. More details on the format of chunks, lists and tags is presented later in Chapter 1. Detailed rules on reading and writing RIFF files are published in the RIFF documentation[4]. Platform Independence The same NIFF format definition can be used by software running on any type of machine. RIFF rules allow for separate formats for Intel (IBM compatible) and Motorola (Macintosh) machines, with different integer byte orders for the two machines. However, to make file translations across platforms easier for users, only the Motorola format will be used for NIFF, regardless of the machine used. The byte order is always from most significant to least significant, for both 16-bit and 32-bit integers, on all machines. The first 4 bytes of a RIFF file indicate the byte ordering. 'R' 'I' 'F' 'X' means Motorola byte ordering, so all NIFF files will begin with these four characters. NIFF programs might therefore be required to translate integers from and to the correct byte order for their machine before reading and writing NIFF files. More on Flexibility NIFF is highly structured at its highest levels according to the rules of RIFF. However, writing programs have extremely wide latitude in their choice of what to include in any particular file, and how exactly to organize the data. A minimal NIFF file has little more information than a MIDI file. On the other end of the spectrum, an immense amount of detail can be recorded about the graphical arrangement of complex orchestral scores with custom shapes. NIFF software developers will need to be creative when facing this range of possibilities. As with the TIFF (Tagged Image File Format) format, there will probably not be any two programs that make use of NIFF in exactly the same way. Bibliography 1. Read, Gardner, "Music Notation - A Manual of Modern Practice," Second Edition, New York: Taplinger Publishing Company, 1969 (1979). 2. Ross, Ted, "The Art of Music Engraving and Processing," Miami Beach: Hansen Books, 1970. 3. Byrd, Donald, "Music Notation by Computer" , PhD dissertation , Indiana University, 1984. Available from UMI, 300 N. Zeeb Road, Ann Arbor, MI 48106. Telephone 1-800-521-3042. Order number DA8506091. 4. Microsoft Press, "Microsoft Windows Multimedia Programmer's Reference," Redmond, WA, 1991. Telephone: 1-800-MSPRESS, ISBN#1-55615-389-9. Contains the full description of Microsoft's RIFF standard. 5. Ornstein, Severo M. and Maxwell, John Turner Maxwell III, "Mockingbird: A Composer's Amanuensis," Xerox Palo Alto Research Center, 3333 Coyote Hill Road, Palo Alto, CA, 94304. CSL-83-2. January, 1983. [P83-00002]. 6. Apel, Willi and Daniel, Ralph, "The Harvard Brief Dictionary of Music", New York: Amsco Music Publishing Company, 1960. 7. Heussenstamm, George, "The Norton Manual of Music Notation," New York: The Norton Company. 8. Roemer, Clinton, "The Art of Music Copying", Sherman Oaks, CA: Roerick Music Co, 1985. (out of print) 9. Vinci, Albert C., "Fundamentals of Traditional Music Notation," Kent State University Press, 1989. 10. G. Schirmer, Inc. "The G. Schirmer Manual of Style and Usage," New York: The G. Schirmer Publications Department, 1990. Logical Structures There are some terms commonly found in discussions of music notation which most musicians intuitively understand. This section defines the specific usage of these terms in NIFF. ¥ Score. Each NIFF file contains one score. A score could hold anything from a one bar music example, to a song, a piano sonata movement, or a movement of a symphony in full score. A work in more than one movement would normally be stored with each movement in its own NIFF file. ¥ Part. A stream of musical events and associated symbols, text and graphics which can be extracted and printed on a part score for an individual performer. A part may contain music to be played sequentially on different related instruments by the same performer (e.g. oboe/English horn). The maximum number of staves used for display is defined for each part. ¥ Voice. A rhythmically independent stream of musical events within a part, and its associated symbols, text and graphics. Voices can appear and disappear at any time within a part. ¥ System. The visual framework on a page, where symbols representing simultaneous events in the various parts are more or less vertically aligned. All parts of the score are logically present in every system although some may be "hidden." ¥ Staff. An arrangement of parallel horizontal lines serving as the locale for displaying musical symbols. It is a sort of vessel within a system into which musical symbols can be "poured." Displayed on it are music symbols, text and graphics belonging to one or more parts. ¥ Time-Slice. The mechanism by which a specific point in time is identified in the score. Musical symbols representing simultaneous events.are logically grouped within the same time-slice. The music symbols in a NIFF file are physically grouped by page and staff, so symbols belonging to a common logical time-slice may be physically separated in the file. Horizontal placement can optionally be supplied for a time-slice. There are two types of time-slice: measure start and event. The measure-start time-slice identifies the start time of a measure with respect to the start of the score. The event time-slice identifes the start time of an event such as a note or rest with respect to the start of the measure. Examples. The NIFF logical structures were designed to handle situations like the following: Example 1. In a Mahler symphony score there are three trumpet parts. In one system the trumpets appear on three separate staves (labelled "Tpt. 1", "Tpt. 2", Tpt. 3"), because they are playing a complex canon. In another system they appear all together on one staff, called "Tpts. 1,2,3," because they are playing homophonic music. They are written as chords, with 3 notes on one stem. In the logical view, the notes played by the trumpets belong to three separate parts. In the physical view of the canonic system, each trumpet part is assigned its own staff. Each staff is labelled with its own name. In the physical view of the homophonic system, the three parts are combined together onto a single staff, labelled "Tpts. 1, 2, 3." The simultaneous notes of each chord played by the three trumpet parts appear together with a single stem within each time-slice. Each note indicates the part to which it belongs. Example 2. Consider a score with divisi writing where the first violin part is temporarily divided into groups. The first violin part is split onto two separate staves in one system, and three separate staves in another system. There are a variety of ways this could be represented in NIFF. The choice depends on the desired result when the parts are to be extracted and printed for individual players: a) If the first violin part score is to show all the divisi parts, the first violin should be defined as a single part with three voices and a maximum number of staves of three. The notes of this part would be distributed among the one, two or three active voices, each voice presented on its own staff. b) If separate part scores are to be printed for different first violin players, more than one first violin part should be defined in the NIFF file. All the musical symbols that are to be printed on a particular part score would have that part number indicated. If the same passage is to be printed on two different part scores, both part numbers should be indicated for each symbol within the passage. Physical Structures A NIFF file is divided into two sections - the Setup Section, containing general information that applies to the whole score, and the Data Section, containing the music symbols and layout information. The Data Section is discussed in some detail here. The structures in the Setup Section are described later under Setup Section Structures. The topic of the relationships between individual music symbols in the Data Section is treated in Chapter 2, Symbol Relationships. Hierarchy. The music symbols in the Data Section are stored in page-ordered format. The format has a hierarchical structure, where pages contain systems, systems contain staves, and staves contain time-slices and individual music symbols. Within each level, data are supplied generally in a left to right, top to bottom order, except as discussed in Chapter 2, Symbol Relationships. Text and graphics can be included at any level of the hierarchy, according to the type of object to which they logically belong. Lists and Chunks. Pages, systems, and staves are all represented by lists composed of a header chunk followed by other component chunks that belong at the same hierarchical level. To save space, the time-slice has not been defined as a list chunk with a header and component chunks. Instead, the Time-Slice chunk functions as a sort of header to the group of symbol chunks which follow it. Every symbol within a Staff list, except for text or graphics immediately following the Staff Header chunk, is logically associated with the Time-Slice chunk that most closely precedes it. A Staff list may contain music symbols belonging to more than one part. When more than one part is present on the staff, the part must be uniquely identified for every symbol. When only one part is present in a particular Staff list, its Part ID is identified in the Staff Header chunk instead of on the individual symbols. Simulated Part Ordering, and Spacing By Part. A special case of the page-ordered data structure is known as "simulated part ordering." In this structure, there is only one system on one "very wide" page that extends from the start to the end of the score, with each part appearing on its own staff or staves. This special type of file contains a single Page list whose Page Header chunk has zero Width and Height tags. The simulated part ordering structure is designed to accommodate non-page- oriented programs and programs which offer the user the option to strip page layout data when writing NIFF files. The music symbols of a one-staff part would all be stored contiguously in a single Staff list. Multiple-staff parts such as piano or organ would be split apart into two or more Staff lists. Another special type of file structure is "spacing by part." In this scheme used by some notation programs, the symbols of each part are assigned horizontal placement values independently of the other parts, as though the file contained a set of part scores instead of one ensemble score. This could be used in a file with page ordering or simulated part ordering. A file recorded with this scheme is identified by the presence of the Spacing By Part tag on the NIFF Information chunk in the Setup Section. Reading programs unable to make use of this spacing should ignore all horizontal placement values, using its own spacing defaults instead. Notes and Stems. A musical note is normally composed of at least two chunks - a Stem chunk and a Notehead chunk. It can be viewed as a degenerate case of a chord. A full chord is represented by a Stem chunk and several Notehead chunks, each of which represents a single notehead. There is no requirement that a Stem be followed by any Noteheads. Measurement Units and Coordinate System. Goals NIFF's measurement system is designed: 1) to allow enough flexibility to accommodate page-oriented notation programs, non-page-oriented notation programs and scanning programs, 2) to allow a fine enough resolution to describe high-quality printed music, 3) to use integers rather than floating point numbers, for the purpose of avoiding rounding errors and incompatibility among platforms, and 4) to describe each size and position measurement in a way that is semantically useful. In addition, an attempt has been made to limit rounding errors during translation between the reading and writing programs' measurement units. For this reason, each writing program has its choice of units for absolute measurements. Absolute Units and Staff Steps NIFF uses two different measurement systems - absolute units and staff steps. Absolute units are the writing program's own choice of units, declared in the Setup Section NIFF Information chunk. The unit choice is expressed in two field values: the standard unit (inches, centimeters, or points), and the number of absolute units per standard unit. For example, if the resolution used by the writing program were 4000 dots per inch, the writing program would choose a standard unit of "inches" and the number of absolute units per standard unit would be 4000. The placement of a symbol whose meaning depends on its vertical position on a staff line or space is given as a staff step. The origin of the staff step system is the bottom line, which is given the value zero. Step numbers increase by one for each successive line or space in an upward direction from the origin. Negative numbers are used for the spaces and ledger lines below the origin. Measurements and symbol placement are discussed in detail in the Symbol Relationships section below. Page Coordinate System. The size of a page is given as its height and width in absolute units. The origin of the page's coordinate system is the top left corner of the page (as in the lower right quadrant of a Cartesian coordinate system). Measurements are increasingly positive to the right and towards the bottom of the page. The origin of a staff is the left end of its top line. The origin of a system is the staff origin of its top staff. Font size. The size of text fonts is given in twips. (One twip = 1/20 of a point, or 1/1440 of an inch.) This allows for scaling of fonts between point sizes, for those who can use this feature (e.g. a 210 twip font = a 10 1/2 point font). The size of music fonts is described in two different ways: font size (in twips) and space height (in absolute units). Since there is no agreement on the meaning of font size between different music fonts, the space height is intended to provide a clue about the intended size of the symbols on a standardized scale. It is equal to the vertical distance in absolute units between two adjacent staff lines of a staff on which the music font symbols would appear of normal size. Timing Representation Goals Two goals in NIF's timing representation are 1) to describe the time values in a semantically useful way, and 2) to provide enough information for the reading program to produce a MIDI playback of the score. Two kinds of playback are: 1) logically precise playback derived from the notation, and 2) nuanced rubato of a recorded performance. For each playback event, there are two pieces of information to be described: 1) start time, when the event is to occur, and 2) duration, how long it lasts. Duration. Durations in music notation are inherently rational numbers (fractions) which describe the relationship between a specific unit of time (the note value) and a standard unit of time (traditionally the whole note). A half note is 1/2 of a whole note; a quarter note is 1/4 of a whole note. Infinitely smaller note types can be invented by increasing the denominator to any power of 2. More interestingly, the duration of each note in a tuplet sometimes can be precisely represented only by a fraction, such as half note triplets, where each note's duration can be accurately represented as 1/3. When three half notes occur in the time normally allotted for 2, each note takes up 2/3 the time of a normal half note (1/3 = 2/3 * 1/2). Similarly, when 3 quarter notes are stretched out to the time of 4 (notated as 3:4 over a bracket, in tuplet notation), this duration can also be represented as 1/3: each note takes up 4/3 of the time of a normal quarter note (1/3 = 4/3 * 1/4). A fraction consisting of two integers (a numerator and a denominator) is therefore a natural way to describe durations. Tuplets. The duration field in a Notehead chunk is the same whether or not the note is included in a tuplet. Additional information (a series of tuplet chunks) is to be stored in the file for each tuplet. The first tuplet chunk contains a transformation ratio to be applied to each note in the tuplet, and graphical information about the appearance of the tuplet such as the presence of numbers and/or brackets. The tuplet transformation ratio is in the form of 4 integers: a, b, c, and d, where a b-type notes occur in the time of c d-type notes. In conventional usage of tuplets, b and d will be the same, but many musicians use tuplets in an "unconventional" way, and may choose to represent a tuplet as, for example, three half notes in the time of four quarter notes (a, b, c, d = 3, 2, 4, 4). For example, in the case of half note triplets the transformation ratio in the tuplet chunk is 3:2. When applied to the half note duration on the note chunk (1/2), this would result in an effective duration of 1/3 (1/3= 2/3 * 1/2). The effective duration need not be stored in the file, since it can be calculated by the reading program from values in the note and tuplet chunks. A tuplet is normally a multi-node symbol, represented by a series of Tuplet node chunks, each one associated with one Stem chunk. All notes on a tupletized stem must contain the same duration. See Chapter 2 for information about multi-node symbols. Nested tuplets are represented by an additional tuplet associated with a subset of notes already included in a tuplet. The transformation ratios are applied cumulatively to each affected note. More than one voice or part can be included in a tuplet. For example, when all horns shown on the same staff are playing in rhythmic unison, a whole collection of chords may be tupletized. However, within each voice (or part, if there is one voice per part), the sum of the durations of the notes must equal a b-type notes. Logical Start Time. An explicit start time is required because simultaneous events are not always vertically aligned - for example, a chord with seconds. Ambiguity can result for a variety of other reasons as well. The start time of a note or rest is stored on the event Time-slice chunk associated with (most recently preceding) the note or rest symbol. The start time is represented by a fraction which is the sum of the durations of all events that have occurred within the voice since the previous measure-start time-slice. Here is an example, showing the start times and durations for 4 quarter notes in the first measure of a score in 4/4 time. Time-slice, type=event, start-time=0/4 Stem Notehead, duration=1/4 Time-slice, type=event, start-time=1/4 Stem Notehead, duration=1/4 Time-slice, type=event, start-time=2/4 Stem Notehead, duration=1/4 Time-slice, type=event, start-time=3/4 Stem Notehead, duration=1/4 The start time of a measure is stored on a measure-start Time-slice chunk. It is given as the cumulative duration of all events since the start of the piece. The effective start time of each event in a measure is therefore the sum of the measure start time (from the measure-start Time-slice chunk) and the event start time (from the event Time-slice chunk). In the example above, the start time on the measure-start Time-slices of the first and second measures, respectively, would be 0/4 and 4/4. The reference back to the start of the piece permits the correspondence between events in different parts to be determined even when the parts are in different meters. Logical Gaps. An additional reason start time is required is that voices are not always logically complete from start to finish. If a voice were logically complete, the start time of each event within the voice would always be the exact time that the previous event in that voice finished. Logical incompleteness (gaps) can occur, however, for various reasons: 1) Piano music often allows temporary voices to appear and disappear with no rests to fill the time gaps. 2) A non- metrical cadenza-like section can appear in one voice or part, leaving all other voices or parts with a logical gap during that time. 3) Scanning programs can easily miss one or more notes in the middle of a sequence. 4) Inactive parts might be hidden for large sections of a score. Logical gaps can be filled in with invisible rests and placeholding measure- start time-slices. Or, logical gaps can be handled by adding extra value to the start time of the event following the gap to compensate for the missing time. Either technique ensures that the event following a logical gap in one voice will not occur until its proper time among the events in all other voices and parts. Performance Information For performance playback, both start time and duration are measured in MIDI clocks, which denote some fixed amount of time using an integer. MIDI clocks are well suited to performance information because of their high resolution. The relationship between the performance and logical values is described by the field MIDI clocks per quarter note, stored in the NIFF Information chunk in the Setup Section. The performance start time and duration are given as offsets (+/-) from the logical start time and duration of the event. Lengthy or complex MIDI information that cannot be represented with the simple MIDI Performance tag can be supplied with the MIDI Data Stream chunk (see below under MIDI Integration). Additional Comments. The Notehead and Stem chunks and associated chunks and tags contain graphical features such as notehead shape, number of dots and number of flags that in printed music describe a note's duration. However, the reading program need not concern itself with the timing implications of these details. The duration field stored on the Notehead chunk should be used for the timing value, regardless of the graphical features. For example, a note with duration of 3/16 could appear visually as a dotted eighth note with either a flag or a beam. In practice, any combination of a note's graphical features, or even an invisible note on a zero length stem, could be used to represent any time value. The performance playback values may be affected by other chunks and tags associated with the Notehead or Stem chunks, however. For example, an Accidental chunk will affect the pitch, an Articulation chunk or Silent tag might affect the performance duration, and a Grace Note tag would likely affect the start time. An event's start time and duration are always present (each composed of a numerator and denominator component); the performance start time and duration are optional values that can be supplied on the MIDI Performance tag. If not present, it is assumed that the performance values are equivalent to the logical values. NIFF does not require logical adherence to time signatures. Barlines, Clefs, Time Signatures, Key Signatures. A barline signals the end of a measure rather than the start of a measure. On the last measure of a system it is necessary to store the Barline chunk before the measure-start time-slice, which belongs in a new Staff list and a new System list. So, for consistency and logical rigor, the Barline graphical symbol chunk is to be stored between the last event in the measure and the measure-start time-slice of the next measure. A special event time-slice chunk should be stored for this purpose, to uniquely identify the sequential position of the barline. Its start time can be the same, in essence, as the start time of the next measure-start time-slice, except given in relation to the start of its measure rather than the start of the score. The only time non-unique time- slices are allowed within a Staff list are when an event time-slice duplicates a measure-start time-slice in this way. Chunks representing changes in clef, key signature and time-signature, when present at a measure boundary, should be stored in the same way, following the Barline chunk. Horizontal placement can be supplied to identify the individual placement of each symbol within this special time-slice, though most reading programs would have spacing algorithms to handle them adequately without it. When changes in clef, key signature or time signature occur in the middle of a measure, they should be stored with the time-slice which represents the following event. The horizontal placement of a symbol chunk in this situation, if specified, should have a negative value. Chunks representing the clefs, key signatures and time signatures that appear at the start of the staff do not need to be preceded by an event-time-slice. They are stored immediately after the new measure-start time-slice. In the case where the new system starts in the middle of a measure, these chunks should be stored with the time-slice which represents the following event. The horizontal placement of a symbol chunk in this situation, if specified, should have a negative value. Grace Notes. A grace note is a note whose time value is not counted in the general rhythm; its time value must be subtracted from that of the preceding or following normal note during performance. A grace note is always associated with the event time- slice of the normal note following it. It is indicated by the addition of a Grace Note tag to a Notehead or Stem chunk. The Grace Note tag gives the note's logical start time as an offset from thestart time of its time-slice (negative, zero or positive, depending on the chosen interpretation of grace notes and the note's position within a series of grace notes). For small notes that break the meter but whose time is not subtracted from that of the preceding or following normal note, do not use the Grace Note tag. The performance start time (in the note's MIDI Performance tag) is given as an offset in MIDI clocks from the grace note's logical start time. Other tags that might be found on a grace note's Notehead or Stem chunk include the Slash tag, Small Size tag, and the Absolute Placement tag (with a negative value) indicating a negative horizontal offset from the time-slice. In the following example, the grace note's time value is subtracted from the preceding note during performance, as in Chopin or Liszt. However, the duration field on the preceding Notehead chunk is not modified to compensate for the grace note. The start time on the Grace Note tag gives a negative offset of 1/32 from its time slice, which can be used by the reading program during playback. Time-slice, type=event,start-time=0/4 Stem Notehead, shape=filled, staff step=0, duration=1/4 Time-slice, type=event, start-time=1/4 Stem, Number of Flags=1, Slashed Stem, Small Size, Grace Note=-1/32 Notehead, shape=filled, staff step=2, duration=1/32 Stem Notehead, shape=filled, staff step=1, duration=1/4 Chunks, Lists, Forms and Tags RIFF chunks, lists and forms. The basic building block of a RIFF file is called a chunk. A chunk is composed of a four character ASCII code indicating what type of chunk it is, followed by a length field, followed by the chunk's data. Defined in the C programming language, a chunk looks like this: typedef unsigned long DWORD; typedef unsigned char BYTE; typedef DWORD FOURCC; /* Four-character code */ typedef struct { FOURCC chunkID; DWORD chunkSize; /* the size of field */ BYTE chunkData[chunkSize]; /* the actual data of the chunk */ } chunk; A list is a type of chunk which can contain nested chunks, or subchunks. Its four character code is "LIST". The type of list it is is supplied in a four character code following the size field, which is followed by a series of chunks or other lists. typedef struct { FOURCC chunkID; /* always "LIST" */ DWORD chunkSize; /* the size of field + 4 */ FOURCC listID; /* the type of list it is */ BYTE listData[chunkSize-4]; /* zero or more chunks and lists */ } list; A form is a special type of chunk which always appears first in a RIFF file, and contains all the other chunks and lists in the file. Its four character code is "RIFF", or in the case of the Motorola format which NIFF always uses, "RIFX". The form type, which is always "NIFF" for NIFF files, is supplied in a four character code following its length field. This is followed by a series of lists and chunks: typedef struct { FOURCC chunkID; /* always "RIFX" */ DWORD chunkSize; /* the size of field + 4 */ FOURCC formID; /* always "NIFF" */ BYTE formData[chunkSize-4]; /* zero or more chunks and lists */ } form; The presence of the chunkSize allows programs to ignore the rest of a chunk, list or form which is not recognized. The chunkData, listData and formData fields always have an even number of bytes. A pad byte with value zero is added to the end, if necessary for the data to end on a word boundary. The value of chunkSize does not include the pad byte. NIFF chunks and tags. Each NIFF file chunk has a fixed-length part and a variable length part. The fixed-length part is composed of a set of required elements described by its chunk definition in Chapter 3. The variable length part is composed of a series of optional tags which may be used occasionally or only by certain programs. A tag is a self-contained set of variable-length information composed of a one byte code indicating what type of tag it is, followed by a one byte length field, followed by the tag's data. Defined in the C programming language, a tag looks like this: typedef { BYTE tagID; BYTE tagSize; /* the size of field */ BYTE tagData[tagSize]; /* the actual data of the tag */ } tag; The presence of the tags' size allows programs to ignore the rest of a tag which is not recognized. The tagData field always has an even number of bytes. A pad byte with value zero is added to the end, if necessary for the data to end on a word boundary. The value of tagSize does not include the pad byte. The tagData field must conform to the documented tag definition as shown in Chapter 3, unless it is a user-defined tag, discussed below. Any number of tags may be appended to the required part of a chunk. NIFF- defined options, user-defined options, and future extensions can all be represented in the form of tags. Any defined tag may be added to any chunk type; however, some combinations might be meaningless. When used on an anchor symbol chunk (see Chapter 2, Symbol Relationships), a tag applies to all symbol chunks dependent on the anchor, where meaningful. When used on a Stem chunk, a tag applies to all associated Notehead chunks. NIFF data types. The same data types are used in both chunk and tag definitions. Currently defined data types are described below. Typedefs can be found in the NIFF.h C header file (Appendix A) for the following data types. Additional types used in the chunk and tag definitions are STRUCT, which refers to a set of data elements in a documented structure format, and char[x], an x byte character value. Type Description BYTE a 1 byte unsigned integer SIGNEDBYTE a 1 byte signed integer CHAR a 1 byte character value SHORT a 2 byte signed integer LONG a 4 byte signed integer FOURCC a 4 byte ASCII character value. RATIONAL 2 2 byte signed integers (numerator and denominator) STROFFSET a 2 byte signed integer pointing to a RIFF ZSTR in the String Table chunk in the Setup Section. A RIFF ZSTR is a series of ASCII characters followed by a terminating null. -1 means a null pointer. Embedded zero bytes are not allowed within a ZSTR. FONTPTR a 2 byte pointer to a Font Description chunk in the Font Descriptions list. EMPTY 0 bytes. This is used for chunk types for which there are no required elements, and tags whose full meaning is conveyed by the tag ID. N.B. Time did not permit full development of an International String Table in time for NIFF 6a. This would be a Setup Section chunk that would allow character strings to be stored for fonts that require two bytes for each character code, such as Chinese, Japanese, or Korean. An associated data type would be required to reference strings in this table, as well as an International Text chunk containing a field with this data type. Other enhancements to the format to make use of this feature have not been fully investigated. It is possible that this feature could be developed in the future. User-Defined Chunks and Tags. NIFF users such as commercial software vendors and academic researchers can define their own NIFF chunks and tags, to provide for features of their software that are not present in the NIFF specification. NIFF users who want to define their own chunks and tags must formally register a unique two byte NIFF User ID, using a protocol yet to be developed. User-defined chunks are identified by the four character code "user". The two byte NIFF User ID is stored in the first two bytes of the chunkData field. User-defined tags are identified by a tag ID of 255 (x'FF'). The NIFF User ID is stored in the first two bytes of the tagData field. The user defines the structure and value of the remainder of the data portion of the chunk tag. The presence of the size field allows reading programs to ignore unrecognized user- defined chunks and tags. The Chunk Length Table in the Setup Section must include an entry for each user- defined chunk type as well as for each standard NIFF chunk type used in the file. NIFF users should clearly document the structure and function of each user- defined chunk and tag. The details of administering a documentation library have yet to be determined. The Setup Section The only required items in the Setup Section are the NIFF Information chunk, the Chunk Length Table, and the Parts list. Optional items in the Setup Section are the standard RIFF INFO list, the String Table, the Staff Groupings list, the Default Values chunk, the Font Descriptions list, and the Custom Graphics list. The required and optional components of each list must appear when present in the order described in Chapter 3, unless "in any order" is specified in the list's definition. The NIFF Information chunk. This includes the following information: NIFF version, writing program type, measurement units and MIDI clocks per quarter. Of these fields, all but the NIFF version can have a value of -1 to indicate "no value". The Chunk Length Table. The purpose of this is to allow for future changes in the fixed length part of the chunk structures, without disturbing existing programs. It is a series of 8 byte table entries, each one composed of a 4 byte chunk name followed by a 4 byte pointer to the first tag field to be found in chunks of that type. The pointer value is always the same as the length of the chunk's required structure. If the required structure for the chunk type is the EMPTY data type, the pointer value is zero. If no tags are allowed in that chunk, the pointer value is -1. There must be a table entry for each chunk type present in the file, including user-defined chunks. Table entries appear in alphabetical order. The Parts list. This list is composed of a series of Part Description chunks, each of which defines the Part ID, part name and part abbreviation, maximum number of staves in that part, MIDI channel and cable numbers, and the number of steps to transpose this part on playback. All fields except Part ID can be set to null values. Part ID's should be assigned sequentially starting with zero. The vertical offset of such optional items as lyrics, guitar grid symbols, and figured bass can optionally be specified by appending tags to the Part Description chunk. The maximum number of staves field in each Part Description must have a nonzero value. This information is used in interpreting staff number values in the Setup Section Staff Groupings list. The String Table is a chunk containing all strings referred to elsewhere in the file. It is a series of null terminated ASCII strings (known in RIFF terminology as ZSTRs). In any NIFF chunk where a string value is needed, the data type STROFFSET is used. This contains the offset of the string in the String Table. The Staff Groupings list is a series of Staff Grouping chunks, each of which describes some type of grouping symbol at the left end of a series of sequential staves in the score, such as an initial vertical line, a brace or a bracket. A default Staff Groupings list can optionally be supplied in the Setup Section. In the Data Section, Staff Groupings lists can be supplied in some System lists as overrides to the default Staff Grouping. Alternatively, the Setup Section Staff Grouping list can be eliminated entirely, with Staff Groupings supplied only in Data Section System lists. Storing a default Staff Groupings list in the Setup Section makes the most sense when there is little variety among the score's staff groupings. The Defaults chunk specifies default fonts for various text categories, vertical offsets of chord symbols, guitar grids, and rehearsal marks, and a default tuplet appearance description. Fonts and Custom Graphics. This section discusses the Font Descriptions list, the Custom Graphics list, and the related structures that allow the writing program to store and use special fonts and graphics in a NIFF file. The Font Descriptions list is an optional table in the Setup Section that is composed of a series of Font Description chunks, each of which defines a particular combination of font name, font size, and font style. Font Description chunks in the Font Descriptions list are referred to elsewhere in the file by means of the FONTPTR data type. The FONTPTR data type is used in the optional Default Values chunk in the Setup Section for specifying default fonts for music symbols, lyrics, figured bass and chord symbols. FONTPTR is also used in the Font ID tag, which is applied to any music symbol or text-type chunk to specify that the same character(s) but a different font, size or style is to be used. Finally, FONTPTR is used in the Custom Font Character tag, which allows a non-default font and character to be used on a music symbol chunk. Each Font Description chunk gives the font name, size (in both twips and absolute units), style (plain, bold, italic, underscored, or a combination), and the location where the font itself can be found, if it is stored in the file. The location is given as a pointer to the PostScript font in the Custom Graphics list, a separate Setup Section structure. The Custom Graphics list is an optional table in the Setup Section that is used to store fonts and custom graphics. Fonts are stored as PostScript Type 1 or Type 3 font, and graphics are stored in EPS (encapsulated PostScript) format. EPS graphics in the Custom Graphics list table are referred to by means of the Custom Graphic Symbol chunk, which represents a symbol with no musical function, or the Custom Graphic tag, which is applied to a music symbol chunk to override the default appearance of the symbol. The NIFF Font Symbol chunk is a font-independent method of indicating the appearance of a music symbol without its musical function. An alternative to the Custom Graphic Symbol chunk, it can be used to indicate that an ornament or clef sign, for example, is to appear in a particular place on a page such as a footnote, without specifying any particular font. The generic "NIFF Font" is composed of the four character code for the music symbol chunk normally used to display the symbol, and the shape, if any, for the desired symbol in that chunk's definition. Miscellaneous MIDI Integration This section describes how a complete MIDI file can be integrated into a NIFF file. In the Setup Section, each part can globally be assigned a MIDI channel number and cable number in the Part Description chunk. The part can be given a new set of channel and cable numbers at any point during the score by applying the Part Description Override tag. This might be used to switch to a new instrument sound, such as in a part for oboe and English horn. In the Data Section, the MIDI Data Stream chunk and MIDI Performance tag are used. There are four possible relationships between the notation symbols and MIDI data: 1) One to one correlation - notes. In the case of the pairing of a Notehead chunk and a Note On message, the MIDI Performance tag is appended to the Notehead chunk. The MIDI Performance tag includes the pitch and velocity of a MIDI Note On message, plus the performance start time and duration in MIDI clocks. The start time is given as an offset from the current time-slice. 2) One symbol, one or more MIDI messages. For example, a dynamic associated with a control change message, a hairpin associated with a controller 7 sweep or a turn or a trill symbol associated with a series of Note On and Note Off messages. This is represented by a MIDI Data Stream chunk anchored to a music symbol chunk. The MIDI Data Stream chunk indicates the start time of the beginning of the stream, in MIDI clocks, as an offset from the current time- slice. It includes any number of MIDI events, stored as in a MIDI file, starting at time zero. 3) Many to many correlation, where the number of symbol chunks is different from the number of MIDI messages. For example, a pitch bend might be associated with portamento notation composed of two Notehead chunks and the diagonal line Portamento chunk between them. In this case, the MIDI Data Stream is made into a multi-node symbol, with each node corresponding to one of the notation symbols. Only the first node contains the actual series of MIDI Pitch Bend Change messages. 4) No correlation. Either the notation has no clear MIDI meaning (for example a text string like "espressivo"), or the MIDI data has no standard notational equivalent (like panning information). The latter case is represented by a MIDI Data Stream chunk anchored to a Time-Slice. It may or may not be associated with a particular part. Guitar Tablature. Guitar Tablature is encoded as a separate Staff list within a System list in the Data Section. It is normally the second staff of a part with two staves, and should be counted in the maximum number of staves in the Setup Section Part Description chunk. The Guitar Tablature tag, the Number of Staff Lines tag (with a value of 6), and the Part ID tag are added to the Staff Header chunk. The standard Clef chunk is used, with its value indicating TAB. Guitar TAB Number chunks are used to place the numbers on the string lines, and standard Barline chunks are used for barlines.The tablature symbols are stored with time- slice chunks that correspond to those of the music symbols displayed on the standard notated staff above. Guitar slashes. There are two types of guitar slashes. Those with rhythm indicators such as stems, flags and beams are encoded using standard Stem and Notehead chunks, with a special slash notehead shape. For a guitar slash indicating a simple repetition of a chord symbol, the Repeat Sign chunk should be used, most likely with a Chord Symbol chunk. Part and Staff Names. The Part Description chunk has fields for part name and part abbreviation. These can be used by the reading program as the names to be placed to the left of the system identifying the parts. This would be easiest in simple scores, where there is a clear correspondence between parts and staves and each Staff Header chunk has a Part ID tag to identify it. The part name font in the Default Values chunk can be used by the reading program for these simple part names and abbreviations. In more complex cases, the writing program can use more precision in describing the function and placement of text to appear to the left of the system. An individual label can be specified for either a staff or a staff grouping. For instance, it is possible to give the label "Horns" to a brace connecting a pair of horn staves, one labeled "1-3" and the other "4-6." To create a label for a staff or staff grouping, the writing program should use the Staff Name tag on Text chunks stored in the appropriate context. The placement tag and Font ID tag may also be used. For a staff name, a Text chunk with the Staff Name tag should be stored following a Staff Header chunk. Its placement, if specified, would be given relative to the staff's origin. For a grouping name, a Text chunk with the Staff Name tag should be stored following a Staff Grouping chunk in a Staff Groupings list (in either the Setup Section or the Data Section). Its placement, if specified, would then be given relative to the staff origin of the top staff of the grouping. Ossias. An ossia is to be stored as one or more additional Staff chunks within a System list, each labelled with an Ossia tag applied to the Staff Header chunk. The presence of the Ossia tag indicates that this is an alternate performance of the symbols in one or more other staves. The part and voice of the ossia staves' symbols must be marked (individually, or by a shorthand method), to indicate which parts and voices it represents an alternative to. The value of the ossia tag indicates whether the ossia or the non-ossia alternative is to sound during playback. (The choice may be given to the user, or may depend on the capabilities of the notation software.) Additional tags which might be added to the Staff Header for an ossia are the placement tags and the Width tag, indicating a shorted staff that starts partway into the measure.. Measure Numbering and Rehearsal Marks. The Measure Numbering chunk is used to assign a measure numbering scheme. It allows for choice of the numbering frequency, starting number, and logical placement of the measure numbers. The measure numbering scheme can be changed at the start of any measure in the score, by storing this chunk after the appropriate measure-start Time-Slice chunk in the first Staff list of a System list. For precise placement of individual numbers, or to use letters instead of numbers, use the Rehearsal Mark chunk instead. Repeats and Alternate Endings. A repeated section of a score appears in the NIFF file only once. A Repeat Sign symbol contains information about both the graphical repeat sign and its function. It follows a Time-slice chunk (either measure-start or event type) at either the beginning or the end of the section to be repeated. The Repeat Sign chunk can be used for many kinds of repetition. It can indicate the appearance of symbols, printed words, or abbreviations, and the repetition of a beat, measure or whole section. Alternate endings introduce an apparent timing inconsistency: the start times in the measures of later endings duplicate the start times of measures in the first ending. To allow the reading program to make sense of this inconsistency, each measure-start Time-slice chunk of each ending is to have an Alternate Ending tag attached. When calculating the start time of the time-slice following a series of alternate endings, only the longest of the alternate endings should be considered. There would normally also be an Alternate Ending Graphic chunk which indicates the appearance of the alternate ending, at least on the topmost staff. But it is the Alternate Ending tag which definitively resolves the timing conflict. Tag Activate/Tag Inactivate When one or more tags is to be applied to a sequence of symbols in a Staff list, the Tag Activate chunk can be used to identify the start of the sequence, and the Tag Inactivate chunk to identify the end of the sequence. Each tag is activated independently of the others, but they can be grouped together on the Tag Activate/Inactivate chunks. For example, the Tag Activate may include the Font ID, Small Size and Grace Note tags, while one Tag Inactivate chunk ends the Grace Note tag long before the other two tags are ended with another Tag Inactivate chunk. A tag on a Tag Activate chunk remains in effect until a Tag Inactivate chunk appears with the same tag, or the end of the current Staff list is found, whichever occurs first. Tag Activate chunks can also be nested. The Tag Activate chunk is useful for saving space, but another purpose is to allow for additive applications of a particular tag - such as when a very small grace note is present within a cadenza-like passage of small notes. This example is shown below: Time-Slice, type=event Stem a) Notehead Tag Activate, Small Size Time-Slice, type=event Stem Notehead Time-Slice, type=event Stem, Grace Note, Small Size b) Notehead Stem c) Notehead Time-Slice, type=event Stem Notehead Tag Inactivate, Small Size Time-Slice, type=event Stem d) Notehead Notehead (a) before the Tag Activate chunk and Notehead (d) after the Tag Inactivate chunk are normal sized. Notehead (c) is a small note, affected by the Small Size tag on the Tag Activate chunk. Notehead (b) is a very small note, affected cumulatively by the Small Size tag on its Stem and by the Small Size tag on the Tag Activate chunk. Tag Activate restricted by Part ID, Voice ID Part ID and Voice ID have a special meaning on the Tag Activate chunk. When Part ID and/or Voice ID appear on the Tag Activate chunk, their purpose is to restrict the action of the Tag Activate to the subset of the intervening chunks which have matching Part ID and/or Voice ID's. If any intervening chunks have a different Part ID or Voice ID from that specified on the Tag Activate chunk, those chunks are not affected by the Tag Activate. The following example shows use of the Voice ID to restrict the mode to one voice only: Tag Activate, Voice ID=2, Small Size Time-slice Stem, Voice ID = 1 a) Notehead Stem, Voice ID = 2 b) Notehead Tag Inactivate, Voice ID=2, Small Size Only Notehead (b) is affected by the Small Size tag on the Tag Activate chunk. N.B. For some chunks within the Tag Activate scope, the tags would be meaningless and should be ignored by the reading program. An example is the Small Size tag as applied to a Time-Slice chunk. Chapter 2 - Symbol Relationships The meaning of a music notation symbol often depends on its relationships with other music symbols. Storing enough information in the NIFF file to relate music symbols to one another introduces complex programming issues. NIFF has been carefully designed in an attempt to allow programs to indicate symbol relationships with logical rigor, flexibility and efficiency. A balance has been sought between the sometimes conflicting efficiency goals of minimizing processing time, programming effort, memory usage and disk space. Dependent symbols and their anchors. In NIFF, a music symbol whose placement depends on one or more other symbols is called a "dependent" symbol, and the symbol or other chunk type on which its placement depends is called its "anchor." For each symbol chunk type, a default anchor chunk type is defined. For example, for the Fingering chunk, the Notehead is the default anchor, and for the Articulation chunk, the Stem is the default anchor. The Anchor Override tag can be used on a dependent symbol chunk to indicate a non-default anchor type. For example, a Slur's default anchor type is a Stem, but an anchor override could be applied to a particular slur endpoint to anchor it to a Notehead or Fingering chunk instead. The Time-Slice is the default anchor for some symbols, and is a valid override anchor as well. The dependent/anchor relationship between symbols plays a major role in both file syntax and symbol placement. File Syntax. Syntax rules. There are two rules defined for the syntactic order of dependent and anchor symbols: 1) The dependent symbol physically appears in the file as soon as possible after its anchor. "As soon as possible" means that the only symbols that can be stored between a dependent symbol and its anchor are other symbols dependent on the same anchor, and nested symbols dependent on those. 2) When more than one symbol is dependent on the same anchor, the dependent symbols should be placed in the file in order of graphical proximity to the anchor, from nearest to farthest. For symbols that are the same distance from the anchor, or when distance doesn't matter, any order will do. A detailed example demonstrating these rules is given below. Stems and Notes. The relationship between the Stem chunk and Notehead chunk is a little different from other symbol relationships. In terms of syntax, the Notehead is dependent on the Stem (i.e. Noteheads appear in the file after their associated Stem). However, for symbol placement, both the Notehead and Stem are dependent on the Time-Slice. This is discussed below in "Reference points on Noteheads and Stems." Noteheads and Stems bypass syntax rule 2. Notehead chunks always follow the Stem chunk in order from highest to lowest pitch. Complex dependencies - some examples. The file syntax and use of the Anchor Override tag allow complex dependencies to be represented in NIFF. For example, consider a slur between two fingering numbers related to a single notehead, parentheses surrounding the staccatos over a series of notes, or a small sharp sign above a trill ornament over a note. The anchor of each symbol is the chunk of the appropriate type (either default or explicit) which most closely precedes the dependent symbol in the file. Here are two examples in NIFF pseudo-code. In Example A1 there is a small sharp sign over a trill ornament anchored to one note of a chord; a fingering number is anchored to another note of the chord. In Example A2 parentheses surround the staccatos over three notes. Diagram A1 Diagram A2 Example A1: Stem Notehead, staff step=3, duration=1/4 Fingering, shape=1 Notehead, staff step=7, duration=1/4 Ornament, shape=short trill Accidental, shape=sharp, Small Size, Anchor Override=Ornament, Logical Placement=above [discussed later] Example A2: Time-Slice, type=event,start time=0/4 Stem Notehead, staff step=5, duration=1/4 Articulation, shape=staccato Parenthesis, shape = "(", Anchor Override=Articulation,Logical Placement = left, ID=1, Number of Nodes=2 [multi-node, discussed below] Time-slice, type=event, start-time=1/4 Stem Notehead, staff step=5, duration=1/4 Articulation, shape=staccato Time-slice, type=event, start-time=2/4 Stem Note, staff step=5, duration=1/4 Articulation, shape=staccato Parenthesis, shape = ")", Anchor Override=Articulation,Logical Placement = right, ID=1 Multi-node symbols. Beams, Slurs, Ties and Hairpins are examples of symbols which are normally dependent on more than one anchor. The interpretation of syntax rule 1 would be ambiguous in the case of a dependent symbol with a one-to-many relationship with its anchors. For example, consider a beam connecting three stems. Should the beam appear after the first, second or third stem? To allow syntax rule 1 to be applied consistently, one-to-many relationships have been decomposed in NIFF into one-to-one relationships by subdividing the "one" dependent symbol into several node chunks of a "multi-node symbol", each one corresponding to one of the "many" anchor chunks. Syntax rule 1 can then be followed: each dependent symbol node chunk physically appears in the file immediately after its corresponding anchor chunk. For example, the beam is decomposed into nodes, each one corresponding to a stem. Each node supplies information about the beam at that point, i.e. the number of beam parts to the left and to the right of that stem, including partial (fractional) beams. Every node of a multi-node symbol must contain an ID tag. The same ID is used on all nodes of a multi-node symbol, so the nodes can be recognized as belonging to the same symbol. As a convention, ID numbers should be assigned sequentially within a chunk type starting with zero. The first node of a multi-node symbol (the one appearing physically first in the file) has some special properties. Any information which applies to the symbol as a whole appears here, such as the Fanned Beam tag on Beams. Tags which are independently associated with each node, such as Bezier Incoming/Outgoing and the Anchor Override tag can appear on any node. The first node also contains the Number of Nodes tag indicating how many nodes are present in the file for the multi-node symbol with this ID. This allows the reading program if desired to allocate the appropriate amount of storage when it finds the first beam node, and to release the storage when it has found and handled the last beam node. The Number of Nodes tag and ID tag together identify a symbol as multi-node. In the rare case of a one-node symbol of a type which is normally multi-node, such as a beam when it is anchored to only one stem, the one beam chunk need not contain the Number of Nodes or ID tags. In a cross-staff beam which starts on a stem in the lower staff and ends on a stem in the upper staff of a piano grand staff, the first beam node to appear in the file may be the one corresponding to the rightmost stem in the beam structure (the last one in time-slice order), or perhaps even to a stem in the middle of the beam structure. The reading program may not be able to reconstruct the complete beam until the last beam node has been read. Here is an example in NIFF pseudo-code, showing a cross-staff beam connecting three eighth notes in ascending order. Diagram B Example: (Staff 1) Time-slice, type=event, start time=1/8 Stem Beam, ID=1, Number of Nodes=3,parts to left=1, parts to right=1 Notehead, staff step= 2, duration=1/8 Time-slice, type=event, start time=2/8 Stem Beam, ID=1, part to left=1, parts to right=0 Notehead, staff step=5, duration=1/8 (Staff 2) Time-slice, type=event, start-time=0/8 Stem Beam, ID=1,parts to left=0, parts to right=1 Notehead, staff step= 6, duration=1/8 Multi-staff chords. When a stem contains notes on more than one staff, the stem is represented by a multi-node symbol. Each staff on which a portion of the stem appears has its own Stem node chunk. The first node contains the tags which affect all the nodes, such as Number of Flags. Because the ID tag is unique within the chunk type for the entire score, the ID tag is sufficient to identify the related stem nodes in the different staves. Here is an example: Diagram C Example: (Staff 1) Time-slice. type=event, start-time=0/8 Rest, duration=1/8 Time-slice. type=event, start-time=1/8 Rest, duration=1/8 Time-slice. type=event, start-time=2/8 Stem, ID=1, Number of nodes=2 Notehead, staff step=2, duration=1/4 Notehead, staff step=-1, duration=1/4 (staff 2) Time-slice. type=event, start-time=0/8 Stem Notehead, staff step=6, duration=1/8 Time-slice. type=event, start-time=1/8 Stem Notehead, staff step=6, duration=1/8 Time-slice. type=event, start-time=2/8 Stem, ID=1 Notehead, staff step=7, duration=1/4 Multi-system multi-node symbols. When a multi-node symbol crosses a system boundary, two special tags are used: the Multi-node End Of System tag, and the Multi-node Start Of System tag. These are required because the reading program might not have a system break in the same location as the writing program, and thus might not require these extra nodes. It can ignore all nodes with these tags if desired. An example of the use of these tags is when a tie extends from the last note on one system to the first note in the following system. In this case the tie symbol will contain an extra pair of nodes, one at the end of the first system and one at the start of the next. All four nodes are assigned the same ID. In the following example, the tie's Multi-node End Of System node is anchored to the Barline chunk at the end of the first system. The tie's Multi-node Start Of System node is anchored to the current time-slice, optionally with a negative horizontal placement. Diagram D [the end of system barline was accidentally omitted from this diagram] Example: (System 1) Time-slice, type=event, start-time=3/4 Stem Notehead, staff step=5, duration=1/4 Tie, ID=1, Number of Nodes=4 Time-Slice,type=event, start-time=4/4 Barline Tie, ID=1, Anchor Override=Barline, Multi-node End Of System (System 2) Time-slice, type=measure-start, start-time=16/4 Clef, shape=F clef, staff step=6 Time-slice, type=event, start-time=0/4 Tie, ID=1, Anchor Override=Time-Slice, Multi-node Start Of System Stem Notehead, staff step=5, duration=1/4 Tie, ID=1 Symbol Placement. NIFF allows a variety of choices in describing the placement of symbols. The placement of a symbol is always described in terms of its relationship to its anchor. The choices include default placement, logical placement and absolute placement. A reference point for each symbol, defined by default, or explicitly by use of the Reference Point Override tag, is used in the interpretation of both absolute and logical placement values. It is suggested that the writing program allow the user as much control as possible in the choice of the symbol placement technique or combination of techniques used in a particular NIFF file. When non-default placement information is present for a symbol, it should not contradict the placement relationship implied by the file syntax, but should complement it. Default, logical and absolute placement. Default placement: This is the case when no indication of symbol placement is present for a symbol other than that implied by the file syntax. The reading program must use its own defaults for intelligent placement of the symbol. Logical placement: This supplies the logical relationship between a dependent symbol and its anchor. It is implemented by the use of the Logical Placement tag, which indicates direction such as left, right, above, below or centered, and proximity such as touching or offset; and the Staff Step tag, which gives the position of the symbol's hot spot as a particular staff line or space. Absolute placement: This gives the exact location of the symbol, as an offset in absolute measurement units relative to its anchor. This is useful when an exact reproduction of the original image is desirable. It is implemented by the use of the Absolute Placement tag, which supplies the exact horizontal and vertical offsets of symbols from one another. Choice of placement technique by the writing program. Absolute placement allows for the most precise rendering of the original notation. However, there are many situations where logical or default placement is more appropriate: ¥ When the reading program does not have access to the music font specified by the writing program, use of absolute measurements could result in overlapping or incorrect alignment of symbols. ¥ When the reading program has no concept of page layout, absolute positioning would either be discarded or used only for its logical placement implications. ¥ In some cases, the user may simply not care to retain the details of the writing program's symbol placement, preferring a default layout by the reading program instead. Combinations of the various techniques can be included in a NIFF file. One possibility might be for a writing program to record page layout information such as the vertical location of each system and staff, and the horizontal position of each measure. Finer detail might be stored only when the user has specified non-default placement of some object, such as when a slur has been reshaped to avoid another symbol. In this case the writing program might store the absolute placement of a particular slur's endpoints in relation to its stem anchors. The use of the three placement options will likely evolve during the trial implementation of NIFF. Interpretation of placement values by the reading program. When encountering only absolute placement values in a NIFF file, a reading program could ignore them completely (strictly using its own defaults), or it could observe them without question. More intelligently, it could use them as a clue to determine logical placement of the symbols, avoiding collisions or incorrect alignment when necessary. Reference points. Every symbol has a default reference point used in interpreting the logical and absolute placement values. For a symbol such as an accidental or clef sign which has a natural "hot spot," the chunk definition specifies the hot spot as the default reference point. The default reference point of a Time-slice is the intersection of the time-slice at the staff's top line. If not otherwise specified, the default reference point of a symbol is the center of its bounding box. When an absolute placement value is supplied for a dependent symbol, the meaning of its value is "the offset of the dependent symbol's reference point from the anchor symbol's reference point." Note that the NIFF reference point is not the same as the default placement. In other words, an absolute offset of (0,0) on a symbol does not mean "place the symbol exactly at its default horizontal and vertical position." Instead, it means "place the reference point of the symbol (often its center) exactly on top of the reference point of its anchor (often the anchor's center)." The Reference Point Override tag can be used to temporarily change the reference point of either the anchor or the dependent symbol, or both. Descriptions of non-default reference points include codes such as "left of symbol's bounding box", "top of symbol's bounding box", or "vertical center of symbol's bounding box." When present, this tag is always specified on the dependent symbol for a particular dependent/anchor relationship. Reference points on the anchor and dependent symbols are only to be considered when explicit placement information is supplied. Otherwise, the reading program should use its own defaults to determine the placement of a dependent symbol relative to its anchor. Reference points on Noteheads and Stems. As stated earlier, the Notehead and Stem chunks both use the Time-slice as their anchor in terms of symbol placement. This means that the offsets of the Notehead and Stem chunks are both given in relation to the time-slice. The default reference point of a Notehead is its center. A horizontal offset of zero on a note chunk thus means it is horizontally centered over the time-slice. This would also be the default position, on an individual note or on a chord without seconds. When a chord contains a second, the notes on the "correct" side of the stem are by default to be centered over the time-slice. This allows for the correct alignment of simultaneous up-stem and down-stem chords which both contain seconds. When both a normal size notehead and a small size notehead are both present on the same stem, it is the normal size notehead that is centered over the time- slice. Diagram D The time-slice is centered under the two notes to the left of the up-stem, and the two notes to the right of the down-stem. A stem's default reference point is its end where the flag or beam would be attached, and its horizontal center. On a stem, a horizontal offset of zero would indicate that the stem is centered over the time-slice - obviously not the stem's default position. If a horizontal offset were supplied on a normal up- stem just touching the right side of an individual note (not required, since this would be the stem's default placement relative to the note), the stem's offset would be one half of the note width minus a half stem width. A larger stem offset would be used if the stem were to appear slightly separated from the note. Advanced feature: using time-slice start time as a placement clue. There are some cases when the start times on an event time-slice might be used as a clue to the proper positioning of symbols. This is an advanced feature that is not required in either reading or writing programs for successful implementation of NIFF. There are situations in music where the proportional placement of symbols is meaningful: for example, a crescendo hairpin ending somewhere between the start and end of a whole note. When the spacing of symbols is later adjusted, the hairpin should expand or shrink proportionally to its surroundings. When the writing program has used either logical or default placement of symbols rather than absolute, the proportion cannot be described in graphical terms. An event time-slice could be used as an anchor for the hairpin end, to precisely indicate the implied temporal relationship between it and the whole note's start and end. The program should calculate for the anchor time-slice's start time a value with the proper proportion to the start and end times of the whole note. The reading program could then use the temporal proportion of the hairpin end relative to the start and end times of the whole note to calculate the symbols' proportional placement. In mathematical terms: P0 = position of previous timeslice T0 = time of previous timeslice P1 = position of next timeslice T1 = time of next timeslice P = position of hairpin end T = start time on anchor time-slice of hairpin end P = P0 + (T - T0) * (P1 - P0) / (T1 - T0). Chapter 3 - Elements and Values Contents Lists - in order of file appearance Chunks - in alphabetical order Setup Section Data Section Header Chunks Symbol Chunks Tags - in alphabetical order Note - Use of Tags. The "Tags" item listed under each chunk description contains a few suggestions for tags to be used in that context. It is not intended to restrict the the creative use of tags. Any tag is allowed to be placed on any chunk. When the meaning of a particular tag is not specified for a particular chunk, it is the responsibility of the the writing program to use the tag in a meaningful way, and the reading program must do its best to interpret it. Lists in order of file appearance Setup Section LIST Location: NIFF form Required: NIFF Information chunk Chunk Length Table chunk Parts list Optional: RIFF INFO list (RIFF standard "INFO" list) String Table chunk Staff Groupings list Default Values chunk Font Descriptions list Custom Graphics list Parts LIST Location: Setup Section list Required: Any number of Part Description chunks. RIFF INFO LIST Location: Setup Section list Required: One or more of a series of structured comment chunks, as described in the RIFF documentation in the Microsoft Multimedia Programmer's Reference Manual (see References). Some of the chunks which might be included in an INFO list, and their meaning in a NIFF file are listed below. These are strictly for documentation purposes, and do not affect the interpretation of the values in the file. IART artist - the composer of the score ICOP copyright ICRD creation date of the file IDIM dimensions of each page IDPI dots per inch ENG engineer - editor, or person responsible for the notation's appearance IGNR genre - orchestral, jazz, pop song, classical piano, string quartet, theory example, etc. INAM name - name of score ISFT software - name of writing program ISRF source form - previous data format, such as paper, MIDI file, synthesizer keyboard entry, etc. ITCH technician - person operating software at time of output to NIFF file Staff Groupings LIST Location: Setup Section list A series of Staff Grouping chunks. A Staff Grouping chunk indicates some type of connection at the left end of a series of sequential staves in the score, such as vertical lines, braces or brackets. Location: Setup Section list or Data Section list Required: Any number of Staff Grouping Description chunks The Staff Groupings list in the Setup Section, if present, is the default for the score. The default can be overridden in the Data Section for an individual system by storing a Staff Groupings list immediately following the System Header chunkin the System list in the Data Section. If a system has any hidden parts or is different from the default system in any way, an override Staff Groupings list is required immediately following the System Header chunk. It completely replaces the default Staff Groupings list in the Setup Section. Font Descriptions LIST Location: Setup Section list Required: Any number of Font Description chunks. Comment: The FONTPTR data type is a pointer into this list. A value of 0 points to the first Font Description chunk in the list. Custom Graphics LIST Location: Setup Section list Required: Any number of the following, in any order: PostScript Type 1 Font chunk PostScript Type 3 Font chunk EPS Graphic chunk Data Section LIST Location: NIFF form Required: nothing Optional: Any number of Page lists Page LIST Location: Data Section list Required: Page Header list Optional: Any number of the following, in any order: System list NIFF Font Symbol chunk Custom Graphic Symbol chunk Text chunk Line chunk System LIST Location: Page list Required: System Header chunk Optional: Staff Grouping list Any number of the following, in any order: Staff list NIFF Font Symbol chunk Custom Graphic Symbol chunk Text chunk Line chunk Staff LIST Location: System list Required: Staff Header chunk Optional: Any number of the following, in order as appropriate: Time-Slice chunk Any music symbol chunk NIFF Font Symbol chunk Custom Shape Graphic chunk Text chunk Line chunk Chunks in alphabetical order Setup Section Chunk Length Table CHUNK Location: Setup Section list The purpose of the chunk length table is to give programs a tool for adapting to changes in the fixed length part of the NIFF chunk structures. The chunk length table is a series of 8 byte Chunk Length Table Entries, each table entry composed of a chunk name and the offset of the first tag field for chunks of that type. There must be a table entry for each chunk type present in the file. Chunks appear in the table in alphabetical order. chunk name FOURCC offset of first tag LONG A 4 byte pointer to the first tag field to be found in chunks of this type. The pointer value is always the same as the length of the required part of the chunk. If the chunk has no required structure, the pointer value is zero. If no tags are allowed in the chunk, the pointer value is -1. Default Values CHUNK Location: Setup Section list music font FONTPTR part name font FONTPTR Used as the default font for part name and abbreviation. See General Discussion of Part and Staff Names for details. lyric font FONTPTR chord symbol font FONTPTR measure number font FONTPTR rehearsal mark font FONTPTR tuplet grouping symbol BYTE See Tuplet Description tag for values. tuplet number style BYTE See Tuplet Description tag for values. EPS Graphic Location: Setup Section, Custom Graphics list CHUNK One of the valid chunks appearing in the Custom Graphics list. A PostScript description of a graphic, in EPS (encapsulated PostScript) format. Font Description CHUNK Location: Setup Section, Fonts list font name STROFFSET Offset into the string table of the font name. size SHORT Font size, in twips space height SHORT Used only for music fonts. Font size, given as the vertical distance, in absolute units, between two adjacent staff lines of a staff on which the music font symbols would normally appear. where SHORT Where this font can be found. -1 = This font or a substitute is assumed to be known and available to the reading program. 0-32767. The index into the Custom Graphic list where the actual PostScript font can be found. This must point to a fnt1 or fnt3 chunk. style BYTE The following values are additive: 0=plain 1 = bold 2 = italic 4 = underscored NIFF Information CHUNK Location: Setup Section list General information required to interpret values in the file. NIF Version char[8] 6a writing program type SIGNEDBYTE -1 = no value/other 1 = engraving program 2 = scanning program 3 = MIDI interpreter 4 = sequencer 5 = research program 6 = educational program standard units SIGNEDBYTE -1 = no absolute measurements in file 1 = inches 2 = centimeters 3 = points absolute units SHORT Number of absolute units per standard unit. -1 = no absolute measurements in file MIDI clocks per quarter SHORT MIDI clocks per quarter note, to be used in interpreting MIDI time values. Must be a positive number if MIDI time values are present in file. -1 indicates no MIDI timing information is present. Part Description CHUNK Location: Setup Section, Parts list Tags: Lyric Verse Offset (one for each lyric line), Chord Symbols Offset, Guitar Grid Offset, Rehearsal Mark Offset, Figured Bass Offset. Part ID SHORT The Part ID, referred to on Data Section chunks associated with this part. Should be assigned sequentially starting with zero. name STROFFSET Name to be associated with the staff or staves displaying this part on the first page of the score. See General Discussion of Part and Staff Names for details about its use. abbreviation STROFFSET Name to be associated with the staff or staves displaying this part on all pages after the first page of the score. See General Discussion of Part and Staff Names for details about its use. number of staves BYTE Maximum number of simultaneous staves for this part. Used to calculate staff ID's referred to in the Setup Section Staff Groupings list. A value of zero is allowed only if the Staff Groupings list is omitted from the Setup Section. MIDI channel SIGNEDBYTE Use -1 to specify none. MIDI cable SIGNEDBYTE Use -1 to specify none. transpose SIGNEDBYTE Number of halfsteps to transpose this part during playback. PostScript Type 1 Font CHUNK Location: Setup Section, Custom Graphics list One of the valid chunks appearing in the Custom Graphics list. Contains a complete PostScript type 1 font. PostScript Type 3 Font CHUNK Location: Setup Section, Custom Graphics list One of the valid chunks appearing in the Custom Graphics list. Contains a complete PostScript type 3 font. Staff Grouping CHUNK Location: Setup Section Staff Groupings list, or Data Section Staff Groupings list. Indicates some type of connection at the left end of a series of sequential staves in the score, such as vertical lines, braces or brackets. Staff groupings can be nested. When the same staff is included in more than one grouping, the grouping symbols are stored in the file in the order they are to be applied to the staff, from right to left, starting at the staff origin. grouping type BYTE 1 = vertical line at start of system 2 = brace at start of system 3 = bracket at start of system first staff SHORT 1-32767. Staff ID of first staff in grouping. See note below. last staff SHORT 1-32767. System Staff ID of last staff in grouping. See now below. N.B.: In a Data Section override Staff Grouping chunk, use the Staff ID's of the staves in the system to which the grouping applies, starting with zero for the first staff and increasing sequentially. In the Setup Section default Staff Groupings, Staff ID's of the default system are assigned as follows: A Staff ID is assigned to every staff of every part, using the maximum number of staves for each part. The ID numbers are assigned in increasing order starting with Part 0, Staff 0. Here is an example: Part 0 has maximum number of staves = 3 Part 1 has maximum number of staves = 3 Part 2 has maximum number of staves = 1 Default System Staff ID Description 0 Part 0, Staff 0 1 Part 0, Staff 1 2 Part 0, Staff 2 3 Part 1, Staff 0 4 Part 1, Staff 1 5 Part 1, Staff 2 6 Part 2, Staff 0 String Table CHUNK Location: Setup Section list char[] Contains one or more character strings in RIFF ZSTR format. Each ZSTR is composed of a series of ASCII characters followed by a one byte NULL (0x00) terminator. The character strings are referenced throughout the file by STROFFSET values which represent the offset into the tabl. 0 offset points to the first character after the chunk length. Data Section Header Chunks Page Header CHUNK EMPTY Default anchor: None Reference point/ Page Origin: Top left corner of page Tags: Width, Height. For a file with simulated part ordering, use values of zero for Width and Height. Staff Header CHUNK EMPTY Comments: The staff size is described by the Height tag, which contains the vertical distance between the top and bottom staff lines. The default number of staff lines is 5. If only one part is present on this staff, the Part ID tag should be appended here, so it won't have to be appended individually to each symbol in the Staff list. Default anchor: System origin Reference point/ Staff Origin: Top line of staff Tags: Part ID, Placement tags, Width, Height, Number of Staff Lines, Silent (eg. for ossias) System Header CHUNK EMPTY Default anchor: Page origin Reference point/ System Origin: Staff origin of first (top) staff Tags: Placement tags, Width, Height. Time-Slice CHUNK time slice type BYTE 1 = measure-start 2 = event start time RATIONAL depends on time-slice type type 1: measure start time, relative to start of score type 2: event start time, relative to previous measure-start time- slice Default anchor: Previous measure-start time-slice, or staff origin (for first time-slice in a staff) Reference point: Bottom staff line at its intersection with the time- slice. Symbol Chunks Accidental CHUNK shape BYTE 1 = double flat 2 = flat 3 = natural 4 = sharp 5 = double sharp 6 = quarter tone flat 7 = three quarter tones flat 8 = quarter tone sharp 9 = three quarter tones sharp Default anchor: Notehead Reference point: Hot-spot of symbol. See Diagram XX. Tags: Small Size, Parenthesis (Note: for triple sharps or triple flats, or for the combinations natural+sharp and natural+flat, simply use two accidental chunks.) Alternate Ending Graphic CHUNK Graphical symbols used on alternate endings. Used together with the Repeat Sign chunk and Alternate Ending tag. See General Discussion on Repeats and Alternate Endings for example. bracket shape BYTE 0 = no down-jog 1 = down-jog at beginning 2 = down-jog at end 3 = down-jog at beginning and end text string STROFFSET Number to appear at start of bracket. Normally "1." or "2." but any text string is allowed. Comments: Normally an alternate ending would have two nodes. Default anchor: Time-slice Tags: multi-node symbol tags Arpeggio CHUNK The symbol in front of a chord indicating that the notes of the chord are to be played successively from lowest to highest pitch, rather than simultaneously. This is a multi-node symbol, with node chunks anchored to the first and last Notehead chunks of the chord. It has both a logical and graphical function. shape BYTE 1 = wavy line 2 = vertical slur mark Default anchor: Notehead chunk Reference point: end points of the wavy line Articulation CHUNK shape SHORT 1 = strong accent (vertical wedge) 2 = medium accent (>) 3 = light accent ( tenuto) 4 = staccato 5 = down bow 6 = up bow 7 = harmonic (small circle) 8 = fermata 9 = arsis sign (unstressed) 10 = thesis sign (stressed) 11= plus sign 12 = vertical filled wedge (staccatissimo) 13 = double tonguing (two dots) 14 = triple tonguing (3 dots) 15 = "snap" pizzicato For some symbols, such as the strong accent and fermata, the shape depends on the context of the symbol - a strong wedge with the point at the top is used above up-stem notes, while the point is at the bottom when it is below down-stem notes. The non-default version of the symbol can be specified with the Articulation Direction tag. Default anchor: Stem Reference point: Center of symbol Tags: Articulation Direction Augmentation Dot CHUNK EMPTY For more than one dot, store additional Augmentation Dot chunks. When the dot is on a note or rest on a staff line, the vertical component of the Logical Placement tag can be used as follows: 1= above staff line 2 = below staff line For the reference point when the anchor is a rest symbol, see table (Diagram XX from Read pg. 96) Default anchor: Notehead Tags: Logical Placement, Barline CHUNK type BYTE 1 = thin line 2 = thick line extends to BYTE 1 = to bottom line of bottom staff indicated by number of staves. 2 = currently unused. (This option is a holdover from a previous version of NIFF, where the barline chunk wording was quite different. The numbering is being retained so as not to conflict with the NIFF SDK or header file.) 3 = only in spaces between staves (not through staves) number of staves SHORT Any number of these chunks can appear together (normally following a measure-start time-slice), with their order of appearance in the file indicating their graphical placement from left to right. The Barline chunk has only graphical significance. Use the Barline chunk together with the Repeat Sign chunk for repeat barlines. The Repeat Sign chunk would be stored by itself in all but the first staff of the barline's number of staves. The Barline chunk should be stored only in the topmost staff of each part. It represents a graphic line extending from the current staff to the part's bottom staff. The Width tag can be used with either value of the type field to specify line width. However, for writing programs not concerned with exact measurements, the type field should be used to to distinguish between thick and thin barlines. The Line Quality tag can be used to indicate a dotted or dashed line. Default anchor: Time-slice Reference point: Vertical: staff origin. Horizontal: center of barline. Tags: Thickness, Width, Line Quality. Beam CHUNK Normally a multi-node symbol. See Discussion Section, Multi-node Symbols for more details. beam parts to left BYTE beam parts to right BYTE Default anchor: Stem Reference point: Reference point of anchor. Tags: multi-node symbol tags Chord Symbol CHUNK The chord symbols placed above a staff. The chord symbol offset value in the Setup Section Part Description, if any, applies to this Chord Symbol. These chunks are interspersed with the music symbols of the part in the Staff list. text description STROFFSET A case-sensitive ASCII text string that represents the chord symbol to be printed. Special characters and their meanings are as follows: What to type Description @ (at sign) a flat sign # (pound sign) a sharp sign - (dash) a minor sign * (asterisk) a diminished symbol % (percent) a half-diminished symbol & (ampersand) a major 7 triangle 6/9 the 6/9 chord suffix / (forward slash) A diagonal slash for a hybrid chord, inversion or altered bass \ ((backward slash) escape character. the next character typed appears "as is" in the chord symbol, instead of being interpreted as a functional operator (for example, type "\&" to place an ampersand in the chord symbol _ (underline) a horizontal slash for a poly chord the text itself any other text type the suffixes and enclose them in parenthese, i.e. (#9@13) stacked suffixes within braces type the suffixes and enclose them in brackets, i.e. [#9@13] stacked suffixes within brackets type the suffixes and enclose them in < and > (left and right angle brackets). stacked suffixes with no braces or brackets Examples: What to type Chord C7(#9@13) C7#9@13 C7<#9@13> A/B F_C Cmin7@5/B@7(#9@13) Default anchor: Stem Reference pt: The baseline of the chord symbol text. (If more than one baseline, as in hybrid chord or poly chord, use lowest baseline. Tags: Font ID Clef CHUNK Indicates that the following musical symbols are to be interpreted in the specified clef. When two clefs are active on the same staff, one or more Voice ID tags can be applied to the Clef chunk to associate it with a subset of the following symbols. It is active until the end of the Staff list, unless terminated by a new Clef (perhaps with an Invisible tag), which applies to the same voice or voices. shape BYTE 1 = G clef 2 = F clef 3 = C clef 4 = percussion 5 = Double G clef 6 = TAB for guitar tablature staff step SIGNEDBYTE Staff step of clef sign hot spot. treble clef: shape = G clef, staff step = 2 bass clef: shape = F clef, staff step = 6 alto clef: shape = C clef, staff step = 4 tenor clef: shape = C clef, staff step = 6 guitar tablature: shape = TAB, staff step = 8 (on a 6 line staff). octave number BYTE Used to modify the shape by attaching a little "8" above or below the clef symbol. The presence of the 8 above or below transposes the staff an octave up or down. 0 = no number 1 = 8 above 2 = 8 below 3 = 15 above 4 = 15 below Default anchor: Time-slice Reference point: Vertical: clef hot spot (See Diagram XX). When dependent, use left of symbol for horizontal reference. When an anchor, use center for horizontal reference. Tags: placement tags, Voice ID Custom Graphic Symbol CHUNK Used when a custom graphic is to be placed on the page, with no musical function or sound. value SHORT The index into the Custom Graphic list of an EPS Graphic chunk containing a description of the graphic symbol. Used only within a page or system context. This chunk has no musical sound or function. Default anchor: In System list: system origin. In Page list, page origin. Dynamic CHUNK code BYTE 1 = pppp 2 = ppp 3 = pp 4 = p 5 = mp 6 = mf 7 = f 8 = ff 9 = fff 10 = ffff 11 = sp 12 = sf 13 = sfz 14 = fz 15 = fp 16 = cresc. 17 = crescendo 18 = dim. 19 = diminuendo When a change in dynamic is to occur over a range (such as with values 16 - 19), the Dynamic chunk can be a multi-node symbol, indicating the start and end of the range. The Line Quality tag can be included on the start node, normally with a value of dashes. Default anchor: Part/Time-slice Reference point: Bottom left of text string. Tags: multi-node symbol tags, Line Quality Figured Bass CHUNK text description STROFFSET Used to describe the numerals and accidentals of a basso continuo. These chunks are interspersed with the other music symbols of the staff to which it belongs (such as in a harspichord part). Each chunk is composed of an ASCII character string with the following interpretation: What to type Description digits 0-9 the numerals themselves @ (at sign) a flat sign # (pound sign) a sharp sign - (dash) a natural sign \ (backwards slash) the previous numeral is altered with a slash (for chromatic alteration) / (forward slash) the following characters appear at the next stacking level below Default anchor: Stem Reference point: bottom left of first symbol Fingering CHUNK shape BYTE 0 = finger 0 1 = finger 1 2 = finger 2 3 = finger 3 4 = finger 4 5 = finger 5 Default anchor: Notehead chunk Reference point: Bottom left of text character Glissando CHUNK EMPTY Used to describe a line that functions as a glissando, a rapid swoop from a lower to a higher note passing all half-steps in between. Normally a multi-node symbol anchored to two Notehead chunks. Use the Line Quality tag to specify anything other than a wavy line. Default anchor: Notehead chunk Reference point: endpoint of line Tags: Line Quality, Thickness Guitar Grid CHUNK The guitar grid symbols placed above a staff. The guitar grid offset in the Setup Section Part Description, if any, specifies the default vertical placement for this guitar grid symbol. Guitar Grid chunks are interspersed with the music symbols of the part in the Data Section Staff list. To display a prepared PostScript graphic, use the Custom Graphic Symbol chunk instead of the Guitar Grid chunk. number of frets BYTE The number of frets of the guitar fingerboard represented by the grid. number of strings BYTE 6, for guitar. Could be another value, such as 4, for ukele. The length of the text description is the same as the number of strings (i.e., for guitar, the text description is 6 digits, ABCDEF). text description STROFFSET A number represented as an ASCII character string ABCD..., where A refers to the lowest string, B the next, and so on. The numbers in the text description indicate on which fret the dot is to be placed. The number 9 will create an open circle above the grid indicating a higher fret. The number 0 represents an open string. Examples: (See table to be added) Default anchor: Event Time-Slice Reference pt: The bottom left of the grid symbol Guitar TAB Number CHUNK Used to indicate numbers to be placed on a guitar tablature staff. number BYTE The ASCII representation for the number, normally 0-6. staff step SIGNEDBYTE Indicates the string line on which the number is to be placed, specified in staff steps. For traditional guitar tablature notation, even numbers should always be used. Default anchor: Notehead Reference pt: The center of the bounding box of the number. Tags: Voice ID Hairpin CHUNK direction BYTE 1 = open to left 2 = open to right Normally a hairpin would be a multi-node symbol. The direction field should have a value of 0 for all nodes but the first. The Height tag can be used to specify the vertical distance between the end points on the open node. Default anchor: Time-slice Reference point: See Discussion Section, Reference Points, Multi-node Symbols, for details. Tags: Hairpin Direction, Thickness, Height Harp Pedal Symbol CHUNK pedal positions STROFFSET A 7 digit ASCII character string ABCDEFG representing a Salzedo diagram, where each letter represents one of the seven harp pedals, A, B, and C on the left, and D, E, F and G on the right. Each digit can have a valueof 1, 2, or 3, depending on whether the pedal is in the bottom (sharp) position, the middle (natural) position, or the top (flat) position. Examples: 1222121 3332123 1111111 Default anchor: Time-slice Reference point: Vertical center, horizontal left of diagram. Key Signature CHUNK standard code SIGNEDBYTE 0 = no sharps or flats 1-7 =1-7 sharps 8-14 = 1-7 flats -1 - -7 = 1-7 naturals in the sharp positions -8 - -14 = 1-7 naturals in the flat positions Explicit cancellation of the previous key signature is indicated with a Key Signature chunk containing a negative value, preceding the new Key Signature chunk. The key signature affects the pitch of the notes for MIDI playback. Default anchor: Time-slice Reference point: Vertical: staff origin. Horizontal: left of leftmost symbol. Key Signature - Nonstandard CHUNK number of chunks BYTE Indicates the start of a nonstandard key signature. This chunk is followed by a series of graphical chunks such as NIFF Font Symbol chunks, Custom Graphic Symbol chunks, or Text chunks, each one representing a character to be printed. The number of chunks following this one is given in the number of chunks field. The referenced chunks are to be considered only in the context of the key signature, and are otherwise devoid of function. Each referenced chunk contains its own placement information. If placement information is absent, the symbols are to be placed from left to right. The Width tag indicates the width of the entire key signature, from the left of the leftmost symbol to the right of the rightmost one. Example: To place a sharp sign on the top line, store this chunk with a number of chunks of 1. Following it, store an Accidental chunk with a shape of sharp sign and a Staff Step tag of 8. Default anchor: Time-slice Reference point: Vertical: staff origin. Horizontal: Left of leftmost symbol's bounding box. Line CHUNK shape BYTE Used on each node, to describe the characteristics of the line at that node. 0 = no unusual feature 1 = arrowhead at node 2 = down-jog at node 3= up-jog at node Normally a multi-node symbol. The Line Quality tag is used to indicate such features as dashed, dotted or wavy. For glissando or portamento functions, use Glissando or Portamento chunks. Default anchor: Time-slice Reference point: Endpoint of line at each node Tags: multi-node symbol tags, Glissando, Portamento, Anchor Override, Thickness, Line Quality Lyric CHUNK text STROFFSET A text string representing a word or syllable. For a lyric which extends beyond one time-slice, a multi-node lyric should be constructed. On each node but the first, the text pointer should be given the value -1. The Line Quality tag should be used on the first node, to indicate the graphical technique used to extend the word. If the word is split into two syllables, each in a separate time-slice, the text of the first syllable can be followed by a backslash "\" and then a hyphen. This indicates that a hyphen is to be horizontally centered between the two syllables. When a lyric is to be left justified rather than centered, the Reference Point Override tag can be used. Lyric Verse ID BYTE Associates this Lyric chunk with a particular Lyric Verse Offset tag on the Setup Section Part Description. If there is more than one Lyric within a Time-Slice, the Lyric Verse ID must be different on each. An Anchor Override = stem can be used to relate a lyric to a chord. Default anchor: Notehead Reference point: Center of text string Tags: Font ID, Line Quality, Reference Point Override Measure Numbering CHUNK Used to set or change the measure numbering scheme anywhere in the score. Stored after a measure-start Time-Slice chunk in the first Staff list of a System list. The instructions given in this chunk are in effect until the end of the score, or until the next Measure Numbering chunk, whichever comes first. The numbering of alternate endings is left to the default of the reading program, unless explicitly indicated by the writing program with Measure Numbering chunks. Only logical placement options can be specified for this chunk. If precise placement of numbers is desired, use the Rehearsal Mark chunk instead. number which measures BYTE 0 = no measure numbering 1 = use number frequency field 2 = number start of each system 3 = number start of each page number frequency BYTE How frequently measure numbers are to appear. 1 means every measure, 2 means every other measure, etc. starting number SHORT The number to be used for the measure starting with the current measure-start Time-Slice. font ID FONTPTR The font, size and style to be used for measure numbers. above or below BYTE 0 = above top staff of system 1 = below bottom staff of system horizontal centering BYTE 0 = centered at barline 1 = to left of barline 2 = to right of barline 3 = to left of start of system (number which measures = 2 or 3 only) enclosure BYTE 0 = none 1 = box 2 = circle MIDI Data Stream CHUNK Used to record a free-form stream of MIDI events. When its sound is associated with more than one notational symbol, it is a multi-node symbol, with each node anchored to a symbol chunk. In this case, its first node contains the full MIDI data stream in the value field, and all other nodes contain a null value field. Otherwise it contains only one node. It replaces any explicit or implied MIDI Performance of the chunks to which it is anchored. If anchored to a Time-Slice, it is independent of any notational element. See General Discussion of MIDI Integration for more details. start time BYTE Start time of the stream, given in MIDI clocks, as an offset from the logical start time of its anchor. value char[] The MIDI data stream. Its length is equal to the chunk size minus 1. Default anchor: preceding chunk Tags: Multi-node symbol tags NIFF Font Symbol CHUNK A standard music font character that is to be placed on page or system outside of a staff, without its normal sound or function. Any of the music symbols normally indicated with a music symbol chunk can be represented this way. This chunk can be used within a Page list or a System list but not in a Staff list. One example of its use is withiin the list of characters following a Tempo Marking Nonstandard chunk. For notes and stems, use the normal syntax of a stem followed by one or more notes, with the Height tag optionally added to the stem to indicate its precise length. The same tags can be added to the NIFF Font Symbol chunk as to the ordinary music symbol chunks, such as Number of Flags, and Small Size. chunk type FOURCC The four character chunk type of the music symbol, such as STEM, NOTE, ORNM, or ARTC. space height SHORT The size of the character, given as the height in absolute units of a space on a staff on which the character would appear of normal size. shape BYTE The value of the shape field in the chunk of type chunk type. For example, for a filled notehead, the value of shape would be 4. If there is no shape field on the referenced music symbol, leave shape 0 on this chunk. Default anchor: In system list: system origin. In page list, page origin. Reference point: The middle of the symbol's bounding box. Notehead CHUNK shape BYTE 1 = breve (double whole) 2 = whole 3 = half (open) 4 = filled (solid) 5 = open diamond 6 = solid diamond 7 = x notehead 8 = open x notehead 9 = filled guitar slash 10 = open guitar slash 11 = filled square 12 = open square 13 = filled triangle 14 = open triangle staff step SIGNEDBYTE See Discussion Section - Measurement Units duration RATIONAL See Discussion Section - Timing Representation Default anchor: Time-slice Default reference pt: The center of the bounding box of the notehead. Tags: Part ID, Voice ID, placement tags, MIDI Performance, Grace Note, Cue Note, Small Size, Large Size, Invisible, Split Stem, Silent Octave Sign CHUNK Normally a multi-node symbol indicating that all symbols in the Staff list between the first and last nodes are to be performed one or two octaves higher or lower than as written, or, in the case of coll' ottava, are to be doubled at the octave above or below. Only a starting and ending node are required, unless the octave marking extends beyond a system boundary (see multi- node symbols). One or more Voice ID or Part ID tags can be appended to the first node, indicating that only the specified voices or parts are affected. The function is active until its final node is encountered in the file. On all nodes but the first, the meaning of the fields can be ignored, and should be stored as null. Placement tags are used to indicate where the symbol appears in relation to the staff. The Line Quality tag should be used if anything besides a dashed line is desired. number of octaves BYTE Normally 1 or 2. above or below BYTE To be performed above or below the notated symbols. 1 = above 2 = below type BYTE 1 = notated symbols to be transposed one or more octaves 2 = notated symbols to be doubled (coll' ottava) text string STROFFSET The text string appearing at its start, such as "8va" or 8 or "8a alta" Tags: Line Quality Ornament CHUNK shape SHORT 1 = mordent 2 = inverted mordent 3 = double "long" mordent 4 = inverted double "long" mordent 5 = turn 6 = inverted turn 7 = trill (spelled "tr") 8 = trill (short symbol - 2 bumps) 9 = trill (short symbol - 3 bumps) 10 = trill (long wavy line) 11 = long trill with up-hook at start 12 = long trill with down-hook at start Accidental chunks may be anchored to an ornament, with placement tags indicating above or below, usually with a Small Size tag. The long trill symbols (shapes 9, 10, 11) are multi-node, anchored to the start and end anchors of the trill. Default anchor: Stem Reference Point: Center of symbol Parenthesis CHUNK shape BYTE 1 = left parenthesis '(' 2 = right parenthesis ')' 3 = left brace - '{' 4 = right brace '}' 5 = left bracket '{' 6 = right bracket '}' 7 = left and right parentheses surround anchor 8 = left and right braces surround anchor 9 = left and right bracket surround anchor The default size of the symbol(s) is the reading program's default for the given context. By default symbols 1, 3 and 5 should be placed to the left of the anchor, and symbols 2, 4, and 6 to the right of the anchor. A Parenthesis can be a multi-node symbol, for instance when parentheses surround a series of staccatos over a series of notes. This would allow the sequence of staccatos to be understood as logically grouped by the parentheses. Default anchor: Preceding symbol chunk. Reference point: bottom left of text character Tags: multi-node symbol tags Pedal (Piano) CHUNK Normally a multi-node symbol with two nodes, the starting node indicating where to depress the pedal, and the ending node indicating where to release it. Each node should use the appropriate shape node. For half-pedal markings, a node should be stored at each time-slice where the line has a notch. shape BYTE 0 = no graphic (for last node, when no graphical symbol appears there) 1 = "Ped." (graphic) 2 = Asterisk (*) indicating end of damper pedal 3 = alternate end of damper pedal symbol (circle with cross-hairs) 4 = horizontal line with up-jog at this node 5 = horizontal line with down-jog at this node 6 = upslanted line with up-jog at this node 7 = upslanted line with down-jog at this node 8 = notch in line at this node 9 = "una corda" text 10 = "tre corde" text 11 = "S.P. " text (sostenuto pedal) Pedal (Organ) CHUNK shape BYTE 1 = heel (u shape) 2 = heel (o shape) 3 = toe ( up-pointed wedge) 4 = toe (down-pointed wedge) This chunk is interspersed with the music symbols on the organ pedal staff. The Logical Placement tag is used to place these symbols above or below the staff, to indicate right foot or left foot. The line or slur sometimes connecting two organ pedal symbols is represented by multi-node Line or Slur chunks anchored to the organ Pedal chunks. Default anchor: Stem Portamento CHUNK EMPTY Used to describe a line that functions as a portamento, a rapid swoop from a lower to a higher note smoothly over all intervening frequencies. Normally a multi-node symbol anchored to two Notehead chunks. Use the Line Quality tag to specify anything other than a straight line. Default anchor: Notehead chunk Reference point: endpoint of line Tags: Line Quality, Thickness Rehearsal Mark CHUNK The rehearsal letters or numbers placed above a staff . The rehearsal mark offset in the Setup Section Part Description, if any, specifies the default vertical placement for this rehearsal mark. Rehearsal Mark chunks are interspersed with the music symbols of the part in the Data Section Staff list. text string STROFFSET The letter(s) or number(s). enclosure BYTE 0 = none 1 = box 2 = circle Default anchor: Time-slice Reference point: top left of bounding box Tags: Font ID, placement tags Repeat Sign CHUNK Logical and graphical components of a repeat sign. Indicates the start or end of a section to be repeated, or the repetition of a previous beat, measure or measures. graphical code SHORT 0 = no graphical symbol - this is only a logical chunk 1 = Segno symbol :S: 2 = Coda symbol (circle with crosshairs) 3 = one slash (such as with logical code 3 or 7) 4 = 2 slashes (such as with logical code 3) 5 = 3 slashes (such as with logical code 3) 6 = 2 slashes with dot on either side (such as with logical code 3) 7 = 1 slash with dot on either side (such as with logical code 4) 8 = 1 slash with dot on either side, and barline through it (such as with logical code 5) 9 = 2 slashes with dot on either side, and barline through it (such as with logical code 5) 10 = Repeat dots - use Barline chunk(s) with this 11 = "D.C." 12 = "D.C. al Fine" 13 = "D.C. al Segno" 14 = "D.C. al Segno e poi la Coda" 15 = "D.S." 16 = "D.S. al Fine" 17 = "Fine" 18 = "Coda" logical code BYTE 0 = no repeat function - this is only a graphical chunk 1 = beginning of section to be repeated 2 = end of section to be repeated 3 = repeat the previous beat 4 = repeat the previous measure 5 = repeat the previous two measures 6 = function as described by words (graphical codes 12 - 19) 7 = repeat chord indicated by associated Chord Symbol for one beat A text chunk should be anchored to this chunk if a number over a slash repeat sign is to appear here. For "bis" surrounded by brackets, logical codes 1 and 2 should be used at the start and end of the section, respectively, with graphical code zero. The graphical elements (brackets and the word "bis") should be constructed with Line and Text chunks. See also Alternate Ending Graphic chunk and Alternate Ending tag, and General Discussion of Repeats and Alternate Endings, which gives an example. Default Anchor: Time-slice Reference pt: top center of symbol Rest CHUNK shape BYTE 1 = breve (double whole) 2 = whole 3 = half 4 = quarter 5 = eighth 6 = sixteenth 7 = 32nd 8 = 64th 9 = 128th 10 = 256th 11 = multiple rest symbol - 4 measures 12 = multiple-measure rest - thick horizontal bar (normally used with dependent text chunk containing a number, and possibly with Width and Thickness tags) 13 = multiple-measure rest - thick slanted bar (same options as shape 11) 14 = vocal breath mark (comma) 15 = vocal breath mark (2 small slashes) staff step SIGNEDBYTE See Discussion Section - Measurement Units duration RATIONAL See Discussion Section - Timing Representation Default anchor: Time-slice (event type) Reference point: Hot spot of rest - see Diagram XX. Slur CHUNK EMPTY A simple slur is a multi-node symbol with start and end nodes. The Tie Direction tag can be used on the first node of the slur to indicate whether the slur is bowed up or down. The standard placement tags when used on each slur node, indicate the placement of the slur endpoint relative to its anchor. Bezier Incoming and Bezier Outgoing tags can be used to specify Bezier control points for each node. A complex slur can be built by storing any number of slur nodes, each with its own Bezier Incoming and Outgoing control points. Default anchor: Stem Reference point: The slur end point. If a dependent symbol is centered relative to a 2 node slur, the slur's horizontal reference is the center, and the vertical reference is the lowest or highest point of the arc, for slurs bowed downward or upward, respectively. Centering of dependent symbol is undefined for cross-system slurs (which have more than two nodes). Tags: multi-node symbol tags, Tie Direction, Bezier Incoming, Bezier Outgoing Stem CHUNK EMPTY The end point of the stem is the end to which a flag or beam would be attached. When its position is known, it is indicated using one of the vertical placement tags. For whole notes and stemless rhythm slashes, a Height tag of zero should always be used. The Split Stem tag, when required for altered unisons, should be applied directly to the affected Notehead chunks rather than to the Stem chunk. Use the LogicalPlacement tag to represent stem direction. (This tag is optional, since not all notation programs store stem direction.) Default anchor: Time-slice Reference point: End point of stem (where the flag or beam would be attached). Tags: Placement tags, Voice ID, Part ID, multi-node symbol tags, Height, Small Size, Large Size, Cue Note, Grace Note, Silent System Separation Mark CHUNK Used in ensemble scores to vertically separate systems. Should be stored immediately following the System Header chunk. BYTE 1 = placed at left margin 2 = placed at right margin Default anchor: System origin Reference point: Center of symbol's bounding box Tag Activate CHUNK EMPTY This chunk can be stored at the start of a series of chunks to indicate that each of its tags are to be applied to all of the chunks appearing between it and a matching Tag Inactivate chunk. If a Part ID or Voice ID tag appears on it, this restricts its scope to chunks of that part or voice. See General Discussion for details and examples. Tag Inactivate CHUNK EMPTY This chunk is used to end the application of tags started with a Tag Activate chunk. Each tag can be ended independently of the others with its own Tag Inactivate chunk, or they can be grouped together. See General Discussion for details and examples. Tempo Marking CHUNK A standard tempo marking either in the form [note] = [metronome setting], or text tempo instructions. text string STROFFSET Used for text instructions such as "Allegretto". If ia special font or italics are required, append the Font ID tag. note value RATIONAL The note value representing one beat. See discussion of Timing Representation for values. If only text is desired, leave this 0/0. beats per minute SHORT The metronome setting, where one beat is equal to a note with duration of note value. If only text is desired, leave this 0. Example: [dotted quarter] = 72 text string -1 note value 3/8 beats per minute 72 Default anchor: Time-slice (most recent one of any type) Reference point: Bottom left of bounding box. Tags: Font ID Tempo Marking Nonstandard CHUNK number of chunks BYTE Indicates the start of a tempo marking. This chunk is followed by a series of graphical chunks such as NIFF Font Symbol chunks or Text chunks, each one representing a symbol or word to be printed. The number of chunks following this one is given in the number of chunks field. The referenced chunks are to be considered in the context of the tempo marking, and are otherwise devoid of function. Each referenced chunk contains its own placement information. If placement information is absent, the symbols are to be placed from left to right. The Width tag indicates the width of the entire tempo marking, from the left of the leftmost symbol to the right of the rightmost one. Example: Allegro moderato (M.M. [dotted eighth note] = 72) Tempo Marking Nonstandard, number of chunks = 5 Text, string="Allegro moderato (M.M." NIFF Font [Stem] NIFF Font [Notehead, shape=4], number of flags=1 NIFF Font [Augmentation Dot] Text, string = "= 72)" Default anchor: Time-slice (most recent one of either type) Default reference point: Bottom left of bounding box. Tags: placement tags, Width Text CHUNK value STROFFSET A text string. By default, the bottom left of the text string is placed at the anchor's reference point. The Font ID tag can be used to specify the font. Text can be centered or justified by use of the Reference Point Override tag. Default anchor: Time-slice Reference point: bottom left Tags: Font ID Tie CHUNK EMPTY Normally a tie would have two nodes. The Tie Direction tag is used on the first tie node to indicate which direction the tie is bowed. The standard placement tags when used on each tie node, indicate the placement of the tie endpoint relative to its anchor symbol reference point. Default anchor: Notehead Reference point: The tie end point. If a dependent symbol is horizontally centered relative to the tie, the tie's horizontal reference is the center, and the vertical reference is the lowest or highest point of the arc, for ties bowed downward or upward, respectively. Tags: multi-node symbol tags, Tie Direction, Bezier Incoming & Outgoing Time Signature CHUNK top number SIGNEDBYTE bottom number SIGNEDBYTE The common non-numeric time signatures are represented as follows: "common time" symbol: top number = -1, bottom number = -1 "cut time" symbol: top number = -2, bottom number = -1 For a single number time-signature, use the top number, and set the bottom number to -1. To place an ordinary time-signature above the staff, use the Logical Placement tag, vertical component = above. To place it between the staves, use the Logical Placement tag, vertical component = below, and omit the Time Signature chunk in the lower staff. Default anchor: Time-slice Reference point: Vertical: staff origin. Horizontal: center of bounding box. Tags: Placement tags, Large Size, Small Size Time Signature - Nonstandard CHUNK number of chunks BYTE Indicates the start of a nonstandard time signature. This chunk is followed by a series of graphical chunks such as NIFF Font Symbol chunks, Custom Graphic Symbol chunks, or Text chunks, each one representing a character to be printed. The number of chunks following this one is given in the number of chunks field. The referenced chunks are to be considered only in the context of the time signature, and are otherwise devoid of function. Each referenced chunk contains its own placement information. If placement information is absent, the symbols are to be placed from left to right. The Width tag indicates the width of the entire key signature, from the left of the leftmost symbol to the right of the rightmost one. A special case of the Time-Signature - Nonstandard chunk is when it has a single text chunk starting with the backslash character "\". In this case, the ASCII string following the backslash is a string of numbers and '+', '/' and ' ', interpreted as follows: '+' represents the literal plus sign '/' means place the previous number(s) above the following number(s) ' ' means leave space between the previous and following number(s). Examples of special case: \2+4/8 \2/8 4/8 Default anchor: Time-slice Default reference point: Vertical: staff origin. Horizontal: Left of leftmost symbol's bounding box. Tremolo CHUNK Normally multi-node with two nodes. For a single stem tremolo with slashes through the stem, there will be a single node, with attached beam parts containing the number of slashes, and unattached beam parts zero. For whole note tremolos, set attached beam parts to zero, and use unattached beam parts. The presence of a Tremolo chunk affects the playback of the related Notehead chunk. The duration on each Notehead should be assigned such that the total duration of all Noteheads belonging to the tremolo equals the total duration of the notes on playback. attached beam parts BYTE The number of beams attached to the stem (primary beams). unattached beam parts BYTE The number of beams not attached to the stem (secondary beams). Default anchor: Stem Reference point: Reference point of anchor. Tags: multi-node symbol tags Tuplet CHUNK EMPTY A tuplet node chunk is placed with each stem or rest belonging to the tuplet. Normally a multi-node symbol. TheTuplet Description tag is required on the first node. Default anchor: Stem Tags: Tuplet Description, multi-node symbol tags Tags in alphabetical order Absolute Placement STRUCTURE horizontal SHORT vertical SHORT Non-default horizontal and vertical placement, in absolute units, of the dependent symbol's reference point relative to the anchor's reference point. Logical Placement and Offset Placement are mutually exclusive. Alternate Ending BYTE The sequence number of the ending. Used on the first measure-start Time-Slice chunk of each alternate ending to validate the duplicate start time values. See also Alternate Ending Graphic chunk and Repeat Sign chunk, and the General Discussion section of Repeats and Alternate Endings, which includes an example. Anchor Override FOURCC Contains the chunk typeof the non-default anchor symbol. Articulation Direction BYTE Used on the Articulation chunk to specifically indicate a particular version of the articulation symbol, such as fermata or strong accent. 1 = pointed up 2 = pointed down Bezier Incoming STRUCT Used on a slur node to specify an incoming Bezier control point. Gives the horizontal and vertical placement of the incoming Bezier control point relative to the slur endpoint. Can also be used on a tie node. See also Bezier Outoing tag. horizontal SHORT vertical SHORT Example 1 - slur anchored to two notes: Stem Notehead Slur, ID=1, Number of Nodes=2, Absolute Placement= (H1, V1), Bezier Outgoing = (H2, V2) Stem Notehead Slur, ID=1, Absolute Placement= (H3, V3), Bezier Incoming = (H4, V4) Example 2 - slur anchored to three notes (such as when it starts below an upstem note, swings up over the top of a down stem note, and then back down below another upstem note): Stem Notehead Slur, ID=2, Number of Nodes=3, Absolute Placement = (H1, V1), Bezier Outgoing = (H2, V2) Stem Notehead Slur, ID=2, Absolute Placement = (H3, V3), Bezier Incoming = (H4, V4), Bezier Outgoing = (H5, V5) Stem Notehead, ID=2, Absolute Placement = (H6, V6), Bezier Incoming = (H7, V7) Bezier Outgoing STRUCT Used on a slur node to specify an incoming Bezier control point. Gives the horizontal and vertical placement of the incoming Bezier control point relative to the slur endpoint. See Bezier Incoming tag for examples. horizontal SHORT vertical SHORT Horizontal and vertical placement of the outgoing Bezier control point relative to the slur endpoint. Chord Symbols Offset SHORT Used on the Part Description chunk, to specify the default vertical placement of chord symbols with respect to the top staff of the part, in absolute units. In the Data Section, Chord Symbol chunks are interspersed with the music symbols of the first (top) staff of the part. Custom Font Character STRUCT Used on a music symbol chunk to indicate that a nonstandard character and font is to be used. The function of the music symbol chunk is otherwise unchanged. font ID FONTPTR character code char[2] Custom Graphic SHORT Used when a custom graphic is to be used in place of the standard appearance of the music symbol. value SHORT The index into the Custom Graphic list of an EPS Graphic chunk containing a description of the graphic symbol. End Of System EMPTY Used to indicate that the chunk is located at the rightmost end of a system. This could be used at the end of a system on a Barline symbol in place of a horizontal offset, to avoid the undesirable results of rounding errors or font-width errors. It could be used at the end of a system where no barline is present, on an event Time-Slice chunk used as an anchor for a dependent symbol. To indicate the continuation of a multi-node chunk onto another system, use the Multi-node End Of System and Multi-node Start Of System tags instead. Fanned Beam SHORT Used on the first node of a Beam to indicate an accelerando or ritard. On first beam node only. 1 = fanned beam expanding toward right 2 = fanned beam shrinking toward right Figured Bass Offset SHORT Used on the Part Description chunk, to specify the default vertical placement of the top numeral of figured bass symbols with respect to the bottom staff of the part, in absolute units. In the Data Section, Figured Bass chunks are interspersed with the music symbols of the last (bottom) staff of the part. Font ID FONTPTR Used to indicate that a nondefault font is to be used for the chunk on which this tag occurs. Can be used on any music symbol or text-type chunk. Gives the index into the Font list, of the font to be used. Grace Note RATIONAL Used on a Stem, Notehead, or Rest. Indicates the logical start time as an offset from the time-slice start time. Negative values indicate that the grace note starts before the time slice, so during playback it should sound before the note. Zero and positive values indicate that the grace note's time value is stolen from the following note in the same voice. Guitar Grid Offset SHORT Used on the Part Description chunk, to specify the default vertical placement of guitar grid symbols with respect to the top staff of the part, in absolute units. In the Data Section, Guitar Grid chunks are interspersed with the music symbols of the first (top) staff of the part. Guitar Tablature EMPTY Used on a Staff Header chunk to indicate that the staff is guitar tablature, and its symbols should be interpreted accordingly (not used for playback). Height SHORT Vertical height, in absolute units. ID SHORT Identification number. Used to uniquely identify multi-node symbols. Should be assigned sequentially within a chunk type, starting with zero. Invisible EMPTY When this tag is used on a symbol, the symbol's function and/or sound is unchanged, but the symbol does not appear visibly in the score. Large Size EMPTY Indicates that the symbol is larger than default size. For more precise control of size, use the Font ID tag instead. Line Quality BYTE Used on symbol chunks such as Barline, Line, or Slur to indicate that the line is not solid. 0 = no line 1 = dotted line 2 = dashed line 3 = wavy line Logical Placement STRUCTURE Non-default horizontal and vertical logical placement of the dependent symbol's reference point relative to the anchor's reference point. Logical Placement and Offset Placement are mutually exclusive. horizontal BYTE 0=default 1=left 2=right 3 = stem side 4= note side 5 = centered Values 3 and 4 are only to be used on a symbol dependent on a note or stem. "Stem side" and "note side" have the same meaning as "left" and "right" respectively for down stems, and the opposite for up stems. vertical BYTE 0=default 1=above 2=below 3 = stem side 4= note side 5 = centered Values 3 and 4 are only to be used on a symbol dependent on a note or stem. "Stem side" and "note side" have the same meaning as "above" and"below" respectively for up stems, and the opposite for down stems. proximity BYTE 0= not applicable, or default 1 = touching, or exactly aligned 2 = offset slightly Used to refine the meaning ofNon-default logical placement of the symbol's bounding box relative to the anchor's bounding box. For instance, a note slightly offset from a stem would be given the value 2. Lyric Verse Offset STRUCT This tag is appended to the Part Description chunk in the Setup Section, to define the vertical offset and Lyric Verse ID of one line of lyrics. Any number of them can be present. lyric line offset SHORT Default vertical placement of a line of lyrics with respect to the bottom staff of the part, in absolute units. A null value (-1) is allowed, even when Lyric chunks are present in the Data Section. In the Data Section, Lyric chunks are interspersed with the music symbols of the part in the Staff lists. Lyric Verse ID BYTE Used to associate the Lyric Verse ID field on Lyric chunks in the Data Section with the default vertical offset supplied here. MIDI Performance STRUCT Used on note chunks. See Timing Representation in the Discussion Section, for a description of its use. start time RATIONAL Start time, given in MIDI clocks, as an offset from the time-slice duration RATIONAL Duration, given in MIDI clocks pitch BYTE MIDI pitch (0-127) velocity BYTE MIDI velocity (0-127) Multi-node End Of System EMPTY Used on a node of a multi-node symbol to indicate that the symbol continues on the following system. The node containing this tag will always be paired with a node with the Multi-node Start Of System tag, located at the beginning of the following system. A reading program that does not have a system break at the same measure can ignore both nodes and use just the logical start and end nodes of the multi-node symbol. Multi-node Start Of System EMPTY Used on a node of a multi-node symbol to indicate that this is the continuation of a symbol which started on the previous system. See Multi-node End Of System tag for more details. Number of Flags BYTE Number of flags on stemmed note. Number Of Nodes SHORT Total number of nodes in file for this multi-node symbol. Always present on the first node chunk of any multi-node symbol. Number of Staff Lines BYTE Non-default number of lines in a staff, used on the Staff Header. The default number is 5. This should be used for guitar tablature, with a value of 6, and for percussion parts, with a value of 1. Ossia BYTE Used on one or more Staff Header chunks in a system to indicate an alternate performance of another staff or staves. The Part ID and/or Voice ID of the symbols in the ossia staff or staves duplicate those in the staff or staves to which the ossia is an alternative. See General Discussion on ossias for more details. 0 = do not playback the ossia - for display only 1 = playback the ossia instead of the staff to which it is an alternative Part Description Override STRUCT Used with Part ID on any chunk where Part ID can be specified, such as a Tag Activate/Inactivate, Staff Header or a music symbol chunk. It overrides the default characteristics of the part given in the Setup Section Part Description chunk. Its scope depends on the chunk type on which it appears. MIDI channel SIGNEDBYTE Use -1 to specify none. MIDI cable SIGNEDBYTE Use -1 to specify none. transpose SIGNEDBYTE Number of halfsteps to transpose this part during playback. Part ID SHORT 0-32767. Used to associate chunks in the Data Section with a particular Part Description chunk in the Setup Section When used on a Staff Header chunk, it indicates that all symbols within the Staff list belong to the part. It can also be used on a Tag Activate or Tag Inactivate chunk to restrict the scope of those chunks (see general discussion of Tag Activate/Inactivate). When this tag is applied to an anchor, its scope includes all symbols dependent on the anchor. Reference Point Override STRUCTURE Description of non-default reference points on the anchor and dependent symbols. Always used in combination with either Offset Placement or Logical Placement tags. anchor h BYTE dependent h BYTE 0 = the symbol's default horizontal reference 1 = left of symbol's bounding box 2 = right of the symbol's bounding box 3 = horizontal center of the symbol's bounding box anchor v BYTE dependent v BYTE 0 = the symbol's default vertical reference 1 = top of symbol's bounding box 2 = bottom of the symbol's bounding box 3 = vertical center of the symbol's bounding box Rehearsal Mark Offset SHORT Used on the Part Description chunk, to specify the default vertical placement of the rehearsal mark with respect to the top staff of the part, in absolute units. In the Data Section, Rehearsal Mark chunks are interspersed with the music symbols of the first (top) staff of the part. Rest Numeral SHORT Number that is to appear centered over multiple-measure rest symbol Silent EMPTY When this tag is used, the sound is suppressed for the symbol. The function of the symbol is other wise unchanged: it appears visibly in the score, and its duration is set as normal for use by a spacing algorithm. A cue note is one example of its use. Slashed Stem EMPTY Indicates the presence of a slash on a stem, as in a grace note. For Tremolo slashes, use Tremolo chunk. Small Size EMPTY Indicates that the symbol is smaller than default size. Examples of its use are on a Clef chunk for clef changes, on a Stem, Notehead or Rest chunk with the Grace Note tag for small grace notes, and on a Stem, Notehead or Rest with the Silent tag, to indicate a cue note or rest. For more precise control of size, use the Font ID tag instead. Spacing By Part EMPTY This tag is added to the NIFF Information chunk to indicate that a special horizontal spacing scheme is used. In this scheme, the symbols of each part are assigned horizontal placement values independently of the other parts, as though the file contained a set of part scores instead of or in addition to one ensemble score. Each part's symbols are stored with the minimum size requirement for displaying those symbols when only that part is present. To produce correct spacing of an ensemble score recorded with this scheme, a reading program would calculate for each time-slice the greatest required width among any of the parts, and use that width for the whole ensemble at that time-slice. A reading program that does not handle this type of spacing scheme should ignore horizontal placement completely, using its own spacing defaults instead. Split Stem EMPTY Used on each Notehead chunk of an altered unison, when a single stem connects two or more notes, usually at the same staff step but different horizontal placements that are more than one notewidth apart. The exact visual appearance depends on the reading program's defaults. Staff Name EMPTY Used on a Text chunk to indicate its function as a name for a staff or staff grouping. This allows the reading program to use intelligent defaults for placement of the text, when no placement tag is supplied. For a staff name, this tag should appear on a Text chunk following a Staff Header chunk. For a grouping name, it should appear on a Text chunk following a Staff Grouping chunk in a Staff Groupings list (in either the Setup Section or the Data Section). Staff Step SIGNEDBYTE Used to indicate vertical placement using the "staff step" units of measurement. Places the symbol's vertical hot spot on the specified staff line or space. If used with Logical Placement or Offset Placement, it overrides the vertical component of those tags. When used on a chunk that has staff step as a required field, such as Notehead or Clef, it overrides the graphical placement of the symbol but not the musical function of the staff step field. Thickness SHORT Used on symbol chunks such as Barline, Line, Hairpin, or Slur, to indicate the thickness of the line, in absolute units. When used on a Rehearsal Mark symbol, it refers to the thickness of the enclosure (box or circle). Tie Direction BYTE Used on Tie chunks and simple Slur chunks, to indicating the bow direction of the curve. 1 = endpoints below, rounded above 2 = endpoints above, rounded below Tuplet Description STRUCT transformation ratio a b RATIONAL transformation ratio c d RATIONAL The four integers in the transformation are applied to the events at each node of the tuplet, as described in Chapter 1, Timing Representation. grouping symbol BYTE 0 = default 1 = number only 2 = number with broken slur 3 = number outside slur 4 = number inside slur 5 = number with broken bracket 6 = number outside bracket 7 = number inside bracket 8 = bracket only 9 = slur only 10 = no symbol Voice ID SHORT 0-32767. Used on music symbols in the Data Section to uniquely identify a voice within the part. As a convention, should be assigned sequentially starting with zero, although voices can appear and disappear at random within a part. Always used in conjunction with Part ID. It can also be used on a Tag Activate or Tag Inactivate chunk to restrict the scope of those chunks (see general discussion of Tag Activate/Inactivate). When this tag is applied to an anchor, its scope includes all symbols dependent on the anchor. Width SHORT Horizontal width, in absolute units. 1 NIFF 6a.1 Chapter 1 - General Discussion 47 NIFF 6a Chapter 3 Elements and Values 68 NIFF 6a Chapter 3 - Elements and Values