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.