SMUS IFF Simple Musical Score - Revision history

Steven Solie: /* Data Chunk TRAK */

2012-05-09T03:34:22Z

Data Chunk TRAK

← Older revision		Revision as of 03:34, 9 May 2012
Line 225:		Line 225:
	This format is extensible since new event types can be defined in the future. The “note” and “rest” events are the only ones that every program must understand. ''We will carefully design any new event types so that programs can safely skip over unrecognized events in a score''.		This format is extensible since new event types can be defined in the future. The “note” and “rest” events are the only ones that every program must understand. ''We will carefully design any new event types so that programs can safely skip over unrecognized events in a score''.

	Caution: ID codes must be allocated by a central clearinghouse to avoid conflicts. ~~''Commodore~~ ~~Applications~~ ~~and~~ ~~Technical Support''~~ provides this clearinghouse service.		Caution: ID codes must be allocated by a central clearinghouse to avoid conflicts. The AmigaOS development team provides this clearinghouse service.

	Here are the C type definitions for TRAK and SEvent and the currently defined sID values. Afterward are details on each SEvent.		Here are the C type definitions for TRAK and SEvent and the currently defined sID values. Afterward are details on each SEvent.
Line 262:		Line 262:

	#define SID\_Mark 255 /* sID reserved for an end-mark in RAM. */</pre>		#define SID\_Mark 255 /* sID reserved for an end-mark in RAM. */</pre>

	=== Note and Rest SEvents ===		=== Note and Rest SEvents ===

Steven Solie: /* Reference */

2012-05-09T03:33:43Z

Reference

← Older revision		Revision as of 03:33, 9 May 2012
Line 38:		Line 38:
	Electronic Arts is a trademark of Electronic Arts.		Electronic Arts is a trademark of Electronic Arts.

	Amiga is a registered trademark of ~~Commodore-~~Amiga, Inc.		Amiga is a registered trademark of Amiga, Inc.

	== Background ==		== Background ==

Steven Solie: /* “SMUS” IFF Simple Musical Score */

2012-04-24T14:55:35Z

“SMUS” IFF Simple Musical Score

← Older revision		Revision as of 14:55, 24 April 2012
Line 1:		Line 1:
	= “SMUS” IFF Simple Musical Score =		= “SMUS” IFF Simple Musical Score =

			; Document Date:
	<table>
		⚫	: February 20, 1987 (SID_Clef and SID_Tempo added Oct, 1988)
	<tbody>
			; From:
	<tr class="odd">
		⚫	: Jerry Morrison, Electronic Arts
	<td align="left">'''Document Date:'''</td>
		⚫	; Status Of Standard:
⚫	~~<td~~ ~~align="left">7.9cmFebruary~~ 20, 1987 (SID_Clef and SID_Tempo added Oct, 1988)~~</td>~~
			: Adopted
	</tr>
	<tr class="even">
	<td align="left">'''From:'''</td>
⚫	~~<td~~ ~~align="left">7.9cmJerry~~ Morrison, Electronic Arts~~</td>~~
	</tr>
	<tr class="odd">
⚫	~~<td~~ ~~align="left">'''~~Status Of Standard:~~'''</td>~~
	<td align="left">Adopted</td>
	</tr>
	</tbody>
	</table>

	== Introduction ==		== Introduction ==
Line 180:		Line 170:
	The optional data chunk “ANNO” holds any text annotations typed in by the author.		The optional data chunk “ANNO” holds any text annotations typed in by the author.

	An ANNO chunk is not a property chunk, so you can put more than one in a FORM SMUS. You can make ANNO chunks any length up to 2~~<math>~~^{31} - 1~~</math>~~ characters, but 32767 is a practical limit. Since they’re not properties, ANNO chunks don’t belong in a PROP SMUS. That means they can’t be shared over a LIST of FORMs SMUS.		An ANNO chunk is not a property chunk, so you can put more than one in a FORM SMUS. You can make ANNO chunks any length up to 2^31 - 1 characters, but 32767 is a practical limit. Since they’re not properties, ANNO chunks don’t belong in a PROP SMUS. That means they can’t be shared over a LIST of FORMs SMUS.

	Syntactically, each of these chunks contains an array of 8-bit ASCII characters in the range “ ” (SP, hex 20) through “~” (tilde, hex 7F), just like a standard “TEXT” chunk. [See “Strings, String Chunks, and String Properties” in ''“EA IFF 85” Electronic Arts Interchange File Format''.] The chunk’s ckSize field holds the count of characters.		Syntactically, each of these chunks contains an array of 8-bit ASCII characters in the range “ ” (SP, hex 20) through “~” (tilde, hex 7F), just like a standard “TEXT” chunk. [See “Strings, String Chunks, and String Properties” in ''“EA IFF 85” Electronic Arts Interchange File Format''.] The chunk’s ckSize field holds the count of characters.
Line 295:		Line 285:
	Putting these three fields together, the duration of the note or rest is		Putting these three fields together, the duration of the note or rest is

	`="202D 4.5em 2~~<math>~~^{- division} * \{ 1, 3/2\} * \{ 1, 2/3, 4/5, 6/7\}~~</math>~~		`="202D 4.5em 2^{- division} * \{ 1, 3/2\} * \{ 1, 2/3, 4/5, 6/7\}

	These three fields are contiguous so you can easily convert to your local duration encoding by using the combined 6 bits as an index into a mapping table.		These three fields are contiguous so you can easily convert to your local duration encoding by using the combined 6 bits as an index into a mapping table.
Line 378:		Line 368:
	[Implementation details. Unsigned “:n” fields are packed into ''n'' bits in the order shown, most significant bit to least significant bit. An STimeSig fits into 16 bits like any other SEvent. '''Warning''': Some compilers don’t implement bit-packed fields properly. E.g., Lattice C pads a group of bit fields out to a LONG, which would make an STimeSig take 5-bytes! In that situation, use the bit-field constants defined below.]		[Implementation details. Unsigned “:n” fields are packed into ''n'' bits in the order shown, most significant bit to least significant bit. An STimeSig fits into 16 bits like any other SEvent. '''Warning''': Some compilers don’t implement bit-packed fields properly. E.g., Lattice C pads a group of bit fields out to a LONG, which would make an STimeSig take 5-bytes! In that situation, use the bit-field constants defined below.]

	The field type contains the value SID_TimeSig, indicating that this SEvent is a “time signature” event. The field timeNSig indicates the time signature “numerator” is timeNSig + 1, that is, 1 through 32 beats per measure. The field timeDSig indicates the time signature “denominator” is 2~~<math>~~^{timeDSig~~}</math>~~, that is each “beat” is a `="202D 2~~<math>~~^{-timeDSig~~}</math>~~ note (see SNote division, above). So 4/4 time is expressed as timeNSig = 3, timeDSig = 2.		The field type contains the value SID_TimeSig, indicating that this SEvent is a “time signature” event. The field timeNSig indicates the time signature “numerator” is timeNSig + 1, that is, 1 through 32 beats per measure. The field timeDSig indicates the time signature “denominator” is 2^timeDSig, that is each “beat” is a `="202D 2^-timeDSig note (see SNote division, above). So 4/4 time is expressed as timeNSig = 3, timeDSig = 2.

	The default time signature is 4/4 time. Be aware that the time signature has no effect on the score’s playback. Tempo is uniformly expressed in quarter notes per minute, independent of time signature. (Quarter notes per minute would equal beats per minute only if timeDSig = 2, n/4 time). Nonetheless, any program that has time signatures should put them at the beginning of each TRAK when creating a FORM SMUS because music editors need them.		The default time signature is 4/4 time. Be aware that the time signature has no effect on the score’s playback. Tempo is uniformly expressed in quarter notes per minute, independent of time signature. (Quarter notes per minute would equal beats per minute only if timeDSig = 2, n/4 time). Nonetheless, any program that has time signatures should put them at the beginning of each TRAK when creating a FORM SMUS because music editors need them.

Steven Solie: /* Appendix B. SMUS Example */

2012-03-24T03:46:03Z

Appendix B. SMUS Example

← Older revision		Revision as of 03:46, 24 March 2012
Line 625:		Line 625:
	Here’s a box diagram for a simple example, a SMUS with two instruments and two tracks. Each track contains 1 note event and 1 rest event.		Here’s a box diagram for a simple example, a SMUS with two instruments and two tracks. Each track contains 1 note event and 1 rest event.

			[[File:DevIFF-14.png]]
	<sub>e</sub>psf<sub>f</sub>igure8cmiff<sub>s</sub>mus<sub>e</sub>xample

	The “0” after the first INS1 chunk is a pad byte.		The “0” after the first INS1 chunk is a pad byte.

Steven Solie: /* Note and Rest SEvents */

2012-03-24T03:43:27Z

Note and Rest SEvents

← Older revision		Revision as of 03:43, 24 March 2012
Line 313:		Line 313:
	A treble staff with chords and ties:		A treble staff with chords and ties:

			[[File:DevIFF-12.png]]
	<sub>e</sub>psf<sub>f</sub>igure12cmiff<sub>s</sub>mus<sub>c</sub>hord<sub>t</sub>ies

	Corresponding SNote values in the TRAK chunk:		Corresponding SNote values in the TRAK chunk:
Line 322:		Line 322:
	If you read the above track into a monophonic-track program, it’ll strip out the chorded notes and ignore unresolved ties. You’ll end up with:		If you read the above track into a monophonic-track program, it’ll strip out the chorded notes and ignore unresolved ties. You’ll end up with:

			[[File:DevIFF-13.png]]
	<sub>e</sub>psf<sub>f</sub>igure12cmiff<sub>s</sub>mus<sub>c</sub>hord<sub>s</sub>tripped

	<pre> Pitch: G G G G G B B G		<pre> Pitch: G G G G G B B G

Steven Solie: /* Instrument Registers */

2012-03-24T03:40:22Z

Instrument Registers

← Older revision		Revision as of 03:40, 24 March 2012
Line 98:		Line 98:
	Each reference from a SMUS track to an instrument is via an “instrument register”. Each track selects an instrument register which in turn points to the specific instrument data.		Each reference from a SMUS track to an instrument is via an “instrument register”. Each track selects an instrument register which in turn points to the specific instrument data.

	Each score has an array of instrument registers. Each track has a “current instrument setting”, which is simply an index number into this array. This is like setting a raster image’s pixel to a specific color number (a reference to a color value through a “color register”) or setting a text character to a specific font number (a reference to a font through a “font register”).		Each score has an array of instrument registers. Each track has a “current instrument setting”, which is simply an index number into this array. This is like setting a raster image’s pixel to a specific color number (a reference to a color value through a “color register”) or setting a text character to a specific font number (a reference to a font through a “font register”). This is diagramed below:

			[[File:DevIFF-11.png]]
	This is diagramed below:

	<sub>e</sub>psf<sub>f</sub>igure10cmiff<sub>i</sub>nstrument<sub>r</sub>egisters

	“INS1” chunks in a SMUS score name the instruments to use for that score. The player program uses these names to locate instrument data.		“INS1” chunks in a SMUS score name the instruments to use for that score. The player program uses these names to locate instrument data.

Steven Solie at 05:54, 20 March 2012

2012-03-20T05:54:58Z

← Older revision		Revision as of 05:54, 20 March 2012
Line 1:		Line 1:
	= ~~“ILBM”~~ IFF Simple Musical Score =		= “SMUS” IFF Simple Musical Score =

	<table>		<table>

Steven Solie: Created page with "= “ILBM” IFF Simple Musical Score =

'''Document Date:''' 7.9cmFebruary 20, 1987 (SID_Clef and SID_..."
2012-03-20T05:54:38Z

Created page with "= “ILBM” IFF Simple Musical Score = <table> <tbody> <tr class="odd"> <td align="left">'''Document Date:'''</td> <td align="left">7.9cmFebruary 20, 1987 (SID_Clef and SID_..."
Show changes