I can think of these options, but all of them take some effort and tweaking:
1- Miles Sound System MDIplay.exe for DOS. Needs midiform.exe to convert MID to XMI. Uses sample.opl soundbank.
2- Doom Midi Player MUSplay.exe for DOS. Needs midi2mus.exe to convert MID to MUS. Uses Genmidi.op2 soundbank.
3- Create a new DOS midi player with the modified Allegro 3 from my Doom MBF project. Uses IBK soundbanks.

FM Soundbank converter and some old notes from me:
http://winwolf3d.dugtrio17.com/phpbb/viewtopic.php?t=418

Don't forget you can record the OPL commands with DOSBox, so if you can play your MIDI file in a way that you like, you get the OPL instructions for "free."

Edit: nevermind, you talked about doing exactly that in the OP. I am a dope & shouldn't skim things.

Writing suggestion No.3 I wondered wheter Allegro comes with a command line midi player: It does. It is called play.exe. It can change Soundbanks through the configuration in Allegro.cfg.
Attached is the play.exe compiled with Modified Allegro 3.0B, Modified as in: fixed issues with FM play and by default it has the Doom 1 soundbank.
Note that Modified Allegro 3.0B has some new Digitized sound drivers (ESS, GUSPnP), but the play.exe sound driver listing is outdated, I have no time to fix that now.

The soundbanks can only change the FM sounds to a certain degree: Some lookup tables and melodic FM mode are hardcoded.

gerwin, thanks for the Allegro player! It works a little better than the others I've tried. It might work for some things. Still, on large MIDI files with many channels, it breaks down.

I tried the DOOM MUS player with similar results.

I haven't been able to find the Miles Sound System player, though... is there a place I can find that?

OK. Good to hear it works and sorry about the limitations. Does it crash with these midis? Maybe it has something to do with melody vs rhythm mode of the driver. Also I suspect it is necessary for a Midi to FM driver to drop channels that are overloading the limits of FM, preferably with some logic to estimate the least important channels.

Attached the files needed to get the Miles Sound System variant going.

It doesn't crash, it just has a lot of trouble playing them and they don't sound right.

With these big MIDI files it's always the same with these OPL3 players, sometimes the timing is completely wrong, sometimes certain notes are wrong, sometimes an instrument is totally wrong, sometimes certain parts of the song are in the wrong octave, sometimes an instrument sounds like a distorted wraith screech, etc.

The MDIPLAY thing seems to work pretty well! It's the best I've heard for small MIDI files that don't use that many channels. But with my test large MIDI file, MIDIFORM complains of an "unpaired MIDI note".

By the way, there shouldn't be channel issues with OPL3... MIDI supports up to 16 channels/instruments at once, while OPL3 supports 18. So there should be plenty of room. OPL2 is what usually has issues as it only has 9 channels, I think. But some OPL3 MIDI players still drop notes for some reason, even on songs with only 3 or 4 instruments.

keenmaster486 wrote:

By the way, there shouldn't be channel issues with OPL3... MIDI supports up to 16 channels/instruments at once, while OPL3 supports 18. So there should be plenty of room. OPL2 is what usually has issues as it only has 9 channels, I think. But some OPL3 MIDI players still drop notes for some reason, even on songs with only 3 or 4 instruments.

Just like with midi voices there are probably annoying limitations in that regard, like here it says only six OPL3 channels are full featured. But I cannot explain the problems with just 3 or 4 instruments.

Source So let's clear some facts. First, OPL3 has only thirty-six (36) operators which can be combined in several ways: - 18 FM […]
Show full quote

Source
So let's clear some facts. First, OPL3 has only thirty-six (36) operators which can be combined in several ways:
- 18 FM channels (36 operators), or
- 15 FM channels (30 ops) and 5 percussion instruments (6 ops), giving us 20 channels altogether, or
- up to 6 four-operator FM channels (max 24 ops), the rest again being divided into two-operator FM channels and drums.

As I've mentioned elsewhere, one of my Windows 98 systems has a Yamaha MIDI-to-FM driver driver installed, which allows playing MIDI files on the integrated OPL3 FM soundcard. I'm not sure whether that driver was included with the YMF driver package or not; in the latter case I could try extracting it if someone could provide instructions on how to do so.

Although it will have to wait a few weeks, as the system I mentioned is currently packed up because I'm in the middle of moving...

keenmaster486 wrote:

By the way, there shouldn't be channel issues with OPL3... MIDI supports up to 16 channels/instruments at once, while OPL3 supports 18. So there should be plenty of room.

No, because OPL3 supports 18 *notes* at a time, where MIDI supports an infinite number of notes at a time, per channel.
MIDI only has note on/off commands, and in theory you can send as many note-on commands as you want, and never send a note-off.
So the polyphony in MIDI is 'endless', and it's easy to overload the 18 notes of a OPL3 even with a single channel.
A MIDI player should have a note allocation algorithm, something like "When the 19th note is played, I automatically turn off the oldest note". But that might randomly make notes cut out when the MIDI file is sloppy with turning notes on and off.

I have an IBM Music Feature Card, which is basically a Yamaha FB-01 on an ISA card. It has an interesting note allocation scheme, where you can select the polyphony per channel/instrument. Since it only has 8-note polyphony, it makes sense to do that. The scheme would be good for OPL2/3 as well, I suppose.

Ah, there you have it. Thanks for explaining it proper.

I remember some disappointment in the past, when a Midi over OPL track lost essential parts of the track. I recon game music composers ideally checked their songs in both GM and FM modes before shipping the game, to verify that it sounded acceptable on OPL2 or OPL3 as well. But that only goes so far.
This matter also illustrates that tracks composed directly for OPL2/3 hardware are in a different league then driver-converted midi tracks.

Would be interesting to experiment with multiple OPL3 chips to increase the capacity of channels and notes. But one would need to program a midi player/driver tailor made for that purpose.

yawetaG wrote:

As I've mentioned elsewhere, one of my Windows 98 systems has a Yamaha MIDI-to-FM driver driver installed, which allows playing MIDI files on the integrated OPL3 FM soundcard. I'm not sure whether that driver was included with the YMF driver package or not; in the latter case I could try extracting it if someone could provide instructions on how to do so.
Although it will have to wait a few weeks, as the system I mentioned is currently packed up because I'm in the middle of moving...

That seems like a Windows player, whereas keenmaster wants to use the player in DosBox to get the DRO format output.

I have a fourth DOS command line midi driver/player when there is interest. This one being based on the HMI sound operating system 4. Again it can only play a proprietary midi format, this time it is .HMI.

IME, it seems music was rarely ever "designed" for OPL. I think that was just the fallback mechanism for many games. What I assume happened is that the game's composer sat in his room with a keyboard and General MIDI module and wrote music. The game's music engine would then use the default in-house or off-the-shelf OPL MIDI patches -- which usually did not even bother to take advantage of OPL3 features, rather sticking to OPL2 for best compatibility. I'm sure there was a token amount of QA, to make sure it didn't sound any worse than any other OPL2 soundtrack, but I doubt the composer made any real effort to optimize music for the lowest common denominator synthesizer.

For games that didn't support much else, the soundtrack was optimized for FM, but still rarely broke the OPL2 barrier. Notable exception to this being Hocus Pocus, which to this day serves as one of the best examples of how not-terrible Yamaha FM can sound. The Super SAPI MIDI drivers were also pretty sweet, except with those complicated patches, polyphony is turrble, and you get lots of dropped notes and glitches.

OPL FM just sucks. Nostalgic, perhaps, but sucky nonetheless. 😁

SirNickity wrote:

IME, it seems music was rarely ever "designed" for OPL. I think that was just the fallback mechanism for many games.

Depends on the game... some have specific AdLib music, and PC speaker/Tandy are fallback.

SirNickity wrote:

What I assume happened is that the game's composer sat in his room with a keyboard and General MIDI module and wrote music.

Except that General MIDI didn't exist until 1991, whereas OPL2 had been available on PC since 1987.
Some composers would use the Roland MT-32 though, but I think quite a few of them did actually try to keep the polyphony down, and make sure the music they composed would map to simple devices.
I'm not entirely sure if the lack of proper FM music is because composers didn't care, or if it's because the proper tools weren't available. The exceptions to the rule tend to be developers who also wrote their own tools.

It was a moving target. Polyphony isn't great even if you're only using one oscillator per voice - and so you're torn between nice-sounding voices with poor polyphony, or simple (typical boring FM BRRRROOOOOWWWWWRRR) voices with better polyphony. I wonder how often the composer even knew what OPL patches would be used, unless -- as you say -- they were integral to the development process as well. Otherwise, I think the best you could do is try to arrange the tracks such that voice-stealing would be as unobtrusive as possible (and hey, even the MIDI modules didn't have great polyphony back then, so that was probably second-nature.) Listening to (for e.g.) a Sierra soundtrack, you can tell that voices are getting robbed all the time with FM, though.

I'm not too sure how PC-speaker music was written. I would be curious to know if someone has insider knowledge on how game music engines typically handled that. I would... again, assume... that it's a separate track entirely, with a hand-chosen single voice extracted from the main music file. Seems like you couldn't just leave it up to fate and have something intelligible come out.

(Alright, you caught me on the GM thing. That was sloppy. I guess my experience with game soundtracks is heavily biased to the 90s.)

SirNickity wrote:

I'm not too sure how PC-speaker music was written. I would be curious to know if someone has insider knowledge on how game music engines typically handled that. I would... again, assume... that it's a separate track entirely, with a hand-chosen single voice extracted from the main music file. Seems like you couldn't just leave it up to fate and have something intelligible come out.

I suppose there were two main approaches:
1) Use a single-channel melody
2) Use a multiplexed soundtrack based on 3 channels (probably based on the Tandy version or perhaps a C64, Atari or similar platform), where the notes are switched between channels quickly (usually around 60 Hz).

Most convenient way is to use the Foobar2000 player with foo_midi plugin set to use adlmidi engine. Adlmidi engine doesn't allow you to use any OPL bank around, but it has over 60 built-in banks taken from popular DOS games, that should suit you in most of the cases.

If you need a specific OPL bank that isn't present in adlmidi, then PX Player. It uses whatever .AD or .OPL file it finds near the played .XMI or .MID file; if none found, it searches its home folder for one. The obvious and non-beatable as of now drawback is that you only can use .AD/.OPL timbre banks with PX Player.

keenmaster486 wrote on 2019-01-21, 21:46:

Is there anything like this out there?

4 years late, I do a project like this right now. 😁

https://github.com/MemberA2600/MID2OPL2

MIDI to VGM translator is also an option. Instrument patches can be edited, though changing assignments with some GM instruments would require editing the source file and recompilation.