#8406 closed patch
Updated GS Support + Percussion Remapping Patch
| Reported by: | SF/tbcarey | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | Audio: MT32 |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Still unfinished and needs to be reviewed for feedback and updating. Please see comments at original patch URL:
http://sourceforge.net/tracker/index.php?func=detail&aid=818939&group_id=37116&atid=418822
Ticket imported from: #1164217. Ticket imported from: patches/511.
Attachments (1)
Change History (16)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
Speaking of g_scumm depoendencies, I demostrated that those dependencies aren't introduced by this patch but already exist for a while in imuse.cpp.
--enable-gs flag sounds good.
Speaking of _native_midi. Sorry, but I don't see where MDT_NATIVE is specified for these games, May you point out an exact place?
comment:3 by , 20 years ago
First, I've uploaded a new version of the patch. Here's what's changed:
1) Rudimentary '--enable-gs' command-line option added. No GUI update yet, obviously.
2) LoomCD works fine, but can someone test zakTowns now to see if it still crashes after this patch is applied? I don't have it.
3) Better, more detailed comments.
4) Removed the GM Master Volume command. The more I think about it, the less I think it should be included. As I said before, many devices don't support it and it's not 'good form'.
To respond to your comments, I know that you demonstrated there are already g_scumm dependencies. However, Jamieson stated the objective was to get away from them, so including more wouldn't help. Now with --enable-gs, one is gone, and the other isn't a viable solution because it bypasses initialization for scumm v3 and below, and thus breaks 'full' mt-32 support for loom.
MDT_NATIVE isn't specified, but they are treated as GM. See the following comment from imuse.cpp: // Euphony tracks show as 'SO' and have equivalent properties to 'ADL' // FIXME: Right now we're pretending it's GM. Then when IMuseInternal::getBestMidiDriver is called, isGM returns true and I guess for some reason _midi_native does too, causing the driver to become _midi_native. I don't know why this is as I haven't looked into it at all yet, and it may not even be the case anymore; I don't have zakTowns to test.
If someone could test zakTowns that'd be good so I know whether this patch still needs to be fixed or can be applied after removing a few comments.
comment:4 by , 20 years ago
| Owner: | set to |
|---|
comment:5 by , 20 years ago
Note to self: Test patch against zakTowns first thing tommorow morning (when i find the damn cd ;p)
comment:6 by , 20 years ago
Added GUI support for 'enable_gs', but it messes up the layout in 'Edit Game -> Audio' due to the font size.
comment:7 by , 20 years ago
Upon closer inspection of SC-55 GS patches and an official Roland GS -> MT-32 emulation setup that I recently acquired, this patch still needs quite a bit more work to take full advantage of GS features when emulating the MT-32. A few things I plan to add soon:
1) Mapping of GS SFX that match MT-32 equivalents (i.e. replacement of the 'Gunshot' GM patch with the 'Thunder' GS patch in MI2, etc.) Hopefully this will solve the problem of most MIDI SFX sounding incorrect and eliminate the need for this RFE: https://sourceforge.net/tracker/index.php?func=detail&aid=758457&group_id=37116&atid=418823
2) Set CM-64/32L drumset as default, since it more closely mirrors the MT-32's. This will only work on Roland Sound Canvas-based modules, but then, this patch is already geared towards them anyway. It should be ignored by other GS synths but once implemented I'll test it against some mediocre GS soft synths to see how they handle it.
3) Modify reverb settings a bit to match Roland's official GS -> MT-32 ones.
4) Move more note mappings outside of imuse.cpp to mididrv.cpp in accordance with eriktorbjorn's patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1168149&group_id=37116&atid=418822
5) If time permits, I will create a custom mt32_to_gs map using more appropriate GS-based sounds. This is the lowest priority for a number of reasons; the biggest reason is that if we're striving for compatability among GS synths, it's best to use the SC-55 patches, and I don't imagine that I'll find a heap of patches among its limited set that are more suited than their GM counterparts.
6) 'enable_gs' needs to be changed so that it can be used without checking the config file every time, and to remove the config-manager.h include. This will be easy; right now it's just hacky to test functionality.
comment:8 by , 20 years ago
Numbers 2, 3, and 4 are now done. However, as I changed the default drum set to CM-64/32L, I realized that I introduced a bit of a regression. Changing to a non-GS drum set will cause the same problems with GS-mapped SFX sounding inappropriately; this means that item number 5 below now becomes a necessity, and should probably be done anyway since right now we're doing MT-32 -> GM -> MT-32 mapping for the drums. When I get around to it, I'll make certain that GS drums are left identical to the original MT-32's mapping. Unfortunately, this may render the drums a bit off for GS instruments that do not contain the CM-64/32L drum set, but I think it's a worthwhile trade-off.
comment:9 by , 20 years ago
Number 6 is now complete as well, and work started on number 1. I would like to suggest that this patch is broken up into two parts; the GS support, and the percussion remapping part. The two do not really have any reason to be linked, and I would rather see the percussion remapping get committed now than whenever the GS portion is complete.
This is especially true because of eriktorbjorn's patch mentioned in #5, which specifically deals with instrument mapping; it erroneously moved mappings to mididrv.cpp, when they should in fact be in instrument.cpp. I will create a patch to move everything over to instrument.cpp, and include the percussion map in it.
comment:10 by , 20 years ago
This patch is now done. I still haven't completed SFX remapping for GS, but that'll be a fairly significant task because of the way that SFX remapping is handled right now in instrument.cpp; it should be added via a separate patch at a later date. Here's what the patch does:
Adds a GS option to both the command line and the GUI. The GS option allows any GS-capable synth to mimic the settings of the MT-32 in order to offer more realistic overall emulation. It also makes sure a GM or GS synth is re-initialized so as not to maintain previous settings which could make playback sound incorrect. Lastly, it allows GS synths that support an MT-32-compatible map to use that map (and drumset) while playing back in Native MT-32 mode; this offers better emulation for games without custom instruments, and also ensures that playback will never use the wrong instruments on a GS synth -- that is to say, it eliminates the 'incorrect instruments with Native MT-32 mode' problem on GS synths. For this latter mode to work, both Native MT-32 and Enable GS should be used simultaneously.
Because of adding another audio option to the GUI, a new audio tab will have to be created. I will submit an additional patch that does just that, but since it's not directly related to this feature set, it isn't included in this patch.
comment:11 by , 20 years ago
Actually, I lied. Because I made changes to the GUI already, it's just easier to fix it all at once. This will now split the GUI audio options up into an audio tab -- with midi driver, subtitles, and volume -- and a MIDI tab that contains sound font, mt-32, gs, and multi-midi settings. It looks much prettier than before, especially since the addition of the sound font setting.
I also fixed a little bug I had forgotten about; scumm.cpp now checks to see whether the game is v6 (DOTT + SAMNMAX) and sets _enable_gs to false if it is. Those games shouldn't support GS, since they're written in GM natively and do not need to emulate MT-32 settings.
I'll upload the patch without deleting the other, so if you don't want to patch all at once, you can apply the first separately and then this one later if you so desire.
by , 20 years ago
| Attachment: | GSMidiTab.patch added |
|---|
comment:12 by , 20 years ago
| Status: | new → closed |
|---|
comment:13 by , 20 years ago
| Owner: | changed from to |
|---|
comment:15 by , 6 years ago
| Component: | → Audio: MT32 |
|---|
Pasting original __tom's comments for easier discussion following:
I revised the patch a bit and add comments that were more intuitive, so that others can understand what each SysEx command actually does; it should also patch cleanly now.
As far as remapping notes 24 - 34 to avoid random GS patches playing that are assigned to those notes, the patch works well; I tested it on several games and noticed the improvement in percussion. I disagreed entirely with the GS parameters meant to emulate the MT-32, though. For one thing, setting any Roland sound module in CM-64 mode will automatically select 'Hall 2' reverb, which should give you a hint that it's definitely not 'Room 1' reverb (that's probably the 'lightest' of all the reverbs; the MT-32's reverb has long decay times and very little damping or diffusion, so it does not match that setting at all). I decided to figure out what settings actually did match the MT-32's reverb best, and so I messed around by ear, took samples of the percussive channel soloed, and compared them to an original MT-32 soloed rhythm part recording I made as well. Comparing delay times and levels, I was able to match it quite well to 'Hall 2' with a longer delay time and a Pre-LF (low pass filter). I think this is the closest that any GS device will come to emulating the MT-32's reverb.
Additionally, I removed the GS SysEx messages specific to Dream/Terratec, because I didn't see the need for them. GS Reset message is a Universal Exclusive command that is recognized by all GS-compatible devices irrespective of whether the command contains a Roland Manufacturer's ID or not. As for setting up reverb for non-Roland devices, I don't think it makes sense to include just the commands for Terratec. Either we only support Roland devices (which all LucasArts games were composed with, so it makes sense to favor them; they're also the creators of GS) or we have to support hundreds of other GS devices. There is a list of manufacturer IDs here if anyone is interested: http://www.midi.org/about-mma/mfr_id.shtml
I left the GM Master Volume command intact, just in case I'm missing something. It seems redundant to me, because we've already set the Master Volume to 127 by issuing a GM System On command earlier. Also, GM Master Volume is not really defined in the original GM specs, so many GM Level 1 devices don't support it. If no one gives me a reason to keep this in here, I will remove it the next time I work on this patch.
Lastly, there are the g_scumm dependencies which I haven't really touched. I did remove the check at the beginning because it breaks (theoretically) proper MT-32 support for Loom since it's Scumm v3. It also does nothing to fix LoomCD, which is Scumm v5. I realize that leaving it as it is still breaks zakTowns and LoomCD (maybe other YM2612/FMTowns games - I haven't tested), so something will have to be changed.
The only viable solution seems to be the one that Jamieson proposed, which is to set up an '--enable-gs' or similar flag. Somewhere outside of IMuse, the engine would have to be modified to ignore the flag if the game selected was DOTT or Sam'n'Max, since IMuse would obviously have no way of knowing what game it was playing the music for.
In the meantime, I'll ask again (as logicdeluxe rightly did): why are LoomCD and zakTowns flagged as _native_midi? Even if _native_midi is juxtaposed against _native_adlib for the purpose of allowing '--multi-midi' to function properly, it still doesn't make sense in the context of those games. LoomCD supports neither Adlib nor Native MIDI, and ZakTowns doesn't support YM2162 in conjunction with Adlib or MT-32/GM playback (and YM2162 shouldn't even be considered GM by IMuse, as it is now). This should be fixed immediately.
Since I can't attach the new patch to this request, I'll open a new request and link to this one.