Falcosoft wrote on 2026-09-18, 19:43:

I'm not sure if you realized that the guys you are talking with do not want to use the future 64-bit S-YXG50 in a DAW environmen […]
Show full quote

hockinsk wrote on 2026-09-18, 18:35:

Yes, it will be compiled to 64-bit. SYXG50 was built using the Steinberg VST2 SDK so all of that side of it is very easy to move over to VST3, SDK 64-bit and all the goodies that brings. I have a loose idea to offer the plugin, you pull the ROM you want from an MU and it just loads it, but MUXG2K is the priority because that's been 2 years solid work now.

I'm not sure if you realized that the guys you are talking with do not want to use the future 64-bit S-YXG50 in a DAW environment but for playing legacy MIDI titles and games. Your 64-bit VST 3 idea will be a disappointment for such gamers since no known VST hosts used by them (e.g. SAVIHost, the only widely used host by them that supports VST3 natively) will be able to use the VST programs abstracted away from raw Program Change messages by VST 3 properly. They will hear wrong instruments on all channels. Not to mention using oxF5 port select messages or any other Midi messages that VST 3 cannot transfer properly:
https://github.com/tarboh/S-MU2000/issues/24
VST3 is the only format that cannot transfer raw Midi streams. So much for the advantages and all the goodies that VST 3 brings. So CLAP format is a must instead. Theoretically I could run a branch and recode to old x86 without all the goodies being used post 2013 in CPUs, but it's not a priority.

Must gamers run 32-bit VST2 at all for gaming? Wouldn't most use modern 64-bit machines and emulate 32-bit games instead? I'm all ears if I'm mistaken, but I would assume they would just use the .exe standalone version instead of .vst3 or .vst2 ? I build in JUCE, so release to VST3, AAX, AU, CLAP (No SysEx restrictions), LV2, .exe and the user decides how they want to run MUXG2K. Theoretically I could develop a 32-bit pre-AVX2-era instruction set MUXG2K or SYXG50 but I'm not sure what it's gaining. If 32-bit gamers are playing on 32-bit machines, they already have a 32-bit official VST and real 32-bit drivers and hardware anyway?

.exe works fine

MUXG2K Reply Decoded:

7E 7F — Universal Non-Realtime, broadcast device
06 02 — Identity Reply
7D — manufacturer ID (MMA non-commercial/private — demix.me, deliberately not Yamaha 0x43)
00 01 — device family (demix.me)
01 00 — device member (MUXG2K)
01 00 00 00 — software revision 1.0.0

They have to use 32-bit hosts, because the (freely) available Yamaha and Roland VSTs are from the 32-bit era of computing and not the 64-bit, not including the last version of the Roland Virtual Sound Canvas. Many also choose to use older 32-bit systems and Windows for their retro-gaming and MIDI making. This is why we need to reverse engineer and tinker, to get everything opened up and transitioned to 64-bit software, so we can use it across the board and the people who want the old stuff can go their own way.

Most gamers will want to figure out some way to hook things up to their game. Which means it has to show up as a system midi port that games can see. I know the following ways.

1) use savihost with a vst2. i think there's also a vst 3 version. Use a virtual midi cable to hook it up. Requires that you fire up savihost instance before running the game. Advantage is you only have it running when you need to.
2) get a vst2, and use falcosoft vst midi driver, with or without the global proxy. this works with both 32 and 64 bit vst2. When not using global proxy, this loads an instance for each app that tries to access vst midi synth port a or b.. some plugins take too darn long to init (sound canvas VA). the global proxy would bypass that, and it will stay loaded.
3) integrate into dosbos as a CLAP plugin. This works fine with nuked, and probably works fine with s-mu2000 as well. 88Emu will have this going at some point most likely.
4) run standalone, and have the standalone use virtual midi cables. this is similar to 1 above, but less overhead most likely. works with s-mu2000 and 88EmuPlayer, and future standalones can do the same thing.

Stuff that's yet to be developed that i'd like to see..

1) CLAP system midi driver. this would be like vst midi driver, but accepts a CLAP plugin, and provides midi ports that can be seen by games. t would have a global proxy mode, and the ability to disable per app creation.
2) vst3 system midi driver. probably useful as well, though much more annoying to make probably, compared to CLAP, which is designed with MIDI in mind.
3) genuine installable driver for a midi softsynth, like the old wdm xp s-yxg50. You install the driver in device manager, and then any game that looks for midi ports will see it. I think this is a case of "good fricking luck" but it would be nice.

VST2 provides the most options, but it's limited to 16 channels. I'm not sure any game actually uses multiport midi files at all, so i'm not sure vst2 is even a limitation for that use case. If any games do play 32 or 64 channel midi over the serial /usb on a tone module, please say what they are.

With the clap to vst wrapper, a clap plugin allows choice 1,2,and 3 above. however a 32 bit vesion MUST be available for retro gaming systems.

Most games expect either an MT-32, a sound canvas, which is either an sc55 or an sc88(pro) depending on how new the game was, or an XG level 1 synth. The only game i know of that uses xg is final fantasy vii pc. i think 8 might also make some use of it. I would like to see a list of games that use XG midi.

A few Japanese games used XG MIDI, but outside of the Asian territories, the only ones I know of that used it were FF7 and FF8, with FF8 only being compatible with the DirectMusic implementation of XG, which requires a special version of the XG soft-synth or a patched DirectMusic-hook version of the older XG soft-synths that were out when FF7 was released. On paper, it's possible to use FF8 with XG hardware, but it requires the hardware unit to be visible to the DirectMusic software, just as the older XG soft-synths had to be patched to be visible to it.

Sounds like VST2 is used primarily because it offers the SysEx support needed, SAVIHost etc just wraps a 32-bit VST2 into a 64-bit.exe wrapper which provides the midi I/O and audio I/O. JUCE Standalone on MacOs, Windows and Linux is the way to go. I bundle ASIO, JACK, WASAPI/Windows Audio /CoreAudio and DirectSound for the audio side and Windows 11 has the new midi services support coming soon, so 3rd party midi drivers are probably not needed and a thing of the past then. Just add a Windows midi loopback and all is well, you can route anything to anything else natively then.

There are 32 and 64 bit versions of savihost. You use the one that matches your vsti,

Most of them are 32 bit. But latest sc Va is 64 bit. A32 bit vsti will run on 32 bit windows which is retro. It will also run on 64 bit. But I still need to know if any games use multiport midi or TO HOST and cable select

Sure, you either bridge 32-bit to 64-bit or host like-for-like. Either way using a dedicated .exe is the way to go. Once MUXG2K is finished i'll look at something more gaming-specific. Sounds like it just needs to be an MU2000 in an .exe which will contain every XG voice at the expected msb/lsb/pgm, very low UI requirements, full sysex and midi support and be as efficient as possible. The midi side is I think going to be easy in Windows 11. The latest beta i'm running allows very easy routing too.

Yamaha devices understand a abuse of the midi 1.0 spec they call "cable select", which when used with the serial interface, allows sending two bytes to change which internal port all following midi data goes to

This does not work outside of user mode drivers in the windows midi API, because these don't exist in the midi 1.0 spec.

Fortunately i found a virtual midi cable that's compatible. it's Midi Yoke New Generation, made by the person that made SaviHost.

RetroGamer4Ever wrote on 2026-09-19, 16:57:

A few Japanese games used XG MIDI, but outside of the Asian territories, the only ones I know of that used it were FF7 and FF8, with FF8 only being compatible with the DirectMusic implementation of XG, which requires a special version of the XG soft-synth or a patched DirectMusic-hook version of the older XG soft-synths that were out when FF7 was released. On paper, it's possible to use FF8 with XG hardware, but it requires the hardware unit to be visible to the DirectMusic software, just as the older XG soft-synths had to be patched to be visible to it.

Agreed, hardly any XG-aware games, but obviously gamers were not aware they were just playing the GM mapped voices on an XG sound card or daughter board. This is the lines I'm thinking. Take the standard XG/GM voices into a leaner .exe and bundle system midi driver that installs with it.

All the references i've seen say that falcom made some, but i've lteralyl only found one actua falcom xg midi file.

https://web.archive.org/web/20051124145043fw_ … sc/ssc101xg.mid

And it likely was not the one from the game.

So i would like someone to confirm that other game exist that actually need more than xg level 1.

If no such games exist that need more than 16 channels and more than xg level 1 effects, then a simple plugin can be made for game usage only.

A number of games have general midi soundtrack options that are optimized for the db50xg, but that's not the same thing as actual XG midi.

Demonstar is confirmed to have a few XG midis in it, and i'm guessing they were composed for XG Level 1.

I know the final fantasy 7 was 100% composed for XG level 1, with no insertion effects. i hope other people can track down stuff. all those dos games that gave waveforce/db50xg as a midi driver option were actually just yamaha optimized GM files. Maybe soem of them actualyl use XG effects, but if so, they are nothing s-yxg50 can't handle.

Okay it seems the mu2k actually does all of it's effects in all effect blocks. earlier synths ALL just use a mu50 variation effect block for the other blocks, but the mu2000 jp manual proves that that's not the case for the mu2k.

Clearly, the mu2000ex is the best yamaha xg synth of all time.

I have some new info on s-yxg50.

Turn out ff7 soudntrack reveals a bug in it.

Even with actual mu-50 rom sample data stuffed into s-yxg50, there is a weird high pitched "shink" noise at the end of the first woosh in bombing mission.

This either does not happen, or is much quieter on actual hardware and actual emulated hardware. for the former, there are videos on youtube.

I am no longer even sure that it's worth using s-yxg50 as a base for anything. It's still worth having a better integration, but dumping mu50 waveforms into it does not actually make it an mu50, and the final fantasy vii soundtrack proves it.

I do still like the idea of ymf-254 HiEnd, though, and think a custom table with samples from multiple yamaha mu synths, could create something very nice.

If you could isolate the instrument that's screwy that would be helpful

The 2MB version of S-YXG50 is kind of it's own beast. All the voices are 1 element only, so a lot of it sounds very different. Still uses some 16 bit waveforms though

it's starship, and it's wrong in s-xg50.

here's the midi file.

https://gifx.co/music/Game%20MIDI%2F-%2 ... ission.mid

when played on s-y50xg, there's s a weird sound at the end of the woosh, created by Starship and messing with xg parameters. when played on an actual mu50 or mu80, or s-mu2000, it does not happen.

I was hoping your converter would fix it, but no dice. the high pitched sound is still very audible, and that does NOT happen with actual recordings from real hardware.

https://youtu.be/Ii2h9yWAKzw?list=RDIi2h9yWAKzw&t=344

https://www.youtube.com/watch?v=49ibqCOVKsg&t … gcJCTEAlc8ueATH

This isn't a fault in your converter. it's a fault in s-yxg50 itself.

Okay the instrument itself is working correctly I think, that's what the SFX starship is supposed to do when you lay on it, like it "takes off". The problem is it's supposed to key off before that high pitch part plays
Could be a difference in how the S-YXG50 receives and processes midi commands. Seems to work correctly in foo_midi

zaphod77 wrote on Today, 02:03:

it's starship, and it's wrong in s-xg50. […]
Show full quote

it's starship, and it's wrong in s-xg50.

here's the midi file.

https://gifx.co/music/Game%20MIDI%2F-%2 ... ission.mid

when played on s-y50xg, there's s a weird sound at the end of the woosh, created by Starship and messing with xg parameters. when played on an actual mu50 or mu80, or s-mu2000, it does not happen.

I was hoping your converter would fix it, but no dice. the high pitched sound is still very audible, and that does NOT happen with actual recordings from real hardware.

https://youtu.be/Ii2h9yWAKzw?list=RDIi2h9yWAKzw&t=344

https://www.youtube.com/watch?v=49ibqCOVKsg&t … gcJCTEAlc8ueATH

This isn't a fault in your converter. it's a fault in s-yxg50 itself.

The difference is the starship sample itself. This has nothing to do with XG parameters (btw, only the pan controller is changing when starship is played by the Midi file). The instrument/sample sounds differently by default even after an XG reset.
Here are 2 mp3 files that demonstrate how the starship instruments sounds on S-YXG50 vs. S-MU2000 when it is fully played from start to end without interruption. As can be heard that high pitched part is really part of the sound but it's much louder and starts somewhat earlier on the S-YXG50 than on the S-MU2000. So this is not a bug with the engine. Changing the instrument/sample should fix this.

then how come when i dropped the mu50 samples into s-yxg50 it *still happened*, but it doesn't happen on the actual mu50?

actual mu50.

https://youtu.be/Ii2h9yWAKzw?list=RDIi2h9yWAKzw&t=344

it keys off before the sound.

but in s-yxg50 it doesn't.

And even when i drop the actual converted mu50 in, it doesn't cut off in time.

so something is off about s-yxg50 compared to the real hardware.

with converted mu80 rom, it is correct, and keys off on time. but with converted mu50 rom, it's wrong.

and yes i tested with foo_midi just now. same thing. real mu50 differs from s-yxg50, even with the mu50 samples dropped in.

I now think the right approach is to manually fix those super long pads from the mu80, removing just enough cycles from the samples so they fit properly and still loop correctly.

zaphod77 wrote on Today, 04:23:

then how come when i dropped the mu50 samples into s-yxg50 it *still happened*, but it doesn't happen on the actual mu50? […]
Show full quote

then how come when i dropped the mu50 samples into s-yxg50 it *still happened*, but it doesn't happen on the actual mu50?

actual mu50.

https://youtu.be/Ii2h9yWAKzw?list=RDIi2h9yWAKzw&t=344

it keys off before the sound.

but in s-yxg50 it doesn't.

And even when i drop the actual converted mu50 in, it doesn't cut off in time.

so something is off about s-yxg50 compared to the real hardware.

with converted mu80 rom, it is correct, and keys off on time. but with converted mu50 rom, it's wrong.

and yes i tested with foo_midi just now. same thing. real mu50 differs from s-yxg50, even with the mu50 samples dropped in.

BTW, the S-YXG50 WinXP WDM driver version does not produce the problematic harsh sound when the Midi file is played and sounds somewhat different even when played alone:

Maybe it's an aliasing problem in the VSTi version. It changes the sound noticeably when you change the playback frequency. At 22050 Hz is sounds good even with the VSTi version.

Very interesting. the syxg70 that came with ff7 was the 2 mb version as near as I can tell, and it sounds significantly different. you are correct that it does NOT do the bad sound. i found a video reference. https://www.youtube.com/watch?v=LSkuTPRanuk

however, did you test the wdm driver with the 4 meg bank, or was it with the 2 meg? because your sample sure sounds like the 2 meg bank.

There are two versions of the wdm driver from microsoft, the 2 meg and the 4 meg.

I also have distinct memories of phaze1.mid playing back differently on the sy70xg compared to everything else, with the intro wacky wave having a lot more portamento all over the place, where there's nearly none on everything els ei tried it.