Is this still being worked on? The svn log indicates nothing has happened in the MIDI code since the PQ2 reverb fix, and the reverb still isn't properly reset.

It would help us if you told us what game you're talking about, and what (if any) messages ScummVM prints on the console when you try to add it.

waltervn wrote:We are aware of this. The code is still work-in-progress. I'll let you know when it's ready for testing.

I know, but I'll continue testing your work in progress anyway, 'cause I like doing that.

I'm not criticizing, I'm just trying to help.

waltervn wrote:In SCI0, reverb is always reset before every song.

Okay, that's interesting. May I point out that ScummVM currently does not do that? I guess a call to setReverb should be inserted into some place like sendInitCommands after all?

I did some testing on the latest revision (54495): Reverb appears to be correct in KQ1SCI, KQ4 and KQ5. However, it is not correct in Police Quest 2. Running PQ2 in DOSBox, it seems the reverb is initialized to reverb config 0 (00 04 05), but is then immediately changed to reverb config 2 (01 01 07)...

No repro on that in 54490. By the way, reverb handling in 54490 is better, but not correct. For KQ5 it now works right, because it will send reverb config 0 once it encounters the reverb 127 in the first song (is this true for all SCI1 games?) For SCI0, it will send the default reverb read from the ...

No problem, I understand. Take your time, I'm just glad to have helped.

@Raziel: I can't reproduce that issue. All I'm doing is starting a new game and walking outside, and there is music. I am getting a checksum error though; is ScummVM sending the sysex data too quickly? EDIT: Found the cause of the checksum error, will submit a patch. EDIT2: Patch submitted. I still ...

No problem. Please let me know when you've fixed this issue so I can test it.

My tests seem to confirm that KQ5 (CD) always sends reverb config 0 to the MT-32, regardless of the default reverb value in the patch. Just to make sure, I also modified the actual values of the first reverb config entry, and that did show up in the capture. I also tried this with KQ4 (newer version...

Is there a better option to do that than trying to manually locate patch.1 in the file with a hex editor?

Thanks for looking into this. It seems that at least KQ1, KQ4 and KQ5 send the default reverb to the MT-32. Maybe the reverb 127 has something to do with that in KQ5, but looking from the trace I took it sends the reverb sysex before it starts playing the song that contains that event. In KQ1 and KQ...

Okay, looks like this patch was accepted (though the fact that it needs to send the default reverb to the MT-32 is still left as TODO; note that this also doesn't fix envisagedOne's KQ5 issue). Meanwhile, I've submitted another patch for an issue with the MT-32 when paused music is resumed. We'll ge...

Ok, I've figured out another piece of this puzzle (I'm sorry for the multiple posts). The MidiPlayer_Midi::readMt32Patch (engines/sci/sound/driver/midi.cpp) function doesn't read the reverb configs correctly. It reads the values in the wrong order. The code was: for &#40;int i = 0; i < kReverbCo...

The more I look at this, the less sense it makes. I was wrong before: when running KQ5 in DOSBox it does send a reverb sysex. The data it sends is 00 04 04. This value is not among the reverb configurations that ScummVM reads from the patch data. I rechecked KQ4, and reverb isn't handled properly th...