- 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.
- move mac, pc speaker and fm-towns ims sound drivers into separate directory
(AdLib and MT32/GM drivers are still too entangled with common code to be moved so easily, especially MT32/GM. It would require lots of changes to the common code and possibly to all engines using the MidiDriver class. So I leave that for now.)
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.
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.
This should help identify incorrect dumps/file naming like what (probably)
happened in bug #3570973
"FOA: Doesn't start anymore after adding Mac sound support".
Formerly we ever only used the lower 4 bit of the priority setting for a new
part. The original used a full 8 bit setting though (based on the Indy4 PC
Speaker output driver). This fixes missing notes in the Indy4 intro with PC
Speaker output.
This might affect other outputs too! And could cause regressions in case other
outputs implemented priority settings differently.
Now we only output a new frequency if a new channel was selected or a new
output frequency has to be send. This makes the sound much more like in
DOSBox. This is not present in the original, but since our timings are
different this should make up for that.
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.
