September 25, 2001 Changes in NIFF 6b (from NIFF 6a.3) * Reformatted the NIFF spec into HTML with table of contents links. * Added support for a UTF-8 encoded Unicode string following any RIFF ZSTR in the String Table chunk. Therefore any string referred to by a STROFFSET may have a Unicode representation. * In chapter 3, changed Time Slice chunk's reference point to be the top line of the staff, instead of the bottom, to be consistent with the time-slice discussion in Chapter 2, as well as the Staff Header chunk whose anchor is the top line. * Added list, chunk and tag ID's as defined in niff.h. * Added mention of User-Defined chunk in the symbol chunks section. * Added mention of User-Defined tag at the end of the tags section. * In NIFF Information Chunk, changed NIFF version to 6b. * In Custom Graphic SHORT tag, removed redundant mention of "value SHORT". * Corrected references to diagrams in image NIFFspec.egs.jpg. * Added more to Acknowledgements section for work on NIFF 6b. * In chapter 3, Barline chunk removed Thickness from list of relevant tags (since there is no Thickness tag). * In Rest CHUNK, specify normal placement for staff step 4. * Removed references to non-existent "diagram XX" and put entries in the to do list to create these. [The following changes harmonize NIFF 6b with niff.h from the NIFF SDK] * Changed STROFFSET type from 2 bytes to 4 bytes. niff.h has always defined this as 4 bytes, and most implementations write 4 byte STROFFSET. * In the System Separation Mark CHUNK, added missing field name of "where" to the BYTE field. * In MIDI Performance tag, changed "start time" and "duration" to LONG instead of RATIONAL. * Renamed FONTPTR type to FONTIDX. * Added Number Style tag which was in niff.h but not the spec. __________ Oct. 17, 1998. Changes in NIFF 6a.3 (from NIFF 6a.2) * In the Ornament chunk definition, changed the second sentence to read: "The long trill symbols (SHAPES 10, 11, 12) are multi-node, anchored to the start and end anchors of the trill." Now shapes 9, 10, 11 are listed instead. * In the Page List definition, changed the "Required:" line to read: Required: Page header CHUNK (instead of Page Header list) * In the Pedal (Piano) chunk definition, changed the second sentence to read: "Each node should use the appropriate shape BYTE.", instead of "...shape node." * In the Staff Grouping chunk definition, changed the First and Last staff parameters should to range 0-32767, not 1-32767, as they are now. Because as stated below, "The ID numbers are assigned in increasing order starting with Part 0, Staff 0." * Added the following paragraph to the dynamic chunk: Note: NIFF represents only the most common subset of music words and symbols with special chunks and tags. Words and symbols not in the NIFF standard - like for example the rare "fffff" - should be represented as generic text or graphics chunks. Note that single words implying simultaneous change in both dynamics and tempo (calando, slentando, incalzando, morendo, smorzando) can be encoded as text with atatched midi. How about using text with attached MIDI? * Added the following paragraph re pickup bars at the end of the "Logical Start Time" section: Note concerning pickup bars: NIFF has no standard "correct" way to represent such (incomplete preliminary) bars. In particular, scanning programs may not have the intelligence to distinguish a genuinely incomplete bar from a pickup measure. Therefore the writing program has the choice of representing the pickup either as simply a "normal" incomplete bar, or else of representing it "correctly" (in musical terms) as the final portion of a preceding bar. As long as the barline time slice and the following measure time slice contain the same time, it should make little difference on which beats the two pickups are placed. Implementations should be prepared to deal with either of these possible representations of time in a pickup measure. * Changed 12 references from "MIDI clocks" to "MIDI ticks". (This was clearly a confusion on Cindy's part) * In the Repeat Sign Chunk, replaced: "logical code 6: "(graphical codes 12 - 19)" with "logical code 6: (graphical codes 11 - 18) (The codes end at 18.) * In the Rest Chunk, shape 13, replaced: "(same options as shape 11)" , with "(same options as shape 12) (The options are listed in Shape 12, not Shape 11.) * In the Bezier Incoming Tag, the last note of Example 2, now reads as follows: Stem Notehead Slur, ID=2, Absolute Placement = (H6, V6), Bezier Incoming = (H7, V7) (The new line and the word "Slur" were omitted.) * Changed the wording of the Bezier Outgoing tag to read: Used on a slur node to specify an outgoing Bezier control point. Gives the horizontal and vertical placement of the outgoing Bezier control point relative to the slur endpoint. Can also be used on a tie node. See Bezier Incoming tag for examples. (The previous wording referred to "incoming", instead of "outgoing", in the first 2 sentences, and the sentence referring to ties was omitted. Obviously a typo in the original.) * In the Parenthesis Chunk, changed the examples for options 5 and 6 to [ and ] (they were previously { and }, already classified as braces under options 3 and 4). * In the tags section, replaced 4 occurences of the old phrase "offset placement" with "Absolute Placement". (There is no "Offset Placement" tag.) * Changed the text for the Number of Staff Lines tag to read: Non-default number of lines in a staff, used on the Staff Header. (The default number is 5.) For example, a value of 6 would be used for guitar tablature, or a value of 1 for some percussion parts.. The old text read: 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. (There are percussion parts with > 1 lines.) __________ Aug 20, 1998. Changes in NIFF 6a.2 (from NIFF 6a.1). * changed bottom number of Time Signature Chunk to signedbyte to allow for -1 (used for single number time-signatures). * Changed the Tuplet Description Tag by deleting: "number style BYTE 0 = default 1 = first number only 2 = two numbers, with colon between 3 = use number string in text chunk dependent on first tuplet node 4 = no number" so as to remove inconsistency with the NIFF.header file. * revised the barline chunk wording again (undoing the change from NIFF 6a.1) in the light of comments from Lippold Hakken on Lime's implementation, which interprets the original wording in a better way. The final wording is: "Barline CHUNK [...] extends to BYTE 1 = to bottom line of bottom staff indicated by numberofstaves. 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 only so as not to conflict with the NIFF SDK or header file.) 3 = only in spaces between staves (not through staves)" * added the following to the Stem chunk to clarify representation of stem directions: "Use the LogicalPlacement tag to represent stem direction. (This tag is optional, since not all notation programs store stem direction.)" * added the following note to the accidental chunk: (Note: for triple sharps or triple flats, or for the combinations natural+sharp and natural+flat, simply use two accidental chunks.) __________________________________________________________ June 25, 1998. Changes in NIFF 6a.1 (from NIFF 6a). * removed opening paragraph with reference to cartah and Cindy. * removed all refs to Appendices other then A (niff header file). They were never written. * replaced barline chunk material with corrected version. (Essentially, the old mistaken version made it sound like barlines could only be assigned to systems as a whole, rather than parts. This had the effect of making standard barline groupings within a system (e.g. strings, winds, etc.) impossible.) This is the NEW text. (Text between "**" is new. ) Barline CHUNK type BYTE 1 = thin line 2 = thick line extends to BYTE 1 = to bottom line of last staff **of part**. 2 = through the space below the last staff **of part**, to the top line of the next lower staff **in system**. **(This is to allow barlines to continuously connect multiple parts within a system)** 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** last 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.