Also means it can be avaiable in standalone, VST3, AU, AAX, CLAP formats too

32 bits is indeed a limitation, but replacing samples in s-y50xg seems to already be a solved problem, with ymf-754 HiEnd, TyRUS and Vampire being a thing.

So it should be as simple as comparing the samples from the table with the samples from the rom, matching the stuff up, and adjusting the metadata if needed to account for the new sample sizes.

I'm probably missing something.

I'm also trying to get a straight answer to the question of do the different units all have the exact same effects, even though they have different effects processors. I know it's a cut down version of AWM2, and that yamaha has a software only version of AWM2, and if you buy a hardware synth that uses it, they give you the software in VST form!

https://usa.yamaha.com/products/music_product … odxm/index.html

I suspect that this E.S.P. for Montage M vst is actually what was used to create the s-y50xg. Of course the download for said vsti is much larger than the s-y50xg.

And yes, the montage M can be put into a mode that plays XG midis fine.

I meant the VST2 itself is 32-bits (doesn't run on modern PC without a wrapper), the syxg50 wav contains 8-bit and 16-bit samples same as hardware MU50 ROMs do, although Yamaha might have re-arranged what is 8-bit and 16-bit differently for the same voices.

AWM2 is simply a synthesis method afaik, it is identical across hardware or software, there isn't different versions of it. As far as I needed to explore it, syxg50 is essentially Yamaha's SWP20 chip in C++ software and there's strong evidence it exactly replicates the digital hardware. The ROM of a hardware MU50 unit does work with it, but it's stored differently for hardware even if the data is byte-for-byte identical where it should be.

I'll share more. The .tbl is fully understood now and documented so this is a major milestone although I'm sure others have done this, but I've never seen them apply it to a new VST or Software host so that's my goal. But that means reverse engineering binary back to C++, it's a lot of work and slow. But it already plays audio and critically plays the right voice in the right place and sounds the same when A/Bing.

hockinsk wrote on 2026-04-23, 17:14:

I meant the VST2 itself is 32-bits (doesn't run on modern PC without a wrapper)...

Hi,
I do not want to be overly pedantic but this is not true. 32-bit dlls/plugins can be loaded by 32-bit Midi players/DAWS even on modern PC with the newest 64-bit operating system.
64-bit DAWS really can only load 32-bit plugins through wrappers but 32-bit DAWS can load 32-bit plugins directly even on 64-bit Windows.
Reaper, SAVIHost, or my Midi Player still have 32-bit releases besides the 64-bit releases.

No worries, i understand. I'm simply looking at it as a 32-bit VST2.dll for normal users not interested in making this work, will give up. I know because many have asked me why it doesn't work. The reality is VST2 requiring sysex to fully control it isn't really useable. In fact DAWs often don't even support sysex to the VST because sysex is now replaced, nobody uses it in VST SDK other than very specific requirements (often to control extendal hardware from a VST GUI).

hockinsk wrote on 2026-04-24, 08:48:

No worries, i understand. I'm simply looking at it as a 32-bit VST2.dll for normal users not interested in making this work, will give up. I know because many have asked me why it doesn't work. The reality is VST2 requiring sysex to fully control it isn't really useable. In fact DAWs often don't even support sysex to the VST because sysex is now replaced, nobody uses it in VST SDK other than very specific requirements (often to control extendal hardware from a VST GUI).

This kind of perspective is really reflected in VST3 and modern DAWs. You cannot even process program change messages normally in VST3. VST3 simply abstracted Midi away. This way it is really hard to write an emulator like VSTi plugin in VST3.
In this respect VST2 while really an older standard is much better to write emulator like virtual synths/plugins. You can get the real Midi byte streams from the VST2 host while in VST3 this is not fully possible.
And the truth is that contemporary Midi files and games themselves used SysEx messages to configure XG synths. So an emulator plugin and DAW environment have to support this kind of configuration mode since the best examples that can show how XG can really sound depend on SysEx messages. Of course a better GUI that besides SysEx messages also supports graphical controls to set parameters is not a problem but SysEx still has to be supported.
While it can be said that S-YXG50 is not ideal for DAW usage but the best aspect of S-YXG50 is that you can use it a a real XG synth. That is set it as an output device and it plays any contemporary Midi files/game music almost perfectly.
BTW, Cubase (at least older versions the supported VST2) Reaper, SAVIHost, and my Midi player etc. can send SysEx messages even to VSTi plugins.

Everyone seem to insist that the samples in the actual mu-50 rom are compressed, and that every sample in the s-y50xg is only 8 bits, while the actual hardware has higher quality compressed samples.

hence me wanting to see the softsynth actually using the same samples as the hardware.

I haven't seen a straight answer to this question.

I'm *also* curious if stuffing roland samples into it will make it sound like a sound canvas after a GS rest. 😀