RetroGamer4Ever wrote on 2022-03-25, 14:41:

There's been some experimental updates with a fork of the driver, which is now ready for testing. Some useful improvements and enhancements, but I don't know what all of them mean exactly.

https://github.com/DB50XG/vstdriver/releases

I discovered that this version is actually a fork of the long-defunct fork of the original and now defunct VST MIDI Driver from Mudlord and Arakula's fork is forked from the same defunct fork, but has different code. Hopefully, we can ditch the forks and just get a functional spoon that everyone shares.

Oh... and I thought the latest is based on Arakula's release. Going in different directions code-wise doesn't seem like the smartest idea. But well, looks like both projects still have a lot on their plate before you can call them fully functional. Until then, it's FSMP/loopMIDI combo for me.

Btw, did anybody experience music getting stuck in games? I am having this in Doom with the Woof port (using SCVA, FSMP and loopMIDI). Happens rarely, but when it does, I have to do a GS reset to make it stop. Can it be MIDI loopback? In loopMIDI, the threshold for loopback detection is 5.000 commands/5 sec, which should be pretty high.

I have not used the driver for game MIDI, apart from a testing with the Sierra remakes, which went perfectly and I have had no problems with MIDI file playback. The best choice for DOOM is to simply use an HQ GM/SoundFont solution, as there is no GS MIDI functionality in that game or it's sequel. Heretic/Hexxen might have GS functionality, but I'm not familiar with either of those titles beyond playing the Heretic demo quite a few times.

They are all GM. I don't know any game from the top of my head which uses GS. At least none that I play, anyway.

Yeah, GM is as high as probably any game really goes. It's worth noting that external synthesizers or daughterboards or even soundcards with daughterboard functionality (until the AWE32 and maybe the GUS) were super expensive and rare for the most part and most normal users just didn't have them. The extra functionality of GS wasn't particularly used in games and, unfortunately, the further extra functionality of XG never was. I think Sierra did supposedly do some extra GS functionality in a game or two because they were among the first to push for things like the Roland GS, but I could never personally hear a real difference and it wasn't in many games anyway. YMMV I guess there. Honestly, the only game I ever personally ran across that could truly benefit from something other than the standard General MIDI was Monkey's Island which, famously, used the MT-32 optimally, but then that not only isn't more than General MIDI, it's actually less (an early, more proprietary system that wasn't really even standard.)

What it comes down to ultimately is you can always do better with a custom soundfont. The sample ROM in devices of that time period was typically exceptionally small (4MB generally was the max of such devices and many were 2 or even less. Many were 512KiB I think? Even those like the AWE32 with RAM only had small amounts of sample RAM -- I think the AWE32 was 2MiB with an optional very expensive upgrade chip available to go to 4MiB if I remember, but it has been a very very long time.) The problem is, a custom soundfont is more... shall we say "personal." The samples that work great in one game's musical style can sound horrible in another's. A soundfont that sounds excellent in Doom can sound horrible in, say, Daggerfall. Worse: it's rare, but sometimes a soundfont that sounds great in one track can sound terrible on another track even just in the same game... Now, to my ears at least, the XG synthesizer's samples and normal sound just seemed to work really well as a generic sound across all games and sounded better than all the other wavetable devices that at least I ever had access to. I never have found a soundfont I was truly 100% satisfied with as a good generic. The basic XG sound is definitely worse than a good soundfont -- I mean, to be fair, they only had a 4MiB ROM to work with for the full sample set on the DB50XG (which S-YXG50 basically emulates) -- but you can just play one game after another and it still sounds pretty great in each at least relatively speaking. I'm sure if you actually make music using MIDI the extra functionality of GS and XG might be nice, but then again, at this stage I wonder if using a more modern, more "tracker"-like setup isn't better?

Perhaps by now there's a better generic soundfont to use simply across multiple games. That would be nice because a lot of things like DOSBox do have built in synthesizers that can use a soundfont. I just haven't run across one that (to my ears) seemed to work for that yet. Alternately, what would possibly be the best thing if one is patient enough is to actually set the emulator to use a different soundfont on a per-game basis. Then you could get incredible results. That's potentially quite a lot of work though. If someone knows of a really good generic that actually sounds great across virtually every single game I'd be interested to know. Anyway, for now I still try to keep a mechanism of using S-YXG50 going for those rare few games I actually play that use MIDI (mostly in DOSBox.) As support begins to fade more and more I'm thinking ultimately I'll probably have to start running DOSBox in a VM (probably using Windows 7 at the latest) as insane as that is. I really wish we had a WinBox by now since Windows is making it harder and harder to run any legacy games, lol. (Yeah, I know DOSBox can technically be made to run some Windows versions, but it will never officially support it and I feel like development is almost sort of hostile towards it. Many optimizations for DOS gaming actually hurt the accuracy of some functionality needed for Windows support anyway.) Many Windows 9x games just don't even work in Windows 10 at all anymore and of course anything 16-bit can't be run on a system running in 64-bit mode. Possibly even full blown emulation like QEMU is ultimately the best way to go long term. But the beauty of a VST driver that can use the S-YXG50 VST is you don't have to deal with all those complexities right now. Just set it and forget it.

BTW, there is a soundfont based on the XG's sampleset. It never sounded right to me though. Not even the version that is modified to be more GM-like (apparently the normal one had different instrument mapping or something.) I presume the actual synthesizer itself must do things more complex with the sample ROM than just simply the equivalent of a soundfont. (It's worth noting that, for its time, XG was the most powerful and complex MIDI synthesizer. ... For its time, lol.)

None of the soundfonts trying to imitate SC55 or XG50 are getting close enough. I found Masquerade55 acceptable as an SC55 substitute, but for gaming purposes, the 8MBGM Enhanced soundfont is also remarkable. Especially optimized for Descent, Doom, ROTT, Duke3D and even old LucasArts adventures like Indy or Monkey Island.

The main advantage of using soundfonts these days is they are easy to set up. All you need is Coolsoft VMS and MIDIMapper and you have a system synth that works just like that.

I have tried 3 versions of vstmididrv.exe in Windows 10

1 - installs ok, works ok, latency is good enough for my uses, after reboot no software can see vstmididrv at all
2 - installs ok, works but latency is awful, after reboot it can still be seen by software
3 - installs ok, is seen by software, but it doesn't work

I think these are in version/age order

Does anyone have a solution to get this to work every time Windows 19 starts?

My aim is to get the Yamaha SYXG5o VSTi, vstmididrv, XGedit95, with an old version of Cakewalk working together. It does work after installing, but not after reboot

I have no real issues with the one that I'm using, which is the Arakula build. Bumping up the priority of the programs to High or Realtime might improve things for you.

RetroGamer4Ever wrote on 2022-05-01, 20:58:

I have no real issues with the one that I'm using, which is the Arakula build. Bumping up the priority of the programs to High or Realtime might improve things for you.

I've set the priority of "XGEdit" and the "vsthost32.exe" to high and also realtime, but it does not improve the latency unfortunately

I've tried it on another machine too, with the same result

Arakula version is kinda sufficient if you are using the SYXG50 plugin. As soon as you use anything that requires preset adjustments such as the SCVA, you have to go for a different solution.

The older version of the SYXG50 plugin through the vstmididrv works with much lower latency, but doesn't appear after reboot.

The Arakula version works after reboot, but the latency is not good

Are there other settings that can be changed to tweak this? I don't see any files associated with the SYXG50 or vstmididrv that could contain some form of config

Did you try the DB50XG version? It says it supports ASIO. Maybe that would decrease the latency enough?

I think part of the problem is these are largely meant for stuff like gaming. But also it's kind of tricky with 10 being the way it is to get very good results from MIDI and this is kind of an indirect way of handling an already indirect thing, so it's definitely not ideal. Most ideally you'd want something with a built-in VSTi handler rather than using something this convoluted, but I guess that's not possible the way you want to do it.

Nazo wrote on 2022-05-02, 21:03:

Did you try the DB50XG version? It says it supports ASIO. Maybe that would decrease the latency enough?

I think part of the problem is these are largely meant for stuff like gaming. But also it's kind of tricky with 10 being the way it is to get very good results from MIDI and this is kind of an indirect way of handling an already indirect thing, so it's definitely not ideal. Most ideally you'd want something with a built-in VSTi handler rather than using something this convoluted, but I guess that's not possible the way you want to do it.

I've not heard a DB50XG version. Is there a link to download it?

I'm going to try the VSTi version in other DAWs and see if I can get it working better that way. I know there are other ways of getting the sounds, but the on-screen editing with XGEdit (specifically) is what i'm looking for nostalgia-wise.

Scroll up. There are two forks of the original emtee40 vstmidi software. One by Arakula, and the other by DB50XG. (Yeah, their name is confusing and sort of a bad choice in this situation.) The DB50XG one says on the Github it supports an ASIO output. (Also, I see it can do WASAPI exclusive mode which may produce better results in modern Windows versions depending on your setup.) ASIO or WASAPAI exclusive would cause troubles for things like gaming where it could conflict with digital output, but for your needs it may actually help since both are lower latency outputs. Of course, like I said, the whole thing is made more for gaming than anything else, so I'm not saying it will definitely reduce latency enough for you, but it seems worth a try.

Nazo wrote on 2022-05-03, 21:24:

Scroll up. There are two forks of the original emtee40 vstmidi software. One by Arakula, and the other by DB50XG. (Yeah, their name is confusing and sort of a bad choice in this situation.) The DB50XG one says on the Github it supports an ASIO output. (Also, I see it can do WASAPI exclusive mode which may produce better results in modern Windows versions depending on your setup.) ASIO or WASAPAI exclusive would cause troubles for things like gaming where it could conflict with digital output, but for your needs it may actually help since both are lower latency outputs. Of course, like I said, the whole thing is made more for gaming than anything else, so I'm not saying it will definitely reduce latency enough for you, but it seems worth a try.

Unfortunately in case of DB50XG's version ONLY ASIO output works. If you try to set either WASAPI shared or WASAPI exclusive in the config dialog then you cannot open VST driver port(s) from Midi applications. So the current version of this fork actually requires ASIO. Most likely this is the reason why RetroGamer4ever and RBretrox had problems to make it work at all. If you install ASIO4ALL or you have native ASIO driver it has rather good latency but unfortunately this DB50XG fork is not very stable. Arakula's version is much more stable but has really terrible latency ( about 500+ ms). I think the reason is that this version has missing BASS_SetConfig(BASS_CONFIG_BUFFER, XX ms) call. You can only find the BASS_SetConfig(BASS_CONFIG_UPDATEPERIOD, 5) call in the source which does not change the default 500 ms buffer of Bass. BTW, you cannot improve this latency/buffer default by setting priority of processes 😀

Ah, I haven't used the DB50XG one particularly or messed with the WASAPI options (though WASAPI shared would probably be preferred for normal gaming) so didn't know about that. Still, that may be their best bet for lower latency, depending on their ASIO setup.

It's funny though. It sounds like the Arakula version may actually be very easily fixable for those who know how to make that slight code change and recompile it. Perhaps someone with the knowhow might someday provide such a thing? (I'm surprised the default is 500ms though. That's HUGE!)

Nazo wrote on 2022-05-04, 00:23:

(I'm surprised the default is 500ms though. That's HUGE!)

Bass is first and foremost a general audio library for playing many formats (mp3, wav, mod, etc.) so it has to be tuned if someone wants real-time Midi synthesis with it. E.g the Waveout and Directsound output engines of Winamp use 2000 ms buffer by default to give better skipping/buffer underrun protection. So 500 ms is not that much overall 😀

Hi,
It seems I was right. I have added the missing BASS_SetConfig(BASS_CONFIG_BUFFER, 50) call to MidiSynth.cpp. This way the Arakula version of this driver has a much better latency ( 50 ms vs. 500).
Since I do not have the full tool set to compile the whole package I only compiled vstmididrv.dll. You have to overwrite the original dlls with these after you have installed the Arakula driver.
If you cannot do this from another operating system you first have to uninstall the Arakula driver and then re-install it without opening any Midi application that loads the driver. This is because once the driver is loaded by a Midi application/Windows you cannot overwrite the dlls.

In case of 64-bit OS:
1. Copy the vstmididrv.dll from the x64 folder to C:\Windows\System32 and confirm to overwrite the existing one.
2. Copy the vstmididrv.dll from the x86 folder to C:\Windows\SysWOW64 and confirm to overwrite the existing one.

In case of 32-bit OS:
1. Copy the vstmididrv.dll from the x86 folder to C:\Windows\System32 and confirm to overwrite the existing one.

It's sad that this probably won't find its way into Seib's driver any time soon, considering the last update was already four months ago. But well, hope dies last.

Either way, it's very much appreciated that you shared this. I do have an idea if you're amenable. You could open an issue and share that upload on the issue as a temporary solution on the Github. Then people doing searches would find it there at least. Who knows, it could potentially even encourage a newer build? Even if not, at least they'd find it with searches. Sadly, it seems like Vogons isn't publicly viewable I guess, so people won't find it here from Google/etc.