Topic: XMPlay MIDI plugin

[Ian @ un4seen]

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".

Oh yes, you're right. I just tried Creative's Soundfont Bank Manager for the first time in ages, and it does indeed work the way that the XMPlay MIDI plugin used to. I guess that's why the plugin worked the way it did, and I forgot

The plugin's config UI doesn't currently have any way of choosing between 2 bank number systems, so I'll return it to the old system for now and post an update (hopefully tomorrow). One issue is that I'm not sure the base bank number system is compatible with the SFLIST file format. Perhaps the "b<target bank #>" option can be extended with a sign to indicate that it's a base number, ie. "b+<base bank #>" (or "b-<base bank #>").

[winner]

...The plugin's config UI doesn't currently have any way of choosing between 2 bank number systems, so I'll return it to the old system for now and post an update (hopefully tomorrow)...

Thanks, Ian! I agree that the old behavior for multiple bank soundfonts is the way to go.

[Ian @ un4seen]

OK. Here's an update that should return the default behaviour to treating the bank number as a base number:

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

The absolute bank number option is also still available via SFLIST files ("b<bank#>" entries). As proposed in my previous post, "b+<bank#>" is used for a base bank number in SFLIST files.

Let me know if you have any trouble with the update (it hasn't been tested much yet).

[sevendy]

Let me know if you have any trouble with the update (it hasn't been tested much yet).

Thanks! Seems fine so far.

[ELP]

Could we have one XMPlay-MIDI(&maybe Bass MIDI) which respond also to LSB Bank select ( normal CC32 & XG SysEx LSB Bank select message)
and not only MSB Bank Select? (cc0 & MSB Bank select via SysEx)0,128,256.....(MSB 0,1,2...)

And of course at least additional 127 LSB Bank Slots(1 to 127)
Or maybe just change these
-already there but for me more unnecessary(rather useless)
D001 to D127 additionally Drum Bank Slots
-which respond only to MSB (CC & SYSEX MSB) Messages and only together with Ch10,
to
additionally Bank Slots for LSB Bank select Messages
LSB001 ,...., LSB127  (1 to 127) for all channels (Ch1-16 | 0-15) with a fallback to Bank0 MSB 0 LSB 0 ?
 
Otherwise really not a single XG MIDI File, which use other Banks like the Bank 0, would sound as it should...( And that´s mostly all ^^)
(means without excessive User modification to change normal XG LSB Bank select messages CC &SysEx to MSBs first)

Maybe it would be enough, if XMPlay-MIDI (within XGMode) 
would automatically change LSB messages to MSBs ,
but the better, perfect LSB respond/bank assign solution, would be of course the above.

Thank you and greetings
 
 

[Ian @ un4seen]

BASSMIDI has more flexible soundfont config options than the XMPlay MIDI plugin currently does, which allows it to support LSB banks; an SF2 file can be assigned to a specific LSB bank (or all MSB in combination with that LSB), but even so it would probably need a lot of work to set up what you want. The problem is that SF2 soundfonts don't support LSB banks, so you would probably need to create your own "LSB" soundfonts as there are unlikely to be any ready-made SF2 files for it.

I'm not sure changing LSB bank events to MSB bank events would be a good idea, as there may be conflicts, eg. XG has MSB=64 and LSB=64 banks. If you only need LSB banks with MSB=0, then perhaps some support can be added for that specifically. It would probably be simplest to include all LSB banks in a single SF2 file, ie. the file's bank numbers basically become LSB instead of MSB?

[ELP]

I am only talk about the Normal Voice List( Bank LSB 1 to 127( decimal  1 to 127), Ian
(which use. like you said MSB 0  LSB 1 up to 127
I mean only the LSB numbers between MSB 0 and MSB 1 (decimal 1 to 127)

I am not talking about XG Model exclusive Voice Banks, which use for example MSB 48 together with different LSBs
-Which would be near the same like within GS Standard - the different Model Sound-Sets MSB xx + LSB 0 to 4

And these XG MSB 64 (SFX) or MSB 127 Drums... don´t make the problem because they use only MSB  without LSB or better only MSB xx + LSB 0

So if we could have additional 127 LSB Banks
( like these non standard extra drum Banks D001 to D127 -which respond to MSB xx but only together with CH10)
and could map voice/sound banks to these List, which then respond to LSB Bank Select messages ( #CC and XG SysEx )- all channels
it would be enough and really perfect...

in principle we would have extra, 127 Bank Slots- like these D001- D127- or like I said before change these D001-D127 to LSB ...
I find this LSB ... more useful and maybe it would be less work?

If this could be done it would be great,
Bank Slots LSB 1 to LSB 127 with a fallback to MSB 0 LSB 0 bank

At the moment XG MIDI Files which address variations banks would always fallback to MSB 0 LSB 0
( which clear not sound correct and is like simple GM1 0-127 prg)

SRY for my bad....

Greeting

BTW.
And yes Ian only change lsb to msb messages would be only one workaround and not really good.
much better would be extra slots and real respond to lsb

[ELP]

BTW:
"The problem is that SF2 soundfonts don't support LSB banks"

This is a myth, Ian.
By the fact SF-Files Riff Version 3 was future designed from EMU/Creative the way, that it could hold/store the complete MIDI MSB / LSB Range = 16384 (0 to 16383) Banks + 1 Drum Bank for CH10
( which do not need Bank Switch/Select over MIDI- So that is the reason why it is store/ is address as 7 Bit MSB Byte overflow = 0x80 (128) MSB LSB 0x8000 decimal 16384.

Both bytes within  WORD wBank should/must be used as MIDI  7Bit Bytes MSB Byte|LSB Byte Range 0x0-0x7F

The problem is only that there is not a single third Party Editor or other App which interpret the wBank WORD  LSB byte within -phdr- correctly
incl. editing
Viena as example interpret only the MSB Byte as 8bit instead of 7Bit which is simply wrong and Polyphone as one second example interpret both Bytes MSB  LSB as 8 Bit
MIDI never use 8Bit for DATA .7Bit is used...
Devices/ Apps etc which use only MSB for Bank switches use of course only the first Byte and the the second byte is unused...
That´s the reason why it is as Standard Value stored as 0 MSB XX LSB 0   .. And maybe that is the reason why this myth is born... The creator of this standard (Creative/EMU)used only the MSB for their devices.. like within GM2/GS
But it can store the LSB address as 7Bit 0x0 to 0x7F and should be handle as 7 Bit and not 8Bit... single 8 Bit Byte for DATA over MIDI is impossible/illegal..
>0x7F would be a Status.byte and not DATA Values...

-phdr
WORD wBank  0xMB|LB
MB/LB = 7bit Bytes Range 0-127|0x0-0x7F
0x8000 = Drumbank

Someone should told the Viena guys that it is wrong to handle the MSB as 8 Bit and the polyphone guys should also know it...
And maybe that is the reason why these D001 to D127 Non Standard Drumbank is born, Ian?
MSB byte >128 = D001 up to D127? That is simple the wrong interpretation of the MSB byte within wBank WORD
Over MIDI as single Byte DATA impossible.. And events on Ch10() within GM/GS mode automatically use Drums and this don´t need any Bank Select/Switch... It is not designed for. Only Prg Select.. is needed

[Ian @ un4seen]

SF2 files can technically contain up to 65536 banks, but the SF2 spec doesn't support that, quote: "If the value in either field (wBank or wPreset) is not a valid MIDI value of zero through 127, or 128 for wBank, the preset cannot be played but should be maintained". So I think it is unlikely that you will find any ready-made SF2 files to provide the LSB bank sounds you want. In which case, you would need to create your own SF2 file(s) to provide them. Have you already looked into that?

Regarding the D001-127 banks in the XMPlay plugin, they are MSB banks 1-127 in a drum channel, in case anyone happens to want to use them.

Please upload a few examples of XG MIDI files that make use of LSB banks to have a look at here:

   ftp.un4seen.com/incoming/

[PSXGamerPro1]

btw Ian I did convert some Playstation vab's to sf2 (after I had to merge 64 KB chunks because the format of Crash Bandicoot's nsf is all chuncked out by 64 KB chunks) that it seems either A some instruments are missing or B those instuments is not executed by the plugin. But then again I have a few files that are completely fine but most of the levels and the warp room in the game and in Crash 3 dont end up sounding just right.

And I needed them to be sf2 because I had to convert the seq's to midi.

btw did you know that Playstation VAB and SEQ's are similar in that SEQ is almost like MIDI and that VAB's are almost like sf2.

Also it seems like some of the files like to play with some awkward reverm in them when they are not supposed to have one.

uploaded for looking into:

Code: [Select]

reverb issue.zipyeah I know I stuck the file name in a code block to easily know what all is in the name and for easy selecting.
Also included is a playstation vab file and a seq for you to look at if you want to make a plugin to read sony PS1 (PSX they call it on game executables for all games)

Edit: it also seems that some instruments they play too low that they sound like they are missing.

1 Example is the Warp Room in Crash Bandicoot 2 from the final version vs what you get in the game. (similar with some differences everytime that instrument is used)

So uploading that to for a look.

Code: [Select]

Instrument Issue.zip
So yeah the Instument issue on this I am not sure if it is the sf2 file or some playback stuff going wrong. although it could be the sf2 not having the right instrument but I would think it would be right.

[Ian @ un4seen]

it seems like some of the files like to play with some awkward reverm in them when they are not supposed to have one.

Those SF2 files are setting the reverb level to 70% on all of the presets, so you should remove that if it is unwanted. The MIDI plugin does also add some reverb itself by default (CC#91 = 40); you can disable that by setting CC#91 to 0 at the start of each MIDI channel.

All reverb can also be disabled manually via the "Reverb level" slider (or "Reverb & chorus effect processing" switch) in the plugin's "MIDI mixer" window.

it also seems that some instruments they play too low that they sound like they are missing.

1 Example is the Warp Room in Crash Bandicoot 2 from the final version vs what you get in the game. (similar with some differences everytime that instrument is used)

So uploading that to for a look.

Code: [Select]

Instrument Issue.zip
So yeah the Instument issue on this I am not sure if it is the sf2 file or some playback stuff going wrong. although it could be the sf2 not having the right instrument but I would think it would be right.

Which instruments are sounding too low? The attenuation settings in the SF2 file look OK, so I would guess that the problem is in the MIDI file, eg. in the channel volume levels (CC#7/CC#11) or note velocities. You could check that stuff in a MIDI file editor/sequencer.

[lybxlpsv]

add lsb support pls
with 2 options.

1, based on most xg soundfont i found in the web, maybe sf2bank=1 = lsb=1 .. sf2bank=126 = lsb=126 ignoring the other banks  which means user should add the same soundfont in normal msb mode.

2, then for roland gs lsb,  being able to specify a soundfont to an lsb should be enough.

then i can finally ditch my crappy player :p

[PSXGamerPro1]

it seems like some of the files like to play with some awkward reverm in them when they are not supposed to have one.

Those SF2 files are setting the reverb level to 70% on all of the presets, so you should remove that if it is unwanted. The MIDI plugin does also add some reverb itself by default (CC#91 = 40); you can disable that by setting CC#91 to 0 at the start of each MIDI channel.

All reverb can also be disabled manually via the "Reverb level" slider (or "Reverb & chorus effect processing" switch) in the plugin's "MIDI mixer" window.

it also seems that some instruments they play too low that they sound like they are missing.

1 Example is the Warp Room in Crash Bandicoot 2 from the final version vs what you get in the game. (similar with some differences everytime that instrument is used)

So uploading that to for a look.

Code: [Select]

Instrument Issue.zip
So yeah the Instument issue on this I am not sure if it is the sf2 file or some playback stuff going wrong. although it could be the sf2 not having the right instrument but I would think it would be right.

Which instruments are sounding too low? The attenuation settings in the SF2 file look OK, so I would guess that the problem is in the MIDI file, eg. in the channel volume levels (CC#7/CC#11) or note velocities. You could check that stuff in a MIDI file editor/sequencer.

Know of anny that also pre-loads the soundfonts. I am not sure if OpenMPT can do that although it would read midi as a type of "Impulse Tracker" module. I hope it can.

[PSXGamerPro1]

it seems like some of the files like to play with some awkward reverm in them when they are not supposed to have one.

Those SF2 files are setting the reverb level to 70% on all of the presets, so you should remove that if it is unwanted. The MIDI plugin does also add some reverb itself by default (CC#91 = 40); you can disable that by setting CC#91 to 0 at the start of each MIDI channel.

All reverb can also be disabled manually via the "Reverb level" slider (or "Reverb & chorus effect processing" switch) in the plugin's "MIDI mixer" window.

it also seems that some instruments they play too low that they sound like they are missing.

1 Example is the Warp Room in Crash Bandicoot 2 from the final version vs what you get in the game. (similar with some differences everytime that instrument is used)

So uploading that to for a look.

Code: [Select]

Instrument Issue.zip
So yeah the Instument issue on this I am not sure if it is the sf2 file or some playback stuff going wrong. although it could be the sf2 not having the right instrument but I would think it would be right.

Which instruments are sounding too low? The attenuation settings in the SF2 file look OK, so I would guess that the problem is in the MIDI file, eg. in the channel volume levels (CC#7/CC#11) or note velocities. You could check that stuff in a MIDI file editor/sequencer.

Ok, so I just looked under the samples Tab on the Info Window on all of the files I got by extracting the sequences and soundfonts and converting them for use in XMPlay it seems that all of them are missing the d0:9 instrument that is a certain note that I do not know of to some instrument. So that explains how all of them do not sound exactly right as they are all missing that Instrument.

This explains why I dont hear them so that makes me think they are too low.

Maybe have XMPlay MIDI Plugin guess what that instrument is by attempting to load one up from the default ones if it is not found in the soundfont file with the same file name as the midi?

here is one of the things I see from 1 of the files I have.

Code: [Select]

warp.sf2:
0:0 Instr bnk0 num0
0:1 Instr bnk0 num1
0:7 Instr bnk0 num7
0:8 Instr bnk0 num8
0:4 Instr bnk0 num4
0:2 Instr bnk0 num2
0:5 Instr bnk0 num5
0:10 Instr bnk0 num10
0:3 Instr bnk0 num3
0:6 Instr bnk0 num6
0:11 Instr bnk0 num11

missing:
d0:9


Edit: I think Plugin messed up thinking it is d0:9 when II think it should be 0:9 as named in the soundfont itself.

[kode54]

With some help and suggestions from my SO, I have devised a SoundFont List format based on JSON, with the intention of it being easier to parse, assuming you use something like json.c to parse it, and the related json-builder.c to serialize it again.

https://gist.github.com/kode54/a7bb01a0db3f2e996145b77f0ca510d5

Maybe this would be something a little easier to swallow when it comes to extraneous formats? Something that takes:

https://github.com/udp/json-parser

and turns a memory loaded .json into an array of SoundFont handles for BASS, would probably be quite useful.

[Ian @ un4seen]

Ok, so I just looked under the samples Tab on the Info Window on all of the files I got by extracting the sequences and soundfonts and converting them for use in XMPlay it seems that all of them are missing the d0:9 instrument that is a certain note that I do not know of to some instrument. So that explains how all of them do not sound exactly right as they are all missing that Instrument.

This explains why I dont hear them so that makes me think they are too low.

Maybe have XMPlay MIDI Plugin guess what that instrument is by attempting to load one up from the default ones if it is not found in the soundfont file with the same file name as the midi?

here is one of the things I see from 1 of the files I have.

Code: [Select]

warp.sf2:
0:0 Instr bnk0 num0
0:1 Instr bnk0 num1
0:7 Instr bnk0 num7
0:8 Instr bnk0 num8
0:4 Instr bnk0 num4
0:2 Instr bnk0 num2
0:5 Instr bnk0 num5
0:10 Instr bnk0 num10
0:3 Instr bnk0 num3
0:6 Instr bnk0 num6
0:11 Instr bnk0 num11

missing:
d0:9


Edit: I think Plugin messed up thinking it is d0:9 when II think it should be 0:9 as named in the soundfont itself.

It looks like the issue is that the MIDI file needs channel 10 to not be a drum channel? If you are converting/creating the MIDI files yourself, there are a couple of solutions that you could use. If you don't need all 16 MIDI channels, then the simplest solution is just not use channel 10. Otherwise, you could use GS/XG/GM2 sysex to switch channel 10 to a normal channel.

With some help and suggestions from my SO, I have devised a SoundFont List format based on JSON, with the intention of it being easier to parse, assuming you use something like json.c to parse it, and the related json-builder.c to serialize it again.

https://gist.github.com/kode54/a7bb01a0db3f2e996145b77f0ca510d5

Maybe this would be something a little easier to swallow when it comes to extraneous formats? Something that takes:

https://github.com/udp/json-parser

and turns a memory loaded .json into an array of SoundFont handles for BASS, would probably be quite useful.

Looks good. I think that would indeed be easier to parse due to existing JSON libraries, and more elegant too. But perhaps not so easy for creating/editting by hand, ie. you couldn't simply use something like Notepad for that?

Is it possible to optionally omit the program number from a "source/destination" entry to map an entire bank? For back compatibility, BASS/XMPlay would also need to have a base bank number option when using an entire soundfont. For example, if the base number is set to 1, then the soundfont's banks would be used in 1 bank higher than normal, eg. bank 0 becomes bank 1. Perhaps a "baseBank" option could be added for that, which would be mutually exclusive with the "patchMappings" option?

I notice all of your example "filename" entries have leading slashes. I presume a leading slash (or drive letter like "c:") indicates a full path, and otherwise it's a relative path?

[kode54]

I didn't start the leading slashes thing. That would be for absolute paths, at least on Unix-like operating systems where that's root. Otherwise, they'd be paths relative to the sflist.json.

baseBank sounds like an appropriate option for specifying a bank offset without explicit patch mappings, and should be mutually exclusive to the patchMappings.

My SO is working on a GUI editor, in C#. A future version may use BASSMIDI to query information on the banks, and possibly preview the whole list.

[kode54]

Bumping to report that the gist now contains a processor/loader and a conversion tool. Conversion appears to work, but I have yet to test loading.

Linking it again:

https://gist.github.com/kode54/a7bb01a0db3f2e996145b77f0ca510d5

[Ian @ un4seen]

Looks good. It looks like you have extended the existing "patchMappings" option to support a bank base/offset (via a lone "destination:bank" field), so there's no need for something like a "baseBank" option? One other thing you could add support for is the bank LSB option (accessed via MIDI_EVENT_BANK_LSB/CC#32). That would only be applicable to "destination" (not "source"), as SF2 soundfonts don't support it themselves.

[kode54]

I will add that, once you've added a channel field of some sort to the BASS_MIDI_FONTEX structure, since I currently use bank LSB to implement that. Not sure how else to go about that. Other than, say, completely dynamically mapping patch and bank numbers.

[karbock]

Here's an update that will release only a single instance of a note (the oldest one) upon a "note off" event...

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

It shouldn't have any effect on the vast majority of MIDI files, as they don't normally have same note overlapping, but let me know if you do find it causing problems for any files.

Wow! Fast response once again, thanks!

This did indeed fix problems with the Jurassic Park theme file and has corrected playback glitches in some other of GaryW0001's (Gary Wachtel's) midi files. His sequences are high quality and very popular, so perhaps this has been a positive fix for a lot of people. I will certainly test many of my midi files to see if problems crop up on other files. 

Hello! It seems like I'm digging out an oldie, but the problem mentioned above -- that had been fixed -- shows up in recent releases of xmp-midi.

I've just uploaded the concerned MIDI file (Cinema - Jurassic Park [Wachtel].mid) into ftp://ftp.un4seen.com/incoming/.

The problem (glitches from 1:27) happened because the MIDI file contains overlapping similar notes.
It was fixed in xmp-midi v1.0.13.03, and it worked like a charm until v1.0.14.00.
From v1.0.14.01, xmp-midi renders the MIDI file with glitches again.

[Ian @ un4seen]

I will add that, once you've added a channel field of some sort to the BASS_MIDI_FONTEX structure, since I currently use bank LSB to implement that. Not sure how else to go about that. Other than, say, completely dynamically mapping patch and bank numbers.

Oh, right. Perhaps you could have both the channel option and a bank LSB option, but make them mutually exclusive for now (until BASSMIDI allows them separately). I guess most people won't use bank LSB anyway, but they will at least have the option of it then.

Here's an update that will release only a single instance of a note (the oldest one) upon a "note off" event...

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

It shouldn't have any effect on the vast majority of MIDI files, as they don't normally have same note overlapping, but let me know if you do find it causing problems for any files.

Wow! Fast response once again, thanks!

This did indeed fix problems with the Jurassic Park theme file and has corrected playback glitches in some other of GaryW0001's (Gary Wachtel's) midi files. His sequences are high quality and very popular, so perhaps this has been a positive fix for a lot of people. I will certainly test many of my midi files to see if problems crop up on other files. 

Hello! It seems like I'm digging out an oldie, but the problem mentioned above -- that had been fixed -- shows up in recent releases of xmp-midi.

I've just uploaded the concerned MIDI file (Cinema - Jurassic Park [Wachtel].mid) into ftp://ftp.un4seen.com/incoming/.

The problem (glitches from 1:27) happened because the MIDI file contains overlapping similar notes.
It was fixed in xmp-midi v1.0.13.03, and it worked like a charm until v1.0.14.00.
From v1.0.14.01, xmp-midi renders the MIDI file with glitches again.

That's strange. Comparing the output of rev.13j (13.10) and rev.14g (14.07 - the latest stuff), I don't see/hear any differences. The only thing that comes to mind is that perhaps you have a "NoteOffAll=1" line in your XMPLAY.INI file? If so, removing that should get the file playing properly again.

[karbock]

That's strange. Comparing the output of rev.13j (13.10) and rev.14g (14.07 - the latest stuff), I don't see/hear any differences. The only thing that comes to mind is that perhaps you have a "NoteOffAll=1" line in your XMPLAY.INI file? If so, removing that should get the file playing properly again.

Good point! Indeed, "NoteOffAll" was set. Thank you, Ian!

[winner]

I'm using XMPlay 3.2.18 with Midi plugin rev.15 on Windows 10 Home. For some reason, the Mixer button on the MIDI config display does not launch the mixer. I've tried a couple of previous MIDI plugin versions and they have the same issue. This button has worked properly in the past, but I can't say for sure when it stopped working.

[Ian @ un4seen]

That's strange. The button is working OK in Win10 here, so the problem doesn't appear to be something related to that. Does removing all other plugins help? Is the "MIDI - Mixer" shortcut key still working?