Nazo wrote on 2022-11-20, 23:14:

Again I want to emphasize: I'm not saying "panic now!" I'm saying "eventually this is just not going to work in a meaningful way for purposes like serious retro gaming. We should prepare in advance instead of waiting until after it happens." But, I'm really just saying it on principle anyway. I think those who have the knowhow to actually do things like implement a more versatile MIDI handler in software like DOSBox simply aren't going to until their hand is forced. But at least I'd like it if someone with such knowhow should see this and hopefully I've at least planted the thought in their minds so that at such time as it actually becomes a major issue they'll already have thought of the solution such that the world waits months for a solution instead of years.

The worry you are raising still feels extremely overblown. Both iOS and Android support MIDI. Tradition DIN connectors are starting to go away, but USB MIDI is still on lots of new and modern equipment.

We have MUNT for MT-32 which is open-source and can be ported to anything. There's a Sound Canvas SC55/88/88 Pro in development. We have the S-YXG50 VSTi which can be decompiled and rewritten if it becomes necessary to run on unsupported OSes. Though for just gaming a good SoundFont meets the needs of 99% of anyone taking a casual look at how MIDI was with old games. Is it 100% authentic? No, but for the people who really care, they can be the audiophiles they are and drop the money on real modules.

SScorpio wrote on 2022-11-20, 23:37:

The worry you are raising still feels extremely overblown. Both iOS and Android support MIDI. Tradition DIN connectors are starting to go away, but USB MIDI is still on lots of new and modern equipment.

I'm sorry, but I utterly fail to see the relevance of iOS and Android having really basic (and not very good) MIDI support. In case somehow I was unclear, I am not saying that ARM can't do MIDI -- that wouldn't make sense as MIDI is basically an interpretation thing much like BASIC or etc, so just about any architecture could technically implement some sort of code for implementing it. My point is just that there is basically no option or control in such things. In fact, you'll find that on those platforms things like DOSBox, ScummVM, and other such things relevant to this conversation do not use any OS implementations but, in fact, implement their own MIDI handling. But my real point in bringing up ARM architectures (BTW, I actually specified the Switch in my previous post, which has no MIDI implementation built into the OS) is just that you can't run many options such as S-YXG50 on those because they simply can't execute the code. A 32-bit x86 binary simply won't execute on an ARM processor in any meaningful way. It currently just isn't possible at all with ports of things like DOSBox and ScummVM on such platforms to have, say, the XG50 sound, which is all I was saying.

We have MUNT for MT-32 which is open-source and can be ported to anything.

Yes. That exists. And it's the example of exactly the sort of thing I was saying I'd like to see more of.

There's a Sound Canvas SC55/88/88 Pro in development.

See, that's good to hear. Why couldn't you have opened with that? This is exactly the sort of thing I'm talking about being what is needed. Nice open source implementations of specific synthesizers is exactly what we need to see more of.

We have the S-YXG50 VSTi which can be decompiled and rewritten

It's closed source and technically would be illegal to do this. Yamaha still owns the license to their MIDI products and isn't exactly super excited to let people make unapproved uses of it. Japanese companies in particular are kind of bad about maintaining an iron-grip control of their IP even when they actually would lose money in doing so (they sell zero copies of S-YXG50, but they'd still be quick to issue takedowns or even threaten lawsuits -- I can guarantee that.) But, of course, Japanese companies aren't the only ones who do this sort of thing, just the worst ones about it. If anyone did ever actually manage to just simply break down the existing VSTi plugin, they could not legally distribute it, making it hard even to get (and illegal to do so,) and software like DOSBox could not implement it in any official capacity, which significantly narrows down the usefulness of such a thing. Unfortunately, it gets a lot more complicated with real implementations of such thing: they basically have to implement a from-scratch implementation of something that ends up at the same functionality. Yeah, basically reinventing the wheel over and over. Well, that is the legal system that this world has in regards to software, so it can't be helped. If you want to make your own tire that exactly implements, say, a Yokohama style, you need to learn how to make the rubber yourself, how to get exactly the right mixes yourself, how to mold it yourself, redo the math/design entirely from scratch to produce the divots, etc etc etc all from scratch. That generally represents an enormous investment in time and effort and often money too. This is why it's so rare that this actually happens. What you're talking about is the equivalent of making a mold from their tires, melting them down, reforming them in the mold, and then calling the result your own. (Ok, tires are a bit more complicated, but you get the idea. Or you can if you want to anyway.) Even if you don't sell it, just by producing it as your tire you've reached a point they'll send a C&D on principle.

Actually, what I had in mind was maybe if they could figure out some sort of more universal way of handling these things. It's messy and complicated, but, for example it might theoretically be possible for a VSTi system that actually emulates a 32-bit x86 CPU doing basically nothing but running that VSTi plugin. That's inefficient and requires a lot of processing power, but not on the same scale as how much processing power it takes to run the entire software (eg DOSBox or whatever) in an emulated CPU. It does have the advantage of the VSTi environment itself would be absolutely under the control of the developers so they could 100% predict the exact results every time for completely reproducible results in basically any platform or situation. Or maybe there is some much more efficient and overall better way of doing it. Again, I just wanted to plant the seeds of thought on the matter. Why you oppose this I do not know, but luckily you're not really the target audience of this idea. If they ever create such a thing you can just refuse to use it.

if it becomes necessary to run on unsupported OSes. Though for just gaming a good SoundFont meets the needs of 99% of anyone taking a casual look at how MIDI was with old games. Is it 100% authentic? No, but for the people who really care, they can be the audiophiles they are and drop the money on real modules.

I'm not sure if you know what audiophile actually means as this is very much not it. My point about finding a good general MIDI soundfont to actually sound right across a variety of games isn't that you have to be an audiophile for it to matter but that most just simply don't sound right in some. As in outright wrong or even bad. I'm not talking about the quality of the samples or etc. Perhaps the average user won't know the difference between a soundfont with 8-bit samples and one with 16-bit. Maybe. That is a different discussion entirely though. Even with tin ears one can tell if instruments sound badly off in a particular game. And no, you don't have to be a rich perfectionist to prefer the sound of one option over another. That's just personal preference. And not all of us can afford to drop the money on real modules even if that were always viable (though even if it were, you basically can't with a DB50XG.) I just like my DOS gaming to sound nice without the complication of switching soundfonts back and forth depending on the game.

Again. All I am saying is that eventually it won't be possible to use some things like S-YXG50 for MIDI. I am not saying it is not possible today (outside of non-x86 32-bit compatible platforms that is.) I don't understand why this is so confusing. I am only saying we need to think about the future. I'm not really clear why you're so dead-set to argue against even taking such thoughts into consideration or willing to understand that I'm saying "some day" and not "today." Either way, this conversation has reached the point of pointlessness and I have no more to say on it.

One thing is sure: Using digitized audio tracks as MIDI replacements is NOT a viable option - unless you just play the original games and nothing else, that is. For Doom or Duke3D there are tons of custom addons which come with their own MIDIs. You can't digitize all of those - and even if you did, it would bloat filesizes extremely. MIDI is a very compact music format, it's a clear advantage, as outdated as it is. You just need a decent synth to make it sound good. (Doom Unity tries to compromise by using digital music only when playing official content, loading GUS patches as fallback option when loading custom content.)

Anyway, I am hopeful the loopMIDI/FSMP combo will keep working as long as those components receive updates when needed. A system driver with on-demand activation is easier to handle, but with every Windows update you have to be afraid it might stop working. From that perspective, it's maybe better to give up on restoring VSTi Midi Driver functionality. There are other options out there and most people that have to deal with MIDI in games will rather use soundfonts, anyway.

Nazo wrote on 2022-11-21, 03:48:

I'm sorry, but I utterly fail to see the relevance of iOS and Android having really basic (and not very good) MIDI support. In case somehow I was unclear, I am not saying that ARM can't do MIDI -- that wouldn't make sense as MIDI is basically an interpretation thing much like BASIC or etc, so just about any architecture could technically implement some sort of code for implementing it. My point is just that there is basically no option or control in such things. In fact, you'll find that on those platforms things like DOSBox, ScummVM, and other such things relevant to this conversation do not use any OS implementations but, in fact, implement their own MIDI handling. But my real point in bringing up ARM architectures (BTW, I actually specified the Switch in my previous post, which has no MIDI implementation built into the OS) is just that you can't run many options such as S-YXG50 on those because they simply can't execute the code. A 32-bit x86 binary simply won't execute on an ARM processor in any meaningful way. It currently just isn't possible at all with ports of things like DOSBox and ScummVM on such platforms to have, say, the XG50 sound, which is all I was saying.

...

Again. All I am saying is that eventually it won't be possible to use some things like S-YXG50 for MIDI. I am not saying it is not possible today (outside of non-x86 32-bit compatible platforms that is.) I don't understand why this is so confusing. I am only saying we need to think about the future. I'm not really clear why you're so dead-set to argue against even taking such thoughts into consideration or willing to understand that I'm saying "some day" and not "today." Either way, this conversation has reached the point of pointlessness and I have no more to say on it.

I'm sorry I only brought up the two most used modern OSes, Android, and iOS having full MIDI support since you are worried about it disappearing for some reason. Roland had even ported Virtual Sound Canvas to iOS so you could use a phone or tablet as a MIDI module. You can both record and playback MIDI from either, so what is lacking in their MIDI implementation in your mind?

I don't understand why you would think the Switch or any video game console would have MIDI. The SNES's Sony sound chip came the closest functionality, but MIDI is a way to record and playback music. Game consoles have their own audio hardware which would be targeted rather than needing external sound modules. There were always 3rd party add-ons, the NES and SNES had the Miracle Piano that used a custom connector. But by running them on MiSTer you can play with a normal MIDI keyboard. And the PS3/4/5, Xbox 360/One/Series X, and Wii/Wii-U all had the ability to connect MIDI drums in Rockband and later Guitar Hero games. With Rockband 3 supporting MIDI guitars as well. But this was just a game input method, not actually playing back music.

As for SoundFonts and being an Audiophile. Some people have it in their heads that the only "right" way to hear the music from a game is with the specific MIDI module the composer was using to make the music, those people can spend hundreds to thousands if they really want. SoundFonts work for pretty much anyone else, and your argument that one instrument might not sound right in a song of some game isn't a SoundFont problem. The exact same thing happens with real MIDI modules, listen to some recordings from a Casio GZ-50M, it has an interesting sound but once brass instruments start up, it sounds like someone making farting noises with a kazoo. With SoundFonts, you just load a different one and move on with your life.

Finally, 32bit x86 code doesn't run natively on ARM processors, but Apple's M1/2 emulation layer is pretty insane in how well it works. The problem with VSTs is they are designed around Windows, though you could use Wine to handle the Windows-specific calls allowing playback on other OSes or even CPU architectures. And a dev that will remain nameless other than having developed one of the projects talked about in this thread was braining storming and contemplating that very thing well over a year ago. There were major issues at the time that need to be figured out, but this isn't something that's just forgotten and nobody is working on.

Unfortunately this thread was wildly derailed in ways that really have nothing to do with the actual topic at hand. I'd like to ask if there are any updates on which one is the best build/etc of the VSTi host MIDI driver for modern OSes? At this point it's all gotten a bit mixed up for me as to which is the latest build that can be actually downloaded. I had three saved and am no longer even clear which is which as well as the rebuild DLL posted earlier for the low latency host.

I use the Arakula one and it works alright. He hasn't touched the code at all, since the discussion was last active.

Here's what's out on Github....

https://github.com/emtee40/vstdriver/forks?in … targazer_counts

Nazo wrote on 2023-06-27, 08:33:

Unfortunately this thread was wildly derailed in ways that really have nothing to do with the actual topic at hand. I'd like to ask if there are any updates on which one is the best build/etc of the VSTi host MIDI driver for modern OSes? At this point it's all gotten a bit mixed up for me as to which is the latest build that can be actually downloaded. I had three saved and am no longer even clear which is which as well as the rebuild DLL posted earlier for the low latency host.

There's actually no best version for all situations so far.
Arakula's version is the most stable but it has 2 major drawbacks:
1. It cannot save plugin settings.
2. It has a huge 500 ms latency.

DB50XG's version is not very stable but it cures the above mentioned 2 drawbacks of the Arakula version.
It has 1 major drawback besides stability issues:
1. In its current form it works only in ASIO output mode (so it requires a working ASIO driver).

The other forks have not added any meaningful features/fixes so far.

And all drivers inherited the problem of integrated Bass libraries. Kode54 decided to replace pure WinMM Waveout to Bass/Basswasapi right before the abandonment. I think it was a mistake.
Since VST Midi driver is an in-process driver it cannot use its own Bass libraries if the Midi client already uses some other versions of Bass libraries. More info:
Re: Yamaha S-YXG50 Portable VSTi (a software MIDI synth)
This is also true the other way around: If a Midi client uses VST Midi driver then it cannot use its own Bass libraries afterward since the libraries are already loaded to the client's address space through VST Midi driver:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

Both situations can cause subtle and hard to debug problems. This is the main reason why I do not recommend any of the current versions.

BTW, for the ones that still would like to use a somewhat more usable version of Arakula's driver (despite my warnings) I have made a modified version that cures the above mentioned 2 main drawbacks.
1. You can save plugin settings. In the folder of the VSTi plugin you should find a file with the same name as the VSTi plugin but with the extension of .set right after you close the configuration dialog. After you open the config dialog again and click on "Configure VSTi.." you should also see that your saved settings are restored. During Midi playback you should also hear that the saved settings are active. For testing I recommend a plugin that does not work at all without restored settings (such as my Munt VSTi or BassMidi VSTi plugins).
2. The latency is reduced to 50 ms.

@Edit2:
The version uploaded for this post is obsolete now so it has been deleted.
For the fixed Arakula version (the one this post is talking about) look at this post:
Re: VST Midi Driver Midi Mapper

For the fixed DB50XG version look at this post:
Re: VST Midi Driver Midi Mapper

Alright, thanks for the clarity. I had done a clean OS reinstallation and it was a confusion as to which driver was even which anymore. On the plus side in my case I'm using the Yamaha S-YXG50 plugin and someone made a modified version of it with all the settings pre-configured, but of course not all VSTi plugins have such an option available, so that is probably useful to a lot of people.

Hi,
Here is a new version which removes the dependency on Bass/Basswasapi and restores standard Wave Output.
So you can use Midi clients that use Bass libraries without problems (FSMP, KaraFun etc.)
Also fixed the installer problem on 32-bit OS versions (namely no uninstaller is created. Arakula's version is also affected).
Contrary to the previous version this one also supports Win XP.
Inherited from the previous version you can also save/restore plugin settings and the latency is reduced.
This time the full source code is included.

@Edit:
This version also has more precise Midi timings due to the using of timestamped Midi messages and waveOutGetPosition. The original Arakula driver and DBXG50's version dropped timestamps (more precisely Kode54 dropped it when introduced Bass/Basswasapi) so Midi precision depends on Bass update periods (5 - 10 ms at best but in case of ASIO it can be better or worse depending on ASIO buffer sizes).

Thank you Falcosoft for continuing to work on this useful program.

Ooh, thanks indeed yes for your hard work. Know that it is appreciated.

Will the WaveOut version conflict with things that use outputs such as DirectSound at the same time? I'm not sure exactly at which point Windows decides to lock an output device to a particular program. No problem when that's the only thing going of course, but if one is running VMs/emulators/etc I imagine it could be an issue?

Nazo wrote on 2023-06-30, 20:52:

Ooh, thanks indeed yes for your hard work. Know that it is appreciated.

Will the WaveOut version conflict with things that use outputs such as DirectSound at the same time? I'm not sure exactly at which point Windows decides to lock an output device to a particular program. No problem when that's the only thing going of course, but if one is running VMs/emulators/etc I imagine it could be an issue?

No, WaveOut is never exclusive since WDM drivers exist. You can have as many clients using WaveOut and Directsound output as you like (at the same time).

@Edit:
Meanwhile I have also fixed DB50XG's version. You can use it if you want really low latencies and you want to see the VSTi dialog and edit the VSTi settings during playback.
It can use ASIO, WASAPI shared and WASAPI exclusive modes. Only WASAPI shared mode can be used the same way as the above WaveOut version since WASAPI exclusive and ASIO (in most cases) are exclusive and cannot be used together with other audio clients.
Since it depennds on Bass libraries the above mentioned problems with Midi clients using Bass still holds.
It does NOT work with XP. Since only 1 source file had to be modified only this one is included. Full source is included.
Newest version actually works also under Win XP since WASAPI shared mode has a Directsound fallback through Bass. The only difference compared to Win7/Win10 that you should never close the VSTi editor dialog since it kills vsthost32.exe and sound output. Thus saving settings also works only if the VSTi editor is open (you should close the configuration dialog without closing the VSTi editor).

PS: I know this is not ideal ( I mean so many different versions) but it was not me who created the situation.
The 2 forks are so different by now that it would be hard to make a single version. I just fixed them to be as usable as they were intended to be.

@Edit2:
I have not noticed at first, but in DB50XG's version only PortA works, PortB simply remain silent. The exact reason requires further investigation.

@Edit3:
Port B is fixed now. Both ports can be used even simultaneously (the same way as in Arakula's version). Port name also added to VSTi dialog. Download has been replaced to new one.

@Edit 4:
Unfortunately this version has worse Midi timing/precision than the above WaveOut version because precision depends on Bass update periods. Bass update period is currently set to minimum (5ms) but in case of ASIO output precision depends on the ASIO buffer size. This Midi precision depends on Bass update period problem has already been fixed by Ian for BassMidi and by me in my Bass_VST version but unfortunately none of them applies to VST Midi drivers using Bass libraries.
More info about this Bass related problem:
https://www.un4seen.com/forum/?topic=18485.ms … 29797#msg129797
https://www.un4seen.com/forum/?topic=19639.ms … 37463#msg137463

Well, the forks are useful simply because they give us different roads to go down and sometimes those roads end up connecting back together in a new one.

Either way, we're all grateful. I've been largely giving up on S-YXG50 lately (especially in regards to telling others what to install) but this sort of thing makes the process a lot less painful and it looks like you've solved all the major and most of the minor problems. Now the only thing I'd want to see (which you likely won't want to even do anyway) would be just if it could have its own MIDI mapper (for an all-in-one solution) or set itself as device 0 (like MIDI mappers such as CoolSoft do.) I can understand if you don't want to do such a thing though, just wanted to plant the idea.

Nazo wrote on 2023-07-01, 01:52:

Either way, we're all grateful. I've been largely giving up on S-YXG50 lately (especially in regards to telling others what to install) but this sort of thing makes the process a lot less painful and it looks like you've solved all the major and most of the minor problems. Now the only thing I'd want to see (which you likely won't want to even do anyway) would be just if it could have its own MIDI mapper (for an all-in-one solution) or set itself as device 0 (like MIDI mappers such as CoolSoft do.) I can understand if you don't want to do such a thing though, just wanted to plant the idea.

Midi mapper is not a thing anymore in Win8+. So to emulate one you have to write a complete program with full logic. I do not even think it would have a place in a VST driver since it should achieve a completely different functionality.
It should install a new driver (VST Midi mapper?). But the same one already exists in the form of Coolsoft Midi mapper.

BTW I have fixed the Port B problem in DB50XG's version. New download can be found in the above post.

Yeah, I figured that was more than anyone would really want to do for this. Was worth asking. Either way, kudos to you for all your work on this. Just know that we do appreciate it.

https://devblogs.microsoft.com/windows-music- … -midi-services/

RetroGamer4Ever wrote on 2023-07-03, 19:33:

https://devblogs.microsoft.com/windows-music- … -midi-services/

According to the Github repo old school WinMM Midi should work even with the new Midi stack. Only Directmusic will be fully dropped.
https://github.com/microsoft/midi

Falcosoft wrote on 2023-07-03, 20:41:

Only Directmusic will be fully dropped.

If DirectMusic is dropped that would mean some early Windows 9x games like No One Lives Forever will stop working wouldn't it? Unfortunately, DOSBox and the like haven't quite caught up to that level of gaming yet, so I guess it would have to be VMWare or something non-gaming oriented like that for those. (Though NOLF may not be a great example anyway since it pretty much forced the Microsoft Synth somehow even if you had another device that supported DLS.)

@Falcosoft:
You just made the most useful posts in this thread since ages! Your updated drivers are a real godsend! I never thought I'd live to see the day we get a new version. For me it works like a charm, as it used to do in the old days. Thanks a lot!