Opened 18 years ago
Closed 17 years ago
#2650 closed defect (fixed)
LOOM: Unknown Roland MIDI music events
| Reported by: | eriktorbjorn | Owned by: | eriktorbjorn |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Loom |
Description
Current SVN snapshot English PC floppy version
At the very end of the clerics's music, there are some MIDI events that our "RO" MIDI parser does not know how to handle. They will pass through to the default MIDI parser, which won't know what to do with them either.
The result is that the note will hang.
This probably isn't a regression. Most players will have already opened the cage, thus ending the music, long before the bug happens. I'm attaching a patch that will turn these events into bogus META events, but that makes the music sound slightly wrong.
Ticket imported from: #1498785. Ticket imported from: bugs/2650.
Attachments (3)
Change History (10)
by , 18 years ago
| Attachment: | ro-workaround.diff added |
|---|
comment:1 by , 17 years ago
| Owner: | set to |
|---|
comment:2 by , 17 years ago
I thought for a while that the old savegame was broken, because ScummVM crashes with a failed assertion if you try to load it while using the Adlib sound driver. You have to use the native MIDI driver.
Oh well, a fresh savegame might still be useful. This one is made right before the music starts, so you can listen to the whole thing. The bug is still there. File Added: loom.s40
comment:3 by , 17 years ago
A small note to anyone seeking to reproduce this: It may sound as if the music is simply looping, but it's not. The glitch happens about 2 minutes and 45 seconds into the song.
comment:4 by , 17 years ago
| Owner: | removed |
|---|
comment:6 by , 17 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:7 by , 17 years ago
I think I see the problem. The marker event is usually 0xF0, but in this case (and in a few subsequent cases in the same tune) it's 0xF1. We already handled the 0xF0 case, using the next byte to add to the "delta" value of the MIDI event. But the 0xF1 case was ignored, so instead of using the next byte as delta, it was misinterpreted as an illegal MIDI event.
I'm speculating now that 0xF1 is for adding values > 255 to the delta value. Adding another 256 sounds good enough to me, so that's the change I've made now in SVN. I don't know for sure which games it affects
Ugly workaround patch