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.