DMXGUS

[shadow1013]

Should we make a quick DMXGUS? In addition to the GENMIDI for FreeDOOM?

[fraggle]

shadow1013 said:

Should we make a quick DMXGUS? In addition to the GENMIDI for FreeDOOM?

DMXGUS is just a text config file, though I'm not quite sure what it's even used for. It's less important for Freedoom because there aren't any source ports that support the GUS or GUS emulation as far as I know. It would only be relevant if you were playing Freedoom under Vanilla Doom using a GUS card, which seems a bit of a niche (does Dosbox have GUS emulation?)

[shadow1013]

Yes it does in fact have GUS emulation, both for WAV and MIDI (but you can't play quake with it for some reason...) Umm, DMXGUS just tells the way to load the GUS patches into the soundcards memory, and what patch goes to what instrument number

[shadow1013]

I couldn't catch it D: But then again I'm using the original GUS patch set. Also, DMXGUS is technically DMXGUS.INI (can be seen in the heretic wadlink script) which is structually identical to the ULTRAMID.INI, so I'm sure there exists some free version we can scrounge outta linux or bsd or something.

[CODOR]

There's this, except I don't think the Chocolate Bar License is compatible with Freedoom's. :-)

This might work, as the terms are similar but not quite the same as Freedoom's (it requires credit in the resource and documentation, while Freedoom says "documentation and/or other materials provided with the distribution"). Conveniently, it's also the lump distributed with Doom 1.666 and up...

[shadow1013]

Well... I think the second one is an awesome idea, all we have to do is put the documentation somewhere in the freedoom source tree and *boom* it abides by both licenses. So that would be a perfect solution.

[fraggle]

In terms of licenses I think it's a bit more complicated than that. It's not enough for it to be "compatible" with Freedoom's license - Freedoom as a WAD is distributed under its license, and that file has not been distributed under it by its author.

The DMXGUS format doesn't look too complicated. Would it be possible to just write one from scratch? Possibly one of you guys if you care about it?

[shadow1013]

It's just a normal .ini file, I'm sure someone could write up a relatively simple one

[fraggle]

I've been having a look at this out of idle curiosity. GUS cards could have either 256K, 512K, 768K or 1024K of memory on-board, so the file has effectively four configurations, one for each. You can only load a certain number of patches depending on the amount of memory available on your card, so you have to reuse the same patch for multiple instruments. For example, here are the bass instruments from the standard ULTRAMID.INI:

32, 39, 32, 32, 32, acbass
33, 39, 32, 32, 32, fngrbass
34, 39, 32, 32, 34, pickbass
35, 39, 32, 32, 32, fretless
36, 39, 36, 36, 36, slapbas1
37, 39, 36, 36, 36, slapbas2
38, 39, 36, 36, 32, synbass1
39, 39, 36, 36, 32, synbass2

On the 256K configuration, the same patch is used for all 8 instruments (#39 = synbass2). If you upgrade to 512K you get two patches instead (#32, #36). If you max the card out to 1024K you get three (#32, #34, #36).

It seems Doom originally used a copy of standard ULTRAMID.INI that comes with the drivers. This was improved by Tom Klok in gus1m.zip (already mentioned). This was mentioned in the Doom FAQ and it seems Id took the updated config and incorporated it into later versions of the IWAD files (with some modifications? Comments in the DMXGUS lump refer to it as "gus1mx"). Doom 2 uses DMXGUSC which is slightly different to Doom 1's DMXGUS - presumably tweaked for Doom 2's music.

If we want a config for Freedoom, it has to be completely original. A good config would prioritise the patches, so that there would be a variety of distinct patches for the instruments used often in Doom 2's music, with reused/shared patches for the instruments that are less used. It could probably be calculated and generated by an automatic script, using a statistical analysis of Doom 2's instruments as a source. It would also need a list of sets of "similar patches" to work out which ones to combine together.

Testing is an issue because DOSbox's GUS emulation has 1024K of RAM with no option to change it. It could probably be changed by recompiling though.

[shadow1013]

Hmm.. I find it weird you can't change that. We should tell the Dosbox people that should be configurable! If only people actually had a real GUS of all four. I guess for now 1024k would be easiest to provide and would probably be most used, as that's what's in dosbox. Maybe if people with real GUS'es use DMXGUS, they can give idea's of how it sounds?

[fraggle]

shadow1013 said:

Hmm.. I find it weird you can't change that. We should tell the Dosbox people that should be configurable!

Well, I guess it's understandable. Even if you had a GUS in the '90s and are feeling nostalgic, it makes sense that you would want to max out your virtual GUS to the maximum possible.

It looks like it would be fairly simple to do - if you read here, the way to determine memory size is to read/write at different memory locations:

   It is also a good idea to find out exactly how much RAM is on the
 GUS, and this can be done in a similar process to the above routine.
 Since the memory can either be 256k, 512k, 768k or 1024k, all we have
 to do is to read/write values on the boundaries of these memory
 addresses. If we read the same value as we wrote, then we know exactly
 how much memory is available.

Compare this with the DOSbox source:

static Bit8u GUSRam[1024*1024]; // 1024K of GUS Ram
[...]
        case 0x307:
                if(myGUS.gDramAddr < sizeof(GUSRam)) {
                        return GUSRam[myGUS.gDramAddr];
                } else {
                        return 0;
                }

So all it needs is a new config variable ("gusram"?) and the check to be against that instead of sizeof(GUSRam).

[shadow1013]

Yes that would be the right thing to do :D I wonder what's the bug that cause quake not to be able to play on a gus though...

[Gez]

Wiki reference.

fraggle said:

If we want a config for Freedoom, it has to be completely original.

Can the default ultramid.ini be considered copyrighted? I mean, it's what everybody has been using as a base, including people like Id or Raven, and I don't think they bothered to consult Gravis' legal department about it. It was treated as being effectively public domain -- and since it's just a config file to remap patches, it didn't need a better status. The patches themselves are protected of course. And given that Gravis is dead now anyway, it's not like there is a body we can consult on the matter or who might come up with the argument that games and other applications that supported their hardware were doing so illegally and should instead not featured GUS support.

fraggle said:

A good config would prioritise the patches, so that there would be a variety of distinct patches for the instruments used often in Doom 2's music, with reused/shared patches for the instruments that are less used. It could probably be calculated and generated by an automatic script, using a statistical analysis of Doom 2's instruments as a source. It would also need a list of sets of "similar patches" to work out which ones to combine together.

Doom 2's, Freedoom's, and a bunch of popular mods'. (I'd suggest using Jimmy's Jukebox.) With a greater weight placed on Freedoom's own soundtrack I guess.

Not sure if the <1024 configs really need much considerations, none of the Doom engine games ever paid attention to them.

[fraggle]

Gez said:

Wiki reference.


Can the default ultramid.ini be considered copyrighted? I mean, it's what everybody has been using as a base, including people like Id or Raven, and I don't think they bothered to consult Gravis' legal department about it.

Possibly it can be considered copyrighted, yes. There's certainly a creative element in choosing which patches to use. So my reasoning is as follows: it could "maybe" be considered copyrighted. Certainly it hasn't been released under the BSD license by its creator. If we were to include it in Freedoom, we would be releasing it under the BSD license, which would be dishonest. Compare this with the fact that it only brings a tiny benefit to the project anyway to even have a DMXGUS lump. I'm more concerned with the Debian project jumping down our throats than having a working DMXGUS.

Doom 2's, Freedoom's, and a bunch of popular mods'. (I'd suggest using Jimmy's Jukebox.)

I agree. I'm planning on performing a similar MIDI analysis (of Doom 2's music and popular mods) for the GENMIDI work anyway.

Not sure if the <1024 configs really need much considerations, none of the Doom engine games ever paid attention to them.

It's certainly pretty irrelevant nowadays considering most people would be using DOSbox's GUS emulation if at all. It looks like all the tweaks that were made (that I mentioned above) were to the 1024K config. If the process can be automated it makes sense to generate all four, though I wonder how much you can even get away with on the smallest config (~20k per patch into 256K ~= 12 instruments - not a lot to work with)

[fraggle]

Okay shadow1013, you successfully nerd-sniped me and I threw together a config this evening. It sounds horrible but at least it's better than nothing. Feel free to improve it if you feel so inclined.

[shadow1013]

Ahh, alas, I'm no musician, my version of it would most likely be worse, I gotta recheckout my git version to test it. And I lol'ed when I saw the xkcd

[shadow1013]

Ahh, so I opened up vanilla DOOM with the GUS selected and listened to some of my favorite tracks (such as map30, I love that one!) (btw, every Ultimate FreeDOOM track except for the intro I dislike.) And honestly, it doesn't sound that horrible. I can see how it might not be the best, but by far from being the worst

[fraggle]

If you want a better example of how terrible it is, try E1M9.

[shadow1013]

E1M9 Normal DOOM? or E1M9 FreeDOOM

[shadow1013]

Holy shit in heaven. It reminds me of the original FreeDOOM GENMIDI. That's not a compliment. If I had the musical skills and any knowledge of the GUS and how much each patch takes up I could probably take a crack at it, but my "music skills" are banging a piano hoping it sounds good.

[fraggle]

Yup, exactly. I wasn't aiming to make something decent, just something that worked. To be honest, it's still marginally better than I expected.

Note that this config is specifically designed to fit within the 256K card, so it uses lots of repeated instruments. I deliberately haven't tried to make the 1024K version better - this leaves room for later improvement. As I'm planning to do a statistical analysis of the MIDI instruments for the GENMIDI work, once I have that information it might be possible to improve the config by adding some of the most-used instruments.

[shadow1013]

Ugh, making DMXGUS properly sounds like a pain in the ass though. I hope it comes out good. And also brings me to the point, if we're adding DMXGUS, shouldn't the maps be a little more vanilla flavored ;) (If you couldn't tell already I'm like a super-vanilla supporter when it comes to FreeDOOM)

[fraggle]

shadow1013 said:

And also brings me to the point, if we're adding DMXGUS, shouldn't the maps be a little more vanilla flavored ;)

No. Freedoom is not and has never been intended to work with Vanilla Doom. I've done this merely out of the nerdy-obsessive interest I have in Doom technical stuff (this interest is pretty well documented now) and it shouldn't be construed as meaning anything else. I think it's counterproductive trying to make Freedoom Vanilla compatible, and more to the point, a vote was already held on this very issue and the idea dismissed.

[shadow1013]

Ahhh, oh well. :/ It always struck me as weird why it was BOOM. On the other hand, any ideas of adding GUS emulation to choco-doom? If you really want to get near vanilla compat, that would be an interesting step to take

[Cire]

Yeah but shadow allready seem to be in good progress of a Vanilla compatible mapset and seem to be willing to make a complete Vanilla mapset for Ultimate Freedoom so if nothing else maybe it would be resonable to have an additional Vanilla Ultimate Freedoom IWAD target? I can understand that people are afraid of additional workload, but I don't think that necessarily would have to be the case since shadow seem to be willing to do the work on the maps? By the way, that poll seem to have ended with equally as many people wanting Boom as Vanilla compatibility?

[Gez]

shadow1013 said:

Ahhh, oh well. :/ It always struck me as weird why it was BOOM. On the other hand, any ideas of adding GUS emulation to choco-doom? If you really want to get near vanilla compat, that would be an interesting step to take

There's a partial implementation of GUS emulation in ZDoom. It's based on TiMidity, and tweaked according to Randy's study of the ultramid driver source code.

The big issue of course is that you'd need to also use the original GUS patches to make it sound like the original hardware. There's EAWPats or 8MBGM but you couldn't bundle them with Choco for obvious license reasons.

[chungy]

Cire said:

By the way, that poll seem to have ended with equally as many people wanting Boom as Vanilla compatibility?

Read more into the poll; discounting the votes that don't matter (the last option), 59% voted for a target that was not just vanilla, even though those were themselves split into merely limit-removing and full-on Boom compatibility.

For what it's worth, vanilla maps are in fact Boom-compatible, so if anyone wants to make vanilla-compat maps, there's nothing really stopping them. Just remember there's nothing stopping maps that require Boom from being in the same IWAD (as is already the case) as well.

[shadow1013]

Yes that is all true. Ahh, I like the idea of vanilla. Regardless, that's off topic. Umm, for the GUS emulation, of course you can't bundle eawpats, or that other one (I really wish you could scroll back while writing replies) but you could link it, or even better, there is the (crappy) patchset in debian called freepats

[Gez]

Bumpity bump.


In addition to freepats I've found many packages of something called dgguspat. Anybody knows what it is? The original GUS set, a renamed freepat, some other recreation, whatever?


Also, I've worked on this so that there'd be at least one port that can make use of those DMXGUS lumps.

[Gez]

Rebump: starting from r3494 and r1327 respectively, ZDoom and GZDoom can be used to test DMXGUS lumps. :)