Falcosoft wrote on 2024-04-15, 16:34:

1. It's enough the send a GM or GS Reset SysEx to cure pitch issue. If you use FSMP or Van Baso you can set them to send resets […]
Show full quote

markanini wrote on 2024-04-15, 14:39:

Can anyone guide on how to handle the two main quirks of mkII rom? If I'm not wrong one is related to battery detection causing pitch change, the second one is missing sounds cased by sound mapping discrepancies aka capital tone fallback.
I've seen seen GS reset proposed as a solution for both issue: Q, hold U and press Q, W.

The question is when is a good time to use the reset operation?

1. It's enough the send a GM or GS Reset SysEx to cure pitch issue. If you use FSMP or Van Baso you can set them to send resets every time a new title is played.
2. Key combo reset and GS reset cannot cure capital tone fallback related problems.
2a. To cure capital tone fallback related problems the simplest way is to send a GM reset. This way all bank select messages are ignored by mkII. But this way you actually disable all variation tones.
2b. The more sophisicated method that does not disable all variation tones is to use FSMP and its software Capital Tone Fallback feature:
You should click Main menu -> Instruments -> Custom Patch definitions and select Roland SCVA -> 'Roland SCVA-55' for melodic and 'Roland SCVA-55 Drumsets' for drum channels. Then you should also enable 'Use Patch info for Capital Tone Fallback' option.
CTF.png

I guess the 2a is the best option dealing with game midi then, when needed. Until someone modifies the rom to handle the issue differently. Thanks for the advice.

EDIT: For reference GM reset is done by: Q. Hold T, press W

markanini wrote on 2024-04-15, 17:57:

Falcosoft wrote on 2024-04-15, 16:34:

1. It's enough the send a GM or GS Reset SysEx to cure pitch issue. If you use FSMP or Van Baso you can set them to send resets […]
Show full quote

markanini wrote on 2024-04-15, 14:39:

Can anyone guide on how to handle the two main quirks of mkII rom? If I'm not wrong one is related to battery detection causing pitch change, the second one is missing sounds cased by sound mapping discrepancies aka capital tone fallback.
I've seen seen GS reset proposed as a solution for both issue: Q, hold U and press Q, W.

The question is when is a good time to use the reset operation?

1. It's enough the send a GM or GS Reset SysEx to cure pitch issue. If you use FSMP or Van Baso you can set them to send resets every time a new title is played.
2. Key combo reset and GS reset cannot cure capital tone fallback related problems.
2a. To cure capital tone fallback related problems the simplest way is to send a GM reset. This way all bank select messages are ignored by mkII. But this way you actually disable all variation tones.
2b. The more sophisicated method that does not disable all variation tones is to use FSMP and its software Capital Tone Fallback feature:
You should click Main menu -> Instruments -> Custom Patch definitions and select Roland SCVA -> 'Roland SCVA-55' for melodic and 'Roland SCVA-55 Drumsets' for drum channels. Then you should also enable 'Use Patch info for Capital Tone Fallback' option.
CTF.png

I guess the 2a is the best option dealing with game midi then, when needed. Until someone modifies the rom to handle the issue differently. Thanks for the advice.

I use 2b. even with DosBox gaming. FSMP can hande Midi Input so you can connect anything to it with a software loopback cable
(instead of Bassmidi/soundfont used by Phil in the post you should select the other loopback port for output that is used by Nuked-SC55):
Re: How to get Virtualmidi Synth worked in Dosbox under Win10

Falcosoft wrote on 2024-04-15, 18:01:

markanini wrote on 2024-04-15, 17:57:

Falcosoft wrote on 2024-04-15, 16:34:

1. It's enough the send a GM or GS Reset SysEx to cure pitch issue. If you use FSMP or Van Baso you can set them to send resets […]
Show full quote

1. It's enough the send a GM or GS Reset SysEx to cure pitch issue. If you use FSMP or Van Baso you can set them to send resets every time a new title is played.
2. Key combo reset and GS reset cannot cure capital tone fallback related problems.
2a. To cure capital tone fallback related problems the simplest way is to send a GM reset. This way all bank select messages are ignored by mkII. But this way you actually disable all variation tones.
2b. The more sophisicated method that does not disable all variation tones is to use FSMP and its software Capital Tone Fallback feature:
You should click Main menu -> Instruments -> Custom Patch definitions and select Roland SCVA -> 'Roland SCVA-55' for melodic and 'Roland SCVA-55 Drumsets' for drum channels. Then you should also enable 'Use Patch info for Capital Tone Fallback' option.
CTF.png

I guess the 2a is the best option dealing with game midi then, when needed. Until someone modifies the rom to handle the issue differently. Thanks for the advice.

I use 2b. even with DosBox gaming. FSMP can hande Midi Input so you can connect anything to it with a software loopback cable:
Re: How to get Virtualmidi Synth worked in Dosbox under Win10

I should have said in-game midi. Outside of the game your preferred solution is best. Unless you route the in game midithrough a second loopmidi device into FSMP.

markanini wrote on 2024-04-15, 18:07:

Falcosoft wrote on 2024-04-15, 18:01:

markanini wrote on 2024-04-15, 17:57:

I guess the 2a is the best option dealing with game midi then, when needed. Until someone modifies the rom to handle the issue differently. Thanks for the advice.

I use 2b. even with DosBox gaming. FSMP can hande Midi Input so you can connect anything to it with a software loopback cable:
Re: How to get Virtualmidi Synth worked in Dosbox under Win10

I should have said in-game midi. Outside of the game your solution is best.

The same is true for any in-game Midi if under in-game Midi you mean a Midi port used by the game and not internal FM sound.

... Unless you route the in game midithrough a second loopmidi device into FSMP.

Yes, exactly.

So I have a question about the odd sampling rate this emulator uses: On the Wikipedia Article it lists 18-bit @ 33.1 kHz as the output format of the SC-55mkii but the emulator is outputting a sample rate of 66207. (and I assume the audio samples themselves are floats because there's no such thing as a "18-bit sample format" only 8-bit, 16-bit, 24-bit, and 32-bit floating points are the norm)

How did the value of 66207 even come to be exactly? I'm curious to know. My sound server (PipeWire) runs at 48000 Hz shared but the resampler it uses doesn't horribly artefact the resulting mixed audio. I can understand on some systems though they might be using a really bad resampler which will cause some nasty aliasing effects.

DracoNihil wrote on 2024-04-15, 21:13:

So I have a question about the odd sampling rate this emulator uses: On the Wikipedia Article it lists 18-bit @ 33.1 kHz as the output format of the SC-55mkii but the emulator is outputting a sample rate of 66207. (and I assume the audio samples themselves are floats because there's no such thing as a "18-bit sample format" only 8-bit, 16-bit, 24-bit, and 32-bit floating points are the norm)

How did the value of 66207 even come to be exactly? I'm curious to know. My sound server (PipeWire) runs at 48000 Hz shared but the resampler it uses doesn't horribly artefact the resulting mixed audio. I can understand on some systems though they might be using a really bad resampler which will cause some nasty aliasing effects.

Samples are oversampled (actually by doubling the frequency) from 33.1 kHz to 66.2 kHz. It is using signed 16-bit integer format for audio output (F=S16LSB on the console output), not floating point.
Ps: I do not know what method Nukeykt used to determine the proper exact frequency but in theory you can check at what frequency the emulator produces exactly 440 Hz at A4(note number 69) when default equal tuning is used (after a reset).

DracoNihil wrote on 2024-04-15, 21:13:

So I have a question about the odd sampling rate this emulator uses: On the Wikipedia Article it lists 18-bit @ 33.1 kHz as the output format of the SC-55mkii but the emulator is outputting a sample rate of 66207. (and I assume the audio samples themselves are floats because there's no such thing as a "18-bit sample format" only 8-bit, 16-bit, 24-bit, and 32-bit floating points are the norm)

How did the value of 66207 even come to be exactly? I'm curious to know. My sound server (PipeWire) runs at 48000 Hz shared but the resampler it uses doesn't horribly artefact the resulting mixed audio. I can understand on some systems though they might be using a really bad resampler which will cause some nasty aliasing effects.

As far as "18-bit", that's the UPD63200 DAC the SC-55mkII (and other devices like the JV-1080) use, set as 18-bits (it might be able to do 16 and 18, I forget). So the audio output is 18-bit, presumably truncated to 16-bit by audio interfaces/mixers operating at 16-bit.
I am curious if there's a way to preserve or improve the mkII's "higher than 16-bit" fidelity by offering a 24 or 32-bit/float option as MUNT does, though.

I would presume as Falcosoft says, 66207 is a multiple of the original sample rate (presumably 33103 or 33104). I would have expected 32768 and 65536 personally, but I'm going to trust Nuke on this!
48 or 96kHz should be good multiples of the close to 32kHz signal to use in your system, though, avoid others.
It does make me wonder what exact sample rate the MT-32 uses, since Nuked didn't create that emulator!

It's not the only module from the era with quirky ROM sample rates either. Just as one example, the Proteus 1 used 39kHz samples, and I definitely have seen others between 22 and 44!

Spikey wrote on 2024-04-17, 10:48:

... I would presume as Falcosoft says, 66207 is a multiple of the original sample rate (presumably 33103 or 33104). I would have […]
Show full quote

...
I would presume as Falcosoft says, 66207 is a multiple of the original sample rate (presumably 33103 or 33104). I would have expected 32768 and 65536 personally, but I'm going to trust Nuke on this!
48 or 96kHz should be good multiples of the close to 32kHz signal to use in your system, though, avoid others.
It does make me wonder what exact sample rate the MT-32 uses, since Nuked didn't create that emulator!

It's not the only module from the era with quirky ROM sample rates either. Just as one example, the Proteus 1 used 39kHz samples, and I definitely have seen others between 22 and 44!

In Nuked-SC55 only the mkii emualtion uses 33103 Hz (66207 oversampled) sample rate. If you use SC-55mk1 ROMs then the sample rate is 32000 Hz (64000 oversampled).
Munt internally always uses 32000 Hz. But you can select what frequency you want for the emulation of the analogue circuits: COARSE = 32000 Hz; ACCURATE = 48000 Hz; OVERSAMPLED = 96000 Hz.

/** Methods for emulating the effects of analogue circuits of real hardware units on the output signal. */ enum MT32EMU_ANALOG_O […]
Show full quote

/** Methods for emulating the effects of analogue circuits of real hardware units on the output signal. */
enum MT32EMU_ANALOG_OUTPUT_MODE_NAME {
/** Only digital path is emulated. The output samples correspond to the digital signal at the DAC entrance. */
MT32EMU_ANALOG_OUTPUT_MODE(DIGITAL_ONLY),
/** Coarse emulation of LPF circuit. High frequencies are boosted, sample rate remains unchanged. */
MT32EMU_ANALOG_OUTPUT_MODE(COARSE),
/**
* Finer emulation of LPF circuit. Output signal is upsampled to 48 kHz to allow emulation of audible mirror spectra above 16 kHz,
* which is passed through the LPF circuit without significant attenuation.
*/
MT32EMU_ANALOG_OUTPUT_MODE(ACCURATE),
/**
* Same as AnalogOutputMode_ACCURATE mode but the output signal is 2x oversampled, i.e. the output sample rate is 96 kHz.
* This makes subsequent resampling easier. Besides, due to nonlinear passband of the LPF emulated, it takes fewer number of MACs
* compared to a regular LPF FIR implementations.
*/
MT32EMU_ANALOG_OUTPUT_MODE(OVERSAMPLED)
};

Strange! I wasn't aware the devices have different sample rates.

I'm familiar with MUNT, though.

I've been playing around with optimizing the emulator code for the last few days, and I'm happy to report that I'm now able to run it at ~85-90% cpu utilization (while playing music) on a single core of a stock Raspberry Pi 4! 🎉
I'll do a bit of cleaning up of the code and then I'll make PR on the github repo.

Eivind wrote on 2024-04-18, 10:04:

I've been playing around with optimizing the emulator code for the last few days, and I'm happy to report that I'm now able to run it at ~85-90% cpu utilization (while playing music) on a single core of a stock Raspberry Pi 4! 🎉
I'll do a bit of cleaning up of the code and then I'll make PR on the github repo.

Is there the same performance improvement on PC x86 CPUs?

Kappa971 wrote on 2024-04-18, 10:34:

Eivind wrote on 2024-04-18, 10:04:

I've been playing around with optimizing the emulator code for the last few days, and I'm happy to report that I'm now able to run it at ~85-90% cpu utilization (while playing music) on a single core of a stock Raspberry Pi 4! 🎉
I'll do a bit of cleaning up of the code and then I'll make PR on the github repo.

Is there the same performance improvement on PC x86 CPUs?

I don't have an x86 desktop computer (besides retro machines and servers) on hand atm, only a macbook pro with the M1 processor. On that, I'm currently seeing a drop from around 39-41% utilization to about 26-28% with my modifications in place. Don't know for the Pi 4, as the stock nuked-sc55 topped out at 100% before. Btw, take these percentages with a bit of salt - I'm guessing there are plenty of factors at play.
My goal was to get the emulator running satisfactory on a Pi 4, and it seems this is now within reach. More testing needed still, obviously.

Eivind wrote on 2024-04-18, 10:04:

I've been playing around with optimizing the emulator code for the last few days, and I'm happy to report that I'm now able to run it at ~85-90% cpu utilization (while playing music) on a single core of a stock Raspberry Pi 4! 🎉
I'll do a bit of cleaning up of the code and then I'll make PR on the github repo.

Great to hear! Something I'm concerned about though: will this sacrifice any nuances or capabilities of the emulation?

OpenRift wrote on 2024-04-18, 17:19:

Eivind wrote on 2024-04-18, 10:04:

I've been playing around with optimizing the emulator code for the last few days, and I'm happy to report that I'm now able to run it at ~85-90% cpu utilization (while playing music) on a single core of a stock Raspberry Pi 4! 🎉
I'll do a bit of cleaning up of the code and then I'll make PR on the github repo.

Great to hear! Something I'm concerned about though: will this sacrifice any nuances or capabilities of the emulation?

Not that I can tell - but once I get the changes into other people's hands I'm sure we'll find out soon enough! 😀

EDIT: I should also add - I've only tested my changes against the mkII roms as I don't have access to any of the others.

Eivind wrote on 2024-04-18, 19:49:

OpenRift wrote on 2024-04-18, 17:19:

Eivind wrote on 2024-04-18, 10:04:

I've been playing around with optimizing the emulator code for the last few days, and I'm happy to report that I'm now able to run it at ~85-90% cpu utilization (while playing music) on a single core of a stock Raspberry Pi 4! 🎉
I'll do a bit of cleaning up of the code and then I'll make PR on the github repo.

Great to hear! Something I'm concerned about though: will this sacrifice any nuances or capabilities of the emulation?

Not that I can tell - but once I get the changes into other people's hands I'm sure we'll find out soon enough! 😀

EDIT: I should also add - I've only tested my changes against the mkII roms as I don't have access to any of the others.

I think it would be wise to try and get the other ROM sets if you can so that you can make sure your optimizations aren't affecting the sound of those.

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

OpenRift wrote on 2024-04-18, 20:15:

I think it would be wise to try and get the other ROM sets if you can so that you can make sure your optimizations aren't affecting the sound of those.

I won't stop anyone DM'ing me...

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

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

Yeah, that wasn't....great. 😁 But to my ears, it plays equally weird on the modded code and the original, at least.

OpenRift wrote on 2024-04-18, 20:15:

I think it would be wise to try and get the other ROM sets if you can so that you can make sure your optimizations aren't affecting the sound of those.

Do they exist? I could only find the full SC-55 mkII ROMs.

Kappa971 wrote on 2024-04-18, 22:25:

OpenRift wrote on 2024-04-18, 20:15:

I think it would be wise to try and get the other ROM sets if you can so that you can make sure your optimizations aren't affecting the sound of those.

Do they exist? I could only find the full SC-55 mkII ROMs.

They exist, but I think only a few people attached to this project have the full sets.

In terms of the original sc55 1.21 roms the only one not accounted for is the Hitachi MCU main rom , its about 32kb in size but you need to inject code into the control rom to dump it and use a logic analyser to read it.

https://github.com/nukeykt/Nuked-SC55/issues/41