VOGONS


VST Midi Driver Midi Mapper

Topic actions

Reply 62 of 228, by RBretrox

User metadata
Rank Newbie
Rank
Newbie

Thank you so much Falcosoft, that has fixed the latency issue.

I think this is beyond the scope of Vogons and this thread, but I'll put it in anyway just in case.

I'm trying to recreate the core of my 90s music making set up as a kid, but in Windows 10. I could do it on an older latop, but its nice to have it running on a device I use daily.

My aim is to use the Yamaha SY50XG softsynth, an old sequencer application (Cakewalk Pro Audio 9) and XGEdit95 to tweak the sounds. I now have all applications working individually. The next stage is to get XGEdit to control the sounds while the sequencer triggers the notes.

If CWPA's output is the VSTmididrv then it'll play all instruments on their correct MIDI channels, but I can't get XGEdit to tweak the sound, even with loopMIDI running to link the two.

If XGEdit's output is VSTmididrv, with incoming MIDI notes from CWPA then everything is trying to only play on one single MIDI channel, so everything is pianos, or drums or whatever, rather than different instruments.

I'll keep experimenting.

Thanks everyone for the help with this.

Reply 63 of 228, by Nazo

User metadata
Rank Member
Rank
Member
RBretrox wrote on 2022-05-07, 07:25:

I'm trying to recreate the core of my 90s music making set up as a kid, but in Windows 10. I could do it on an older latop, but its nice to have it running on a device I use daily.

Perhaps it would make sense to do all this in a VM (which could run Windows 98SE or whatever suits you best) -- this would also have the advantage of being able to transfer from machine to machine as you go. Since your goal is actually relatively uncomplicated in regards to emulated hardware/etc requirements, I think it should probably be pretty easy to setup in just about any major VM software including even the open source ones. DOSBox-X is even capable of running Windows 9x extremely well these days, but since you're not worried about emulating gaming hardware and such you could use VMWare, Bochs or just whatever.

Reply 64 of 228, by RetroGamer4Ever

User metadata
Rank Oldbie
Rank
Oldbie

I'm reinstalling the VST MIDI Driver. After I installed the optimized library from Mr. FalcoSoft, it apparently stopped being detected by the Coolsoft MIDI Mapper and all programs. I didn't realize it until this morning, because I forgot to test it with game MIDI after I manually installed the new library and have been using the VST function of FSMP to enjoy MIDI files. I've uninstalled the driver and will reinstall it, but replace the unoptimized library with the optimized one, before I reboot the system and load the driver for the first time.

Reply 65 of 228, by RetroGamer4Ever

User metadata
Rank Oldbie
Rank
Oldbie

Even with a reinstall and the installation of the optimized library after reinstall, the VST synth doesn't come up in the MIDI manager or any other programs. I guess I'll go back to using the unoptimized library and see if that will get it recognized again.

Reply 67 of 228, by Trelokk

User metadata
Rank Member
Rank
Member

I assume there hasn't been any significant development in the meantime? Currently I am still using a loopMIDI + FSMP + S-YXG50 combination, but I am manually activating them since I don't need MIDI outside of retro gaming. Would still prefer a solution that activates and ideally also terminates itself on demand.

Reply 68 of 228, by RetroGamer4Ever

User metadata
Rank Oldbie
Rank
Oldbie
Trelokk wrote on 2022-11-12, 12:11:

I assume there hasn't been any significant development in the meantime? Currently I am still using a loopMIDI + FSMP + S-YXG50 combination, but I am manually activating them since I don't need MIDI outside of retro gaming. Would still prefer a solution that activates and ideally also terminates itself on demand.

Indeed, both forks of the VST MIDI Driver have been abandoned for almost a year or so. One was a minor fork that more or less worked and needed some tuning and the other didn't seem to work at all, despite frequent updating to fix/add stuff. Hopefully, one or more people will pick up the code and try yet again, but there never seems to be any real interest. I guess the roundabout solution you and others have been using is what many people are okay with.

Reply 69 of 228, by Nazo

User metadata
Rank Member
Rank
Member

Ultimately, long term, we're probably going to have to rely more and more on virtual machines for retro gaming. Though it's particularly stupid since that means running stuff like DOSBox in, of all things, a VM, which just seems silly. It would be nice if someone could convince them to implement VSTi support since that could open up a lot of possibilities or, better still, an actual XG emulator (this would be best for all as it could even be ported to other platforms and would retain maximum future compatibility,) but I get the impression that no one who is able to do such things cares enough to really look into it. I note a very distinct and strong lack of interest in general in MIDI beyond what has already been implemented in these things. To most it's "good enough" as it is. It probably doesn't help that the supposed "XG soundfont" exists out there even though it sounds wrong and awful. For now I guess the best results are to be had by running DOSBox within a Windows 7 VM.

Reply 70 of 228, by Trelokk

User metadata
Rank Member
Rank
Member

That SC-55 soundfont based on the original ROM isn't so bad, actually. There are a few others I have been using time and again, but in the end I usually return to a VSTi synth.

It's really frustrating that developing a new functional driver seems to be a bridge too far these days. Mudlord's solution used to be the best option for me while it was working.

Reply 71 of 228, by Nazo

User metadata
Rank Member
Rank
Member

I guess it makes sense that a SC-55 soundfont might come out ok. But some things like XG just end up horrible. Honestly I'm not sure an XG soundfont is truly impossible -- at least for GM and not GS or XG obviously -- just I guess people weren't interested enough in doing it to give it the time it needs even if so.

I think the real problem is MIDI is basically being abandoned. MS seems to be on course to eventually remove it entirely from Windows and people working on software like that just seem to have lost interest. I hope I'm wrong, but I'm thinking we may need to look into long term solutions that don't rely on the OS.

Reply 73 of 228, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
Trelokk wrote on 2022-11-16, 22:52:

Fun fact: The EAWPATS soundfont by Bashe is XG compatible since the original GUS patches also were. It doesn't sound anything like the XG50, but at least it works.

1. Unfortunately XG compatible single SF2 soundfont (even in theory) is not possible. While theoretically you can create a full SC-55 GS implementation with a soundfont (I mean the full program/bank combinations) you cannot implement even the XG Lite standard with an SF2 soundfont. The reason is the limitation of SF2 format itself. SF2 soundfonts use only 1 bank dimension so they can only use 128 banks that are usually addressable by Bank MSB. XG requires 2 bank dimensions (Bank MSB+LSB addressing, so 16384 possible banks). Because of this so called 'XG compatible' SF2 soundfonts can only achieve very limited XG compatibility. Namely they can contain XG compatible Drum kits at Bank MSB 127 and SFX sounds at Bank MSB 64/126. But since the lack of 2nd bank dimension in SF2 they cannot contain any variation tones that are available in XG by Bank LSB addressing.
So you have to make multiple SF2 files to handle all XG bank combinations.

2. And then there is the lack of XG specific effect engine in any known SF2 soundfont synths . That is almost entirely missing from Bassmidi, FluidSynth, SB HW synths etc. (with the exception of reverb and chorus effects).
So if you want to play with XG compatible Midi files/games I seriously recommend that you should not use SF2 soundfonts/synths.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 74 of 228, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
Nazo wrote on 2022-11-16, 01:30:

...
I think the real problem is MIDI is basically being abandoned. MS seems to be on course to eventually remove it entirely from Windows and people working on software like that just seem to have lost interest. I hope I'm wrong, but I'm thinking we may need to look into long term solutions that don't rely on the OS.

I do not think such removal will ever happen. First of all the core WinMM Midi APIs work the same way from Win 3.1 to Win 11. Considering the main API nothing has been removed so far. And recently new MIDI related services have been added to Win10/11 such as WinRT Midi API and Bluetooth MIDI. And adding Midi 2.0 support to Windows is also planned:
https://devblogs.microsoft.com/windows-music- … -midi-services/
Of course some of the Midi related built-in Windows tools and services are removed and abandoned such as the Windows Midi Mapper.
Windows Midi Mapper was at its peak at the Win 3.1 era. Even Windows 95 removed some features that were available in Win 3.1.
And with Windows 10 it is completely gone. But the Windows Midi Mapper was never integral part of WinMM API. It was only helpful but never necessary for properly written Windows Midi programs to work.
You can argue that DirectMusic is also deprecated and abandoned. Yes, but besides Direct3D all the other DirectX APIs are deprecated and abandoned now including DirectSound, DirectDraw etc.
Of course this does not mean that MS would like to prevent developers to use Midi, digital audio, frame buffer etc.

For the record Steinberg is much worse in this respect than Microsoft. You cannot get VST2 licences from Steinberg anymore and with the 'new' VST 3 architecture it's nearly impossible to write instrument plugins that can emulate legacy hardware.
Steinberg has really abandoned Midi in VST3 and you cannot use VST2 in new software legally anymore...
http://www.un4seen.com/forum/?topic=19769.msg … 38381#msg138381

So unless the DosBox team has already acquired a VST 2 license there is not much hope that the team can add hosting support for plugins such as SC-VA and S-YXG50 since these are all VST 2 plugins.

Last edited by Falcosoft on 2022-11-17, 08:47. Edited 1 time in total.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 75 of 228, by Nazo

User metadata
Rank Member
Rank
Member

The funny thing is, I don't think any actual games actually support the XG extensions. I always felt like the XG50 sounded possibly the best as a general purpose all-rounder for DOS/early Windows games, but that's more just in having the right balance of samples/etc. In theory this could absolutely be duplicated with a soundfont and there are a number that do try to be good all-rounders, just somehow I personally never found one that felt satisfactory. And, of course, that 4MB of actual sample ROM can easily be beaten by a really good soundfont which can easily go into hundreds of megabytes with no problems in software implementations, but SoundFonts always tend to end up on a case-by-case basis. Something that sounds amazing in one game tends to sound not very good or even bad in another. Though perhaps it all comes down to something even simpler still: game music was made with the synthesizers of the time in mind -- often really more for the lowest common denominator more than the highest in fact. Either emulation is bad (I never actually had a GUS if I'm being honest, though I certainly wished for one at the time) or I just haven't really found any games that sounded better using the GUS compared to the XG50 -- despite the fact they could use custom patches to the GUS. Well, this may be a matter of opinion of course, but I feel like most just weren't really composed with the assumption a lot of people would have a GUS because, frankly, not many people outside of certain scenes really did and that they just didn't put in tons of effort I feel like, so it still sounds better just with standard GM playing on the XG50.

I think most of the extensions of XG really only matter to those who do music compositions. After all, even if you just simply like a particular MIDI that actually utilizes all that, there's no reason you can't just record its output and compress that as a MP3/FLAC/whatever. It would be silly to keep jumping through hoops just to be able to keep listening to the same MIDI files when you can make an independent format that will work and sound exactly the same in anything with future proofing with zero effort.

I honestly don't really know why no one seems to have successfully created a SoundFont that can sound the same for plain GM. To be clear, in case it's forgotten: there is a XG50 soundfont out there. It had to be modified to remap to GM to be meaningful, but even then it just for some reason simply does not sound right. Everything sounds just enough off to be unpleasant. You can compare the same game/MIDI file with it versus S-YXG50 and the difference is just night and day. So I guess the XG50 must be doing at least a little bit of something even in full GM-only mode beyond just playing the samples directly.

Well, eventually MIDI support is going to die I think. Windows is dropping it slowly but surely and it was never exactly what I'd call great in Linux. Things like tablets and smartphones don't really truly have it in the first place, so it's software implementations only there and XG was never possible since the software synthesizers are 32-bit x86 binaries. It's kind of sad that it has never been possible in other architectures (outside of super extreme methods like emulating an x86 system running Windows with S-YXG50 installed, which is generally just not exactly something you want to do on a phone or a tablet just to run ScummVM or DOSBox or whatever.) I guess as current PC architectures move further and further away from any legacy compatibility in this regard we'll just have to revert to extreme measures like running an older Windows version inside a VM to run DOSBox/ScummVM/etc within that (though this may get tricky if they drop support for older OSes in later versions as they surely will eventually do.) I've been wondering about the viability of DOSBox-X running Windows 9x running S-YXG50 playing DOS games, but this is pretty messy and doesn't yield the best results.

I don't really know what the long term answers are honestly. Probably we just have to give up and rely solely on soundfonts with built in standard GM emulators long term and anything outside of the range of what those really do is just eventually going to go away.

Reply 76 of 228, by Nazo

User metadata
Rank Member
Rank
Member
Falcosoft wrote on 2022-11-17, 07:29:
1. Unfortunately XG compatible single SF2 soundfont (even in theory) is not possible. While theoretically you can create a full […]
Show full quote
Trelokk wrote on 2022-11-16, 22:52:

Fun fact: The EAWPATS soundfont by Bashe is XG compatible since the original GUS patches also were. It doesn't sound anything like the XG50, but at least it works.

1. Unfortunately XG compatible single SF2 soundfont (even in theory) is not possible. While theoretically you can create a full SC-55 GS implementation with a soundfont (I mean the full program/bank combinations) you cannot implement even the XG Lite standard with an SF2 soundfont. The reason is the limitation of SF2 format itself. SF2 soundfonts use only 1 bank dimension so they can only use 128 banks that are usually addressable by Bank MSB. XG requires 2 bank dimensions (Bank MSB+LSB addressing, so 16384 possible banks). Because of this so called 'XG compatible' SF2 soundfonts can only achieve very limited XG compatibility. Namely they can contain XG compatible Drum kits at Bank MSB 127 and SFX sounds at Bank MSB 64/126. But since the lack of 2nd bank dimension in SF2 they cannot contain any variation tones that are available in XG by Bank LSB addressing.
So you have to make multiple SF2 files to handle all XG bank combinations.

2. And then there is the lack of XG specific effect engine in any known SF2 soundfont synths . That is almost entirely missing from Bassmidi, FluidSynth, SB HW synths etc. (with the exception of reverb and chorus effects).
So if you want to play with XG compatible Midi files/games I seriously recommend that you should not use SF2 soundfonts/synths.

The funny thing is, I don't think any actual games actually support the XG extensions. I always felt like the XG50 sounded possibly the best as a general purpose all-rounder for DOS/early Windows games, but that's more just in having the right balance of samples/etc. In theory this could absolutely be duplicated with a soundfont and there are a number that do try to be good all-rounders, just somehow I personally never found one that felt satisfactory. And, of course, that 4MB of actual sample ROM can easily be beaten by a really good soundfont which can easily go into hundreds of megabytes with no problems in software implementations, but SoundFonts always tend to end up on a case-by-case basis. Something that sounds amazing in one game tends to sound not very good or even bad in another. Though perhaps it all comes down to something even simpler still: game music was made with the synthesizers of the time in mind -- often really more for the lowest common denominator more than the highest in fact. Either emulation is bad (I never actually had a GUS if I'm being honest, though I certainly wished for one at the time) or I just haven't really found any games that sounded better using the GUS compared to the XG50 -- despite the fact they could use custom patches to the GUS. Well, this may be a matter of opinion of course, but I feel like most just weren't really composed with the assumption a lot of people would have a GUS because, frankly, not many people outside of certain scenes really did and that they just didn't put in tons of effort I feel like, so it still sounds better just with standard GM playing on the XG50.

I think most of the extensions of XG really only matter to those who do music compositions. After all, even if you just simply like a particular MIDI that actually utilizes all that, there's no reason you can't just record its output and compress that as a MP3/FLAC/whatever. It would be silly to keep jumping through hoops just to be able to keep listening to the same MIDI files when you can make an independent format that will work and sound exactly the same in anything with future proofing with zero effort.

I honestly don't really know why no one seems to have successfully created a SoundFont that can sound the same for plain GM. To be clear, in case it's forgotten: there is a XG50 soundfont out there. It had to be modified to remap to GM to be meaningful, but even then it just for some reason simply does not sound right. Everything sounds just enough off to be unpleasant. You can compare the same game/MIDI file with it versus S-YXG50 and the difference is just night and day. So I guess the XG50 must be doing at least a little bit of something even in full GM-only mode beyond just playing the samples directly.

Well, eventually MIDI support is going to die I think. Windows is dropping it slowly but surely and it was never exactly what I'd call great in Linux. Things like tablets and smartphones don't really truly have it in the first place, so it's software implementations only there and XG was never possible since the software synthesizers are 32-bit x86 binaries. It's kind of sad that it has never been possible in other architectures (outside of super extreme methods like emulating an x86 system running Windows with S-YXG50 installed, which is generally just not exactly something you want to do on a phone or a tablet just to run ScummVM or DOSBox or whatever.) I guess as current PC architectures move further and further away from any legacy compatibility in this regard we'll just have to revert to extreme measures like running an older Windows version inside a VM to run DOSBox/ScummVM/etc within that (though this may get tricky if they drop support for older OSes in later versions as they surely will eventually do.) I've been wondering about the viability of DOSBox-X running Windows 9x running S-YXG50 playing DOS games, but this is pretty messy and doesn't yield the best results.

I don't really know what the long term answers are honestly. Probably we just have to give up and rely solely on soundfonts with built in standard GM emulators long term and anything outside of the range of what those really do is just eventually going to go away.

Falcosoft wrote on 2022-11-17, 08:20:
I do not think such removal will ever happen. First of all the core WinMM Midi APIs work the same way from Win 3.1 to Win 11. Co […]
Show full quote
Nazo wrote on 2022-11-16, 01:30:

...
I think the real problem is MIDI is basically being abandoned. MS seems to be on course to eventually remove it entirely from Windows and people working on software like that just seem to have lost interest. I hope I'm wrong, but I'm thinking we may need to look into long term solutions that don't rely on the OS.

I do not think such removal will ever happen. First of all the core WinMM Midi APIs work the same way from Win 3.1 to Win 11. Considering the main API nothing has been removed so far. And recently new MIDI related services have been added to Win10/11 such as WinRT Midi API and Bluetooth MIDI. And adding Midi 2.0 support to Windows is also planned:
https://devblogs.microsoft.com/windows-music- … -midi-services/
Of course some of the Midi related built-in Windows tools and services are removed and abandoned such as the Windows Midi Mapper.
Windows Midi Mapper was at its peak at the Win 3.1 era. Even Windows 95 removed some features that were available in Win 3.1.

Don't misunderstand me. MS clearly considers it to be a minimum legacy requirement and won't actually remove it, but there is a difference between it being removed entirely and it just simply being depreciated to such an extreme as to be basically worthless for anyone not using it in extremely specialized ways. Extremely specialized... That means not things like DOSBox/ScummVM/etc. Less and less will be possible outside of those incredibly specialized and specific use-cases.

Also, don't forget that MS is dead-set convinced that no one would ever want to use anything other than their own none-too-great MIDI synthesizer. This is the biggest reason this entire thread actually exists. Fighting with getting Windows to do literally anything else at all outside of any of those ultra-specialized scenarios (which DOSBox/ScummVM/etc obviously is not.) It's getting harder and harder to actually do and eventually I think it will reach a point that you can't even install stuff like external MIDI mappers because they honestly believe people only want to use their synth.

Reply 77 of 228, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
Nazo wrote on 2022-11-17, 08:48:

Don't misunderstand me. MS clearly considers it to be a minimum legacy requirement and won't actually remove it, but there is a difference between it being removed entirely and it just simply being depreciated to such an extreme as to be basically worthless for anyone not using it in extremely specialized ways. Extremely specialized... That means not things like DOSBox/ScummVM/etc. Less and less will be possible outside of those incredibly specialized and specific use-cases.

Also, don't forget that MS is dead-set convinced that no one would ever want to use anything other than their own none-too-great MIDI synthesizer. This is the biggest reason this entire thread actually exists. Fighting with getting Windows to do literally anything else at all outside of any of those ultra-specialized scenarios (which DOSBox/ScummVM/etc obviously is not.) It's getting harder and harder to actually do and eventually I think it will reach a point that you can't even install stuff like external MIDI mappers because they honestly believe people only want to use their synth.

I feel you overestimate the problem. What is so extremely specialized about that required Midi In and Midi Out ports have to be explicitly selected? Explicit port selection in Midi software itself was the right way even from the beginning. But some Midi software decided that they omitted explicit port selection and always used the default one. These software has problems since Midi mapper has gone. But other software that allows users to select ports explicitly can work that same way in Win10 as in Win7/XP/Win9x. DosBox and ScummVM belong to the 2nd camp. They allow you to select your desired Midi ports explicitly and this works the same way on Win 8/10/11 as on Win7/XP/Win9x.
In DosBox you can use mixer /listmidi to get all the possible Midi out ports and then you can set the desired port number in dosbox.conf. And in ScummVM you can still select your desired Midi ports from the UI.
You do not need any Midi mappers for such direct port selections to work.

dosbox1.png
Filename
dosbox1.png
File size
18.6 KiB
Views
1370 views
File license
Public domain
scummvm1.png
Filename
scummvm1.png
File size
63.67 KiB
Views
1370 views
File license
Public domain

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 78 of 228, by Trelokk

User metadata
Rank Member
Rank
Member

At least for classic gaming, MIDI will always be relevant to some degree. Especially the Doom community has some very dedicated composers who are still producing really good MIDI music even now. I don't think the standard is going to die and MS cannot ignore it (and apparently won't). It's still a pity that they removed the Windows MIDI mapper in Win10.

As for that EAWPATS soundfont: It's true, I shouldn't have claimed it's XG *compatible*, but let's say "capable". It has mappings for the XG instruments, so it can at least play XG MIDIs. Ofc it would never even get remotely close to playback with an XG50.

Reply 79 of 228, by Nazo

User metadata
Rank Member
Rank
Member
Falcosoft wrote on 2022-11-17, 09:15:

I feel you overestimate the problem. What is so extremely specialized about that required Midi In and Midi Out ports have to be explicitly selected? Explicit port selection in Midi software itself was the right way even from the beginning.

While for me personally it's quite annoying having to manually select it every time, there's a much bigger problem: not everyone knows about this stuff. Most people don't even know what MIDI is. If I want to help someone get setup with DOSBox I wouldn't even begin to try to get them setup with anything but the built-in MIDI options because, let's be realistic, their eyes are just going to glaze over and they may even stop right there. It also makes it impossible to produce a single ready-to-use setup that uses any MIDI device that isn't built in because you simply don't know the result on any other system (in fact, it's distinctly possible it simply won't work consistently even across your own systems that you do know.) Even if I walked someone through the process of installing the VSTi driver and all the files necessary, I then have to walk them through the selection process as well and try to explain to them that it can change and they may have to redo things (remember the issue of the disappearing VSTi driver.)

But also, I think you missed something else entirely in what I was saying: I'm saying also that the current system WILL break. Even assuming that MS never eventually stops us from installing external MIDI options (which I point out is still a realistic possibility) what I mean is the actual software eventually will break as we move on to systems that lose legacy compatibility and can't be used at all on anything else but what they were intended for. For example, the S-YXG50 VSTi is a 32-bit x86 binary. It will not run on any ARM system unless you setup some sort of very complicated CPU emulation process for it (which I just don't see being a thing people would even do for MIDI.) Eventually we may end up in a scenario where even modern x86-type systems can't run 32-bit executables. Besides the obvious (someday far far down the road I presume we'd eventually move to 128-bit addressing, so then we'll lose 32-bit once we do) there is probably a more likely scenario that major changes might perhaps make 32-bit support even on 64-bit systems become undesirable such as processor extensions that break while 32-bit access is allowed or something of that sort of nature. While nothing specific of that sort is on the immediate horizon, it's distinctly possible. Just look at the way Intel was willing to let their Raptor Lake processors basically break in anything below Windows 11 or anything but the very latest Linux kernels. (Since the economy cores don't have the same extensions as the performance cores, the kernel must intelligently route commands to the correct cores. Sending higher extension commands to the economy cores causes things to crash and burn when they fail.) It seems that they're in a benchmark war (my Ryzen 5600X -- which is a "low heat" 65W TDP processor -- could hit 80C almost instantly under heavy loads such as encoding with the stock HSF and settings. And when I say almost instantly I mean LESS than one second and would go over 90C within mere minutes then start downclocking.) Not only is it realistic that compatibility with things people don't normally even think about could be lost -- such as MIDI -- but with the way things are going it could even happen in the near future. Right now it's impossible to really predict, but you must admit that MIDI is pretty darned low in the list of legacy compatibility considerations.

No I'm not saying all support for MIDI as a whole will go away, but, if we want to continue using it the way we have been -- such as for playing retro games with the sound the right balance of "as intended" and still being as good as it reasonably can be given the limitations of the mechanisms themselves -- we need to at least be thinking in terms of what might be done in such a future. And to be clear, I'm not saying "WE MUST FIX THIS NOW!!!ONEONEONE" I'm saying "loss of compatibility is on the future horizon, we should prepare in advance instead of waiting until after it happens."

Trelokk wrote on 2022-11-17, 10:09:

At least for classic gaming, MIDI will always be relevant to some degree. Especially the Doom community has some very dedicated composers who are still producing really good MIDI music even now. I don't think the standard is going to die and MS cannot ignore it (and apparently won't). It's still a pity that they removed the Windows MIDI mapper in Win10.

I don't really get your argument there. MS doesn't particularly support or in any way care if people are playing classic Doom. What's more, this specific use case is actually canceled entirely by the fact that virtually every major engine reimplementation of classic Doom (including the ones that try to replicated the original feel with no jumping or mouselook or etc on by default) support using external digital audio files -- meaning you can use what are basically recordings of the original MIDIs (available free online, just google them -- though none available online use the XG50 as far as I know) for music in the game. I think some modern distributions of it even already come with such audio files (and I know they have to in some implementations such as on the Switch which simply lacks any MIDI system in the OS entirely.)

But honestly, I think this is actually a great example of what I'm saying by accident even. Some of the most popular retro PC games have modern engine reimplementations. It's not all by a long shot, but it's enough to give them more leeway in deciding that they don't really have to care about loss of legacy support in regards to such things. Especially as more and more things implement their own MIDI system (such as DOSBox, which GoG bundles together with the retro games they sell for example.) In fact, in most cases, the only way to legally actually get retro games new (excluding buying old copies on eBay -- most of which are used of course) is where they would probably have it bundled or modified in such a way that it implements a more modern music handling method. Naturally there are tons of games not included in that list for various reasons (including many that can't be legally sold,) but companies like Microsoft already have a pretty strong tendency to not care about legacy support, so with the former excuse it's pretty much enough in their minds to just simply not even care (just take a look at the mess that is NTVDM. It's pretty much a bare minimum implementation with no cares given for the myriad of things that simply don't work with it.)

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.