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 reset. 😀

The samples in ALL old ROMplers are compressed, memory was at a premium. We know Roland compressed 2:1 in a companding style, other manufacturers appear to have done this to varying extents. Yamaha does this NOW (their wave ROM spec differs from the amount of RAM on board), but it's unclear what they did with the MU's.

From what mattw said in this thread, there was also 2:1 compression used by the MU50, which has 4MB of samples but uncompressed it is 8MB of wave ROM. Conversely, S-YXG50 has 4MB also, but that is uncompressed - so, half as much as the hardware (4MB vs 8MB ), presumably from being 8-bit instead of 16!

Putting Roland samples in won't make it a Sound Canvas because you would have Yamaha patches with Roland waveforms, and the patch structure wouldn't cross over anyway.

If you wanted the highest quality banks for XG ROM swapping, you'd hump an SW1000XG Pro Audio Card or an MU1000/MU2000, with all the expansion cards you could get, for additional sounds. Those are the hardware units that had the HQ samples, though I have no idea if either of those is superior to the other or if they are equivalent at the basic level.

Spikey wrote on 2026-05-01, 13:11:

From what mattw said in this thread, there was also 2:1 compression used by the MU50, which has 4MB of samples but uncompressed it is 8MB of wave ROM. Conversely, S-YXG50 has 4MB also, but that is uncompressed - so, half as much as the hardware (4MB vs 8MB ), presumably from being 8-bit instead of 16!

that's what i'm saying. i want the uncompressed samples from the mu50 slapped into the s-y50xg to make the true ymf-754 HiEnd.

And my idea would be to replace the yamaha samples that are used in tg300B mode with the roland samples, so when the softsynth got a GS reset, it would switch to using the GS samples. 😀

other good sources for high quality samples would be the tyros 2 kontakt instrument, the tyros 4 vsti, and the montage M vsti 😀

I've managed to extract the MU1000 ROM voices and metadata so I could compare to doing the same with the SYXG50. This is what I understand so far reverse engineering both now and reflects what others have already said about it:

The MU1000 is higher fidelity than SYXG50 in both rate and depth: 44.1 kHz output (vs 32 kHz native) and four storage formats including 16-bit linear and 12-bit packed (vs SYXG50's 8-bit / 16-bit only)

For those interested, I think this is valid statement:

SYXG50 stores all samples at a fixed native rate of 32 kHz, in either 8-bit or 16-bit linear PCM (with a custom biased-u8 byte encoding the DLL XOR-decodes at load time).
MU1000 doesn't have a single native rate, the SWP30 chip selects playback rate per-voice from its pitch register, with the chip output stage delivering 44.1 kHz stereo to the DAC. Stored samples use four formats: 16-bit linear, 12-bit packed, 8-bit linear, and 8-bit DPCM (Yamaha's adaptive format). All standard signed encoding, no biasing.

Here's where I am with the MU1000 ROM, which essentially has all the possible voices available and what I'll turn into a VST3, CLAP and AU 'MUXG' Rompler. I'm not interested in creating an MU1000 or even SYXG50 emulation, but I do want something I can just load an XG sound in a simple plugin in the DAW and it sound and behave exactly the same as a dry sound on the original. I'm not going to recreate FX, that's a whole other RE task. Besides Yamahas fx are really nothing unique and better quality fx can be found in a DAW these days.

MU1000 Rompler — XG v2.00 Feature Support
Channel Messages

• Supported: Note On / Note Off, Program Change, Channel Aftertouch (CAT), Polyphonic Aftertouch (PAT), Pitch Bend, Bank Select MSB/LSB, Modulation Wheel, Data Entry MSB/LSB, Main Volume, Panpot, Expression, Sustain Pedal, Resonance / Harmonic Content, Release Time, Attack Time, Brightness, Data Increment/Decrement, NRPN MSB/LSB, RPN MSB/LSB, All Sound Off, Reset All Controllers, All Notes Off, Poly Mode
  Inferred (deferred): Portamento Time, Portamento Switch, Sostenuto Pedal, Soft Pedal, Portamento Control, Omni Off, Omni On, Mono Mode
• Out of scope: Effect Send 1 (Reverb), Effect Send 3 (Chorus), Effect Send 4 (Variation)

NRPN Parameters

• Supported: Vibrato Rate, Vibrato Depth, Vibrato Delay, Filter Cutoff Frequency, Filter Resonance, HPF Cutoff Frequency, EG Attack Time, EG Decay Time, Drum Filter Cutoff, Drum Filter Resonance, Drum EG Attack Rate, Drum EG Decay Rate, Drum Pitch Coarse, Drum Pitch Fine, Drum Level, Drum Pan, Drum HPF Cutoff, Drum Velocity Pitch Sensitivity, Drum Velocity LPF Cutoff Sensitivity
  Planned (Layer 4 EQ extension): Drum EQ Bass Gain, Drum EQ Treble Gain, Drum EQ Bass Frequency, Drum EQ Treble Frequency
• Out of scope: HPF Resonance, EQ Mid-Bass, EQ Mid-Treble, EQ Mid-Bass Frequency, EQ Mid-Treble Frequency, Drum Reverb Send, Drum Chorus Send, Drum Variation Send, Drum EQ Mid-Bass, Drum EQ Mid-Treble

System Exclusive — System Data

• Supported: Master Tuning, Master Volume, Master Attenuator, Master Transpose, Drum Setup Reset, XG System On, GM System On, All Parameter Reset, Master Fine Tuning, Master Coarse Tuning
  Inferred (deferred): Display Data
• Out of scope: Multi Effect Data, Insertion Effect Data, AD Part Data

Multi EQ

• Planned (Layer 4 EQ extension): Per-part 2-band parametric EQ (Bass Gain, Treble Gain, Bass Frequency, Treble Frequency)
  Out of scope: 4-band EQ (Mid-Bass, Mid-Treble bands)

Multi-Part Parameters — Voice and Basic Config

• Supported: Bank Select MSB, Bank Select LSB, Program Change, Receive Channel, Part Mode (Normal / Drum / Drum Setup), Note Shift, Detune, Volume, Velocity Sense Depth, Velocity Sense Offset, Pan, Note Limit Low, Note Limit High
  Inferred (deferred): Mono/Poly Mode, Same-Note Key-On Assign
• Out of scope: Chorus Send, Reverb Send, Variation Send

Multi-Part Parameters — LFO, Envelope, and Filter Offsets

• Supported: Vibrato Rate, Vibrato Depth, Vibrato Delay, LPF Cutoff Frequency, LPF Resonance, EG Attack Time, EG Decay Time, EG Release Time, HPF Cutoff Frequency
  Planned (Layer 4 EQ extension): EQ Bass Gain, EQ Treble Gain, EQ Bass Frequency, EQ Treble Frequency

Multi-Part Parameters — Modulation Matrix

• Supported (all 36 source × destination routings): Modulation Wheel, Pitch Bend, Channel Aftertouch, Polyphonic Aftertouch, Assignable Controller 1, Assignable Controller 2 — each routing to Pitch, LPF Cutoff, Amplitude, LFO PMod Depth, LFO FMod Depth, LFO AMod Depth
  Supported: AC1 Control Number assignment, AC2 Control Number assignment

Multi-Part Parameters — Receive Switches

• Supported (all): Rcv Pitch Bend, Rcv Channel Aftertouch, Rcv Program Change, Rcv Control Change, Rcv Poly Aftertouch, Rcv Note Message, Rcv RPN, Rcv NRPN, Rcv Modulation, Rcv Volume, Rcv Pan, Rcv Expression, Rcv Hold1, Rcv Portamento, Rcv Sostenuto, Rcv Soft Pedal, Rcv Bank Select

Multi-Part Parameters — Pitch EG and Velocity Limits

• Supported: Pitch EG Initial Level, Pitch EG Attack Time, Pitch EG Release Level, Pitch EG Release Time, Velocity Limit Low, Velocity Limit High
  Inferred (deferred): Scale Tuning (per-note tuning offsets), Portamento Switch, Portamento Time

Drum Setup Parameters (per drum note)

• Supported: Pitch Coarse, Pitch Fine, Level, Alternate Group (mute group), Pan, Key Assign (single/multi), Rcv Note Off, Rcv Note On, LPF Cutoff, LPF Resonance, EG Attack Rate, EG Decay 1 Rate, EG Decay 2 Rate, HPF Cutoff, Velocity Sense Pitch, Velocity Sense LPF Cutoff
  Planned (Layer 4 EQ extension): EQ Bass Gain, EQ Treble Gain, EQ Bass Frequency, EQ Treble Frequency
• Out of scope: Reverb Send, Chorus Send, Variation Send, EQ Mid-Bass / Mid-Treble bands, Output Select (per-drum multi-out routing — SW1000XG only, not on MU1000)

Out of Scope (entire categories)

• Effects DSP: all reverb, chorus, variation, and insertion effect parameters and types — sysex silently accepted but no audio processing
  Audio input (AD Part): the MU1000's stereo line/mic input
  Multi-out routing: per-part / per-drum individual output assignment (SW1000XG feature)
  Vocal Harmony: requires the optional PLG100-VH board, not on MU1000
• 4-band parametric EQ: addresses reserved in spec but never shipped on any XG hardware

Yes, a mu 100 vst would be nice. but that doesn't remove the need for the best quality mu50 or mu80 vst2/vst3/standalone/CLAP

i know the s-y50xg is a mu-50 simulation, but it uses degraded samples. hence wanting higher quality versions. I was unaware that many of the samples were already 8 bit, though.

It seems there are different goals.

Yes the MU1000 samples were obviously re-encoded for higher sample rate at some point by Yamaha. The various bit-depths are just to save space for sounds that don't need 16-bit or benefit much from it. The VST Rompler will simply use a fixed 44.1khz 24-bit encoding. But there are several benefits over the hardware unit now possible in software and not the hardware chips.

The following is my readme.md and findings and what can improve over the hardware. It's generated by Claud AI, but based on what I propose as being possible in my spec.

Sample interpolation. The SWP30 uses a 4-tap polynomial interpolator with a 2048-step fractional position table. It's economical — a few multiplies and a shift per sample — but at extreme pitch ratios (small samples played at high notes, or vice versa) you get audible aliasing and a slightly grainy top end. Modern sinc interpolation (windowed, 32+ taps) or band-limited resampling makes pitch-shifted samples sound essentially perfect, no aliasing, no grain. Especially audible on bell, glock, and high piano notes which the MU1000 plays at large pitch ratios from compact source samples.

Filter quality. The SWP30's filter blocks are 16-bit fixed-point with no oversampling. At high resonance and low cutoff this produces audible quantisation distortion — the chip's own engineers calibrated the coefficient tables to mostly avoid it but resonant sweeps still have a characteristic "stair-step" quality. Floating-point filters with 4× or 8× internal oversampling eliminate this entirely. The same captured filter coefficients sound noticeably cleaner.

Bit depth and dynamic range. The chip works in 16-bit (sometimes 24-bit internal accumulator, but 16-bit at most stage boundaries). Float internal processing means no truncation noise, no quantisation between filter → envelope → mix stages. The noise floor of the plugin can be -140 dB; the MU1000's hardware noise floor is more like -80 to -90 dB on quiet voices, dominated by chip-internal quantisation rather than analog converter noise.

Output sample rate. The MU1000 produces 44.1 kHz fixed; you then resample at the audio interface. The plugin can render natively at the host rate (48, 88.2, 96, 192 kHz) so there's no resampling stage at all between the synth's internal computation and the audio buffer. Direct 96 kHz output captures harmonic content above 22 kHz that the hardware physically cannot produce.

Polyphony and CPU. The hardware is hard-capped at 128 voices (dual SWP30, 64 each). The plugin has no chip cap; modern CPUs run thousands of voices easily. So you never get voice stealing on dense MIDI files unless you choose to enable the cap for behavioural authenticity.

No bus-saturation artifacts. The SWP30 mixes 64 voices into a fixed-headroom 16-bit accumulator and clips when the sum overflows. This is audible as gritty saturation on dense passages. Float mixing with proper headroom never clips internally, only at the final output stage where you control it.

Stereo image and panning. The chip's pan is 7-bit (128 positions) implemented as fixed-point gain pairs. Float panning is continuous and uses proper equal-power curves; the stereo image is smoother and wider when modulating pan in real time.

No analog converter colouration. The hardware MU1000 has Yamaha's late-90s/early-2000s DAC at the output, which has a recognisable signature — slight high-frequency roll-off, mild low-bit-depth dither character. The plugin output is mathematically clean. (Some users will want the hardware character; an optional convolution/EQ stage can reproduce it if the goal is authenticity rather than fidelity.)

Modulation rate. The SWP30's LFO and envelope updates run at chip-block rate, not per-sample. This is fine but causes very slight zipper noise on fast modulation. Per-sample updates in software eliminate this.

Headroom for extensions. Things like per-note pitch bend (MPE), more LFO destinations, modulation matrix beyond XG's 6×6, oversampled non-linear waveshaping for "hot" voices, convolution reverb in place of the chip's algorithmic one — all trivial to add in software, impossible on the chip.

The general principle: anything that was a numerical compromise to fit 33.9 MHz of DSP budget per voice is now free. The voice character (which envelope shape, which filter mode, which sample, which LFO routing) lives in the captured register data and stays MU1000-authentic. Everything around that — the precision of the math implementing those choices — gets a substantial upgrade.

My goal is simply accurate and high quality playback of XG midi data. Which s-y50xg isn't quite, as i understand it.

Well if all goes to plan. there will be a Standalone, VST3, AU, CLAP and AAX 'MU-XG' of all XG voices ever possible and with faithful and improved audio quality and control that goes beyond what was ever possible le in hardware too.

I've begun JUCE development today. Hopefully I can get a skeleton synth working in standalone mode in the next couple of days as it's a bank holiday weekend off work here in UK. I'm also going to implement MIDI 2.0 control which will give audi-rate modulation capability. Something just not possible in MIDI 2.0 or in hardware. As the audio engine will run at sample rate, it brings some new things to the XG table never possible before. I'm going to keep backwards compatibility with sysex and midi cc, but obviously everything will also be exposed to the DAW now as plugin parameters too.

hockinsk wrote on 2026-05-03, 09:14:

Well if all goes to plan. there will be a Standalone, VST3, AU, CLAP and AAX 'MU-XG' of all XG voices ever possible and with faithful and improved audio quality and control that goes beyond what was ever possible le in hardware too.

Your goal is clearly different from zaphod77's. Your plugin will be more suited for creators in a DAW environment who wants to fine tune his/her own tracks. Since the original insertion effects, effects DSP etc. will be missing it clearly will not be the best fire and forget plugin for zaphod77 who mainly wants to consume existing Midi files/games with better overall quality.

hockinsk wrote on 2026-05-03, 09:28:

I've begun JUCE development today.

Be aware that by default VST3 instrument plugins created with the JUICE framewok cannot handle program changes from Midi input properly.
In VST3 Program changes are mapped to VST preset changes by default.
https://forum.juce.com/t/vst3-programs-and-mi … changes/35148/4
https://forum.juce.com/t/solved-vst3-and-pres … me-nuts/63951/3

I'm not particularly interested or focused on repicating midi and sysex. Modern DAWs dont' really use it and of course if its an audiorate modulating DAW you definitely can't use midi 1.0 or sysex anyway, it's too slow.