[Scummvm-devel] V2/3 music in scummvm.

Jamieson Christian jamiesonc at tds.net
Sat Jun 21 22:50:01 CEST 2003


<original-message from="Jochen Hoenicke">
As this is all related to parsing midi scripts (which MidiParser does), I
think it should be enough to add a new super class "MusicParser" (or
"IMuseParser") of MidiParser, which has a clean interface containing a few
public abstract virtual methods.  From this we can extent WAParser,
ADParser, ROParser, and MidiParser.
</original-message>

The current MidiParser is exactly what you are proposing for your
"MusicParser". It is not related to any particular format; it only requires
a derivative class to be able to parse events in whatever format into a
common internal event format. From this we have derived parsers for SMF
(Standard MIDI Files), XMIDI (Sierra's eXtended MIDI format), and even some
oddball proprietary format used for the single music track in the Simon 1
demo (ref. MidiParser_S1D).

The further a particular music format deviates from the information
supported by a spec MIDI stream, the more work is involved to convert it to
a common internal format. This is required, however, in order to be able to
drive a MidiDriver object. The advantage to the architecture, however, is
that ANY MidiParser derivative can drive ANY MidiDriver object.

The WA resources used for V2 games should be parsed by some sort of
MidiParser_WA object, which converts the rather odd information in a WA
resource into information that can be carried in a standard MIDI stream.
Since WA resources make use of direct "register" access (to store temporary
numbers as well as to directly manipulate the waveform generator), I would
recommend that these be converted to SysEx events (which makes perfect sense
as they ARE intended for one specific type of music device).

In reality the MidiParser_WA wouldn't effectively drive any MidiDriver
except for [as of yet unwritten] MidiDriver_pcSpeaker or MidiDriver_PCJr,
since these two devices would be the only ones built to respond to the SysEx
events. However, the goal is to allow these MidiDriver derivatives to also
properly respond to MidiParser_SMF, which would be parsing PC speaker tracks
for V5 games such as MI2.

Note also that AD resources do NOT have to be converted to SMF format (i.e.
'ADL' resources). We could just as easily have derived a MidiPlayer_AD,
rather than using MidiPlayer_SMF. I just had higher priorities when the
MidiParser was first deployed, e.g. writing derivatives to parse formats we
had NO support for at the time.

Jochen: If you want to write a MidiParser_WA, go for it! I would be happy to
provide any help I can, but it's not something I can do myself right now,
since I am busy with another project. Just remember that you will have to
maintain the current state of the register set in both the parser and the
driver, since both sides have to be able to read values from it (and
obviously most of the registers directly affect the waveform generator's
output). Also figure on sending all of the >= 0xF8 events (the ones that
don't merely specify a note number and duration) as SysEx.

    -- Jamieson Christian (sf.net: Jamieson630)





More information about the Scummvm-devel mailing list