DMXGUS parser for internal TiMidity player

Moderator: GZDoom Developers

Post Reply
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

DMXGUS parser for internal TiMidity player

Post by Gez »

So, the [wiki]GUS[/wiki] emulator in ZDoom is unfinished. This patch makes it a bit less unfinished.

It adds a LoadDMXGUS function to the TiMidity renderer that will be called if the new "midi_readlump" CVAR is true (otherwise, it'll load the config pointed at from midi_config as before). Instrument mapping will be performed according to the DMXGUS lump.

Since Doom, Heretic, Hexen, Strife, and Chex Quest use DMXGUS while Doom II, TNT and Plutonia use DMXGUSC, and finally Hacx, Harmony or Freedoom don't have either, I went with a brute-force approach: LoadDMXGUS will first try DMXGUS, then DMXGUSC, and if both fails it falls back to LoadConfig(midi_config).

When loading an existing lump, the midi_1024remap CVAR determines whether instruments are actually remapped as if we were on a GUS with 1024K memory. You can turn that on to listen to clear differences between various configs, or leave it off to benefit from greater quality than was possible on the actual hardware.

The [wiki]advanced sound options[/wiki] menu is updated with the various settings (old and new) for the TiMidity GUS emulator there.

If midi_config isn't loaded, there is the question of finding the patches. To do so, LoadDMXGUS() will add to the path list a midi subdirectory within the directory set from the %ULTRADIR% variable (if it actually exists), as well as directly from the new midi_patchdir CVAR.

And that is the extent of the changes in the patch.

Note: the simplistic parser contained in this patch will gleefully ignore any syntax problem in the lumps. I couldn't get an FScanner-based parser to work, because 1. it uses #-to-EOL comments, not C++ style comments; 2. sidestepping that I got stuff like "Bad numeric constant "0,"" which was very annoying; 3. sidestepping also that, it somehow only parsed the odd numbered patches and that's when I said "screw it" and wrote some ad-hoc code instead. It's not any uglier than the Timidity config parser, and it avoids an extra #include.

A good test file to see the interest of the patch is this. Extract the content of gravpat.zip in your GUS patch folder, then load the .wad file. Set the MIDI device to GUS, give it a listen for a few seconds, then go to advanced sound options, set the "Read DMXGUS lumps" on, back to sound options and "restart sound". Notice the difference. :)
Attachments
gus_emulation.zip
(1.92 KiB) Downloaded 79 times
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: DMXGUS parser for internal TiMidity player

Post by Graf Zahl »

OK, nice. One question though:

What does it do if it finds a DMXGUS lump with valid content but no patches? Looking at your code I can't see any fallback for that.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: DMXGUS parser for internal TiMidity player

Post by Gez »

Then the music playback is silent.

I'm not sure many people have bothered including dummied-out DMXGUS lumps in their mods.
User avatar
randi
Site Admin
Posts: 7746
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Re: DMXGUS parser for internal TiMidity player

Post by randi »

Gez wrote:Note: the simplistic parser contained in this patch will gleefully ignore any syntax problem in the lumps. ... It's not any uglier than the Timidity config parser, and it avoids an extra #include.
If you want to see an ugly parser, this is what the official ULTRAMID.INI parser looks like:
Spoiler: Spoilered to protect the innocent
There is also an ULTRASND\ULTRASND.INI which might be nice to parse as an alternative. It's similar but doesn't care about the amount of memory installed on the GUS and can optionally support multiple patch banks. (On the other hand, it doesn't look like the actual patch assignments are any different than DMXGUS's ULTRAMID.INI if you ignore the memory restrictions, so it's probably not necessary.)

Anyway, thanks for doing this. It was something I had wanted, or it really couldn't be called GUS emulation. I have made the following changes:
  • midi_patchdir renamed to gus_patchdir.
  • midi_readlump renamed to midi_gusdmx and defaulted to true.
  • midi_1024remap renamed to gus_memlimit and now specifies which bank from ULTRAMID.INI to use, so you can pretend you have a castrated GUS with only 256K of RAM if you want.
  • Undefined patch remaps default to 255 instead of 0, as per MIDILIB.C. This probably shouldn't matter, but it's more authentic this way.
Post Reply

Return to “Closed Feature Suggestions [GZDoom]”