Eivind wrote on 2024-04-10, 14:13:

Joseph_Joestar wrote on 2024-04-10, 14:05:

If this emulator ever makes it to VSTi form, would it be possible to have it running on a modern system, while still being able to access it from an actual retro rig using a Roland UM-ONE mk2?

I think something similar is already possible with MUNT, unless I'm misremembering. Phil may have a video on the topic.

I'd think you could do this with the emulator in its current state already? Just gotta route the midi signal correctly on the modern computer.

I'll just answer my own post here - I hooked up a UM-ONE between my macbook and an ISA sound card, and the emulator played back the general midi from warcraft 2 just fine.

at idle (no playback) a Pi5 gets 24.5% execution with the current tree and that's a whole core and it appears visually choppy. Hadn't played a MIDI yet (no dev/sequencer on bookworm). I don't expect it to sound good at this stage.

Joseph_Joestar wrote on 2024-04-10, 14:05:

Roland UM-ONE mk2

please, note that using Roland MIDI-to-USB is not optimal in many cases, because of what I explained here:

Re: Best solution for hardware wavetable in modern desktop or laptop?

as far as brand names go, I guess then Yamaha UX-series like UX16 is the closest to Roland UM-ONE and it has no ActiveSense (at least mine doesn't have, but it could be depending on the firmware version).

mattw wrote on 2024-04-10, 17:37:

please, note that using Roland MIDI-to-USB is not optimal in many cases, because of what I explained here:

Re: Best solution for hardware wavetable in modern desktop or laptop?

Interesting, I wasn't aware of that.

Not sure if I understood this correctly, but this issue seems to occur if you connect the UM-ONE to the MIDI_OUT port of something like a SC-55. As far as I'm aware, one should never do that if the goal is simply playing retro games, and not music production etc. Or is there something else that I'm missing?

Joseph_Joestar wrote on 2024-04-10, 17:47:

Not sure if I understood this correctly, but this issue seems to occur if you connect the UM-ONE to the MIDI_OUT port of something like a SC-55.

nope, the opposite direction: when connect MIDI_Out of UM-ONE (or any other Roland USB-to-MIDI device) to MIDI_In of another device. so, "Active Sense" message is supposed to be filtered on the MIDI_In, but most devices don't expect it at all and instead filter it pass it and that causes huge CPU load of the connected device, because "Active Sense" messages are sent every 300ms by Roland.

mattw wrote on 2024-04-10, 17:53:

nope, the opposite direction: when connect MIDI_Out of UM-ONE (or any other Roland USB-to-MIDI device) to MIDI_In of another device. so, "Active Sense" message is supposed to be filtered on the MIDI_In, but most devices don't expect it at all and instead filter it pass it and that causes huge CPU load of the connected device, because "Active Sense" messages are sent every 300ms by Roland.

Ouch, that's not good then.

Any other issues besides having high CPU usage on the target system? I imagine some people would be interested in running the emulator on a modern(ish) PC while the actual games would be played on their retro rigs. With the UM-ONE providing a connection between the two.

v0.2.0 version released:

• SC-55mk1, CM-300/SCC-1, SC-55st are supported now
• Fix filter overflow on mk2

https://github.com/nukeykt/Nuked-SC55/release … g/0.2.0-hotfix2

nukeykt wrote on 2024-04-10, 18:19:

v0.2.0 version released: […]
Show full quote

v0.2.0 version released:

• SC-55mk1, CM-300/SCC-1, SC-55st are supported now
• Fix filter overflow on mk2

https://github.com/nukeykt/Nuked-SC55/release … g/0.2.0-hotfix2

Man!!! It just keeps getting better and better!! Thank you Nukeykt for this increadible piece of software.

Falcosoft wrote on 2024-04-10, 13:17:

On my 4 core AMD Nuked-SC55 eats 30% -40% while Munt in integer mode eats 5-10% maximum with the same Midi file (even with doubled 64 maximum partials).

What kind of CPU is that? On my 5900x it's 0-1%.

Oetker wrote on 2024-04-10, 20:06:

Falcosoft wrote on 2024-04-10, 13:17:

On my 4 core AMD Nuked-SC55 eats 30% -40% while Munt in integer mode eats 5-10% maximum with the same Midi file (even with doubled 64 maximum partials).

What kind of CPU is that? On my 5900x it's 0-1%.

Phenom 2 x4 😀

Falcosoft wrote on 2024-04-10, 13:17:

In 16-bit integer mode (which is the default and is also used by mt32-pi)...

FWIW, this is false - mt32-pi uses the floating-point render path for both Munt and FluidSynth.
mt32-pi is compiled with aggressive NEON and vectorisation optimisations enabled and so even the Z2W can comfortably use this method.

d0pefish wrote on 2024-04-10, 22:37:

Falcosoft wrote on 2024-04-10, 13:17:

In 16-bit integer mode (which is the default and is also used by mt32-pi)...

FWIW, this is false - mt32-pi uses the floating-point render path for both Munt and FluidSynth.
mt32-pi is compiled with aggressive NEON and vectorisation optimisations enabled and so even the Z2W can comfortably use this method.

Hi,
I know you are the maintainer of mt32-pi so it's very hard for me to say that you are most likely wrong.
Before I wrote the above I have checked the source of mt32-pi (https://github.com/dwhinham/mt32-pi)
and I have not found the necessary API call that is needed to switch Munt into floating point rendering mode.
I strongly think that you simply mix up the full floating point rendering path with the mt32emu_render_float() call that simply converts the internally integer rendered samples to float in the last step.
To really switch Munt into full floating point mode you have to call explicitly the mt32emu_select_renderer_type()/selectRendererType() API with explcit MT32EMU_RENDERER_TYPE(FLOAT) parameter.
Please, show me where this API is called in mt32-pi 's code.
The situation is that without this explicit API call Munt initializes and stays in 16-bit integer rendering mode regardless you use render_float() or render_bit16s() API calls.
From Munt's C API header:

1/**
2 * Selects new type of the wave generator and renderer to be used during subsequent calls to mt32emu_open_synth().
3 * By default, MT32EMU_RT_BIT16S is selected.
4 * See mt32emu_renderer_type for details.
5 */
6MT32EMU_EXPORT void mt32emu_select_renderer_type(mt32emu_context context, const mt32emu_renderer_type renderer_type);

Here are some references about the real 32-bit float rendering mode (that was introduced much later into Munt than the render_float() API:
Re: Falcosoft Soundfont Midi Player
Request for floating point arithmetic version

Please, try the render type API and report back your results.
It's very hard to imagine that it could work on a Z2W as you said since it can cause problems even on 2+ GHz x86/x64 processors with fully optimized SSE2 code. NEON is not that much more efficient instruction set...
But please, correct me if I'm wrong.

Well, crap - that's me humbled. 😔

Thank you for the clarification; for years I believed that it was only necessary to call the float flavour of render() (I'm using the C++ API).
You're absolutely right; we get RendererType_BIT16S by default in the constructor for the Synth class. 🤦‍♂️

I think I need a new hobby.

d0pefish wrote on 2024-04-11, 00:25:

Well, crap - that's me humbled. 😔 […]
Show full quote

Well, crap - that's me humbled. 😔

Thank you for the clarification; for years I believed that it was only necessary to call the float flavour of render() (I'm using the C++ API).
You're absolutely right; we get RendererType_BIT16S by default in the constructor for the Synth class. 🤦‍♂️

I think I need a new hobby.

I do not think it's a problem for mt32-pi since even according to Sergm the integer rendering path of Munt is the more compatible and more faithful to original hardware. So it's definitely the better default modus operandi for Munt/mt32-pi.
You can add the full floating point rendering path to mt32-pi as a selectable option but be prepared for a much more CPU hungry Munt 😀.

Yes, this would be opt-in for Pi 4+ - I will have to do some tests across the various models 😀

I'm glad you told me this - I will remove the calls to render(float*, ...) now that I'm aware Munt is internally integer by default, because it is causing an unnecessary conversion: int -> float -> back to int again for output to I2S DAC, which is just a waste of CPU time.

> I don't expect it to sound good at this stage.

Heh, you don't seem to read what's been posted in this thread, neither do you seem to test things before posting...

It sounds PERFECT, I've A/B compared it extensively with my own SC-55 hardware recordings, and it's indistinguishable from hardware.

Not close, or "90% there", or something... It's spot on, it's the same thing.

The accurate emulation part is 99.99% DONE, it sounds just like the REAL THING!

Rincewind42 wrote on 2024-04-11, 01:35:

> I don't expect it to sound good at this stage. […]
Show full quote

> I don't expect it to sound good at this stage.

Heh, you don't seem to read what's been posted in this thread, neither do you seem to test things before posting...

It sounds PERFECT, I've A/B compared it extensively with my own SC-55 hardware recordings, and it's indistinguishable from hardware.

Not close, or "90% there", or something... It's spot on, it's the same thing.

The accurate emulation part is 99.99% DONE, it sounds just like the REAL THING!

I think you misunderstood Leileilol somewhat. I think Leileilol was talking about the Pi5 experiment and experienced full core consumption and choppy behaviour. This is what explains the 'I don't expect it to sound good at this stage.' statement not the accuracy of the emulator.

Falcosoft wrote on 2024-04-11, 00:08:

Hi, I know you are the maintainer of mt32-pi so it's very hard for me to say that you are most likely wrong. Before I wrote the […]
Show full quote

d0pefish wrote on 2024-04-10, 22:37:

Falcosoft wrote on 2024-04-10, 13:17:

In 16-bit integer mode (which is the default and is also used by mt32-pi)...

FWIW, this is false - mt32-pi uses the floating-point render path for both Munt and FluidSynth.
mt32-pi is compiled with aggressive NEON and vectorisation optimisations enabled and so even the Z2W can comfortably use this method.

Hi,
I know you are the maintainer of mt32-pi so it's very hard for me to say that you are most likely wrong.
Before I wrote the above I have checked the source of mt32-pi (https://github.com/dwhinham/mt32-pi)
and I have not found the necessary API call that is needed to switch Munt into floating point rendering mode.
I strongly think that you simply mix up the full floating point rendering path with the mt32emu_render_float() call that simply converts the internally integer rendered samples to float in the last step.
To really switch Munt into full floating point mode you have to call explicitly the mt32emu_select_renderer_type()/selectRendererType() API with explcit MT32EMU_RENDERER_TYPE(FLOAT) parameter.
Please, show me where this API is called in mt32-pi 's code.
The situation is that without this explicit API call Munt initializes and stays in 16-bit integer rendering mode regardless you use render_float() or render_bit16s() API calls.
From Munt's C API header:

Copy code to clipboard

1/**
2 * Selects new type of the wave generator and renderer to be used during subsequent calls to mt32emu_open_synth().
3 * By default, MT32EMU_RT_BIT16S is selected.
4 * See mt32emu_renderer_type for details.
5 */
6MT32EMU_EXPORT void mt32emu_select_renderer_type(mt32emu_context context, const mt32emu_renderer_type renderer_type);

Here are some references about the real 32-bit float rendering mode (that was introduced much later into Munt than the render_float() API:
Re: Falcosoft Soundfont Midi Player
Request for floating point arithmetic version

Please, try the render type API and report back your results.
It's very hard to imagine that it could work on a Z2W as you said since it can cause problems even on 2+ GHz x86/x64 processors with fully optimized SSE2 code. NEON is not that much more efficient instruction set...
But please, correct me if I'm wrong.

Heh, that's some good info. We use 'MT32Emu::RendererType_FLOAT' in Staging, but seems to be pointless and needlessly expensive. Switching to INT16 in the next version...

Falcosoft wrote on 2024-04-11, 01:42:

Rincewind42 wrote on 2024-04-11, 01:35:

> I don't expect it to sound good at this stage. […]
Show full quote

> I don't expect it to sound good at this stage.

Heh, you don't seem to read what's been posted in this thread, neither do you seem to test things before posting...

It sounds PERFECT, I've A/B compared it extensively with my own SC-55 hardware recordings, and it's indistinguishable from hardware.

Not close, or "90% there", or something... It's spot on, it's the same thing.

The accurate emulation part is 99.99% DONE, it sounds just like the REAL THING!

I think you misunderstood Leileilol somewhat. I think Leileilol was talking about the Pi5 experiment and experienced full core consumption and choppy behaviour. This is what explains the 'I don't expect it to sound good at this stage.' statement not the accuracy of the emulator.

Well, clear communication is hard 😀

Okay, so, apparently, Koreans are REALLY interested in Nuked-SC55.