It's my belief that thees missing ROMs (for the other supported moduels) does not exits. Nukeykt was not hesitant to post examples of the mkII up and running, that they have not done it for the others hint at some possibility that my belief is correct.

It might be so that because mkII now works the others should work as well due to being somewhat simular, but it's just a theory, a midi theory.

Github PR of the Pi4-capable optimized code is up for anyone wanting to give this a spin before it's merged (hopefully)!

Karmeck wrote on 2024-04-19, 08:12:

It's my belief that thees missing ROMs (for the other supported moduels) does not exits. Nukeykt was not hesitant to post examples of the mkII up and running, that they have not done it for the others hint at some possibility that my belief is correct.

It might be so that because mkII now works the others should work as well due to being somewhat simular, but it's just a theory, a midi theory.

If you look at the commit history of Nuked-SC55 related to SC55 mk1 integration you should realize that your suspicion is highly unlikely.
You cannot make such fixes/changes by pure guessing (not to mention that it seems there are many subtle differences). E.g:
https://github.com/nukeykt/Nuked-SC55/commit/ … e9a281bc037606e
https://github.com/nukeykt/Nuked-SC55/commit/ … 06dfbb1491aa35a
https://github.com/nukeykt/Nuked-SC55/commit/ … 8d50f979503d129

Eivind wrote on 2024-04-19, 10:36:

Github PR of the Pi4-capable optimized code is up for anyone wanting to give this a spin before it's merged (hopefully)!

Hi,
I have tried to compile the emulator with your changes to test the speed improvements on x86/x64 CPU but I could not with Visual Studio.
It seems the 'unused' attribute is gcc specific and is not supported by MSVC++ versions. So before the commits could be merged at least some conditionals should be added.

Falcosoft wrote on 2024-04-19, 11:09:

Hi, I have tried to compile the emulator with your changes to test the speed improvements on x86/x64 CPU but I could not with V […]
Show full quote

Eivind wrote on 2024-04-19, 10:36:

Github PR of the Pi4-capable optimized code is up for anyone wanting to give this a spin before it's merged (hopefully)!

Hi,
I have tried to compile the emulator with your changes to test the speed improvements on x86/x64 CPU but I could not with Visual Studio (2019).
It seems the 'unused' attribute is gcc specific and is not supported by MSVC++ versions.

Ah, good to know! On the flip side, I had to change the "stricmp" in your PR#47 to the regular "strcmp" because the former is Windows-only... 😁

Eivind wrote on 2024-04-19, 11:13:

Ah, good to know! On the flip side, I had to change the "stricmp" in your PR#47 to the regular "strcmp" because the former is Windows-only... 😁

To achieve case insensitivity, which is what stricmp means, you will need to use strncasecmp in Linux via a #define method.

Eivind wrote on 2024-04-19, 11:13:

Falcosoft wrote on 2024-04-19, 11:09:

Hi, I have tried to compile the emulator with your changes to test the speed improvements on x86/x64 CPU but I could not with V […]
Show full quote

Eivind wrote on 2024-04-19, 10:36:

Github PR of the Pi4-capable optimized code is up for anyone wanting to give this a spin before it's merged (hopefully)!

Hi,
I have tried to compile the emulator with your changes to test the speed improvements on x86/x64 CPU but I could not with Visual Studio (2019).
It seems the 'unused' attribute is gcc specific and is not supported by MSVC++ versions.

Ah, good to know! On the flip side, I had to change the "stricmp" in your PR#47 to the regular "strcmp" because the former is Windows-only... 😁

😀 Thanks, I will fix it.

@Falcosoft: I got rid of the __attribute__((unused)) issue by inserting "(void)variable_name;" at the top of each function body instead. Should do the trick, and keep the code environment-agnostic.

Eivind wrote on 2024-04-19, 11:54:

@Falcosoft: I got rid of the __attribute__((unused)) issue by inserting "(void)variable_name;" at the top of each function body instead. Should do the trick, and keep the code environment-agnostic.

Thanks,
I would say it's rather impressive even on x86-x64!
For the sake of @zaphod77 I used everquest title theme for testing 😀
With my original build this resulted in maximum 20-21% overall CPU utilization (4 cores) while with your modifications it resulted in 14-15%.

Constantly having to reset is a bit of a bummer, and I honestly can't hear any improvements over Sound Canvas VA, which I now use over my original hardware.

Still, more options are fantastic. For myself, I'm happy to stick with the Sound Canvas VA / Falcosoft Midi Player combinations.

brad86 wrote on 2024-04-20, 08:03:

Constantly having to reset is a bit of a bummer, and I honestly can't hear any improvements over Sound Canvas VA, which I now use over my original hardware.

Still, more options are fantastic. For myself, I'm happy to stick with the Sound Canvas VA / Falcosoft Midi Player combinations.

Things are moving fast and there's already support for command-line auto-resets for GM/GS merged into the master branch on github (courtesy of Falcosoft).

Lovely. I'll take a look at GitHub and see what I could have missed. I'm terrible at navigating that site at the best of times 😂.

brad86 wrote on 2024-04-20, 11:35:

Lovely. I'll take a look at GitHub and see what I could have missed. I'm terrible at navigating that site at the best of times 😂.

I too find github frustrating. Mostly coming from projects providing only source code, telling you to compile, and calling that availability.

Luckily, nukeykt provide releases.
https://github.com/nukeykt/Nuked-SC55/release … g/0.2.0-hotfix2

For the longest time I was browsing github on my phone, and not in desktop mode, so releases is all the way at the bottom. Not knowing what to look for, my frustration was sustained.

I recommend looking in the issues and even the solved issues (those are available once you click issues), as discussion can continue after somthing is considered solved.

Some pull requests (whatever thees are) also have discussions.

Karmeck wrote on 2024-04-21, 08:30:

Some pull requests (whatever thees are) also have discussions.

Pull requests are changes to the source code made by (usually) other people than the repository's owner. The author of the change requests that the change be pulled into the main repository.
It's hard to remember sometimes that not everyone on Github is familiar with coding - I absolutely agree that precompiled releases are essential!

zaphod77 wrote on 2024-04-18, 20:23:

please test with everquest title theme, as that one is a decent polyphony test. 😀

I managed to get a setup working on the Pi4 with two instances of the emulator running, and a python script splitting even/odd channels and routing them to either of the emulators.
Now the everquest theme sounded way better! 😀 I assume this is kind of an edge case, but fun to see that the Pi4 still has the grunts to do this. As long as I'm keeping the utilization of each CPU core under 100% it's happy.

I've also made further optimizations to the code where I've eliminated all runtime checks of which rom set is currently active - took some interesting (and new to me) C++17 trickery. Will make another branch on github soon.

Eivind wrote on 2024-04-21, 08:41:

It's hard to remember sometimes that not everyone on Github is familiar with coding - I absolutely agree that precompiled releases are essential!

Yes, and compiling with Visual Studio is not as straightforward as it should be. So more frequent builds would be better.

I managed to get a setup working on the Pi4 with two instances of the emulator running, and a python script splitting even/odd channels and routing them to either of the emulators.
Now the everquest theme sounded way better! 😀 I assume this is kind of an edge case, but fun to see that the Pi4 still has the grunts to do this. As long as I'm keeping the utilization of each CPU core under 100% it's happy.

I have experienced the same on Windows: If you have at least 4 cores performance is actually better with 2 instances when you split channels to even/odd (per instance) since the bottleneck is 1 core utilization and with 2 instances you can increase parallelism and actually decrease 1 core utilization.

If someone wants to try here is an x64 test version for Windows that outputs 32-bit float samples instead of 16-bit integer samples. It also reverts to the previous volume level before the clipping fix thus increasing the dynamic range and providing better signal to noise ratio in case of quiet Midis. Hard clipping should be prevented by floating point output but if you have a loud Midi you should lower the master volume of the emulator anyway.
This test also includes the latest fixes from master and the optimizations by Eivind. You can set -gs or -gm command line switches to get proper initial state so you do not have to reset the emulator manually after start. The test also supports the -h (help) command line switch ( it's in a commit that has not been accepted yet).
It also has some Windows specific thread priority optimizations so it should provide more consistent output when other programs are used together with the emulator. Default audio buffer size is halved so latency is also better but this can cause problems in some cases. You can use the new -ab command line switch to change buffer size.
Some feedback about the floating point output would be welcome. If it sounds better or if it produces better recordings etc. for some of you then eventually floating point output could be added as an option to master.

https://github.com/Falcosoft/Nuked-SC55/relea … _float_test.zip
(You should simply place the executable into the same folder where the current Nuked-SC55 executable is.)

Greatly appreciated and a bit overwhelming. So many new options.

What is the default buffer size? I can find the number 4096.

Karmeck wrote on 2024-04-21, 23:19:

Greatly appreciated and a bit overwhelming. So many new options.

What is the default buffer size? I can find the number 4096.

The final buffer size is a product of page_size and page_count (page_size * page_count). If you want 4096 as a final buffer size you can use e.g. 1024 as page_size and 4 as page count

1-ab:1024:4

The default buffer size of the above test release is 8192

1-ab:2048:4

The master version uses 16384:

1-ab:512:32

@Edit:
I have also made a 32-bit Win XP compatible test release. Since under Win XP SDL2 cannot use WASAPI only Directsound bigger buffer defaults are set (-ab:8192:4). In the zip the 32-bit SDL2.dll is also included.
https://github.com/Falcosoft/Nuked-SC55/relea … t_x86_winxp.zip

It works fairly well with a Core2 Duo 3.2 GHz under Win XP SP3 (30-35% CPU usage).

Eivind wrote on 2024-04-21, 21:13:

I managed to get a setup working on the Pi4 with two instances of the emulator running, and a python script splitting even/odd c […]
Show full quote

zaphod77 wrote on 2024-04-18, 20:23:

please test with everquest title theme, as that one is a decent polyphony test. 😀

I managed to get a setup working on the Pi4 with two instances of the emulator running, and a python script splitting even/odd channels and routing them to either of the emulators.
Now the everquest theme sounded way better! 😀 I assume this is kind of an edge case, but fun to see that the Pi4 still has the grunts to do this. As long as I'm keeping the utilization of each CPU core under 100% it's happy.

I've also made further optimizations to the code where I've eliminated all runtime checks of which rom set is currently active - took some interesting (and new to me) C++17 trickery. Will make another branch on github soon.

impressive.

the reason i suggested that midi is because it hit the original polyphony limit, so it would be a good torture test for performance.

Falcosoft wrote on 2024-04-21, 22:51:

If someone wants to try here is an x64 test version for Windows that outputs 32-bit float samples instead of 16-bit integer samples. It also reverts to the previous volume level before the clipping fix thus increasing the dynamic range and providing better signal to noise ratio in case of quiet Midis. Hard clipping should be prevented by floating point output but if you have a loud Midi you should lower the master volume of the emulator anyway.

I tried incorporating your 32-bit float sample changes into my current build, and it worked flawlessly on my mac - and also on the Pi4 once I upped the pageSize from 2048 to 8192. Anything less than that and I'd get ALSA buffer underrun warnings and scratchy/clicky sound. With 8192 though, no issues.
Interestingly, this change also lowered the CPU usage a few percent on both platforms. 💪

As an unrelated side note - ever since I've started playing with this emulator, I've gotten sporadic (not very frequent) stuck notes. This happens when playing MIDI files from players both on the mac and Pi4, and also when using the Roland UM-ONE connected to a retro computer playing Doom, on both platforms. I always figured this issue had something to do with my MIDI setup, since I don't think anyone else has reported on this? Thoughts?