SCI: KQ4 SCI version 1.000.111 - MT-32 plays back some improper instruments

[MusicallyInspired]

It seems that playing the early SCI release of KQ4 (with alternate backgrounds for night and day screens rather than alternate palettes for the same backgrounds like the latest release included in collections) mangles the MT-32 music playback. It plays normally and properly in DOSBox but in ScummVM it plays some of the wrong instruments. It seems possibly that the custom sysex patch mapping is not being transmitted? I used the MT-32 emulator inside ScummVM. This was the very first SCI game ever so it likely has some quirks that later games changed. I do know that it doesn't accept (natively) patch files in the game directory to override the resources in the RESOURCE files.

To reproduce, play KQ4 V1.000.111 and choose MT-32 for the music. One specific example is the minstrel playing the lute produces the Recorder sound patch instead of the guitar as it normally should.

[athrxx]

Thank you for this bug report.

Which "custom sysex patch mapping" do you think is not being transmitted?

We do read a patch mapping (which doesn't have anything to with sysex) from the driver file. Even correctly (I just checked).

It is true that KQ4 early doesn't support patch files (nor any other sort of custom sysex patches). The few sysex messages that get sent concern reverb, volume and a couple of display texts.

But sure, maybe we do handle the patch mapping incorrectly somehow.

Where exactly is that guitar sound (minstrel playing a lute)? It might be obvious for people who have recently played this, but not for me. I think the last time I played through this was over 20 years ago.

[MusicallyInspired]

Sorry, I did not see your reply. The effect seems to be random actually. I just brought up the screen with the lute player and the sound played properly with the right instrument this time (I'm using the latest daily build for today (Feb 10, 2021). I also encountered incorrect instruments (sometimes missing instruments) when encountering the unicorn (also a random event) when its theme plays. It's not consistent and sometimes it's a different wrong instrument each time. It seems the easiest way to trigger this is to open ScummVM's debug console and use the STARTSOUND command to play random sound resources. It's almost like certain instruments are persisting on channels they were played on via a previous sound but aren't correct and aren't being set properly for a new sound. My best guess without knowing what's going on under the hood.

[MusicallyInspired]

Thought about this ticket again when reading up on SCI0 sound resource specifications by Ravi. It seems this version of KQ4 uses a different format for the sound resource as described below. This was also the case for the 1988 Sierra Xmas card. I wonder if this is the reason and ScummVM is trying to playback the sound resources in the conventional SCI0 way without taking these earlier differences into account? I haven't looked at the ScummVM source code to check (I wouldn't know where to find it anyway). Though, it doesn't look like there are any differences save the actual header information. Anyway, here's the info:

​https://wiki.scummvm.org/index.php?title=SCI/Specifications/Sound/SCI0_Resource_Format#Header_.28kq4.2C_1988_xmas_card.29

---

Header (kq4, 1988 xmas card)

The first byte is a digital sample flag. Afterwards 1 byte follows for each channel (totals in 17 bytes).

The upper 4 bits of that byte specify how many voices each logical MIDI channel will be playing. The lower 4 bits specify which drivers should react on that channel. Bit 0 set means AdLib shall react. Bit 1 set means PCjr shall react. MT32 will react on all channels. Bit 3 signals the control channel.

The original sierra driver needs bit 3 set and bit 0 unset to find the control channel. Also the AdLib driver needs bit 3 to be unset, otherwise the driver will ignore the channel even if bit 0 is set.

Currently its not known if the digital sample flag behaves the same as in the SCI0 header.