MIDI doesn't send a SysEx reset

[Hellser]

Vanilla Doom used to send a SysEx reset command upon both starting and leaving Doom - so the music will default to standard parameters. I'm using loopMidi for my midi out device (which does support sending and receiving SysEx commands) and routing this into MidiPlayer for my music player. I was getting heavy reverb in E1M1 for an example - come to find out that it's been set to 127. A game I was playing from DosBOX (Stonekeep to be precise) didn't reset the midi device back to default parameters and it carried over into GZDoom.

There's two ways this can be fixed. Revert back to what Vanilla Doom used to do - send a SysEx reset if the user is using a midi device both when starting and quitting GZDoom. Or let the midi song handle the SysEx commands which will allow songs that uses the GS format to use its additional features. (Edit: If a soundfont has compliant GS sounds)

Edit:
These problems become much more apparent when listening to songs in Jimmy's Jukebox. E1M2's song (which pans the drums for the claves) caused E1M3 and all subsequent songs to have its drums panned only to one side. Fluidsynth and all other softsynths doesn't seem to have this problem where as all midi instructions going out to a hardsynth (or in this case, to an external softsynth) are doing it wrong.

[Graf Zahl]

Better late than never to respond, but I cannot help you here.

I neither have any hardware I could test such a feature on nor am I comfortable enough in MIDI programming to implement it without some ability to test.
I'm a bit baffled that opening a device doesn't auto-reset it.

[XxMiltenXx]

I can confirm this bug. I am using a Roland SC-55, which is connected via a MIDI interface. I am using Coolsoft MIDI Mapper to select the MIDI interface.

If I use Jimmy's Jukebox and play E1M2 and then any other songs, the drums are panned to the right.

However, interestingly enough, neither FluidSynth nor the OPL Synthesizer are afffected by this bug and work properly.

[Graf Zahl]

The software synths will be completely deleted and restarted for each song, so obviously they won't be affected. This problem seems to be exclusive to the Windows MIDI API.

[Chris]

Basically any persistent MIDI device. Playing a MIDI song modifies the channel properties of the device as it plays, and those changes stay until modified. To the device, there's no separation, it's just a continual stream of events sent from one or more external sources. A MIDI SysEx reset event is a standard event that tells the device to reset everything back to a fresh power-on state, so that the following events work from the standard defaults as if it was just powered on.

As far as the Windows MIDI API goes, when you open the device it just provides a means for the application to send events to the "external" device. I guess it doesn't want to automatically reset it upon opening since it's a separate device with multiple types of uses. In the context of a game it makes sense to reset everything before playback of a song to ensure it plays as intended, but in the context of a composition suite it's probably best to not do more than the composer says to do (they may have previously set things they want kept for the session).

[Graf Zahl]

The MIDI code already sends this when a song starts:

Code: Select all

		// Send the full master volume SysEx message.
		events[0] = 0;								// dwDeltaTime
		events[1] = 0;								// dwStreamID
		events[2] = (MEVENT_LONGMSG << 24) | 8;		// dwEvent
		events[3] = MAKE_ID(0xf0,0x7f,0x7f,0x04);	// dwParms[0]
		events[4] = MAKE_ID(0x01,0x7f,0x7f,0xf7);	// dwParms[1]
		events += 5;

I guess if the reset message is added here it should do the job - so what's the necessary contents?

[Gez]

The GM reset sysex is F0 7E 7F 09 01 F7.
There's also F0 41 10 42 12 40 00 7F 00 41 F7 for GS and F0 43 10 4C 00 00 7E 00 F7 for XG.

[Graf Zahl]

Do we need all 3?

[Gez]

I believe only the GM reset is necessary.

[Graf Zahl]

Ok. I already added it, but forgot this report.