(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.
I noticed broken sound when starting DOTT with MT-32
setting, then returning to the launcher and then starting in
GM mode.
Turns out that there was a nasty static var in instrument.cpp
that was not always reset to the correct value.
Instead of just doing that I cleaned it up a bit and got rid of
the static var.
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).
Make sure GM init is only done with an actual GM setup.
These are mostly the same checks we already do in the
engine, but it still seems better to do this
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...
- 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.
FOA Amiga uses 'ROL ' resources (unlike MI2 which has 'AMI ' resources). So our imuse player treated those as MT32 tracks playing on a non-MT32 device and applied GM mapping. Which of course messed up the instruments.
Both means to calculate `diff` are essentially equal because
wraparound of unsigned integers is well-defined and does what
the 'else' branch is simulating manually. Because of this,
gcc complains when compiling with -Wduplicated-branches.
Fix the "MI2: Two soundtracks playing at once" bug from the bug tracker.
It's triggered when the player enters the kiosk for the second time and
leaves before tune 113 is started.
Fix the "MI2: Two soundtracks playing at once" bug from the forum. It's
triggered when the player is moving faster then the scripts expect causing
the "stop tune 117" command be executed before the start of the tune.
Effectily creating a hanging tune 107.
This patch kills the tune when this sitation is detected.
1. Remove _sc55 bool. All Roland GS-capable devices have MT-32 sound/drum maps, so they should always be used when _enable_gs is set.
2. Always enable _native_mt32 if Roland GS mode is selected. I don't know why I never did this originally, since _enable_gs is automatically disabled for SCUMM v6+ games that use General MIDI tracks instead of MT-32 music.
3. Set master tune for GS devices to 442.0kHz. This is the master tune setting for the MT-32.
For old savegames, we now use a "dummy" iMUSE objet to skip the old
iMUSE save state. I had hoped to be able to do this without making
any changes to the iMUSE code itself, but I was unable to.
Also added note about how the save state for the new music will not
quite work if the mixer output rate changes. Personally, I'm not
too worried about that. It breaks, but it shouldn't break badly.
Albeit the code is marked as a hack inside the source, the original behaved
exaclty the same. If the code is removed the PC Speaker output will miss notes,
since unlike the original we only output to parts, which have an instrument set
up.
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).