While you are working at rebuilding MBF, would it hurt if Allegro MIDI_TRACKS "theoretical maximum" is bumped from 32 to 64? I am toying with such a build locally which allows me to play MIDIs in more recent WADs (such as those using Bobby Prince's original MIDI files). I also bumped DIGI_VOICES and MIDI_VOICES, but not sure this does anything really, except increase footprint. Sound works fine for me when running in Windows 98. Havent tried with DSDMA yet.

This is probably a bit too specific, but I'm having a major display glitch when running MBF on my ATI Rage Pro-based All-In-Wonder Card. The display runs through its color tests rather than properly displaying an image. I checked if it was the Windows-based driver. In a way, it is. It doesn't show up when using an earlier driver.

However, since MBF is also based on Boom, I have checked Boom, to make sure it worked properly on that same driver. It does.

In short, there's a display bug for the ATI All-In-Wonder, in MBF, that popped up when the code was changed from Boom.

Have been re-reading some of the relevant parts of the thread after @T-Squared mentioned these Adlib-related discrepancies and @gerwin responded, and also actually checked the code in ADLIB.C in ALLEG30B, and am wondering if one could achieve replacing the "stock" Allegro driver with code from MUSLib OPL part "translated" to GCC? Like tossing most of Allegro stuff out of the window (except routines that bind it to the library and its lifecycle and port io stuff), and rewriting using different instrument format and also replacing *.IBK support with *.OP2 support in the process...

I am considering trying my hand at it and creating such drop-in replacement for ADLIB.C, at least starting with OPL2, but am conscious this could be "been there done that didn't work" situation.

Also IMHO, Doom MUS soundtrack played via DMX is not the nicest OPL music you can hear in old games, which kind of holds me back slightly as well...

ludicrous_peridot wrote on 2023-11-03, 15:01:

Have been re-reading some of the relevant parts of the thread after @T-Squared mentioned these Adlib-related discrepancies and @gerwin responded, and also actually checked the code in ADLIB.C in ALLEG30B, and am wondering if one could achieve replacing the "stock" Allegro driver with code from MUSLib OPL part "translated" to GCC? Like tossing most of Allegro stuff out of the window (except routines that bind it to the library and its lifecycle and port io stuff), and rewriting using different instrument format and also replacing *.IBK support with *.OP2 support in the process...

I am considering trying my hand at it and creating such drop-in replacement for ADLIB.C, at least starting with OPL2, but am conscious this could be "been there done that didn't work" situation.

I kinda did that already, back then.
There is a digital and music driver selection and interfacing in Allegro. That part I wanted to keep. It is modular. You can then change the drivers, or add drivers, according to, and within the limits of, that Allegro interfacing API.

ludicrous_peridot wrote on 2023-11-03, 15:01:

Also IMHO, Doom MUS soundtrack played via DMX is not the nicest OPL music you can hear in old games, which kind of holds me back slightly as well...

The mechanism and format prevents it from being the nicest. It is translated from a sort of midi MUS format back to an FM format. It is not tailormade FM music.

gerwin wrote on 2023-11-03, 16:44:

I kinda did that already, back then.

Yes, sure - not arguing that you've located and addressed major sources of sound difference between the two. What I mean however, is like a total rewrite, except that driver API part you mention. Including changing the instrument data type to match one in MUSLib, using a single array of instruments instead of instruments/drums and such. You know, just to copycat the whole MUSLib thing and use the latter as the reference sound for testing, rather then have a somewhat hybrid Allegro driver.
I took a stab at loading GENMIDI.OP2/LMP into current version of ADLIB.C (to use Doom or Hexen native lumps instead of converted instrument banks) and to me the way data from IBK-s is treated suggest a quite different approach to handling it later on than what MUSLib/MUSPlay does.

The mechanism and format prevents it from being the nicest. It is translated from a sort of midi MUS format back to an FM format. It is not tailormade FM music.

Yeah... I personally play Doom engine games with GM almost always.

@ludicrous_peridot
a bit offtop, but
I DMed (on Doomworld) you a savegame crash fix for one of your source ports, pls read

I spent a bit of time considering this idea of mine, aaaand, it appears to be quite a lot of work to do. Still loading OP2 format instead of IBK stuck with me, so I made a new version of Tartar that loads the banks from GENMIDI lump of a WAD after sound system init, and not from separate file at startup like MBF does.
While doing this I actually fixed the high pitch issue reported by T-squared before, as this was caused by per-instrument base not offset, which GENMIDI has - so I put a workaround for ADLIB driver code to respect that.

If you are curious how it sounds I have uploaded recent testing build to moddb page (also, I don't have allegro code online anywhere). Still not exactly LibMUS sound but, say, couple of steps closer. 😉

SilverMiner wrote on 2023-11-04, 10:11:

a bit offtop, but

Thanks, noted.

One other thing I have recently changed is how Allegro MIDI code handles pan. By default it would put the channels around listener, which in principle creates a nice "sound stage" effect if you are there to listen to the tunes. In case of OPL3 handles stereo sound, however, this sounds a bit too pronounced, even distracting - and in my opinion does not work very well for an action game soundtrack even for GM devices. I have thus put all channels into center by default, which makes the tunes sound a step closer to the DMX sound.

I am content with the way OPL music sounds now, so sharing my customized version of Allegro as attachment. This is based on the version @gerwin has linked on the original post.

EDIT: Reattaching with some changes and fixes. Since this is effectively the version I am using for house ports and libAllegro is open source, I am taking advantage of this post to also share the modifications to the source that I made, as I guess I am obliged to do. Not all of them are relevant for the discussion, so please consult ADLIB.C and MIDI.C for these:

* support for loading of OP2 format files
* support for loading OP2 format instruments from memory buffer
* handling of instruments that define note offset in OP2 (not sure if IBK format has anything similar) - addresses wrong pitch as reported by @T-Squared
* Allegro fractional (sub-note) pitch bend no longer incorrectly applied with Adlib driver - has also been addressed in latest build @gerwin has shared
* MIDI instrument pan centered by default, as with Doom and LibMUS (was randomized by default with Allegro)
* Voice pan centered by default upon loading it into sound card
* Minor tweak to panning formula to align to MUSLib
* Convergence of allegro and MUSLib sound card initialization code and also with second chip initialization in 2xOPL2 setup

Other changes include tweaks to setup, additional method for probing current state of music playback, removal of id assets from setup and instruments, and uptic in maximum number of sound channels.

ludicrous_peridot wrote on 2023-11-08, 07:53:

One other thing I have recently changed is how Allegro MIDI code handles pan. By default it would put the channels around listener, which in principle creates a nice "sound stage" effect if you are there to listen to the tunes. In case of OPL3 handles stereo sound, however, this sounds a bit too pronounced, even distracting - and in my opinion does not work very well for an action game soundtrack even for GM devices. I have thus put all channels into center by default, which makes the tunes sound a step closer to the DMX sound.

I am content with the way OPL music sounds now, so sharing my customized version of Allegro as attachment. This is based on the version @gerwin has linked on the original post.

Thanks!
I am sorry my previous intention to consolidate a newer MBF release got stalled, because of distractions, and because crvs his changes where more extensive then I had thought. It is still on my ToDo list... But attached are the bits I changed earlier this year. Both changes were because of user feedback in this topic.
- adlib.c at line 561: "don't use MUSlib pitchtable, because 'bend' has been interwoven with 'note' already."
- midi.c "increased timer from 40 BPS to 80 BPS on 4 occurences."

I will consider what you wrote about panning. It is an interesting observation.

Another noobish question on my part: I've been playing around with different GENMIDI versions from historical Freed∞m releases, and also learned of the DMXOPL project. However, loading the various versions of GENMIDI does not seem to affect the sound of OPL3 music in MBF 2.04. Am I to understand that the way Allegro handles OPL music playback is not dependent on the variables in the GENMIDI lump?

MrFlibble wrote on 2023-11-11, 18:11:

Another noobish question on my part: I've been playing around with different GENMIDI versions from historical Freed∞m releases, and also learned of the DMXOPL project. However, loading the various versions of GENMIDI does not seem to affect the sound of OPL3 music in MBF 2.04. Am I to understand that the way Allegro handles OPL music playback is not dependent on the variables in the GENMIDI lump?

Originally MBF used the Allegro build-in Midi-to-FM conversion table. The table is found in "Allegro\src\djgpp\fm_instr.h". When Allegro is build into its library form, this table is hardcoded in there. For the MBF 2.04 project I changed the fm_instr.h table to the Doom1 values.
For example the first line:
{ 0x00, 0x30, 0x14, 0x00, 0xf0, 0xf1, 0xf3, 0xf4, 0x01, 0x01, 0x0a, 0, 0, 0 }, // Acoustic Grand
Allegro already had the option to load another Midi-to-FM table, as an override, but only when it is in the IBK format, outside of a WAD.
MBF 2.04 uses this functionality for Doom2 mode, loading MBF_D2GM.IBK at startup.
Seemingly the Allegro sound driver should already support a user override through setup.cfg, as below. But I have not tested that.

setup.cfg
ibk_file =

Thank you for the explanation! Very interesting! (now to find more about the IBK format)

UPD: Found the basic info about both SBI and IBK formats at the ModdingWiki. Both are supported by Wohlstand's OPL3BankEditor, and I've just ran a small test: loaded MBF_D2GM.IBK in it and replaced the first 32 instruments with SBI files from the DMXOPL project which are included in the Freedoom repo, saved this as DMXOPL3.IBK and edited the SETUP.CFG to use this file:

1ibk_file =  DMXOPL3.IBK

And it worked juts fine 😀

MrFlibble wrote on 2023-11-11, 20:07:

And it worked just fine 😀

Good to read that!
I should have some tools, notes and soundbanks, from the time I was doing the initial conversion.

I've manually replaced the musical instrument patches (but not the percussion ones) with the DMXOPL ones from the Freedoom repo. Turns out I needed to use the variants with the -2 suffix at the end, because the default ones sound very off in MBF. I'm not sure if this is the intended or best quality, but at least the songs sound recognizable in the port. (I wonder if this works at all on real hardware? I only run MBF in DOSBox.)

I also tried out newer DMXOPL releases from the project's GitHub page, not in the least because I can convert the whole .op2 file into .IBK in OPL3BankEditor, instead of individually replacing instrument files. However, what I tested so far (v2.11d and v2.10) sounds incredibly off in MBF.

UPD: Alright, I figured out a few things. First, OPL3BankEditor can load whole GENMIDI lumps if they have the .op2 extension, which made testing easier. Second, I realised that both the Freedoom GENMIDI lump and the recent releases of DMXOPL v2.x actually contain more data per each instrument than IBK can store, namely Carrier 2 and Modulator 2 sets of values, while IBK can only recognize Carrier 1 and Modulator 1. It appears that when banks with twin carriers and modulators are imported, half of them is truncated, and this causes the instruments to sound off in MBF.

With this in mind, I went back to DMXOPL v1.11, which is the latest to only have Carrier 1 and Modulator 1, and quickly converted it into IBK, which I'm attaching below as DMXOPL11.IBK. I think is sounds pretty decent in-game, and certainly an improvement over the default instrument setup.

MrFlibble wrote on 2023-11-12, 14:59:

GENMIDI lump and the recent releases of DMXOPL v2.x actually contain more data per each instrument than IBK can store, namely Carrier 2 and Modulator 2 sets of values, while IBK can only recognize Carrier 1 and Modulator 1.

"Carrier 2 and Modulator 2" sounds like these are for OPL3 and not OPL2 and they're for using the OPL3's 4-op channel modes. It's worth noting that using the 4-op channel modes drastically reduces the polyphony on the OPL3.

I know DMX has a "double voice" mode which is a fake/psuedo 4-op mode and I haven't come across other MS-DOS sound systems that perform such a trick.

DracoNihil wrote on 2023-11-12, 23:40:

"Carrier 2 and Modulator 2" sounds like these are for OPL3 and not OPL2 and they're for using the OPL3's 4-op channel modes. It's worth noting that using the 4-op channel modes drastically reduces the polyphony on the OPL3.

I'm not really very knowledgeable about how OPL works, so I can't say anything definite about the 4-op modes. However, the newer releases of DMXOPL that have the second set of modulator/carrier values are indeed for OPL3, while version 1.11 is the latest suitable for OPL2 and has only one set. However, it looks as if vanilla Doom can actually use these 4-op modes, unlike MBF via IBK.

I also think that the duplicate SBI instruments I found in the Freedoom repo are actually these dual sets of values for the newer DMXOPL versions, which means that my MBF_TEST.IBK is basically a pretty incomplete half of the new DMXOPL, making the only useful version the DMXOPL11.IBK that was directly converted from DMXOPL v1.11 GENMIDI.op2.

UPD: I ran a further test, which is very simple: I first loaded E1M1 in FastDoom with default OPL settings and recorded the first few seconds of the music, then repeated the process but loaded GENMIDI.op2 from the DMPXOPL v1.11 release. Then I loaded E1M1 in MBF 2.04 w/ FM fixes, with and without the DMXOPL11.IBK that I produced by converting said GENMIDI.op2 with OPL3BankEditor. Interestingly, the default OPL mode sounds identical both in FastDoom and MBF, but DMXOPL sounds different, and not in favour of MBF.

Any idea what might be causing this? If by default MBF 2.04 uses the same instrument settings as Doom's GENMIDI lump, and they do sound the same, what could be wrong with the DMXOPL.IBK? I can only imagine there's been some fault in conversion that I'm not aware of.

Would you mind sharing the exe and the IBK you used for the comparison as an attachment? I am tempted to try listening to the difference with my own ears.

One question/suggestion I have is with regards to the version of DMXOPL to use for testing. Because if I'd do the test I would add the version found in BTSX E2, just because this is likely the most widely tested one out there, and because BTSX E2 famously targets vanilla. EDIT: my bad, maybe not - most of testing of BTSX , I imagine, happened before and during its beta days. GENMIDI seems to have been only added at release in 2020 and it seems to be the just the latest vanilla OP2 available in then current DMXOPL version.

Today I looked closely at the instrument values as displayed in SBTimbre and in OPL3BankEditor, and concluded that there are no conversion errors. Then I opened up the original MBF 2.03 maintenance release from 1999 and ran a small test with the converted IBK files.

As I expected, at least the melodic instruments sound quite similar to DMXOPL when run with vanilla Doom. The drums are off, but this must be an issue with how OPL3BankEditor converts those (hopefully to be fixed sometime, as I have reported the issue to the developer). So it seems that the deviations how IBK files sound must be somehow related to the modified Allegro library in the 2.04 release.

ludicrous_peridot wrote on 2023-11-13, 19:40:

Would you mind sharing the exe and the IBK you used for the comparison as an attachment? I am tempted to try listening to the difference with my own ears.

Sure, I'm attaching both IBKs below. The MBF version I'm using is the FM-fixed release shared by gerwin some posts above. Just to be sure, I also tried the IBKs with the most recent stable MBF release as well, to the same result.

Thanks for explaining, @MrFlibble.

One thing to note is that, Allegro has seperate ibk_file and ibk_drum_file configs and it only loads instrument from the first starting at instrument 0 and drums from the second, starting with instrument 35. This is the same function, but it's called differently for the two cases, so make sure you have the two configs and they point to appropriate IBKs. MBF only loads instruments bank on its own (i.e. without the additional config options), as Doom and Doom 2 have same percussion.

One thing on the OP2-enabled allegro I've shared, it it breaks how percussion sounds. Using @gerwin's built in Doom percussion set and only loading instruments from the OP2 file/lump kind of fixes that, but is a bad solution. I will be updating the post above when I get to the bottom of this, in the meantime it was premature to say I was content with the sound. 🙁

ludicrous_peridot wrote on 2023-11-14, 15:35:

This is the same function, but it's called differently for the two cases, so make sure you have the two configs and they point to appropriate IBKs. MBF only loads instruments bank on its own (i.e. without the additional config options), as Doom and Doom 2 have same percussion.

The banks can be defined straight from the Allegro setup programme, but they're both written inside SETUP.CFG (in MBF 2.03 -- in MBF.CFG):

ludicrous_peridot wrote on 2023-11-14, 15:35:

One thing on the OP2-enabled allegro I've shared, it it breaks how percussion sounds.

I hope you get this fixed soon, I really like the idea of directly using GENMIDI.op2, as originally intended in vanilla.

gerwin wrote on 2023-11-11, 19:13:

Allegro already had the option to load another Midi-to-FM table, as an override, but only when it is in the IBK format, outside of a WAD.
MBF 2.04 uses this functionality for Doom2 mode, loading MBF_D2GM.IBK at startup.

Interestingly, I've just loaded the Freedoom Phase 2 IWAD without any IBK files specified in SETUP.CFG, and then the same but setting Allegro to use MBF_D2GM.IBK. There was no difference in music (suggesting that it works as intended both with internal override and when loaded from SETUP.CFG). Then I loaded E1M1 from the Doom shareware IWAD and again compared it with default MBF settings and with MBF_D2GM.IBK specified as the instrument IBK in SETUP.CFG. Again, no notable difference. I wonder what software you used to produce this IBK file?

UPD: I decided to run another small test and used OPL3BankEditor to convert the Doom shareware GENMIDI to IBK, then compared the values to those in MBF_D2GM.IBK. It appears that all instruments in the latter have these two values always set to 0:

Perhaps setting them to zero after conversion via OPL3BankEditor might "fix" the IBK for use with MBF 2.04.