▲

[Ian @ un4seen]

Yep, here's an updated MIDI plugin with support for the GS "tone number" sysex message:

   www.un4seen.com/stuff/xmp-midi.dll

[ELP]

Wow........
 

[PSXGamerPro1]

Now I wish there was a build of this plugin that allows you to play MIDI files the way Windows Media Player does when they do not have SoundFonts (AKA Duke Nukem's MIDI files).

[Jace]

Downloading/making Windows' default soundfont as .sf2 file would be the best course of action.

This ought to get you on the right tracks.

[captaincavern]

Check those out:

http://www.aimp.ru/forum/index.php?topic=38501.0 (link in post 1)

http://forum.cockos.com/showthread.php?t=62535 (link in post 5)

Using the latter since years now. 

[Ferb]

Check those out:

(link in post 1)

(link in post 5)

Using the latter since years now. 

Those sound fine for some songs, but a lot of other tracks sound "off" for have weird instrument things going on with them. I've tried a lot of different versions of it but they never sound "right" compared to WMP. A good option would be to support .dls alongside .sf2 etc. I can get a recording if anyone is interested but a good example is 10004.mid from Sim City 2000. Load it up in xmplay with a converted gm.dls and compare it to this:

https://www.youtube.com/watch?v=7E2zRkgxwQU

[saga]

Differences in sound do not necessarily come from the conversion between DLS and SF2 but rather the different playback engines used in XMPlay and DirectMusic.

[Alex M]

Absolutely happy to play midi using this plugin with with Musyng Kite 990MB GM/GS soundfont

[Corak]

Yep, here's an updated MIDI plugin with support for the GS "tone number" sysex message:

   www.un4seen.com/stuff/xmp-midi.dll

Another case where r14 sounds much worse than r13 was:
http://files.leraux.ru/Corak/Temp/Bugreport/XmPlay/xmp-midi/desmond_take_five.zip

Compare the transition of sax notes. On r13 it's smooth. On r14 it's too chopping...


http://files.leraux.ru/Corak/Temp/Bugreport/XmPlay/xmp-midi/xmp-midi_r13a.zip
http://files.leraux.ru/Corak/Temp/Bugreport/XmPlay/xmp-midi/xmp-midi_r14.zip

[Ian @ un4seen]

Oops! Rev.14 introduced a bug in mono mode (CC#126), resulting in overlapping notes being choppy as in your example file. Here's an update that should fix it:

   www.un4seen.com/stuff/xmp-midi.dll

Let me know if it still has trouble with any other files.

[Corak]

Oops! Rev.14 introduced a bug in mono mode (CC#126), resulting in overlapping notes being choppy as in your example file. Here's an update that should fix it:
   www.un4seen.com/stuff/xmp-midi.dll
Let me know if it still has trouble with any other files.

Thanks! Now seems it fixed. If there will be some other bugs i will send trouble midi files.

[kode54]

Should volume controller be affecting released notes? I have some old MIDI files ripped from the original PC release of Final Fantasy VII, and they play with the volume controller continuously, and ramp it back up instantly before starting new notes, which causes the tail ends of existing notes to pop up audibly before they fade out. This doesn't seem to affect some commercial synthesizers, such as Roland's Sound Canvas VA.

[Ian @ un4seen]

I believe released notes should be affected by volume (CC#7) changes, but it's possible that some synths will stop a released note once its volume hits 0 as an optimization. I checked what a Creative soundcard and an XG synth do just now, and the Creative soundcard did stop the note when the volume was lowered to 0, but the XG synth kept playing the note so that it could be heard again when the volume was raised. The latter behaviour seems more correct to me (it's what the XMPlay plugin does), but perhaps there are some MIDI files (like the ones you've found) that depend on the former behaviour. I'm not sure there's any way to auto-detect what's best for a particular MIDI file, but perhaps an option could be added. Please upload some affected MIDI files to have a look at here:

   ftp.un4seen.com/incoming/

[piovrauz]

If I remember it correctly, I think there are 2 version of the same ff7 midi pack, and one is for use with creative soundcards.
I'll see if I can find them again and they can help.

Edit: found them, hope it helps. FF7.7z - 406 KB

[quanta]

Tested system
=============
OS: Windows 98SE
Memory: 384MB
CPU: Intel Pentium II 400
Sound: ESS Solo-1
Video: Neomagic MagicMedia 256AV
XMPlay version: 3.8.0.16

When changing XMPlay MIDI plugin's performance decreases when updating from rev.12a to rev.14. Specifically, the amount of active voices in MIDI mixer can reach 107 without going red in rev.12a plugin, but the active voices value reaches red in rev.14 plugin with as little as 90 voices.

[quanta]

When trying to play an empty XMI MIDI file (see EMPTY.XMI from attachment EMPTY.ZIP) using XMPlay MIDI plugin, XMPlay automatically strikes out the file with a single line (ie: marked unplayable). However, when trying to play the struck out file again, eventually the following dialogue box appears:

XMPLAY caused an invalid page fault in
module IN_MIDI.DLL at 018f:01b95580.
Registers:
EAX=05acd500 CS=018f EIP=01b95580 EFLGS=00210212
EBX=00000003 SS=0197 ESP=0077cb40 EBP=0077cb6c
ECX=0625e6bc DS=0197 ESI=0000000c FS=6d2f
EDX=008dab5c ES=0197 EDI=007911c4 GS=0000
Bytes at CS:EIP:
8b 01 85 c0 74 08 50 ff 15 d8 20 ba 01 59 c3 53
Stack dump:
01ba1565 007911c4 007911c8 00000003 00000000 00000388 0077c970 0077cba4 01ba19d0 01ba3060 00000000 0077cbb0 01b953fe 0625e6bc 0000000c 007911bf

After the dialogue box is closed, another one appears:

XMPLAY caused an invalid page fault in
module IN_MIDI.DLL at 018f:01b95580.
Registers:
EAX=0077c724 CS=018f EIP=01b95580 EFLGS=00210202
EBX=01ba3060 SS=0197 ESP=0077c6e0 EBP=0077c708
ECX=0625e6b0 DS=0197 ESI=00000000 FS=6d2f
EDX=bff768fa ES=0197 EDI=8191c710 GS=0000
Bytes at CS:EIP:
8b 01 85 c0 74 08 50 ff 15 d8 20 ba 01 59 c3 53
Stack dump:
01ba15da 8191c710 00000000 01ba3060 0077c6e4 0077c510 0077c724 01ba19d0 01ba3070 00000000 0077cb6c 01ba159f 0625e6b0 0000000c 007911be 01b95580

After closing error dialogue box again, the third error dialogue box appears after XMPlay windows are closed:

XMPLAY caused an invalid page fault in
module IN_TXT.DLL at 018f:01bd23ee.
Registers:
EAX=02240690 CS=018f EIP=01bd23ee EFLGS=00010206
EBX=00000001 SS=0197 ESP=0367fc30 EBP=0367fc70
ECX=7ffce00c DS=0197 ESI=01d00ef4 FS=942f
EDX=c00309fc ES=0197 EDI=00000001 GS=0000
Bytes at CS:EIP:
8b 08 50 ff 51 08 c3 e8 05 00 00 00 e9 0a 00 00
Stack dump:
01bd70e1 00000000 01bd0000 00000001 01bd7084 00000000 00000000 00000001 01bd43e4 01bd447c 01bd0000 00000000 00000001 00000000 01bd0000 819253dc

The number of times needed to trigger the error varies between XMPlay sessions without specific pattern, but XMPlay is more likely to crash if the playlist only has dead file(s). After comparing with XMI MIDI files from Buck Rogers Matrix Cubed[1], it seems the empty XMI MIDI file has 16 bytes at the beginning of the actual file header. After removing the extra contents from the beginning of the, XMPlay properly recognizes and plays the MIDI file without crashing. Even so, XMPlay should never have crashed when trying to play unplayable files.

[1] http://www.old-games.com/download/3900/buck-rogers-matrix-cubed

[quanta]

When playing a MIDI file using XMPlay MIDI plugin, choosing 'Piugin file info' context menu item causes XMPlay to crash with following errors:

XMPLAY caused an invalid page fault in
module IN_MIDI.DLL at 018f:01765580.
Registers:
EAX=1df06f70 CS=018f EIP=01765580 EFLGS=00210202
EBX=00773403 SS=0197 ESP=00772f70 EBP=00772f9c
ECX=1e7b8de0 DS=0197 ESI=0000000c FS=0ecf
EDX=008b000c ES=0197 EDI=008b1e78 GS=0000
Bytes at CS:EIP:
8b 01 85 c0 74 08 50 ff 15 d8 20 77 01 59 c3 53
Stack dump:
01771565 008b1e78 008b1e7c 00773403 00000000 00008e15 00772da0 00772fd4 017719d0 01773060 00000000 00772fe0 017653fe 1e7b8de0 0000000c 027eb3f3

After closing the dialogue box, sometimes another dialogue box with following message appears:

XMPLAY caused an invalid page fault in
module IN_MIDI.DLL at 018f:01765580.
Registers:
EAX=00772b54 CS=018f EIP=01765580 EFLGS=00210216
EBX=01773060 SS=0197 ESP=00772b10 EBP=00772b38
ECX=1e7b8dd4 DS=0197 ESI=00000000 FS=0ecf
EDX=bff768fa ES=0197 EDI=818f3878 GS=0000
Bytes at CS:EIP:
8b 01 85 c0 74 08 50 ff 15 d8 20 77 01 59 c3 53
Stack dump:
017715da 818f3878 00000000 01773060 00772b14 00772940 00772b54 017719d0 01773070 00000000 00772f9c 0177159f 1e7b8dd4 0000000c 027eb3f2 01765580

However, if the Stu003 Text-Speech plugin v1.01 was loaded, this second dialouge box with following message appears:

XMPLAY caused an invalid page fault in
module IN_TXT.DLL at 018f:017a23ee.
Registers:
EAX=020506e0 CS=018f EIP=017a23ee EFLGS=00210202
EBX=00000001 SS=0197 ESP=0357fc30 EBP=0357fc70
ECX=7ffce00c DS=0197 ESI=01b10ef4 FS=50df
EDX=c00309fc ES=0197 EDI=00000001 GS=0000
Bytes at CS:EIP:
8b 08 50 ff 51 08 c3 e8 05 00 00 00 e9 0a 00 00
Stack dump:
017a70e1 00000000 017a0000 00000001 017a7084 00000000 00000000 00000001 017a43e4 017a447c 017a0000 00000000 00000001 00000000 017a0000 8196f804

The bug does not occur if 'Plugin file info' command is chosen when playing a file that is not in archive. In any case, XMPlay should never crash, and it should allow users to use 'Plugin file info' command when playing a file that is inside an archive.

[Ian @ un4seen]

Tested system
=============
OS: Windows 98SE
Memory: 384MB
CPU: Intel Pentium II 400
Sound: ESS Solo-1
Video: Neomagic MagicMedia 256AV
XMPlay version: 3.8.0.16

When changing XMPlay MIDI plugin's performance decreases when updating from rev.12a to rev.14. Specifically, the amount of active voices in MIDI mixer can reach 107 without going red in rev.12a plugin, but the active voices value reaches red in rev.14 plugin with as little as 90 voices.

Using the NULL output plugin to compare how long it takes the 2 versions to process a MIDI file, rev.14 is actually a bit faster than rev.12 for me. If you would like to try that, you can get the NULL output plugin here:

   www.un4seen.com/stuff/xmp-null.dll

Go to the "NULL" page in the "Options and stuff" window to see how long it took to process each file.

Regarding why you're seeing voices killed earlier with rev.14, perhaps it is limiting the CPU usage earlier/lower (I don't recall if it does). Does Task Manager show rev.14 using more CPU than rev.12 when playing the same part of the same MIDI file with the same settings?

When trying to play an empty XMI MIDI file (see EMPTY.XMI from attachment EMPTY.ZIP) using XMPlay MIDI plugin, XMPlay automatically strikes out the file with a single line (ie: marked unplayable). However, when trying to play the struck out file again, eventually the following dialogue box appears:
...

That and the other crashes are all in Winamp plugins (IN_MIDI.DLL and IN_TXT.DLL), so I'm not sure there's much that can be done about that. If you remove those 2 plugins, do you still get crashing in the same scenarios?

[Krstfr]

The file in the zip crashes the midi plugin upon scanning.

[winner]

The file in the zip crashes the midi plugin upon scanning.

The .mid file is only 14 bytes in length. It is incomplete and corrupt.