More SEvents can be defined in the future. The sID codes 133 through 143 and 160 through 254 are reserved for future needs. Caution: sID codes must be allocated by a central "clearinghouse" to avoid conflicts. The following SEvent types are under consideration and should not yet be used. Issue: A "change tempo" SEvent changes tempo during a score. Changing the tempo affects all tracks, not just the track containing the change tempo event. One possibility is a "scale tempo" SEvent SID_ScaleTempo that rescales the global tempo: currentTempo := globalTempo * (data + 1) / 128 This can scale the global tempo (in the SHDR) anywhere from x1/128 to x2 in roughly 1% increments. An alternative is two events SID_SetHTempo and SID_SetLTempo. SID_SetHTempo gives the high byte and SID_SetLTempo gives the low byte of a new tempo setting, in 128ths quarter note/minute. SetHTempo automatically sets the low byte to 0, so the SetLTempo event isn't needed for coarse settings. In this scheme, the SHDR's tempo is simply a starting tempo. An advantage of SID_ScaleTempo is that the playback program can just alter the global tempo to adjust the overall performance time and still easily implement tempo variations during the score. But the "set tempo" SEvent may be simpler to generate. Issue: The events SID_BeginRepeat and SID_EndRepeat define a repeat span for one track. The span of events between a BeginRepeat and an EndRepeat is played twice. The SEvent.data field in the BeginRepeat event could give an iteration count, 1 through 255 times or 0 for "repeat forever". Repeat spans can be nested. All repeat spans automatically end at the end of the track. An event SID_Ending begins a section like "first ending" or "second ending". The SEvent.data field gives the ending number. This SID_Ending event only applies to the innermost repeat group. (Consider generalizing it.) A more general alternative is a "subtrack" or "subscore" event. A "subtrack" event is essentially a "subroutine call" to another series of SEvents. This is a nice way to encode all the possible variations of repeats, first endings, codas, and such. To define a subtrack, we must demark its start and end. One possibility is to define a relative branch-to-subtrack event SID_BSR and a return-from-subtrack event SID_RTS. The 8-bit data field in the SID_BSR event can reach as far as 512 SEvents. A second possibility is to call a subtrack by index number, with an IFF chunk outside the TRAK defining the start and end of all subtracks. This is very general since a portion of one subtrack can be used as another subtrack. It also models the tape recording practice of first "laying down a track" and then selecting portions of it to play and repeat. To embody the music theory idea of playing a sequence like "ABBA", just compose the "main" track entirely of subtrack events. A third possibility is to use a numbered subtrack chunk "STRK" for each subroutine.
[Back to Amiga Developer Docs]