1 Common MUsical Score
\r\r/* ========================================================================= *
\r CMUS - Common Musical Score
\r\r An IFF File format for interchanging
\r musical data using Common Music Notation
\r\r by Talin (David Joiner)
\r\r Verion 0.4
\r * ========================================================================= */
\r\r#ifndef CMUS_H
\r#define CMUS_H
\r\r/* ========================================================================= *
\r Note to Non-Amiga users of this document
\r ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r CMUS is an IFF (Interchange File Format) file. IFF is a "Meta-standard"
\r for making extensible, self-identifying file formats, and was developed
\r by Commodore and Electronic Arts. In order to understand CMUS you will
\r need to get the IFF Documentation. The quickest way to do this is to
\r get the "Amiga ROM Kernal Manual: Devices" volume and look in the Appendix.
\r * ========================================================================= *
\r Note on Timing:
\r ~~~~~~~~~~~~~~~
\r Common Music Notation is a symbolic, rather than a literal
\r representation. It is supposed to be interpreted by the player. A note
\r which is listed as "A quarter note", will seldom be played at the exact
\r time or duration as written. These deviations from mathematically perfect
\r time are important; they are part of what musicians call "feel" or
\r "liveliness".
\r Accordingly, FORM CMUS has two different kinds of timing information.
\r _Formal Time_ is represented in symbolic form: Each symbol has a field
\r which indicates it's duration (dotted quarter-note, etc) in symbolic units.
\r The formal start time of an event can be obtained by summing the durations
\r of all the previous times in the measure.
\r In addition, there is also _Casual Time_. Each event has a "start time"
\r which is the number of basic clock units from the start of the measure to
\r the start of that event. Some event types also have "duration" fields of
\r a similar nature.
\r In general, although there will probably be a strong correlation
\r between formal time and casual time, there is no guarantee of this.
\r Certainly this FORM does not enforce any relationship between the two.
\r This means that you cannot, in general, derive one from the other. You can
\r at most make an educated guess, and even that is a non-trivial problem
\r from an algorithmic point of view.
\r\r * ========================================================================= *
\r Note on Layout Measurements:
\r ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r In general, I have tried to make all measurements as "device-
\r independent" as possible.
\r\r Measurements of page dimensions and other page-related information
\r such as margins and indentations are represented in micrometers.
\r Converting from micrometers to inches and "big points" (the definition
\r of points used by Adobe and Apple) can be done with the following
\r formulas:
\r\r inches = micrometers / 25400;
\r\r points = micrometers * 72 / 25400;
\r\r Vertical distances of musical items are all measured in "Levels".
\r A level is one half the distance between the lines of a staff. A note on
\r the centerline of the staff is at level zero. Placing the note just above
\r that line (between the 2nd and 3rd staff line) makes it level 1, while
\r placing it below the centerline makes it level -1. Note that up is positive
\r in this coordinate system.
\r Note positions are recorded as a fraction of the measure width.
\r\r * ========================================================================= *
\r Rules for clipboard use:
\r ~~~~~~~~~~~~~~~~~~~~~~~~
\r A CMUS chunk may be copied to the clipboard. In such cases, it is
\r possible that only a subset of the data might be written. Specifically,
\r measures and signatures which occur before the first selection point,
\r or after the last selection point should not be included. Note that
\r the measure containing the first selection point should be written,
\r however, even if it is not in the selection range itself. (As to whether
\r measure-lines are selectable is up to the application). In addition,
\r an initial time signature item for that measure should be written as
\r well; key signature and clef items are optional in this case. The
\r application receiving the clip has the option of whether to use the
\r signature items in the clip, or to ignore them and use the existing
\r signatures in the score. The application can also decide to "insert"
\r the clip into the score (causing existing other events to be shifted
\r later in time), or "merging" the events with the existing items.
\r The application can also choose to respect measure lines in the clip
\r (each new measure line causes the notes to be pasted into the next
\r measure) or to "flow" the notes across measure boundaries.
\r Note that the notes in a clip may be non-contiguous. For example,
\r If the user were to select every second note and copy those to the
\r clipboard, there would be "gaps" in the clipped track. Unfortunately,
\r a reader program would not be able to detect those gaps (since formal
\r time does not have an explicit start time) and thus the formal time
\r and the casual time would get out of sync. To avoid this problem,
\r "filler" events can be inserted into the score to fill up the empty space.
\r Note that the duration of a filler event is formal, unlike all the
\r other events.
\r Notation programs which only support contiguous selection (i.e.
\r can't have a deselected note between two selected notes) can ignore
\r filler items.
\r A filler event at the end of the measure is not neccessary.
\r In fact, there is no requirement in CMUS that a measure be "filled".
\r In addition, certain music programs allow more notes in a measure than
\r would legally fit (only while editing, the extra notes are never played).
\r CMUS readers should handle this case robustly.
\r\r This allows a reader to make intelligent use of the clip. The clip
\r can be pasted relative to an insertion point, and the relationship of
\r notes to measures can be (optionally) preserved, even if the selection
\r was non-contiguous.
\r * ========================================================================= *
\r Future Directions
\r ~~~~~~~~~~~~~~~~~
\r A number of musical features are currently mising from the CMUS spec,
\r such as the ability for a track to jump from one staff to another. In
\r addition, there are a number of features which would be desirable on the
\r "page" level, such as seperate margins for each page (currently, there is
\r no representation of individual pages in the spec).
\r All of these things can easily be added by defining new IFF chunks
\r or new event types. I have not done this because I feel that these
\r additional features would best be designed by the person who needs them,
\r in other words someone designing a music product that requires such
\r features and is familiar with the issues inolved. Otherwise, the format
\r might be defined wrongly, missing subtle advantages which
\r*/
\r\r/* ========================================================================= *
\r General Definitions
\r * ========================================================================= */
\r\rtypedef long Micrometers;
\r\r#if CM_MICRO_CONVERSION
\r\r /* (optional) conversion to / from inches */
\r\r#define InchesToMicros(inches) ((inches) * 25400)
\r#define MicrosToInches(micros) (((micros) + 12700) / 25400)
\r\r#define HundredthsToMicros(inches) ((inches) * 254)
\r#define MicrosToHundredths(micros) (((micros) + 127) / 254)
\r\r#define PointsToMicros(points) (((points) * 25400 + 36) / 72)
\r#define MicrosToPoints(micros) (((micros) * 72 + 12700) / 25400)
\r\r#endif
\r\r/* ========================================================================= *
\r Score Header Chunk (SCHD)
\r * ========================================================================= */
\r\rtypedef struct {
\r WORD scBarsPerLine; /* preferred bars per line */
\r WORD scOverallVolume; /* overall volume of score */
\r\r Micrometers scPageWidth, /* width of page */
\r scPageHeight, /* height of page */
\r scTopMargin, /* top margin of score on page 1*/
\r scFirstLineIndent, /* left margin indent on line 1 */
\r scLineIndent; /* left indent on other lines */
\r} CM_ScoreHeader;
\r\r/* ========================================================================= *
\r Staff Table Chunk (STAF)
\r\r This section describes the data structures which are used in the CMUS 'STAF'
\r Chunk. There is one STFF chunk per score, which contains an array of
\r StaffEntry structres (1 per staff in the document).
\r\r * ========================================================================= */
\r\rtypedef struct {
\r WORD staffFlags; /* various flags */
\r\r /* This defines the vertical size of a measure. Both of the distances
\r are measured from the center line of the staff (in fact all staff-
\r relative distances are represented this way).
\r */
\r\r Micrometers staffSpaceAbove, /* space above staff */
\r staffSpaceBelow; /* space below staff */
\r\r Micrometers staffLevelSize; /* distance between staff lines */
\r\r} CM_StaffEntry;
\r\r /* This flag indicates that a formfeed should be done before printing
\r this staff (used when a score has more staffs than will fit on a page.
\r */
\r\r#define STAFF_PAGEBREAK (1<<0)
\r\r /* This indicates that the measure lines for this staff should not be
\r connected to the measure lines for the staff below
\r */
\r\r#define STAFF_BAR_BROKEN (1<<1)
\r\r /* This flag indicates that a set of "curly braces" should connect this
\r staff with the staff below.
\r */
\r\r#define STAFF_BRACED (1<<2) /* Staff is "braced" with next */
\r\r /* These flags indicate the start and end of a square bracket which can
\r span over several staffs. The brace should start at the staff
\r marked with the "START" bit and continue until a staff with the
\r "END" bit is encountered.
\r */
\r\r#define STAFF_BRACKET_START (1<<3)
\r#define STAFF_BRACKET_END (1<<4)
\r\r/* ========================================================================= *
\r Track Chunk (TRCK)
\r\r This section describes the data structures which are used in the CMUS 'TRCK'
\r Chunk.
\r\r A track is a sequence of notes which reside on a staff. In the simplest
\r case, there is one TRCK chunk per melody line in the score. However, a
\r track can contain chords, rests, etc, as well.
\r\r A more precise definition of a track is that a track is a sequence of
\r chords, where all the notes within each chord have the same start time
\r and the same duration (in formal time of course; in casual time anything
\r is possible). Note that ties can be used to create the illusion of
\r having broken this rule.
\r\r * ========================================================================= */
\r\r/* Track Header structure:
\r\r Each track begins with a track header structure, followed by any number
\r of score items. (Use the chunk length to determine when to stop reading
\r score items).
\r*/
\r\rtypedef struct {
\r UWORD trkStaff, /* staff number to place this on*/
\r trkTrack, /* track number within staff */
\r trkFlags; /* flags for staff header */
\r\r /* Sometimes notes on the staff are written transposed from how they
\r should actually be played. This is the number that should be added
\r to the pitch before it is actually played back.
\r */
\r\r WORD trkTransposition; /* playback transposition */
\r\r} CM_TrackHeader;
\r\r/* ========================================================================= *
\r Track Item
\r * ========================================================================= */
\r\r/* Item Header:
\r\r Score items are variable in length. The first byte of the item is the
\r length of the item in WORDS. This will allow new item types to be added
\r in the future. All score items are an integer number of WORDS long.
\r\r Each score item has a standard header structure, followed by a variable
\r amount of item-specific data. The 'itemType' field is used to determine what
\r that data is.
\r\r 'itemLength' is the length of the item in WORDS. This allows items to be
\r from 2 to 512 bytes long. (The value '0' is reserved as a special case).
\r\r 'itemXPos' contains the X position of the item in fractions of the measure's
\r width. Note that the area containing the signatures, and the area just
\r before the ending measure line are not considered part of this range.
\r Think of it this way: The value 0 is the first possible note position.
\r The value 0x7fff if the last possible note position. Items placed at
\r these positions should not run into the graphics at either the beginning
\r or the end of the measure. In addition, negative numbers are also
\r allows, which is used for symbols which penetrate into the "signature"
\r area. In this case, 0 represents the first possible note position, and
\r -0x8000 represents the actual barline. This convention is normally only
\r used for lyrics, which can intrude into the signature area.
\r\r 'itemStart' is used to represent the real starting time of each event.
\r This is recorded as a delta-time, in other words itemStart contains
\r how many clock ticks have elapsed between the current item and the item
\r before it. Note that because of the fact that events can sometimes occur
\r out of order (for example, notes in a chord can be ordered by pitch rather
\r than by time, and they might not all start at exactly the same clock),
\r this value can be negative.
\r In addition, the clock is reset at each measure boundary. In other
\r words, the length of a measure is determined only by it's time signature,
\r and not by the delta between the last note and the next measure line.
\r In fact, the itemStart field for measure line items is ignored and should
\r always be set to zero.
\r An item's start time does NOT have to exactly match the event's
\r "formal" time. For example, an event at the beginning of a measure does
\r not have to start at exactly time zero, but can be offset somewhat.
\r This allows the subtle nuances of a live performance to be preserved, if
\r the notation software allows for that capability.
\r\r The 'itemStart' field (and the noteDuration field defined later) use a
\r clock standard of 960 clock ticks per whole note. Thus, a quarter note
\r is one/quarter that, or 240. This number is divisible by 3, 5, and several
\r powers of two, making it convenient for representing triplets and
\r quintuplets as well as small note values.
\r*/
\r\rtypedef struct {
\r UBYTE itemLength, /* length of item in WORDS */
\r itemType; /* type of item */
\r WORD itemXPos; /* horizontal position of item */
\r WORD itemStart; /* start time, in ticks */
\r} CM_ItemHeader;
\r\r#define WHOLE_NOTE_DURATION 960 /* duration of a whole note */
\r\r#define MAX_ITEM_XPOS 0x7fff
\r#define MMIN_ITEM_XPOS -0x8000
\r\r /* type codes for chunk item types */
\r\renum notation_item_types {
\r MEASURE_ITEM = 0, /* measure line */
\r SIGNATURE_ITEM, /* time sig., key sig., or clef */
\r NOTE_ITEM, /* first note in a chord */
\r CHORD_ITEM, /* additional notes in a chord */
\r FILLER_ITEM, /* fills up empty gaps */
\r DYNAMIC_ITEM, /* dynamic volume item (fff) */
\r INSTRUMENT_ITEM, /* instrument change item */
\r TEMPO_ITEM, /* tempo change item */
\r REPEAT_ITEM, /* for jumping around in score */
\r BEGIN_GROUP_ITEM, /* begin slur, crescendo, etc. */
\r END_GROUP_ITEM, /* end slur, crecendo, etc. */
\r TABLATURE_ITEM, /* guitar or other tablature */
\r};
\r\r/* ========================================================================= *
\r Measure Line Item
\r * ========================================================================= */
\r\r/* This item represents the beginning of a new measure. As such, there should
\r be one of these at the beginning of the track, but not at the end.
\r*/
\r\rtypedef struct {
\r CM_ItemHeader measureItem; /* item header */
\r Micrometers measureWidth; /* width of measure */
\r UBYTE measureFlags; /* various flags, see below */
\r\r /* measureEnding: If non-zero, it means that this measure is part
\r of an ending block. The value indicates which ending this measure
\r is part of. For example, if the value = 1, then this measure
\r is only played the first time through, if the value = 2 then
\r it is only played the second time through.
\r\r Each "repeat" section in the score can have it's own set of
\r endings.
\r\r "Endings" can be longer than one measure. Each measure that
\r is encountered that has the same value of measureEnding as the
\r previous measure is considered part of the same ending.
\r */
\r\r UBYTE measureEnding; /* "ending" this measure is in */
\r} CM_Measure;
\r\r#define MEASURE_FULL_WIDTH 0x7fff /* full width of score */
\r\renum measureFlags {
\r\r /* Draw a double bar at the end of this measure. The reason for
\r associating the double-bar flag with the next measure line is
\r because double bar can occur at the end of the score but not
\r at the beginning.
\r */
\r MEASUREF_DOUBLE_BAR = (1<<0),
\r\r /* This is a "line break", in other words it indicates that this
\r measure should start a new line.
\r */
\r\r MEASUREF_NEW_LINE = (1<<1),
\r\r /* If set, this flags means that the measure width was set by the
\r user. It not set, it means that measure width was calculated on
\r the fly, and can be re-adjusted feely if needed to line things
\r up. Note that this width includes signatures, but does not include
\r any indentation from the left margin of the document.
\r */
\r\r MEASUREF_FIXED = (1<<2),
\r\r};
\r\r/* ========================================================================= *
\r Signature Items
\r * ========================================================================= */
\r\r /* Signature items are usually placed just after the measure line.
\r\r Some notators have the ability to change clef in the middle of a
\r measure, but not all notators need support this. If it is not
\r supported, and a clef is encountered in the middle of a measure, it
\r is assumed to apply to the entire measure and therefore is associated
\r with the previous measure line.
\r */
\r\r /* Signature types: Each signature has a "sigSubType" field which
\r indicates the type of signature. In addition, the high bit of the
\r signature type field indicates that the signature should not be
\r shown visibly.
\r */
\r\renum SignatureTypes {
\r SIGTYPE_TIMESIG=1,
\r SIGTYPE_CLEF,
\r SIGTYPE_MAJORKEY,
\r SIGTYPE_MINORKEY,
\r\r SIGTYPE_HIDDEN=(1<<7)
\r};
\r\r /* Stores a time signature. 'Beats' is the number above the line, and
\r 'Notes' is the number below the line. For example, '3/4' time is
\r stored as beats = 3, notes = 4.
\r\r "Common Time" (The "C" symbol) which is equivalent to 4/4 is stored
\r as 4/0 (beats = 4, notes = 0).
\r\r "Cut Time" ("C" with a slash through it) which is equivalent to
\r 2/4 is stored as 2/0 (beats = 2, notes = 0).
\r\r In other words, the value "0" in "sigNotes" should always be treated
\r as the value "4" when calculating measure lengths. See the
\r MEASURE_LENGTH macro for an example of this.
\r */
\r\rtypedef struct {
\r CM_ItemHeader sigItem; /* item header */
\r UBYTE sigSubType, /* (= SIGTYPE_TIMESIG) */
\r sigBeats, /* beats per bar */
\r sigNotes, /* size of each beat */
\r sigPad;
\r} CM_TimeSignature;
\r\r /* compute the measure length in clock ticks */
\r\r#define MEASURE_LENGTH(beats, notes) \
\r (WHOLE_NOTE_DURATION * beats / (notes ? notes : 4))
\r\r /* stores a Clef */
\r\rtypedef struct {
\r CM_ItemHeader sigItem; /* item header */
\r UBYTE sigSubType; /* (= SIGTYPE_CLEF) */
\r UBYTE sigClef; /* new clef */
\r} CM_Clef;
\r\r /* Definitions of clef types. Note clef modifier bits which are used as
\r part of this field as well.
\r */
\r\renum ClefTypes {
\r TREBLE_CLEF = 0, /* G clef in normal position */
\r BASS_CLEF, /* F clef in normal position */
\r ALTO_CLEF, /* C clef centered on line 3 */
\r TENOR_CLEF, /* C clef centered on line 2 */
\r\r /* optional clefs, some of which are obselete (in the U.S.) */
\r\r SOPRANO_CLEF, /* C clef centered on line 5 */
\r MEZZO_SOPRANO_CLEF, /* C clef centered on line 4 */
\r BARITONE_CLEF, /* F clef one line lower */
\r FRENCH_VIOLIN_CLEF, /* G clef one line lower */
\r\r /* For drum scores. One of the things implied by a drum clef is that
\r there might not be a relationship between a note's vertical
\r position and it's MIDI note number, unlike other clef types.
\r (This could be especially handy for work with MIDI drum machines).
\r */
\r\r DRUM_CLEF, /* vertical lines or box */
\r\r /* clef modifier bits: A clef can be raised or lowered by one or two
\r octaves. This is notated by placing a small "8" or "15" above or
\r below the clef.
\r */
\r\r CLEF_DOWN_1_OCTAVE=(1<<4), /* clef 1 oct lower (8 below) */
\r CLEF_DOWN_2_OCTAVES=(1<<5), /* clef 2 oct lower (15 below) */
\r CLEF_UP_1_OCTAVE=(1<<6), /* clef 1 oct higher (8 above) */
\r CLEF_UP_2_OCTAVE=(1<<7), /* clef 2 oct higher (15 above) */
\r};
\r\r /* stores a Key Signature. (used for both major and minor)
\r\r 'sigKeySig' is a signed BYTE, where '0' is the key of C. Positive
\r numbers represent the number of sharps, so 1=G, 2=D, etc, around the
\r circle of fifths. Negative numbers represent the number of flats,
\r F=-1, B-Flat = -2, etc.
\r\r For minor keys, 0 is the key of A-minor, which like C has no sharps
\r or flats.
\r\r Other types of key signatures may be supported in the future, but
\r will probably be done as a different type of signature item.
\r */
\r\rtypedef struct {
\r CM_ItemHeader sigItem; /* item header */
\r UBYTE sigSubType; /* (== SIGTYPE_KEYSIG) */
\r BYTE sigKeySig; /* new key signature */
\r} CM_KeySignature;
\r\r /* major key definitions */
\r\r#define KEY_OF_C_MAJOR 0
\r#define KEY_OF_G_MAJOR 1
\r#define KEY_OF_D_MAJOR 2
\r#define KEY_OF_A_MAJOR 3
\r#define KEY_OF_E_MAJOR 4
\r#define KEY_OF_B_MAJOR 5
\r#define KEY_OF_F_SHARP_MAJOR 6
\r#define KEY_OF_C_SHARP_MAJOR 7
\r#define KEY_OF_F_MAJOR -1
\r#define KEY_OF_B_FLAT_MAJOR -2
\r#define KEY_OF_E_FLAT_MAJOR -3
\r#define KEY_OF_A_FLAT_MAJOR -4
\r#define KEY_OF_D_FLAT_MAJOR -5
\r#define KEY_OF_G_FLAT_MAJOR -6
\r#define KEY_OF_C_FLAT_MAJOR -7
\r\r /* minor key definitions */
\r\r#define KEY_OF_A_MINOR 0
\r#define KEY_OF_E_MINOR 1
\r#define KEY_OF_B_MINOR 2
\r#define KEY_OF_F_SHARP_MINOR 3
\r#define KEY_OF_C_SHARP_MINOR 4
\r#define KEY_OF_G_SHARP_MINOR 5
\r#define KEY_OF_D_SHARP_MINOR 6
\r#define KEY_OF_A_SHARP_MINOR 7
\r#define KEY_OF_D_MINOR -1
\r#define KEY_OF_G_MINOR -2
\r#define KEY_OF_C_MINOR -3
\r#define KEY_OF_F_MINOR -4
\r#define KEY_OF_B_FLAT_MINOR -5
\r#define KEY_OF_E_FLAT_MINOR -6
\r#define KEY_OF_A_FLAT_MINOR -7
\r\r/* ========================================================================= *
\r Note or Chord item
\r * ========================================================================= */
\r\r /* Note Items.
\r\r CHORDS: The first note of a chord is always of type "note".
\r Additional notes, or "intervals" are stored using the "chord"
\r type. The itemXPos, noteTuple, noteDots, noteDivision, noteStyle,
\r noteArpeggio, noteTrill and and noteBeamHeight fields are ignored
\r for chord items and are derived from the base note, however score
\r writers should set them to the same as the base note for consistency.
\r\r RESTS: A rest is a note item with a notePitch of 255. Rests may not
\r be chorded.
\r\r DRUM HEADS: If the NOTEF_DRUM flag is set, indicating that the
\r note has a "drum head" rather than an ordinary note head, then
\r all of the pitch-modifier fields should be ignored.
\r\r OPTIONAL FIELDS: For less sophisticated programs, many of the fields
\r in the note structure can be ignored.
\r At a minimum, notation programs should look at noteLevel,
\r noteAccidental, noteDivision and noteDots. When writing, all other
\r fields can be set to zero, with the exception of noteDuration
\r which should be set to the formal duration of the note in clock
\r ticks.
\r Sequencer programs should look at notePitch and noteDuration
\r when loading CMUS scores. Writing is more difficult. It is suggested
\r that unless the program is very sophisticated, that a different
\r FORM, or perhaps a Standard MIDI File, be used for writing out
\r sequencer data, as most of the fields in CMUS have meaning only to
\r a notator-type program.
\r\r Explanation of Fields:
\r ~~~~~~~~~~~~~~~~~~~~~~
\r\r noteDuration -- The casual duration of the note.
\r\r noteFlags -- various flags which affect either this note. Note that
\r the NOTEF_TIED and NOTEF_TIEDOWN can be different for each
\r note in a chord.
\r\r noteDots: 0, 1 or 2 depending on the number of "dots" this note
\r has. A dotted note is 50% longer. A double-dotted note is
\r 75% longer.
\r\r noteDivision: Indicates the base duration of the note: whole note,
\r half note, quarter note, etc.
\r\r notePitch: The MIDI pitch number for this note.
\r\r noteArpeggio: Indicates an arpeggiated chord, one where the individual
\r notes are played sequentially (like a harp).
\r\r noteTrill: Trills are a rapid alternation between two notes. There
\r are vaious kinds, see below.
\r\r noteAccidental: This includes things like sharps and flats.
\r\r noteLevel: This is the distance, in levels, from the center line of
\r the staff.
\r\r noteBeamHeight: The height of a beamed group of notes isn't always
\r related to the height that the stem would be if the note were not
\r beamed. This field is the distance, in levels, from the center
\r line of the staff to the beam's position. This field is only
\r meaningful for the first and last note of a beam.
\r\r noteStyle: This is a field of flags which indicate things like
\r Staccato, Legato, and other "performance style" modifiers.
\r */
\r\r/* What the note structure looks like with bitfields:
\r\r CM_ItemHeader noteItem; -- item header
\r\r UWORD noteDuration; -- real duration, in ticks
\r UWORD noteFlags;
\r\r unsigned int Pad1 : 2
\r noteDots : 2, -- dotted, double-dotted
\r noteDivision : 4, -- quarter note, etc.
\r\r UBYTE notePitch; -- MIDI note number
\r unsigned int noteArpeggio : 2, -- arpeggiation
\r noteTrill : 3, -- various trill types
\r noteAccidental : 3; -- sharp, flat, etc.
\r\r BYTE noteLevel; -- dist from staff centerline
\r BYTE noteBeamHeight; -- Y position of beam
\r UBYTE noteStyle; -- Note Style type
\r*/
\r\rtypedef struct {
\r CM_ItemHeader noteItem; /* item header */
\r\r UWORD noteDuration; /* real duration, in ticks */
\r UWORD noteFlags; /* various note flags */
\r\r UBYTE noteDivision; /* formal note length */
\r\r UBYTE notePitch; /* MIDI note number */
\r UBYTE notePitchMods; /* modifications to pitch */
\r BYTE noteLevel; /* vertical position */
\r\r BYTE noteBeamHeight; /* y position of beam */
\r UBYTE noteStyle; /* Note Style type */
\r} CM_Note;
\r\r /* macros to access the various bitfields */
\r\r#define CM_NoteDots(f) (((f).noteDivision >> 4) & 0x03)
\r#define CM_NoteDivision(f) ((f).noteDivision & 0x0f)
\r\r#define CM_NoteAccidental(f) ((f).notePitchMods & 7)
\r#define CM_NoteTrill(f) (((f).notePitchMods >> 3) & 7)
\r#define CM_NoteArpeggiation(f) (((f).notePitchMods >> 6) & 3)
\r\r#define CM_SetNoteDivision(note, division, dots) \
\r ((note).noteDivision = (dots << 4) | division)
\r\r#define CM_SetNotePitchMods(note, arp, trill, accidental) \
\r ((note).notePitchMods = (arp << 6) | ((trill << 3) & 7) | (accidental & 7))
\r\r#define CM_RestPitch 255
\r\renum note_dots {
\r NO_DOT = 0, /* Note is normal duration */
\r DOTTED_NOTE = 1, /* Note is 50% longer */
\r DOUBLE_DOTTED = 2 /* note is 75% longer */
\r};
\r\renum note_divisions {
\r DOUBLE_WHOLE_NOTE = 0,
\r WHOLE_NOTE,
\r HALF_NOTE,
\r QUARTER_NOTE,
\r EIGHTH_NOTE,
\r SIXTEENTH_NOTE,
\r NOTE_32,
\r NOTE_64,
\r NOTE_128,
\r NOTE_256
\r};
\r\renum note_accidentals {
\r NOTE_ACC_NONE=0,
\r NOTE_ACC_DOUBLE_FLAT,
\r NOTE_ACC_FLAT,
\r NOTE_ACC_HALF_FLAT,
\r NOTE_ACC_NATURAL,
\r NOTE_ACC_HALF_SHARP,
\r NOTE_ACC_SHARP,
\r NOTE_ACC_DOUBLE_SHARP,
\r\r /* drum styles: used in place of accidental when NOTEF_DRUM is set.
\r Hollow symbols are used in place of "hollow" note heads, such
\r as half notes.
\r\r Note that the assignment of drum parts to symbols is arbtrary,
\r however the X symbol in jazz notation means "brush", and the
\r triangle symbol is often assigned to the triangle instrument.
\r Note also that normal note heads are often used for many
\r drum instruments.
\r */
\r\r NOTE_DRUM_X=0, /* An "x" instead of note head */
\r NOTE_DRUM_DIAMOND, /* diamond shape */
\r NOTE_DRUM_SQUARE, /* square box */
\r NOTE_DRUM_TRIANGLE, /* triangle */
\r\r};
\r\r /* trills and tremolos and other pitch modulations which can be attached
\r to a note. Note that these apply to the entire chord.
\r */
\r\renum note_trills {
\r NOTE_PMOD_NONE=0,
\r NOTE_PMOD_TRILL,
\r NOTE_PMOD_MORDENT,
\r NOTE_PMOD_INV_MORDENT,
\r NOTE_PMOD_TURN,
\r};
\r\r /* Arpeggiation, indicated as a vertical sqiggly line before the chord */
\r\renum note_arp_mods {
\r NOTE_ARPEGGIO = 1,
\r NOTE_REV_ARPEGGIO = 2,
\r};
\r\r /* note style flags */
\r\r#define NSTYLEF_STACCATO (1<<0) /* Staccatto mark ('.') */
\r#define NSTYLEF_STACCATISSIMO (1<<1) /* Staccattissimo mark (wedge) */
\r#define NSTYLEF_LEGATO (1<<2) /* Legato ('-') */
\r#define NSTYLEF_SFORZANDO (1<<3) /* Szorzando ('^') */
\r#define NSTYLEF_ACCENT (1<<4) /* Accent ('>') */
\r#define NSTYLEF_TENUTO (1<<5) /* Tenuto (short '-') */
\r\r /* general note flags */
\r\renum noteFlags {
\r NOTEF_STEMDOWN = (1<<0), /* Note's stem is down */
\r NOTEF_BEAMED = (1<<1), /* Note is beamed with next note*/
\r NOTEF_TIED = (1<<2), /* Note is tied with next note */
\r NOTEF_TIEDOWN = (1<<3), /* tie direction is DOWN */
\r NOTEF_GRACE = (1<<4), /* display as grace note */
\r NOTEF_CUE = (1<<5), /* display as cue note */
\r NOTEF_DRUM = (1<<6), /* note has a drum head */
\r NOTEF_STEMSET = (1<<7), /* Stem direction fixed by user */
\r\r NOTEF_RES1 = (1<<12), /* reserved by DMCS for play */
\r NOTEF_RES2 = (1<<13), /* styles (sorry :-) */
\r NOTEF_RES3 = (1<<14),
\r NOTEF_RES4 = (1<<15),
\r};
\r\r/* ========================================================================= *
\r Filler item
\r * ========================================================================= */
\r\r /* This item is used for supporting sparse clips. The fillerDuration
\r field contains the total of the formal durations of the missing
\r items between the previous event and the next one.
\r */
\r\rtypedef struct {
\r CM_ItemHeader fillerItem; /* item header */
\r UWORD fillerDuration; /* formal size of items left out*/
\r} CM_Filler;
\r\r/* ========================================================================= *
\r Dynamic Item
\r * ========================================================================= */
\r\r /* This item specifies a MIDI volume. Note that the relationship between
\r Volume and dynamic markings (such as fff, pp, etc) is defined
\r elsewhere.
\r */
\r\rtypedef struct {
\r CM_ItemHeader dynItem; /* item header */
\r BYTE dynLevelPos; /* vertical position in leveks */
\r UBYTE dynVolume; /* midi pressure number (0..127)*/
\r BYTE dynSymbol; /* dynamic symbol, see below */
\r UBYTE dynPad;
\r} CM_Dynamic;
\r\r /* Dynamic symbols:
\r\r 0 = symbol not specified, derive from MIDI volume.
\r +1 = mf -1 = mp
\r +2 = f -2 = p
\r +3 = ff -3 = pp
\r +4 = fff -4 = ppp
\r (etc)
\r */
\r\r/* ========================================================================= *
\r Instrument item
\r * ========================================================================= */
\r\r /* Rather than embedding the instrument names in the actual score, a
\r seperate "instrument table" chunk will be defined.
\r */
\r\rtypedef struct {
\r CM_ItemHeader instItem; /* instrument item */
\r UBYTE instNumber; /* instrument number from table */
\r UBYTE instPad;
\r} CM_Instrument;
\r\r/* ========================================================================= *
\r Tempo Item
\r * ========================================================================= */
\r\r /* For compatibility with Standard MIDI files, tempo is represented as
\r microseconds per quarter note, rather than the more commonly used
\r quarter notes per minute. To convert from one to the other, the
\r following formula works both ways:
\r\r T = 60,000,000 / t;
\r\r For accuracy, you may want to round:
\r\r T = (60,000,000 + t/2) / t;
\r\r Of course, the user interface of the program should not use units
\r like this.
\r */
\r\rtypedef struct {
\r CM_ItemHeader tempoItem; /* item header */
\r ULONG tempoValue; /* new tempo value */
\r} CM_Tempo;
\r\r/* ========================================================================= *
\r Repeat Item
\r * ========================================================================= */
\r\r /* This is a general category of items for jumping around in the
\r score in a non-sequential fashion. It includes things like
\r begin/end repeat bars, repeat measure, Da Capo, etc.
\r\r "repeatCount" is the number of times that the jump should occur,
\r not the total number of times a passage should be played. For example,
\r an begin/end repeat which is to play twice (once through, and then
\r prepeated once) should have a repeatCount of "1".
\r\r In addition, repeatCount should be associated with the jump rather
\r than the label. This imples that the count should go with the
\r "end" of a begin/end block rather than the "begin".
\r */
\r\rtypedef struct {
\r CM_ItemHeader repeatItem; /* item header */
\r UBYTE repeatType; /* subtype of group */
\r UBYTE repeatCount; /* number of times to jump */
\r} CM_Repeat;
\r\renum repeat_types {
\r REPEAT_BLOCK_BEGIN=0, /* defines a repeat block */
\r REPEAT_BLOCK_END,
\r\r REPEAT_LAST_MEASURE, /* jumps back 1 measure */
\r REPEAT_LAST_TWO_MEASURES, /* jumps back 2 measures */
\r\r REPEAT_MEASURE_REST, /* rest for N measures */
\r /* (not really a jump) */
\r /* labels to go to */
\r\r REPEAT_LABEL_SEGNO, /* The "sign" D.S. refers to */
\r REPEAT_LABEL_CODA, /* The Coda symbol */
\r\r /* goto operators */
\r\r REPEAT_DC, /* D.C. */
\r REPEAT_DC_AL_FINE, /* D.C. al fine */
\r REPEAT_DS, /* D.S. */
\r REPEAT_DS_AL_FINE, /* D.S. al fine */
\r REPEAT_DS_AL_CODA, /* D.S. al coda */
\r};
\r\r/* ========================================================================= *
\r Group Item
\r * ========================================================================= */
\r\r /* A "Group" Item is defined as a Slur, Crescendo, or Octave Raiser.
\r In general, groups can apply to any contiguous range of notes
\r on a track, and groups of the same type can note overlap.
\r\r Note that in some cases, such as for example a crecendo, although
\r the modification is technically "attached" to a particular
\r track, it affects all the tracks on that staff.
\r */
\r\rtypedef struct {
\r CM_ItemHeader groupItem; /* item header */
\r UBYTE groupType; /* subtype of group */
\r\r /* To even out the structure, we'll add an extra byte which means
\r different things based on the group type. Right now it is
\r only defined in the case of a crescendo / decrescendo in which
\r case it means the final volume.
\r\r For all others, it should be set to zero.
\r */
\r\r UBYTE groupVal;
\r} CM_Group;
\r\r /* Types of group items supported */
\r\renum group_types {
\r GROUPTYPE_SLUR_UP=0,
\r GROUPTYPE_SLUR_DOWN,
\r GROUPTYPE_CRESCENDO,
\r GROUPTYPE_DECRESCENDO,
\r GROUPTYPE_OCTAVE_UP, /* "8va" symbol */
\r GROUPTYPE_OCTAVE_DOWN, /* "8vb" symbol */
\r GROUPTYPE_GLISSANDO_UP,
\r GROUPTYPE_GLISSANDO_DOWN,
\r\r GROUPTYPE_TUPLET, /* see below */
\r GROUPTYPE_TRILL, /* the one with the wavy line */
\r GROUPTYPE_TREMOLO, /* Slashes below a beam */
\r};
\r\r /* Tuplets are a subtype of group items, and as such have an extended
\r structure. Unlike other group types, tuplet group items can be nested.
\r\r Note that for ending a tuplet, the extra fields are not required
\r and a normal "Group" structure can be used. Each tuplet ending
\r item matches the nearest previous unmatched tuplet item.
\r */
\r\rtypedef struct {
\r CM_ItemHeader tupletItem; /* item header */
\r UBYTE tupletType; /* subtype of group */
\r\r /* tupletNumber indicates how many notes can fit in the space of
\r 'tupletSpace'. For example, a triplet, i.e. "3 in the space of 2",
\r or 2/3 duration, can be represented as tupletNumber = 3,
\r tupletSpace = 2.
\r */
\r\r UBYTE tupletNumber, /* How manu items */
\r tupletSpace; /* in the space of how many */
\r\r /* tupletDigits represents the binary number which should be
\r displayed above the tuplet; For example, for a triplet this
\r should be 3.
\r */
\r\r UBYTE tupletDigits; /* number to display */
\r\r /* tupletFlags is for later use when we want tuplets combined with
\r slurs / brackets. Currently there are no flags defined, so the
\r field should be all zeroes.
\r */
\r\r UBYTE tupletFlags, /* various flags */
\r tupletPad;
\r} CM_Tuplet;
\r\r/* ========================================================================= *
\r Tablature Item
\r * ========================================================================= */
\r\r /* The Tablature item is used for guitar, banjo or other fretted
\r instruments. It's a two-dimensional array of bits, which is drawn
\r as a grid indicating the exact placement of fingers.
\r\r In addition, most tablatures have the name of the chord placed above
\r the grid. This can be quite complex, looking something like this:
\r\r 7+6
\r C min
\r\r Which means: "C minor, with an added seventh and a raised sixth".
\r */
\r\rtypedef struct {
\r CM_ItemHeader tabItem; /* item header */
\r\r /* tabRoot is used to indicate the name of the chord placed above
\r the tablature. Note that the root can have superscripts, which
\r are defined elsewhere.
\r\r unsigned int rootLetter : 3, -- A, B, C, etc.
\r rootAccidental : 2, -- accidental of root
\r rootType : 3, -- major, minor, etc.
\r */
\r\r UBYTE tabRoot; /* describes root of chord */
\r\r /* tabDimensions is a field of two 4 bit values, representing the
\r width and height of the tablature array. A dimension of (0,0)
\r indicates that only the chord symbol should be used.
\r */
\r\r UBYTE tabDimensions; /* width/height of tab array */
\r\r /* tabIntervals is an optional field -- if it's zero, it means that
\r the writing program wasn't sophisticated enough to set it.
\r (This is generally true for programs that are typographical
\r rather than musical in orientation).
\r\r The field used to exactly describe the intervals in the
\r chord above the root. Each interval may be:
\r\r 0 - missing ( no interval)
\r 1 - lowered ( one half-step below major chord position )
\r 2 - normal ( in the normal position for a major chord )
\r 3 - raised ( one half-step above major chord position )
\r\r unsigned int chordThird : 2, -- (missing, -1, 0, +1)
\r chordFifth : 2, -- (missing, -1, 0, +1)
\r chordSeventh : 2, -- (missing, -1, 0, +1)
\r chordNinth : 2, -- (missing, -1, 0, +1)
\r chordEleventh : 2, -- (missing, -1, 0, +1)
\r chordThirteenth : 2, -- (missing, -1, 0, +1)
\r chordFifteenth : 2, -- (missing, -1, 0, +1)
\r chordValid : 1, -- TRUE if field valid
\r chordPad : 1;
\r */
\r\r UWORD tabIntervals; /* describes exact chord intervals*/
\r\r /* tabArray is a byte array of finger positions.
\r\r Each byte represents a string. The value of the byte
\r can be from 0 (representing an open string), or 1-16
\r (representing a finger placed above the Nth fret). The high
\r 4 bits are reserved for now, but may be used later to indicate
\r special placement of the fingers.
\r\r Note that the tabArray can be longer or shorter than 6 bytes,
\r up to a maximum of 16 strings. In such cases, the event length
\r stored in the CM_ItemHeader would be adjusted accordingly.
\r */
\r\r UBYTE tabArray[6]; /* tablature array */
\r\r /* Following the tabArray field is an optional variable-length
\r ASCII string which is the actual text of the superscript,
\r such as "maj6+7".
\r\r The length of the string can be computed comparing the end of
\r the event with the end of the tab-array. Null termination is
\r not required.
\r */
\r\r};
\r\renum chord_accidentals {
\r CHORD_ACC_NONE=0,
\r CHORD_ACC_FLAT,
\r CHORD_ACC_NATURAL,
\r CHORD_ACC_SHARP
\r};
\r\renum chord_types {
\r CHORD_TYPE_MAJOR,
\r CHORD_TYPE_MINOR,
\r CHORD_TYPE_DIMINISHED,
\r CHORD_TYPE_AUGMENTED,
\r CHORD_TYPE_SUSPENDED
\r};
\r\renum chord_letters {
\r CHORD_LETTER_A=0,
\r CHORD_LETTER_B,
\r CHORD_LETTER_C,
\r CHORD_LETTER_D,
\r CHORD_LETTER_E,
\r CHORD_LETTER_F,
\r CHORD_LETTER_G
\r};
\r\r/* ========================================================================= *
\r Lyric Font Chunk (LFON)
\r\r This section describes the data structures which are used in the CMUS
\r 'LFON' Chunk.
\r\r LFON chunks are used to store the font table for the document. Embedded
\r within the Lyric, Annotation and title chunks are font specifiers which
\r refer to a given font by number. That number is an index into this table.
\r\r There is one LFON chunk per font. Each LFON chunk consists of the following
\r header, and then the name of the font. The terminating NULL should be
\r included in the font name.
\r\r * ========================================================================= */
\r\rtypedef struct {
\r UWORD fontNumber; /* number assigned to font */
\r UWORD fontHeight; /* height of font in points */
\r\r /* fontName follows */
\r\r} CM_FontEntry;
\r\r/* ========================================================================= *
\r Lyric Chunk (LYRC)
\r\r This section describes the data structures which are used in the CMUS
\r 'LYRC' Chunk.
\r\r Each lyric is associated with a particular track, and a particular measure
\r within that track. The reason for this is because certain elements within
\r the lyrics can be "attached" to notes within a track, so that syllables
\r of the lyric can properly appear under the notes.
\r\r Lyrics associated with a particular track are written immediately after
\r that track. In other words, when reading a lyric, it should be associated
\r with the previously read track.
\r\r * ========================================================================= */
\r\r /* This is the header structure for a lyric. It is followed by the actual
\r text of the lyric. No terminating NUL is used.
\r\r Attaching syllables to notes: This is an optional feature which need
\r not be supported by all readers. Basically, the TAB character is used
\r to specify a block of text to align with the next note. Essentially,
\r each chord on the trackÊacts as a center-justified tab-stop. This is
\r similar to the way tab stops work on medium- to high-end word
\r processors: All the text between a tab, and the next tab (or the end
\r of the line) is "centered" at the tab-stop position. Readers
\r which don't wish to deal with this level of complexity can just
\r treat the tab as a space.
\r */
\r\rtypedef struct {
\r UWORD lyricMeasure; /* starting measure of lyric */
\r\r /* Position of the upper-left coordinate of the lyric.
\r This can be positive or negative, and is interpreted just like
\r the 'itemXPos' field for track events.
\r */
\r\r WORD lyricXPos; /* position relative to measure */
\r\r /* lyricLevel is the position, in micrometers, of the upper-
\r left corner of the lyric's extent box.
\r\r lyricHeight is also in micrometers.
\r */
\r\r Micrometers lyricLevel, /* distance from center of staff*/
\r lyricHeight; /* height of lyric extent */
\r\r /* Width is in micrometers. */
\r\r Micrometers lyricWidth;
\r\r /* lyric text string follows */
\r\r} CM_Lyric;
\r\r /* Codes for specification of fonts and text styles. The "newfont" code
\r is followed by the font number. If no font is specified, font #0 is
\r the default.
\r */
\r\renum {
\r LSTYLE_BOLD_ON=0x80,
\r LSTYLE_BOLD_OFF,
\r LSTYLE_ITALIC_ON,
\r LSTYLE_ITALIC_OFF,
\r LSTYLE_UNDER_ON,
\r LSTYLE_UNDER_OFF,
\r LSTYLE_NEWFONT, /* font number follows */
\r};
\r\r/* ========================================================================= *
\r Annotation chunks (ANOT)
\r\r This section describes the data structures which are used in the CMUS
\r 'ANOT' Chunk. Note that there is a standard IFF chunk called 'ANNO'
\r which can be added to any file to annotate the file. The 'ANOT' is
\r used to specify annotations to the music, not to the file.
\r\r * ========================================================================= */
\r\r /* Annotation chunks are specified exactly like Lyric chunks. The only
\r reason for distinguishing between the two is that a "stripper" program
\r might want to strip out one or the other.
\r */
\r\r/* ========================================================================= *
\r Title Chunk (TITL)
\r\r This section describes the data structures which are used in the CMUS 'TITL'
\r Chunk. Unlike Lyrics, Titles are placed at fixed positions on the page
\r (generally at the top) and are are not adjusted based on the positioning
\r of any particular measure.
\r\r * ========================================================================= */
\r\r /* Title chunks are specified exactly like Lyric chunks, except that the
\r lyricMeasure field is ignored and should be set to 0.
\r\r In particular, the lyricXPos field is no longer based on measure width,
\r but is now a fractional width of the document. Similarly, the
\r lyricLevel field is the number of levels from the top of the page.
\r (Or should that be an absolute measure?)
\r */
\r\r/* ========================================================================= *
\r CMUS Instrument Table (FORM INST)
\r\r The instrument table fo the CMUS form is stored as an embedded FORM
\r called 'INST'. Each instrument in the table is one INST form.
\r\r Instruments can be configured for MIDI, internal audio, or both.
\r When using internal sounds, samples can be sepcified using an embedded
\r FORM 8SVX, or any other IFF sampled sound FORM that the program wishes
\r to support. Sampled sounds can be embedded in the file, or external
\r sample files can be referenced from within the file, by pathname.
\r\r Here's a summary of the chunks which can be included in an INST
\r form:
\r\r 'INHD': This is the instrument header. It contains the instrument
\r number, and the various MIDI-related parameters. The chunk
\r format is defined below.
\r\r 'FORM 8SVX': This is an embedded sampled sound file. The sampled
\r sound is to be associated with the instrument.
\r\r 'SFIL': This is a reference to a sampled sound in a different file,
\r and can be used instead of an embedded sample. The chunk format
\r is simply the name of the file. If the file contains more than
\r one sample, only the first is used. (A different chunk can be
\r defined to select the Nth sample, if it turns out that this
\r feature might be desired).
\r\r 'SHAR': This allows a instrument to share a sampled sound with
\r another instrument. This would be used instead of either and
\r embedded sample or an 'SFIL' chunk. The chunk format is simple
\r a UWORD of the instrument number to share with; This
\r instrument must have been previously loaded.
\r\r 'ATAK': Identical with the ATAK chunk in FORM 8SVX, this allows
\r the instrument have a different envelope than the one in
\r the sampled sound file.
\r\r 'RLSE': Identical with the RLSE chunk in FORM 8SVX, this allows the
\r instrument have a different envelope than the one in the
\r sampled sound file.
\r\r 'NAME': is a standard chunk which can be added to any IFF FORM.
\r In this case, it is used to store the instrument name. Other
\r standard chunks which can be added are "AUTH" (author name),
\r "VERS" (version string), "ANNO" (Annotations) and "(C) "
\r (copyright notice).
\r\r Note: If there is no sampled sound specified, either through an
\r embedded sample or SFIL or SHAR chunks, then this instrument is
\r a MIDI-only instrument.
\r\r * ========================================================================= */
\r\r /* Instrument header chunk -- INHD */
\r\rtypedef struct {
\r\r /* 'instNumber' corresponds to the instrument number used
\r in the "instrument event" in the TRCK chunk.
\r */
\r\r UBYTE instNumber;
\r\r UBYTE instFlags; /* various flags */
\r WORD instTune; /* tuning, in 1/100 semitones */
\r WORD instVolume; /* overall volume, 0-0xffff */
\r\r /* "Pan" can be used by both MIDI and sampled sound instruments, and
\r indicates a preferences for left or right. It ranges from 0 to
\r 127 (same as MIDI), with 0 being ?? and 127 being ??.
\r */
\r\r UBYTE instPan;
\r\r /* MIDI-related variables */
\r\r UBYTE instMidiChannel; /* MIDI channel to use */
\r UBYTE instMidiPreset; /* MIDI Preset for this channel */
\r UBYTE instMidiPort; /* Hardware port #, if applies */
\r\r} InstrumentHeader;
\r\r#define INST_MAXVOL 0x0ffff
\r#define INST_MAXPAN 127
\r\r /* various flags for instFlags */
\r\r#define INSTF_MIDI (1<<0) /* MIDI is enabled */
\r#define INSTF_MIDIVOL (1<<1) /* use MIDI volume, not velocity*/
\r\r#endif
\r
projects / old-projects.git / blob