home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 3 / PDCD_3.iso / utilities / utilsf / ifftext / SMUS < prev   
Text File  |  1993-06-24  |  49KB  |  1,142 lines
  1. "SMUS" IFF Simple Musical Score
  2.  
  3. Date:   February 5, 1986
  4. From:   Jerry Morrison, Electronic Arts
  5. Status: Adopted
  6.  
  7. 1. Introduction
  8.  
  9. This is a reference manual for the data interchange format "SMUS", 
  10. which stands for Simple MUsical Score. "EA IFF 85" is Electronic Arts' 
  11. standard for interchange format files. A FORM (or "data section") 
  12. such as FORM SMUS can be an IFF file or a part of one. [See "EA IFF 
  13. 85" Electronic Arts Interchange File Format.]
  14.  
  15. SMUS is a practical data format for uses like moving limited scores 
  16. between programs and storing theme songs for game programs. The format 
  17. should be geared for easy read-in and playback. So FORM SMUS uses 
  18. the compact time encoding of Common Music Notation (half notes, dotted 
  19. quarter rests, etc.). The SMUS format should also be structurally 
  20. simple. So it has no provisions for fancy notational information needed 
  21. by graphical score editors or the more general timing (overlapping 
  22. notes, etc.) and continuous data (pitch bends, etc.) needed by 
  23. performance-oriented MIDI recorders and sequencers.
  24.  
  25. A SMUS score can say which "instruments" are supposed play which notes. 
  26. But the score is independent of whatever output device and driver 
  27. software is used to perform the notes. The score can contain device- 
  28. and driver-dependent instrument data, but this is just a cache. As 
  29. long as a SMUS file stays in one environment, the embedded instrument 
  30. data is very convenient. When you move a SMUS file between programs 
  31. or hardware configurations, the contents of this cache usually become 
  32. useless.
  33.  
  34. Like all IFF formats, SMUS is a filed or "archive" format. It is completely 
  35. independent of score representations in working memory, editing operations, 
  36. user interface, display graphics, computation hardware, and sound 
  37. hardware. Like all IFF formats, SMUS is extensible.
  38.  
  39. SMUS is not an end-all musical score format. Other formats may be 
  40. more appropriate for certain uses. (We'd like to design an general-use 
  41. IFF score format "GSCR". FORM GSCR would encode fancy notational data 
  42. and performance data. There would be a SMUS to/from GSCR converter.)
  43.  
  44. Section 2 gives important background information. Section 3 details 
  45. the SMUS components by defining the required property score header 
  46. "SHDR", the optional text properties name "NAME", copyright "(c) ", 
  47. and author "AUTH", optional text annotation "ANNO", the optional instrument 
  48. specifier "INS1", and the track data chunk "TRAK". Section 4 defines 
  49. some chunks for particular programs to store private information. 
  50. These are "standard" chunks; specialized chunks for future needs can 
  51. be added later. Appendix A is a quick-reference summary. Appendix 
  52. B is an example box diagram. Appendix C names the committee responsible 
  53. for this standard.
  54.  
  55. Update: This standard has been revised since the draft versions. The 
  56. "INST" chunk type was revised to form the "INS1" chunk type. Also, 
  57. several SEvent types and a few text chunk types have been added.
  58.  
  59. Note: This is a MacWrite[tm] 4.5 document. If you strip it down to a 
  60. text file, you'll lose pictures, significant formatting information 
  61. like superscripts, and characters like ")". Don't do it.  
  62.  
  63.  
  64.   ----------------------------------------------------------------
  65.   |(Sorry, EA. We had to strip it down for ease of distribution, |
  66.   |  but we did convert pictures to text-form and where we could |
  67.   |  not do that, we provided ILBM illustrations that people     |
  68.   |  could actually show using the standard "showilbm" program)  |
  69.   ----------------------------------------------------------------
  70.  
  71.  
  72. References:
  73.  
  74. "EA IFF 85" Standard for Interchange Format Files describes the underlying 
  75. conventions for all IFF files.
  76.  
  77. "8SVX" IFF 8-Bit Sampled Voice documents a data format for sampled 
  78. instruments.
  79.  
  80. Electronic Arts[tm] is a trademark of Electronic Arts.
  81.  
  82. MIDI: Musical Instrument Digital Interface Specification 1.0, International 
  83. MIDI Association, 1983.
  84.  
  85. MacWrite[tm] is a trademark of Apple Computer, Inc.
  86.  
  87. SSSP: See various articles on Structured Sound Synthesis Project in 
  88. Foundations of Computer Music.
  89.  
  90.  
  91.  
  92.  
  93. 2. Background
  94.  
  95. Here's some background information on score representation in general 
  96. and design choices for SMUS.
  97.  
  98. First, we'll borrow some terminology from the Structured Sound Synthesis 
  99. Project. [See the SSSP reference.] A "musical note" is one kind of 
  100. scheduled event. It's properties include an event duration, an event 
  101. delay, and a timbre object. Theevent duration tells the scheduler 
  102. how long the note should last. The event delay tells how long after 
  103. starting this note to wait before starting the next event. The timbre 
  104. object selects sound driver data for the note; an "instrument" or 
  105. "timbre". A "rest" is a sort of a null event. Its only property is 
  106. an event delay.
  107.  
  108. Classical Event Durations
  109.  
  110. SMUS is geared for "classical" scores, not free-form performances. 
  111. So its event durations are classical (whole note, dotted quarter rest, 
  112. etc.). It can tie notes together to build a "note event" with an unusual 
  113. event duration.
  114.  
  115. The set of useful classical durations is very small. So SMUS needs 
  116. only a handful of bits to encode an event duration. This is very compact. 
  117. It's also very easy to display in Common Music Notation (CMN).
  118.  
  119. Tracks
  120.  
  121. The events in a SMUS score are grouped into parallel "tracks". Each 
  122. track is a linear stream of events.
  123.  
  124. Why use tracks? Tracks serve 4 functions:
  125.  
  126. 1.      Tracks make it possible to encode event delays very compactly. 
  127. A "classical" score has chorded notes and sequential notes; no overlapping 
  128. notes. That is, each event begins either simultaneous with or immediately 
  129. following the previous event in that track. So each event delay is 
  130. either 0 or the same as the event's duration. This binary distinction 
  131. requires only one bit of storage.
  132.  
  133. 2.      Tracks represent the "voice tracks" in Common Music Notation. 
  134. CMN organizes a score in parallel staves, with one or two "voice tracks" 
  135. per staff. So one or two SMUS tracks represents a CMN staff.
  136.  
  137. 3.      Tracks are a good match to available sound hardware. We can 
  138. use "instrument settings" in a track to store the timbre assignments 
  139. for that track's notes. The instrument setting may change over the 
  140. track.
  141.  
  142.         Furthermore, tracks can help to allocate notes among available 
  143. output channels or performance devices or tape recorder "tracks". 
  144. Tracks can also help to adapt polyphonic data to monophonic output 
  145. channels.
  146.  
  147. 4.      Tracks are a good match to simple sound software. Each track 
  148. is a place to hold state settings like "dynamic mark pp ", "time signature 
  149. 3/4", "mute this track", etc., just as it's a context for instrument 
  150. settings. This is a lot like a text stream with running "font" and 
  151. "face" properties (attributes). Running state is usually more compact 
  152. than, say, storing an instrument setting in every note event. It's 
  153. also a useful way to organize "attributes" of notes. With "running 
  154. track state" we can define new note attributes in an upward- and 
  155. backward-compatible way.
  156.  
  157.         Running track state can be expanded (run decoded) while loading 
  158. a track into memory or while playing the track. The runtime track 
  159. state must be reinitialized every time the score is played.
  160.  
  161. Separated vs. interleaved tracks. Multi-track data could be stored 
  162. either as separate event streams or interleaved into one stream. To 
  163. interleave the streams, each event has to carry a "track number" attribute.
  164.  
  165. If we were designing an editable score format, we might interleave 
  166. the streams so that nearby events are stored nearby. This helps when 
  167. searching the data, especially if you can't fit the entire score into 
  168. memory at once. But it takes extra storage for the track numbers and 
  169. may take extra work to manipulate the interleaved tracks.
  170.  
  171. The musical score format FORM SMUS is intended for simple loading 
  172. and playback of small scores that fit entirely in main memory. So 
  173. we chose to store its tracks separately.
  174.  
  175. There can be up to 255 tracks in a FORM SMUS. Each track is stored 
  176. as a TRAK chunk. The count of tracks (the number of TRAK chunks) is 
  177. recorded in the SHDR chunk at the beginning of the FORM SMUS. The 
  178. TRAK chunks appear in numerical order 1,