Hi @tarboh,

First of all, thank you so much for your work on S-MU2000 — it's really appreciated by the community.

I've tested it on my machine (Core i5 12th gen, 16 GB RAM, Windows 10) and it works great.

I have one question: would it be possible to port the code to Linux as well? I'd love to run it on a Raspberry Pi 5, ideally as an LV2 plugin (so it could be used in hosts like Jalv, Carla, MOD, Zynthian, etc.). No rush at all — I completely understand if it's not practical, but I thought I'd ask.

Thanks again for the great work!

techouselgs wrote on 2026-09-23, 14:39:

I have one question: would it be possible to port the code to Linux as well?

Before they introduced Linux GUI version a couple days ago I've tested CLI version and it was running just fine.
So you can build the program from the source code right now.
But get ready that S-MU2000 will put your Raspberry under heavy CPU load, for sure.

zaphod77 wrote on 2026-09-23, 01:14:

Currently native engine is unstable, and crashes with final fantasy vii midi files, such as bombing mission. native_fx seems stable, but the emulated effects are vastly superior, again revealed by that bombing mission file. ideally the native engine will get to the point that it sounds like the emulated engine for all of the ff7 soundtrack.

We identified and fixed the cause of the crash that occurred when the firmware component was running in native mode.

techouselgs wrote on 2026-09-23, 14:39:

Hi @tarboh, […]
Show full quote

Hi @tarboh,

First of all, thank you so much for your work on S-MU2000 — it's really appreciated by the community.

I've tested it on my machine (Core i5 12th gen, 16 GB RAM, Windows 10) and it works great.

I have one question: would it be possible to port the code to Linux as well? I'd love to run it on a Raspberry Pi 5, ideally as an LV2 plugin (so it could be used in hosts like Jalv, Carla, MOD, Zynthian, etc.). No rush at all — I completely understand if it's not practical, but I thought I'd ask.

Thanks again for the great work!

Thank you; I will keep up the good work.
I have incorporated improvements to ensure it runs on Linux as well.

I gave S-MU2000 a try the other day. It is very promising indeed, reminding me a lot of my old MU1000. CPU usage seemed all right on my system, about 20-25%, but this was also on a Ryzen 7 8845HS. Compatibility seemed to be good with the XG MIDIs I tested, and the VST3 version loaded just fine in Sonar after setting the necessary files up.

Going by the dumping process' use of the Yamaha's MU2000EX firmware updater, MAME source code, and my previous experience with the MU1000, it appears like one can dump and use the MU500 or Mu1000 wave ROMs (and LCD font ROM for the MU1000), then use that with S-MU2000. Alas I don't have said module anymore to test that theory on a real unit. 🙁

In any case this and other XG emulation projects are definitely catching my interest. Cheers for the work!

A/B-ing S/PDIF comparison from MU2000 hardware to S-MU2000, running out of differences. Can't seem to find anything anymore - it's basically a 99.9999% clone.

Emulated mode seems reasonable on my current cpu as well, and does sound very close to all reference videos i can find.

Currently most of the work seems to be being done on the DAW interface.

tarboh wrote on 2026-09-24, 14:45:

Thank you; I will keep up the good work.
I have incorporated improvements to ensure it runs on Linux as well.

I also much appreciate you work here. Yamaha DB50XG Daughterboard was my favority midi device for a few years, and I was beginning to miss it.

Noticed that CPU usage dropped to about 75% of what it was some days ago, so it runs comfortably in the background now (Testing it with live.exe --native-fx-full normally).

MaliceX wrote on 2026-09-24, 15:28:

A/B-ing S/PDIF comparison from MU2000 hardware to S-MU2000, running out of differences. Can't seem to find anything anymore - it's basically a 99.9999% clone.

Thanks for testing. Glad to hear that. Amazing achievement that it got so close.

it's all in japanese. is there any roadmap to build this as a linux alsa driver?

there is no driver build, but the project does build for linux now, and people have used it.

Just to clarify: Should I always do a GS Reset with the S-MU2000, even when using it with games like Doom, Descent or Duke3D which only use GM?

Trelokk wrote on Yesterday, 07:09:

Just to clarify: Should I always do a GS Reset with the S-MU2000, even when using it with games like Doom, Descent or Duke3D which only use GM?

Matter of taste really. Just depends on which instrument set you prefer. Note XG mode has two sets of instruments MU100 Native are the newer instruments, whereas MU Basic will use the older MU80 sounds.
For Descent, I generally prefer Yamaha drums...

Many "gm" midis use gs kits anyway, so i would recommend the GS reset.

but if the mid truly is gm, there should be no difference.

zaphod77 wrote on Yesterday, 15:51:

Many "gm" midis use gs kits anyway, so i would recommend the GS reset.

but if the mid truly is gm, there should be no difference.

In case of S-MU2000 the default program 0 drum kit after GM vs. GS reset is different. Doom sends its own GM reset at start so the pre-set default does not matter. But e.g. Duke Nukem 3D uses GS drum sets without sending explicit GS resets so pre-set GS can be useful.

So I guess keeping the GS reset should be fine. The Woof! port I'm using even has its own built-in setting for this:

1[0-3(1)] [Native MIDI] Reset type (0 = No SysEx; 1 = GM; 2 = GS; 3 = XG)
2midi_reset_type              2

I've set it to GS there as well, even though it seems a bit redundant to do it through the port and the VST driver, too. One thing is sure: When switching between GM and GS reset in MIDI Player, the instruments change considerably. GS seems to be the better choice IMO since it sounds more pleasant to the ear, but it may be a matter of preference/taste.

I updated the Windows XP x86 compatible build of S-MU2000 Live.exe. (No-GUI console midi synthesizer server)
https://github.com/Gerwin2k/S-MU2000-XPmod/releases/tag/0.2
It includes the recent decreased CPU-usage, obviously since It includes the whole synthesizer from upstream. Fixed --diag parameter functionality.

Okay, it seems the gm and gs default drums are different on xg devices that understand GS reset.

Any midi actually composed for a sound canvas is more likely to sound closer to correct after a GS reset.

Otherwise it will probably sound better after a GM rest.

zaphod77 wrote on Yesterday, 19:06:

Okay, it seems the gm and gs default drums are different on xg devices that understand GS reset.

Any midi actually composed for a sound canvas is more likely to sound closer to correct after a GS reset.

Otherwise it will probably sound better after a GM rest.

I am not as knowledgeable as you in regards to synthesizesr, but I remember this video, at minute 40:
https://www.youtube.com/watch?v=PF9ul5JFAH0
Suggesting it is more then just drums.

AS near as I can tell, it's just some of the drums.

and the tenor sax. maybe.

zaphod77 wrote on Today, 04:33:

AS near as I can tell, it's just some of the drums.

and the tenor sax. maybe.

Some guitarts are also affected. A good test Midi file is e.g. Grabbag.mid from Duke Nukem 3D.