- avoid sending unnecessary sysex messages
- add a delay after certain sysex messages
(but without calling OSystem::delayMillis(), since
that has negative impact on the playback).
Move some Midi related code into the new drivers. I have
kept some handling for Mac and PCSpk for now, since I'll
have to do more research, before I touch them. But eventually
it would be nice to get rid of as much of these sound
type checks/exceptions in the common code as possible.
Also, I finally verified that Samnmax does actually init the
pitchbend factor to 2, but it can be set to 0 by control
change 16. In this case the pitchbend message will alter
the volume instead of the pitch. I don't know if that method
is used anywhere, though.
(fixes bug no. 1248 - "SAM: some MIDI channels missing on MT-32")
This is a very obvious bug if the speech is turned off (otherwise the speech will
kind of cover it up). In the SAMNMAX intro it is hardly playing anything.
The reason is that the newer sound system has an extra driver layer between the
imuse parts and the actual hardware which mananges the channels (similar to
what we already do for AdLib, Amiga, FM-Towns...). Whenever the songs are
attempting to use a Midi part > 9 our current system will fail.
I have written the MT-32 player to also handle the older games music and sound
effects. This will allow cleaning up various more hacks in the common sound code.
I have done only little cleanup here, since it is not the main purpose of the commit.
I will also write a GM driver. This is going to be easier. Currently, there is a only
some init and skeleton code for it, the rest is just pass-through...
Currently, Roland MT-32 sound is broken for
SAMNMAX. Just try the intro song with shut off
speech. It is very obvious that it plays with a quite
reduced number of channels compared to the
original interpreter.
Now, due to the not-so-helpful code design (much
of the iMuse code has been drawn into the common
code) it has become increasingly difficult to fix Midi
related thing in iMuse. I have added more and more
crude hacks over time.
SAMNMAX requires more elaborate channel
allocation. To make it happen I have added driver
wrappers for Midi to the iMuse code.
Other than that, I have done only minor cleanup here.
Actually, I would have liked to withdraw much more
of the iMuse code from the common code and move
it to SCUMM (basically all the MidiChannel
stuff which is exclusively used by iMuse. But it turns
out that it is so thoroughly intertwined (the major
blocker here being the AdLib driver) that it requires
more thought and effort and would just distract me
from fixing the SAMNMAX sound.
Reduce abuse of the property function to set init vars.
Better distinction between drivers to prevent a GM init on
the Mac driver (which could happen depending on the
launcher sound setting).
(I have checked some more drivers. It seems that the AdLib and PC Speaker
drivers of the earlier games have larger boundaries, the MT-32 drivers have
smaller ones)
In SAMNMAX the player wouldn't properly distinguish between GM and AdLib, because the sound all have the same 'Midi' tag. Now, this gets tested in a way than works for all targets.
Continued bug fixing for ticket no. 13460 ("Incorrect MIDI
pitch bending"). This time the AdLib part (which applies
to FM-Towns, too, since it is more or less the same driver).
This fixes the sound when the bird is dropping from the
sky in the DOTT intro.
Also separate the GM code for SAMNMAX a bit after
checking the original code.
(General Midi Part only)
The bug report says that the AdLib part is broken, too. I am not sure about that device. For GM it was very obvious, though...
The size in snprintf includes the final null character, so here
3 bytes are not enough to store a space, 2 digits and the null
character.
The compiler complained and the output used to display 1 digit
instead of 2, for each byte.
Extend this size from 3 to 4 in the snprintf call.
- At at least one place in INDY4 the game attempts to send a Roland MT-32 patch to the Amiga driver. This will fail and thus not cause any harm, but I have added a check nonetheless. The original Amiga driver ignores sysex messages that don't have the iMuse manufacturer id 7D.
- In INDY4 the iMuse player thinks it has a percussion channel due to the fact that it plays ROL resources. This should also be irrelevant for the actual playback, but I have added a check for that, too.
Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
This tries to make our code a bit more compliant with our code formatting
conventions. For future use, this is the command I used:
git ls-files "*.cpp" "*.h" | xargs sed -i -e 's/[ \t]*$//'
1) Don't skip transpose setting in sysex command 0. There are only a few sounds where this setting is used (mainly sfx).
2) Make MI2 and INDY4 read certain player start parameters from the sound resource. The start parameters usually match our default parameters (exception: e.g. LeChuck's Fortress). The use of these parameters has been dropped in DOTT (they use default parameters like we do).
Many engines follow the advice in audio/midiparser.h and create a
"pseudo-MidiDriver" subclass. But MidiParser really only needs a tiny
subset of the MidiDriver capabilities, namely those found in
MidiDriver_BASE. So we try to subclass from that whenever possible; this
allows us to remove many stub methods, and enables further future
simplifications.
- Start rewriting audio code for FM-TOWNS versions of Loom, Indy3 and Monkey Island 1 using the recently added code in towns_audio.cpp (Zak should work the same way, but I can't test, since I don't own that one).
- All sound types (pcm, euphony and cd audio) now support volume and balance control (e.g. try walking into/out of the kitchen and opening/closing the door in the Scumm Bar in Monkey Island 1 or walking into/out of the circus tent).
- Pcm sounds now support proper loop start/end and note offsets (e.g. try out the hammer sound in the forge in LOOM for example).
- some other minor improvements
- The FM-Towns versions of Indy 4 and Monkey Island 2 are not affected. I don't have Monkey Island 2, but I presume that it will work like Indy 4. Adding support for these will be a separate task, since they work quite differently.
svn-id: r52198