That's probably the ADPCM. The ADPCM encoding is the biggest difference between S-YXG50 and the MU50. All the long samples, like the acoustic pianos, is always U8 on S-YXG50, but mostly ADPCM on hardware. Both formats are 8-bits per sample, but the ADPCM should come out with a lot lower noise, perhaps at the cost of some frequency response

until recently, it wasn't possible to decode the ADPCM accurately, any samples that used the running delta modes had issues. Like *very* recently, I had to rewrite my decoder yesterday based on tarboh's work

I don't have a good bar chart setup for this but here's the raw data for sample formats on the GM mode patches in GS mode across S-YXG50, MU50 and MU80
https://pastebin.com/un97i9My
The u16 samples used by S-YXG50 here I believe are mostly the same sine wave used at the very highest keysplits. MU50's equivalent sine is 12-bit

Oh. i see what's goin on now. 8 bit adpcm actually can store considerably more dynamic range than 8 bit uncompressed. so decompressing them to 16 bit wav is actually correct.

Now i'm curious what would happen if the tg300b bank and mt32 got replaced with roland samples converted to the xg AWM2 format. 😀

It would be awesome if someone could make one spftsynth to rule them all. one that plays back all xg and gs midis correctly, and uses either the GS or XG gm1 or gm2 banks depending on which of xg or gs was played back first. 😀

Has anyone seen these two variants of the S-YXG50 by OnjLouis? They seem to be interesting, especially the S-YXG2026 Hybrid.
S-YXG100-Hybrid --> S-YXG50 + S-YXG100 VL/PVL + SG
S-YXG2026-Hybrid --> S-YXG2006LE, but apparently fully XG capable, thanks to using S-YXG50 as fallback

I had no idea, but I'm gonna check out that first one. It looks like something I've been hungering for.

Interesting idea there, but I think what we really want is to extract the patches from 2006 le and replace the matching ones in s-yxg50, or to upgrade 2006 if it has more effects in it.

Keeping the S-MU2000 plugin up-to-date is almost impossible right now. The guy is doing commits on his Github with almost demonic speed.
Meanwhile: I'm using this in combination with the Doom source port Woof!. By default, it is doing GM MIDI resets (can be changed via config). Should I switch this to GS or it's irrelevant here?

MaliceX wrote on 2026-09-16, 17:31:

It's practically indistinguishable from my MU2000 now, from the past 72+ hours of A/B-ing various examples over the years.

Some of us have waited for this to exist for over 20 years and it's finally here! 🤣

But yeah, definitely emulating a full CPU, even with optimizations, is always gonna be heavier. But it's basically a substitute at this point. Was thinking of attempting to do a WASM build but after seeing the interpreter performance first-hand with the VST2 experiment, I'll leave that to someone else more willing to waste time 😁

Depending on what tarboh wants to do with it once everything is mapped to hardware emulation there is then opportunity to take that and refactor into pure native dsp equivalence and see a lot of performance improvement. This is exactly why I started MUXG2K a couple of years ago. Here's the rough picture:

On a single core, our native C++ engine runs a MU2000 reverb at ~250× real-time and a single held note at ~600× — roughly ~0.4% and ~0.16% of a CPU core respectively. Software Emulating the same on the real SWP30 chip costs ~45% of a core regardless of how much is playing, because the hardware processes every voice slot and its full 384-step effects DSP every sample whether they're used or not. So the native version is on the order of ~100–285× lighter for a single reverb or note, narrowing to ~5× only at full 64-voice polyphony — which is exactly why we use the emulator as an offline accuracy reference but ship the native DSP. For DAW use emulation is difficult because even if you want a single voice, really all voice slots are hitting the CPU, not just one.

We already know this, because you'll see SYXG50 is doing much of an MU2000, just natively and barely touching the CPU, so you expect 200 to 600x Realtime performance capability.

Main issues with s-yxg50 is the 16 bit loop offset limit, and only the variation effect block, and no insertion effects.

if it has all the effect blocks and effects added to it, as well as the bigger patch table, it would essentially be a mu2k. but that one is still a playback vsti, with no DAW contrrols.

I can't reply to PMs yet but thanks for the table Zaphod

YMF-754Hi looks like an early version of the Vampire engine. It's the same as a regular S-YXG50 table, but all offsets have been expanded to 32-bits. It's an important step, no doubt, but the tables are unmodified, so the two biggest chokepoints in the table format remain: Wavedata entries limited to 255 (it uses 247) and the 24-bit loop address (it's at 10MB out of 16MB)

Shame about the GS breaking in the later version. The Vampire table has a full GS program definition section, too, but it looks like they disabled the GS bank definitions intentionally because they weren't addressing correctly

So can you fit the mu80 in without popping?

btw there are two other engines. the 2006 le engine which is xglite only, and an even later engine, but it only comes with a SINGLE lousy sample.

If anyone can figure out the latter ones bank format.....

what you are looking for is S-YXG2011EE.exe
oh. this apparently just loads a single instrument, and comes with the expansion editor. so it know show to play back a single voice. but it likely has a reasonably complete AWM2 engine inside it.

I have SYXG50 reverse engineered into C++. I did most of it 2 years ago when scoping if it could be modified to use decoded MU2000 voices and realised it was only capable of 2 element voices so stopped digging. I think it should compile into a VST3 or CLAP no problem. Would need more work on the Effects. I'll see if I can finish it today.

It should easily be possible to add the missing samples from the later device roms and the extra insertion effect blocks.

the mu80 apparently only has one insertion effect, which is a dedicated distortion block. at least according to the manual. mu-50 is missing this distortion block. But this distortion block plus eq is the exact same one from the mu80 variation effect block, so it can 100% be implemented in a reverse engineered vst2/3/clap/au/etc.

all of the later synths i can find's extra insertion effect blocks are just a copy of the mu80/50 variation effect block, while the variation effect block on the later synths has more effects available. sometimes significantly more. These are of course not present in s-yxg50. s-yxg50 has the variation effect block, it just doesn't have the additional variation effects from the later synths.

This is why S-YXG2011EE needs too be checked for implementation of the other components in the variation effect block. Either it does have them, and we can use the two to create a very nice vsti, or it does not, and it's useless.

It should be easy enough to use that source to create a 100% functional vsti for mu50 and mu80, and allow it to reads the actual wave roms.

Go ahead and call it s-yxg50 HiEnd and s-yxg80. 😀

Could a 64-bit version of the plugin be created as well while you are at it?

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.

Good point. so it should be a mu50 and mu80 solution because after a quick upgrade it can definitely do both, but it is missing support for later synth stuff, so you would have to add the newer effects in..

SO for a low end system, the standalone and vst2/3/clap plugins made from s-yxg50 would be a high performance solution, while your project will use bettter quality stuff from the mu 2000.

also, it seem s-mu2k is getting it's own native mode, and it's being heavily worked on now.

All the MUXG2K FX and AWM2 from MU2000 are now pure native C++ DSP, there's no swp30 emulation at all, so I think, between both, I can fill any gaps hopefully and so just match the FX needed against the ROM loaded. I like the idea of offering a barebones VST3/CLAP/AU/AAX you load the ROM and it gives you those, just with everything exposed to CC and HOST controllers with state saving so everything recalls with the session.

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.

Here's what would be useful.

1) standalone that listens on up to 4 ports. works with anything that can use virtual midi cables (dosbox, midi players, etc).
2) CLAP plugin for the wrapper and vst system driver, or direct integration into midi players.
3) others strictly for DAW use only but you want your project for daw use anyway. so there should just be a standalone with virtual midi support on windows, system midi support in linux, and a clap plugin compatible with the wrapper