Hey,
> sound.213 in LSL3 have FC F8 F8 78 FC at the end, thats the only
> place I've seen that has 0xfc at this place.
The Adlib driver sees the first 0xFC and immediately calls StopSequence.
StopSequence sets the sound object's signal property to 0xFFFF signifying
the end of the sound, returns the sound position to the loop point (default
is top of file), sets the soundstate (an internal driver variable) to 2
signifying no currently playing sound, and sets the internal delta time
count to 0. StopSequence returns to DoEvents, which promptly exits.
If the first 0xFC weren't there, the Adlib driver basically ignores the
0xF8 messages. It sets the delta time wait count to 0xF0 and sets the sound
state flag to 1. If the call to DoEvents was caused internally by an
external call to export 18, the driver immediately looks for another sound
event. If the call were the result of normal playback by the sound server,
DoEvents exits.
> What's the last byte after a series of 0xf8 doing, is it a real delta
> time?
yes
> 0xfc is also a system real-time MIDI message, but it does follow a delta
> time value.
It doesn't have to, though, according to the Adlib driver. In any case, I
think I was wrong about the use of 0xF8 as a real-time sync message.
Instead, it may be a way of allowing delta times to be any length. The
sequence F8 F8 78 ends up waiting 600 ticks, but that isn't possible in the
usual byte allocated for delta time values.
> I don't recall seeing the MT-32 driver atcually dump the 0xf8 through the
> midi port.
Hopefully this confirms my hypothesis of a delta-time extension. As more
evidence, the Adlib driver doesn't even check for 0xF8 after a normal delta
time value is read.
Cheers,
Ravi.
