▲

[Krstfr]

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

Isn't it still kind of bad that it crashes XMPlay though?

[saga]

Exactly. No matter how broken, it simply shouldn't crash.

[Ian @ un4seen]

Here's an update to fix that problem (by rejecting MIDI files with 0 tracks):

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

This update also introduces improved sinc interpolation (using 16 points instead of 8) with CPUs that support SSE2 (8 points will still be used with older CPUs).

[dsp2003]

Hey, Ian. Thank you for working on the MIDI plugin so far. With the last update, I've finally got proper reproduction of my Japanese SoundCanvas MIDI cover collection. :3

Any plans on implementing more XG variation filters?

[GM88]

Something seems wrong with the vibrato algorithm like it's applying too much of it.  Dozens of songs I've tried has this problem. The vibrato sounds twice as strong as it should be.

[Ian @ un4seen]

Any plans on implementing more XG variation filters?

There aren't any immediate plans for that, but it is something that I would like to see supported eventually.

Something seems wrong with the vibrato algorithm like it's applying too much of it.  Dozens of songs I've tried has this problem. The vibrato sounds twice as strong as it should be.

Is that happening when using a particular soundfont or is it happening with all soundfonts? Also, is it a particular preset in a particular soundfont that's affected? If so, please state which. If you have a MIDI file that clearly demonstrates the problem, please also upload that to try here:

   ftp.un4seen.com/incoming/

[GM88]

I don't know how to upload to ftp, but you can find one midi demonstrating the problem in this archive file.

http://psrtutorial.com/songs/Yamaha/XGByComposer.zip
The file is "Cool by Dave Kelly.mid" in the Dave Kelly folder.

I tried several different soundfonts. Same problem.

[Ian @ un4seen]

Your example MIDI file seems to sound OK with the ChoriumRevA and WeedsGM3 soundfonts that are available from the XMPlay webpage? If those 2 are fine for you too, please state the soundfont(s) that you have found to be affected.

[piovrauz]

I think I spotted a small bug: I got this archive:

http://leejacksonaudio.lbjackson.com/GrabbagOriginalVersionMIDI.zip

if I try to drag and drop on XMPlay, XMPlay crashes;  the rar contains 2 midi files, one text file and a file without estension.
If I remove the file without estension, I can drag and drop succesfully, so it appears that files withouth extension can crash XMPlay.
I think this should not happen. Is there any way to fix this? Thanks.

[Dotpitch]

if I try to drag and drop on XMPlay, XMPlay crashes;  the rar contains 2 midi files, one text file and a file without estension. If I remove the file without estension, I can drag and drop succesfully, so it appears that files withouth extension can crash XMPlay. I think this should not happen. Is there any way to fix this? Thanks.

It doesn't crash here. I think it's an input plugin crashing on that file, usually xmp-ffmpeg or xmp-dshow. Could you try with just XMPlay, xmp-zip and xmp-midi?

[piovrauz]

I will try with vanilla XMPlay and report the result; I don't have xmp-ffmpeg nor xmp-dshow, I know they're trouble and axed them.
Btw, I set .mid as priority filetype for the midi plugin in case it matters.

EDIT: I could investigate faster than I tought; it seems it was caused by libg719_decode.dll and libg7221_decode.dll being present at the same time...
Removing the older one fixes the crash. I still don't get why it crashed nor why there were 2 different dlls but I guess it slipped when manual updating.

[kode54]

libg719_decode.dll and libg7221_decode.dll being present at the same time

Those are two different codecs, and whatever imports them probably needs both, or will fail to load.

[Dotpitch]

Those are two different codecs, and whatever imports them probably needs both, or will fail to load.

Don't they both belong to in_vgm?

[piovrauz]

All of them are from "xmp-vgmstream", that I used sometime ago.
btw, I removed all files related to xmp-vgmstream for now.

[sevendy]

None of the version 14's properly load multiple bank soundfonts. For instance, in version 13 and prior, I have a two-bank file "added" at bank 042, with two banks displayed in the config window at 042 and 043. In version 14, bank 043 does not appear in the config, nor does it sound correctly. Reverting to version 13, and bank 043 magically reappears.

[winner]

None of the version 14's properly load multiple bank soundfonts. For instance, in version 13 and prior, I have a two-bank file "added" at bank 042, with two banks displayed in the config window at 042 and 043. In version 14, bank 043 does not appear in the config, nor does it sound correctly. Reverting to version 13, and bank 043 magically reappears.

Would the soundfont be jeux14.sf2? This is a two-bank file and I can confirm that in Midi plugin 14f it does not load in banks 042 and 043 as I know it did in previous Midi plugin versions. Maybe all of the 14 versions (a, b, c, etc.) show this behavior for this soundfont, but I can't say that I've seen this with any other multiple bank soundfonts.

[sevendy]

Exactly: Jeux14; but also another organ Soundfont, "Stefans" in 80-85. You're right though--I hadn't noticed this, but another multiple bank soundfont does seem to load correctly: the old Sound Blaster "4GMGSMT". I used Rundt's "Viena" to create a two-bank soundfont, and it behaved like Jeux14--the second bank doesn't show up in version 14.

[Ian @ un4seen]

None of the version 14's properly load multiple bank soundfonts. For instance, in version 13 and prior, I have a two-bank file "added" at bank 042, with two banks displayed in the config window at 042 and 043. In version 14, bank 043 does not appear in the config, nor does it sound correctly. Reverting to version 13, and bank 043 magically reappears.

Rev.14 did indeed change how multi-bank soundfonts are used when assigned to a non-0 bank. Previously, the assigned bank would become a base number that's added to all of the soundfont's banks, but that didn't seem particularly useful/desirable, so now only the assigned bank from the soundfont is used in the assigned bank; if the soundfont doesn't contain that bank, then its bank 0 (or 128 for drums) is used.

Do you actually need the soundfont's bank 1 to be used in bank 43 in your case, or are you just reporting the change that you've observed?

[sevendy]

Rev.14 did indeed change how multi-bank soundfonts are used when assigned to a non-0 bank. Previously, the assigned bank would become a base number that's added to all of the soundfont's banks, but that didn't seem particularly useful/desirable, so now only the assigned bank from the soundfont is used in the assigned bank; if the soundfont doesn't contain that bank, then its bank 0 (or 128 for drums) is used.

Do you actually need the soundfont's bank 1 to be used in bank 43 in your case, or are you just reporting the change that you've observed?

Yes, I certainly do need the old behavior to play existing MIDI files which assume banks 42 and 43 (Jeux14) or 80-85 (Stefans). Is there some way to manually load the secondary banks from soundfont files into arbitrary locations? On the other hand, I am content to stay with version 13, which is entirely adequate for my needs.

I brought this to your attention because I didn't understand that the old behaviour was considered a bug. If I recall correctly, the old behavior is consistent with how the old SBLive worked "in hardware".

[saga]

I am content to stay with version 13, which is entirely adequate for my needs.

You could simply render the few MIDI files that need this old behaviour to FLAC and then go on with the times.