Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
natt

Vanilla Doom and music behavior when paused (OPL)

Recommended Posts

I've observed the following in DosBox (I'd do a real test, but my SB16 went south 10 years ago): When you pause the game, currently sustained notes are cut, but those notes aren't restarted when you unpause. I'd like to be sure that this is the way it was originally done and is not due to some bug in DosBox OPL2 emulation.

The relevant section of chocolate doom (src/i_oplmusic.c, I_OPL_PauseSong() and I_OPL_ResumeSong()) do the same thing, with the additional comment "This is what vanilla does". Perhaps whoever wrote that comment has more information, perhaps from disassembly? The observations of anyone who can play Doom on a real OPL in real DOS would be helpful as well.

It's easy to hear the difference in any music track with long, sustained notes; Doom2 MAP05 is one good one.

Share this post


Link to post

That's MIDI for ya. Once a note is cut off, it stays cut off. Unless it doesn't do that in say, ZDoom? I haven't really been paying attention to pausing the game like that.

Share this post


Link to post

in the port of hexen i wrote to pause the music i simply freeze the position in the mus file of the player and set the volume to zero. so my notes dont cut off...

Share this post


Link to post
PRIMEVAL said:

That's MIDI for ya. Once a note is cut off, it stays cut off. Unless it doesn't do that in say, ZDoom? I haven't really been paying attention to pausing the game like that.


GZDoom, when using Fluidsynth, doesn't do it that way; the notes restart seamlessly after the pause ends. A patch will be committed soon to Prboom-Plus that makes it behave the same way as GZDoom when using Fluidsynth. I wrote this thread because I'm not sure whether I should do the same thing with the OPL2 emulator in Prboom-Plus; which is why I'm interested particularly in how it sounds on actual hardware.

Share this post


Link to post

A real OPL accepts commands that generate sustained notes, and if you "cut it off" while playing a sustained note with decay and no looping, it will not play it back again. Kinda like plucking a guitar's chord once. If you interrupt it, it won't resume after you let it free.

The opposite problem also happened: it was not uncommon for DOS games to exit while still playing a sustained note back, or even getting stuck on a particularly annoying pitch simply because they didn't do a forced interruption.

FluidSynth does "cut off" cleanly because what you are interrupting is just a stream of synthesized data, instead of a sound chip cell that will simply "extinguish" its state when paused.

Share this post


Link to post
Maes said:

The opposite problem also happened: it was not uncommon for DOS games to exit while still playing a sustained note back, or even getting stuck on a particularly annoying pitch simply because they didn't do a forced interruption.


I remember using that with a few games as a fast diagnosis tool to know if it had crashed or was merely lagging severely. If a MIDI note was hung, or if the same fraction of a second from a digital sound effect was repeated constantly, then the software side had bitten the bit bucket and the hardware was left aimlessly continuing the last command it had received.

Share this post


Link to post
Maes said:

A real OPL accepts commands that generate sustained notes, and if you "cut it off" while playing a sustained note with decay and no looping, it will not play it back again. Kinda like plucking a guitar's chord once. If you interrupt it, it won't resume after you let it free.

The opposite problem also happened: it was not uncommon for DOS games to exit while still playing a sustained note back, or even getting stuck on a particularly annoying pitch simply because they didn't do a forced interruption.

FluidSynth does "cut off" cleanly because what you are interrupting is just a stream of synthesized data, instead of a sound chip cell that will simply "extinguish" its state when paused.


Yes, I understand all that. But nothing's stopping the program from resounding the notes that it cut off at the pause on resume.

Share this post


Link to post
natt said:

Yes, I understand all that. But nothing's stopping the program from resounding the notes that it cut off at the pause on resume.


Actually, there is something stopping it: it doesn't keep status of which notes were "played before stopping but should still be active" based on their sustain/decay etc. characteristics. Perversely, an emulated synth that produces a precalculated stream of sound (with several ms worth of buffering) can do that just fine.

But imaging playing a piano, and suddenly being ordered to not only stop playing, but also mute the chords somehow, and then "resuming" just at the volume the decaying chords had. It's practically impossible, unless you were using a prerecorded piano sound.

Same with a real sound-event oriented sound chip like the OPL2: it doesn't keep status for notes DURING playback, it can only change them during event firing. And pausing is pretty much a disrupting event: it can't remember at what part of the note decay it was.

Share this post


Link to post
natt said:

Yes, I understand all that. But nothing's stopping the program from resounding the notes that it cut off at the pause on resume.


Actually, there is something stopping it: it doesn't keep status of which notes were "played before stopping but should still be active" based on their sustain/decay etc. characteristics. Perversely, an emulated synth that produces a precalculated stream of sound (with several ms worth of buffering) can do that just fine.

But imagine playing a piano, and suddenly being ordered to not only stop playing, but also mute the chords somehow, and then "resuming" just at the volume the decaying chords had. It's practically impossible, unless you were using a prerecorded piano sound.

Same with a real sound-event oriented sound chip like the OPL2: it doesn't keep status for notes DURING playback, it can only change them during event firing. And pausing is pretty much a disrupting event: it can't remember at what part of the note decay it was.

Share this post


Link to post
Maes said:

Actually, there is something stopping it: it doesn't keep status of which notes were "played before stopping but should still be active" based on their sustain/decay etc. characteristics. Perversely, an emulated synth that produces a precalculated stream of sound (with several ms worth of buffering) can do that just fine.


Right, the notes would have new attacks so it wouldn't sound quite the same, but you could do it more or less.

Share this post


Link to post
natt said:

Right, the notes would have new attacks so it wouldn't sound quite the same, but you could do it more or less.


That would mean creating special code just for recovery of sustained notes (by calculating where the volume should be more or less when it was interrupted etc.). Remember, you can't read the status of OPL cells ;-)

In other words, it falls into the "shit nobody cares about" category.

Share this post


Link to post
Gez said:

I remember using that with a few games as a fast diagnosis tool to know if it had crashed or was merely lagging severely. If a MIDI note was hung, or if the same fraction of a second from a digital sound effect was repeated constantly, then the software side had bitten the bit bucket and the hardware was left aimlessly continuing the last command it had received.


Sometimes the main loop crashes but the music keeps playing normally (because it is controlled by an ISR.) This was very common in Commodore 64 games (though somewhat rarer in DOS games.)

Share this post


Link to post

I used to have the default MIDI out linked to my Korg X5 in multitimberal mode. It sounded really nice, but I ended up canning it because of that very reason. Even if I quit Doom, shut the computer off and disconnected the interface, the notes would carry on until I shut the unit off. Perhaps MIDI 2 will make it's debut within the next 40 or so years and rectify this.

Share this post


Link to post
Ed said:

I used to have the default MIDI out linked to my Korg X5 in multitimberal mode. It sounded really nice, but I ended up canning it because of that very reason. Even if I quit Doom, shut the computer off and disconnected the interface, the notes would carry on until I shut the unit off. Perhaps MIDI 2 will make it's debut within the next 40 or so years and rectify this.

Something like that (active sensing) already exists, but it doesn't help if the app doesn't enable it.

Also when you're debugging MIDI code, it's nice to have an off switch for when your program fails to clean up properly. It's easier to switch off an external synth than to switch to a utility that silences the soundcard's embedded synth.

Share this post


Link to post
Ed said:

I used to have the default MIDI out linked to my Korg X5 in multitimberal mode. It sounded really nice, but I ended up canning it because of that very reason. Even if I quit Doom, shut the computer off and disconnected the interface, the notes would carry on until I shut the unit off. Perhaps MIDI 2 will make it's debut within the next 40 or so years and rectify this.


If you still have that setup, you might consider trying it with the latest prboom-plus (use the "portmidi" midi player option). It's a different midi out codebase that doesn't use SDL mixer, and if there are any problems with it I might be able to fix them for you.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×