Ah, I see. I guess I can use your MIDI player to send those commands, then (looks like there are even presets for them already)! Thanks a lot! ^^

BTW, that soundfont on your website (Reality GM/GS Falco Mod) is also quite good. Where did you get the instruments from (or what did you change compared to the original Reality soundfont)?

Most of the changes happened more than 10 years ago so I cannot give you a perfect list. A far as I remember:
1. Default fingered bass modified. Added Fender bass to bank 1.
2. Default picked bass replaced to Roland one. Original placed to bank 1.
3. Default fretless bass replaced to custom made Rickenbacker. Original placed to bank 1.
4. Original overdrive and distortion guitar modified. Added Garcia to bank 1.
5. Original steel and Nylon guitar modified. Added Washburn to bank 1.
6. Default piano 0 modified.
7. Added other instruments for a more complete GS experience.
8. Added Some Drum sets including an MT-32 compatible one.
9. Added MT-32 compatible remapping to bank 127.
10. Fixed some effects octave problem.
11. Modified/replaced SF2 modulators that could cause unwanted filter cutoff effects on real SB hardware.

I tried to install this via the "VST MIDI Driver (as a system MIDI synth)" method, but whenever I try to connect to the driver (for example, in DOSBox I set mididevice=win32 and the appropriate midiconfig value) I get the attached error message and the application crashes. All other MIDI devices work fine, including Munt.

This error has nothing to do with S-YXG50 since it does not use BASS.dll at all. But e.g. Coolsoft VMS and Bassmidi driver do use BASS.dll so most likely you have failed to configure the correct midi out port or the VST midi driver itself to use syxg50.dll.
Edit:
It seems VstMidi driver also uses Bass.dll so it might be a BASS.dll version conflict between VST midi driver and Coolsoft VMS/Bassmidi driver. Try to remove Coolsoft VMS/Bassmidi driver and reinstall VST Midi driver.

Edit2:
If you do not succeed in using VST Midi driver you can still use DosBox and S-YXG50 with a virtual midi cable and a VST host (like FSMP or SAVIHost)
e.g. like this:
https://www.youtube.com/watch?v=6CdJ7sEt8UM&feature=youtu.be
This method has the advantage that you do not have to modify DosBox's configuration if you want to use other Midi Ports/SoftSynths.

A critical bug in the VST MIDI Driver. It seems that VST MIDI Drivers always renders sound with 44100 sample rate, and it ignores the sample rate which was chosen for the current wave output. It is easy to reproduce: Open Playback Devices → right click on your playback device → Properties → Advanced → Default format → Set 96000Hz and apply. Try to listen any MIDI. As the result you will hear a very high pitch sound.

I mentioned this problem here: https://hydrogenaud.io/index.php/topic,87639. … .html#msg940359
I hope, that kode54 will fix it one day, because people sometimes ask me why S-YXG50 sounds not right when used with the VST MIDI Driver.

Yes, that is a BASS import bug, because it appears your VSTi MIDI Driver is somehow importing the wrong version of BASS.dll, even though it explicitly is supposed to be searching its own folder for it.

Both of my MIDI drivers use BASS's DirectSound output on older systems, and BASSWASAPI on Vista and up. The sample rate bug only manifests with WASAPI output, since the DirectSound output always chooses 44100Hz. The WASAPI bug will be fixed soon.

Glad to hear it.

When I try to use SAVIHost with this it says that there is an error loading syxg50.dll
I renamed SAVIHost.exe to syxg50.exe but the problem still happens.
Any idea what could be going wrong with this?

1. Check the dll is intact: it should be 5 070 848 byte an its property page should say Yamaha S-YXG50 VSTi (4MB)
2. Make sure you use the 32 bit version of SAVIHost ( But I do not know 64 bit version of SAVIHost even exists..)
3. Check your AV solution does not block downloaded files.
4. Try another VST host, e.g. FSMP. Then I can give more help since I know its problems/error messages better.

Falcosoft wrote:

2. Make sure you use the 32 bit version of SAVIHost ( But I do not know 64 bit version of SAVIHost even exists..)

That was it. I was using the 64bit version of SAVIHost which does exist but does not work with this. Thanks!

S-YXG50 is 32 bit VSTi, and a VST host also has to be 32 bit.

This synth sounds great. I used to have the DB50 daughterboard on my SB16 and had to give it up when I replaced my SB16 with an Audigy 15 years ago. This is the closest in all of that time that I've gotten to how I remember the DB50 sounding. I even previously downloaded one of those 250MB soundfonts and it doesn't sound even close to as good as this 5MB VSTi. I'm not sure why that is, but I'm impressed. Very nice job, VEG.

I'm using it in VirtualMIDISynth by setting "Windows Media Player default device" on the MIDI Mapper tab to it. Unfortunately, as the name suggests, that means that it applies only to MIDs that I load up in WMP. Is there a way to use it more globally, so that, for example, games in DOSBox could use it (like they use the soundfonts through VirtualMIDISynth)... or would I not actually want that? I admit that my understanding of software synthesis (including the difference between soundfonts and VSTis) is pretty rudimentary.

So which games sounds better with this VSTi, what to check out? =)

VST MIDI Driver was updated. It is strongly recommended to use this updated version.

kode54, thanks for the update.

kode54, two persons complained me that the new version of the VST MIDI Driver has some unknown problem with some of players, for example, vanBasco. They say that it just doesn't work and tells that some unknown internal error happened. Trying to play a midi using KaraFun v.1.20.86 shows this error: Unable load function Bass_ChannelGetLevelsEx (Bass.dll).

Hi Veg,
This must be the same problem as Laukku reported earlier: Yamaha S-YXG50 Portable VSTi (a software MIDI synth)
And Kode54 has already written:

Yes, that is a BASS import bug, because it appears your VSTi MIDI Driver is somehow importing the wrong version of BASS.dll, even though it explicitly is supposed to be searching its own folder for it.

The problem is both VMS 1.x and vstmididrv are inprocess drivers that implicitly using bass.dll (and bassmidi.dll). So in spite of Kode54's trying to load bass/bassmidi.dll explicitly from its own folder it does not work if VMS 1.x has already imported the same dlls implicitly into the player's process. (You can see e.g. in Sysinternal's process explorer that because of inprocess behavior bass/bassmidi.dll is in the given player's (e.g. Van Basco's) address space. So if VMS 1.x has already loaded a different version of basss.dll into the process's address space vstmididrv cannot load its own version anymore.
The solution can be:
1. Uninstall VMS 1.x. Optionally try the 2.x branch since AFAIK it uses out of process driver behavior so the player's process does not use implicitly bass/bassmidi.dll anymore.
2. Try to replace bass.dll/bassmidi.dll in VMS working directory with the newer one that vstmididrv uses. It should work, there are no breaking changes in 2.4.x versions of Bass.
But in case of my own player FSMP I have experienced that in spite of no dll version conflict I still get sometimes 'error 5 cannot play bass channel' with my own bassmidi implementation after using either VMS 1.x or vstmididrv. So solution 1 is more secure.
3. Using LoppMidi + FSMP can also be a solution since FSMP is a VST and Soundfont host and midi router in one without conflicts.

I have checked KaraFun 2.5.1 and the problem is this player itself also uses the Bass libraries. It is the same problem as with VMS 1.x. If the player loads its own bass version then vstmididrv has no chance to import its own (even newer version).
Edit: I have also checked version 1.2 of KaraFun. The situation is the same. Also solution 2 from the above post does not work since the application checks that old version 2.4.6 of bass.dll can be found in its own folder and insists to use only this version. So there seems to be a fundamental/architectural problem with midi applications and in-process midi drivers that try to use the Bass libraries simultaneously. Maybe that's why VMS 2.x dropped the in-process driver idea.