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

[Jamieson Christian]

<original-message from="Jochen Hoenicke">
One problem I still have for WA resources is that there is only a
single position into the stream.  WA resources can be
"multi-threaded", a good example is the PCjr airport sound in Zak
(sound 87).  On channel 0 the bass is played in a tight loop, while on
channel 1 and channel 2 there are playing slow high notes which are
slowly getting out of sync, because channel 2 makes a pause after each
loop.  Each channel has it's own script.  OTOH there are cases where
the channels can interact with each other, so I can't simply make
three different MidiParsers for it.
</original-message>

The multi-threaded nature of WA resources is really not a problem. The
design solution would resemble that of a parser for a Type 1 (multi-track)
SMF. If you look at the original MIDI code for Simon (before we replaced it
with our own parsers), you can see how this type of code worked. Every
iteration, it simply scans all of the SMF "tracks" (which are fundamentally
equivalent to the WA "threads") to see which track has the
earliest-occurring event.

<original-message from="Jochen Hoenicke">
I think I'd rather handle these opcodes inside the parser and make a
set instrument SysEx event every time a note is played and something
changed in between, giving all waveform-related registers as data.
</original-message>

Well, you're still going to have to maintain the registers on both sides,
regardless. The waveform generator HAS to maintain that information, of
course, and the parser has to maintain all the registers simply because a
script can potentially reference ANY register as a data variable (e.g. the
freqmod_multiplier register could actually be referenced as a loop
counter!). This is the way I understand the capabilities of the WA
scripting, anyway.

At the same time, packaging all the register updates as one single SysEx
would probably cut down on the MIDI traffic, which is always a good thing.

<original-message from="Jochen Hoenicke">
While we are at that topic: The MidiDriver has two different
equivalent interfaces: The allocateChannel()/MidiChannel interface
send/sysEx interface.  If I read the code correctly, the imuse_player
(which is a MidiDriver only implements the send/sysEx interface, but
uses the MidiChannel interface from the back-end MidiDrivers).  It
would be nice to clean this up, e.g. only use the MidiChannel
interface.  This would make writing new midi drivers a bit easier.
</original-message>

The MidiChannel interface uses the MidiDriver's send()/sysEx() interface,
but provides dynamic channel allocation that some, but not all, clients
require. I hesitate to drop either interface for two reasons:

(1) I don't want to REQUIRE MidiChannel support for any MidiDriver
implementation. This would complicate iMuse and Simon's MidiPlayer alike.
The MidiParser doesn't need it, since it knows exactly what channel should
receive what data; the MidiChannel interface would just add unnecessary
overhead.

(2) I don't want to REMOVE MidiChannel support because the MidiChannels
allow us to avoid making the assumption that the 16 regular MIDI channels
are all we can use. The Adlib driver actually makes 32 channels available,
because it doesn't care how many channels you allocate -- it only cares how
many notes are active at the same time. Using the MidiChannel interface in
this situation really simplifies the client code (i.e. iMuse and Simon's
MidiPlayer).

Just remember that if you're coding a MidiDriver intended for actual MIDI
output or waveform generation (as opposed to a virtual in-between MidiDriver
such as iMuse), you MUST implement a MidiChannel interface unless you are
CERTAIN the MidiDriver will ONLY be driven directly from a MidiParser. For
now, I'd say that's a safe assumption -- the plan is to plug the
MidiParser_WA directly into the MidiDriver_pcSpeaker. Once we start tapping
into the PC-Speaker driver from V5 games, a MidiChannel interface will be
necessary.

    -- Jamieson (sf.net: Jamieson630)