Spikey wrote on 2024-04-10, 06:26:

So, where are we at with this? Does it work as a standalone MIDI device, or must it be used with something else?

Does the reverb/chorus work correctly, since someone posted demos last week that sounded like it wasn't implemented?

1. Yes, it works as a standalone device. By default it opens your first Midi In port but with the latest release you can set a command line parameter ('-p:x' where x is the port number) to open the Midi In port of your choice.
2. Both reverb and chorus are implemented and overall it is 99% ready.

Is there any chance to turn this emulator into a MIDI daughterboard?

Bondi wrote on 2024-04-10, 07:27:

Is there any chance to turn this emulator into a MIDI daughterboard?

1. You can build one for yourself if you want but the license is non-commercial so a commercial product cannot be made with it.
2. Because of the emulator current performance requirements it would not be easy to select a proper platform to host the emulator (it seems Raspberry PI's are too weak for it).

I'm fine with it as a port-reading device as other MIDI emulators had been in the past. Any more convenience desired would be a Windows MIDI driver. No need for game/emu integration

As for Pis, I can only imagine the Pi 5 handling it

Falcosoft wrote on 2024-04-10, 07:36:

Bondi wrote on 2024-04-10, 07:27:

Is there any chance to turn this emulator into a MIDI daughterboard?

1. You can build one for yourself if you want but the license is non-commercial so a commercial product cannot be made with it.
2. Because of the emulator current performance requirements it would not be easy to select a proper platform to host the emulator (it seems Raspberry PI's are too weak for it).

Thank you for your respond, Falcosoft. Having such a daughterboard would solve all our problems.
Do you think, one Pi Pico per emulated chip (so three, I guess) would do the job?

Bondi wrote on 2024-04-10, 10:19:

Falcosoft wrote on 2024-04-10, 07:36:

Bondi wrote on 2024-04-10, 07:27:

Is there any chance to turn this emulator into a MIDI daughterboard?

1. You can build one for yourself if you want but the license is non-commercial so a commercial product cannot be made with it.
2. Because of the emulator current performance requirements it would not be easy to select a proper platform to host the emulator (it seems Raspberry PI's are too weak for it).

Thank you for your respond, Falcosoft. Having such a daughterboard would solve all our problems.
Do you think, one Pi Pico per emulated chip (so three, I guess) would do the job?

I seriously doubt it. The MCU emulation needs much higher performance than a Pi Pico (or even 3) can provide.

Falcosoft wrote on 2024-04-10, 10:29:

The MCU emulation needs much higher performance than a Pi Pico (or even 3) can provide.

I tried running the emulator and saw CPU usage of around mid-40% on my M1 macbook pro. Then I ran mt32emu-qt (munt) and saw 30-40% CPU usage.
Given - I have no real idea of the complexity of the sc55 emulation vs the mt-32, or how much processing power is used by the actual emulators as opposed to all the supporting stuff (GUI, midi file playback in the case of mt32emu-qt, etc), but it seems to me that it shouldn't be that far apart. Munt runs perfectly fine on the bare-metal mt32-pi "firmware"/image on a Pi Zero 2, so maaaybe, in theory, the sc55 emulator could as well. Might require further optimizations, definitely making it available as a proper library, etc.
But my point is - having it run on a Pi, which would open the doors to endless possibilities, might not necessarily be as far off as many in here seem to believe.
At least I like to be optimistic, and won't write it off at this early stage of the emulator's life! 😀

Eivind wrote on 2024-04-10, 11:48:

having it run on a Pi, which would open the doors to endless possibilities

like what possibilities for example? considering Thin-Client like "Fujitsu Futro S920" (or equivalent models from HP, Wyse, etc.) costs less and it can run anything. I've never understand the point of running MT32-emu on Pi either - except wasting money and dealing with limited processing power.

mattw wrote on 2024-04-10, 12:05:

Eivind wrote on 2024-04-10, 11:48:

having it run on a Pi, which would open the doors to endless possibilities

like what possibilities for example? considering Thin-Client like "Fujitsu Futro S920" costs less and it can run anything. I've never understand the point of running MT32-emu on Pi either - except wasting money and dealing with limited processing power.

Putting the Pi on various retro hardware projects - take a look at the ones in my signature! 😉

Eivind wrote on 2024-04-10, 12:08:

Putting the Pi on various retro hardware projects - take a look at the ones in my signature! 😉

IMHO, then the correct statements is:

having it run on a Pi, which would open the doors to endless possibilities for my own projects.

and not in general...

mattw wrote on 2024-04-10, 12:14:

IMHO, then the correct statements is:

having it run on a Pi, which would open the doors to endless possibilities for my own projects.

and not in general...

I stand corrected. It would make my own projects better. I do, however, make the assumption it would make the hardware projects (existing or new) of everyone else using the mt32-pi better as well.
Are you satisfied with this statement? If so, please let's not sidetrack this further, ok? I'm sure we can agree that the sc55 emulator is great, and having it be able to run on more systems would benefit us all!

Intel has opened up x86 licensing again, so we may yet see - 2 to 3 years or more from now - some low-end and inexpensive solutions for retro computing that are better than Pi, like the old VIA x86 boards. There are also ARM PC boards from various companies now hitting the market, with new 8-core or more CPUs and up to 32GB of RAM, with modern GPUs and connectivity that makes them suitable for retro gaming.

Eivind wrote on 2024-04-10, 11:48:

I tried running the emulator and saw CPU usage of around mid-40% on my M1 macbook pro. Then I ran mt32emu-qt (munt) and saw 30-40% CPU usage.

1. Then you must be running Munt with the floating point engine (Render type: Float 32-bit). By default Munt uses 16-bit integer rendering that is closer to real MT-32 hardware and requires less performant host hardware. It runs even on a Pentium 3.
In 16-bit integer mode (which is the default and is also used by mt32-pi) Munt processor utilization is nowhere near to Nuked-SC55.
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).
2. Also be aware that the question was about Pi Pico that is a 133 MHz(!) dual core microcontroller that is much weaker than the destionation hardware of mt32-pi (Raspberry Pi 3 or even your mentioned Pi Zero 2).

Do you think, one Pi Pico per emulated chip (so three, I guess) would do the job?

The MCU emulation needs much higher performance than a Pi Pico (or even 3) can provide.

By '3' I reffered to 3 Pi Pico microcontrollers (as suggested by Bondi) and not to Raspberry Pi 3.
I still think we are very far from this.

nukeykt wrote on 2024-03-15, 08:40:

all code inside firmware assumes 28 voices and pcm chip has hard limit of 28 voices (curiosly, on original sc-55 pcm chip DOES support 28 voices, it is just firmware is compiled to work with 24).

I have a different but related question, would it then be possible to restrict it to 24 voices?
This may sound like an odd request but there are some songs that sound off on the SC-55mkII, my pet peeve being d2map05 after 02:12:00 or so.
I don't know if this is a well-understood problem, I've just long wondered if it's because the increased polyphony ends up saving irrelevant notes and dooming important ones in their stead.

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.

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

I have a different but related question, would it then be possible to restrict it to 24 voices?
This may sound like an odd request but there are some songs that sound off on the SC-55mkII, my pet peeve being d2map05 after 02:12:00 or so.

Settlers 2 has this problem too, as documented here.

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

1. Then you must be running Munt with the floating point engine (Render type: Float 32-bit). By default Munt uses 16-bit integer rendering that is closer to real MT-32 hardware and requires less performant host hardware. It runs even on a Pentium 3.
In 16-bit integer mode (which is the default and is also used by mt32-pi) Munt processor utilization is nowhere near to Nuked-SC55.
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).

Ah, didn't know about the different render engines!

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

2. Also be aware that the question was about Pi Pico that is a 133 MHz(!) dual core microcontroller that is much weaker than the destionation hardware of mt32-pi (Raspberry Pi 3 or even your mentioned Pi Zero 2).
By '3' I reffered to 3 Pi Pico microcontrollers (as suggested by Bondi) and not to Raspberry Pi 3.
I still think we are very far from this.

Yeah, I'm sure you're right! I still choose to be optimistic about what can be done with optimizations further down the road though! 😁

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.

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

This may sound like an odd request but there are some songs that sound off on the SC-55mkII, my pet peeve being d2map05 after 02:12:00 or so.
I don't know if this is a well-understood problem, I've just long wondered if it's because the increased polyphony ends up saving irrelevant notes and dooming important ones in their stead.

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

Settlers 2 has this problem too, as documented here.

These problems are not directly related to increased polyphony and would be only worse by reducing it to 24 from 28. These problems are related to changed voice reserve algorithm/settings of mkII compared to original SC-55.
Namely the default voice reserve algorithm gives more preference for 1st Midi channel and neglects any channels after channel 10.
Here are some references about the problem and possible solutions that can work for this emulator, too:
Re: Falcosoft Soundfont Midi Player
Re: Significant differences with certain MIDI files across Roland synthesizers

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.

Munt VSTi has been written by me and yes, it works the way you described. I think this is the video you are talking about:
https://youtu.be/vSk9S1bkRS8?si=6F9M-kjUAE1Hi3wE&t=502

In order to write a VSTi plugin around Nuked-SC55 some kind of refactoring would be needed as suggested by datajake1999:
https://github.com/nukeykt/Nuked-SC55/issues/12