MaliceX wrote on 2026-09-14, 16:06:

Given the CPU usage I doubt an era-accurate PC from WinXP or earlier days would be able to play music with S-MU2000 in real-time 😁

Yeah I noticed that CPU-usage too, after writing that. MU2000 has one 3,5GHz core 90% saturated, two other cores approx. 60%.
There was a commit today about limiting the amount of slave threads proportional to the total core count. Have not tested that yet.

Mine is not an era-accurate system. Still, browsing while playing midi gave sound hickups at times.
Have to check how it compares against Mame MU50 in that regard...

Note: actually did not edit this post, wanted to add a reply instead, but wrong button...

gerwin wrote on 2026-09-14, 16:55:

Yeah I noticed that CPU-usage too, after writing that. MU2000 has one 3,5GHz core 90% saturated, two other cores approx. 60%.

S-MU2000 build from current source (commit 4ab6317):
CPU usage is different now, much better, I have like one CPU core at 25% and two at 15%. Excellent!
Also synth startup time is much reduced, it is ready within 2 seconds.

A new sin-table.bin needs to be generated with make_standins.py. I updated the MD5-hash in the file list above.

I just use the one from MAME. Any reason i should not do so?

zaphod77 wrote on 2026-09-14, 22:43:

I just use the one from MAME. Any reason i should not do so?

sin-table.bin you mean?
If you look at the translated commit history of the past hours, it is mentioned that sin-table.bin was changed for some reason. I cannot check now what he wrote exactly.

Edit:
https://github.com/tarboh/S-MU2000/commit/addadd5
"The sine table substitute was modified to rise from the center 0x8000 to a peak (deep chorus noise)."

But maybe original hardware one is preferable...

oh wow, this now supports all four midi in ports. so you can now actually play back four port xg midi files. 😀

This is getting really darn impressive now

MaliceX wrote on 2026-09-14, 16:06:

Given the CPU usage I doubt an era-accurate PC from WinXP or earlier days would be able to play music with S-MU2000 in real-time 😁

MaliceX, Thanks for the work on the 32-bit JIT, as available on your GitHub.
I actually made it work in Windows XP x86 today. Had the feeling I better try it now before S-MU2000 codebase becomes bigger and maybe harder to port.
GUI.exe has some shutdown problems: saving of NVRAM and closing all its threads, GUI display and sound is fine.
Console program Live.exe works fine (but also does not save state at shutdown, not that important)
IMGUI backend changed from DirectX 11 to DirectX 9. Audio changed from WASAPI to Windows Waveout.

Edit: with up-tempo tracks I notice slight midi timing issues. So sound is not entirely fine with this experimental build...

For gaming this is still a bit heavy on the CPU side. From the changelogs I figured there's something like a "Lightweight Mode" which apparently calculates the effects natively in C++ instead of going through the emulated ROMs - less faithful emulation in return for better performance. I couldn't find the option in the GUI of the plugin itself, though. Does it require gui.exe (which I don't use since I am loading the CLAP plugin via VST wrapper into Falcosoft MIDI Player/VST MIDI Driver)?

edit %LOCALAPPDATA%\S-MU2000\plugin.ini to change the plugins. right click the gui.

Trelokk wrote on 2026-09-18, 06:50:

For gaming this is still a bit heavy on the CPU side. From the changelogs I figured there's something like a "Lightweight Mode" which apparently calculates the effects natively in C++ instead of going through the emulated ROMs - less faithful emulation in return for better performance. I couldn't find the option in the GUI of the plugin itself, though. Does it require gui.exe (which I don't use since I am loading the CLAP plugin via VST wrapper into Falcosoft MIDI Player/VST MIDI Driver)?

Besides "lightweight effects" there is also this now:

gui.exe / live.exe: --native-engine
​​VST3/CLAP: Set `native_engine=1` in `%LOCALAPPDATA%\S-MU2000\plugin.ini`
(Add this after startup is complete; firmware is required for startup.)

It is a welcome feature indeed. It seems like it is now becoming a hybrid mix of say Nuked SC55 and emusc, but for the MU series of course.

Very useful piece of info! I've checked my %LOCALAPPDATA% folder and didn't find a plugin.ini there, though. Maybe it's somewhere else? I am only loading the CLAP plugin through the Falcosoft MIDI Player and the VST MIDI Driver, if that matters.

I think you just have to create the file yourself. there's no header, so you make it and just add the options you want to it

I see. So after creating a text file called plugin.ini, containing the line

1native_engine=1

I have this now in log.txt:

1plugin.ini: native_engine=1 (run SH-2 only when needed)

I assume this means the entry is recognized and used. However, when testing this in the MIDI player, all kinds of strange anomalies occur, e.g. instruments suddenly changing their volume, randomly drowning voices etc. My guess is this feature is still WIP, so I'll avoid it for now.

Are there any other interesting entries for plugin.ini?

there are a few others listed in the docs, but not sure they are any use.

yes, it's still WIP.

I made this:
Windows XP x86 Compatibility of live.exe
https://github.com/Gerwin2k/S-MU2000-XPmod
Binary live.exe is there too.
Also, console text is in English.
It works on my Core i5-3550 system reasonably well.

Parameter "--native-fx-full" is recommended for a small decrease in CPU usage.
At least, for this 32-bit build.
Parameter "--native-fx" did not give such benefit and "--native-engine" is unfinished.

I wonder at what point a release build will exist? Commits are still coming at a crazy high rate.

Right now it doesn't make any sense. By the time you are building, it's likely the AI is already working on the next commit. As long as it is this heavily WIP, it's hard to keep up.

Maybe a daily build can be created at some point, but if you want to stay up-to-date, you would need something like hourly builds, rather.

I think the sound generation adjustments have stabilized for the time being. I am currently working on implementing the GUI controls for the various parameters, though I sometimes encounter further sound-related bugs during this process. Moving forward, I plan to develop the features necessary for using this as a plugin, such as a method for recording parameter automation.

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.

Hi,

I just wanted to say thank you for your work on this — 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:30:

[cite o texto original do post do techouselgs aqui]

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!