skjelten / emusc Goto Github PK

Is it confirmed that the SC55 uses two passes of a RIAA filter to process the samples? By looking at the PCM rom I don't think it's the case.
The PCM data is likely to be some form of DPCM, which if interpreted wrongly could produce a low-freq cutting effect.

Terminal output shows

EmuSC: Illegal confguration for MIDI device

I do have other MIDI devices connected at the time, but nothing is showing up in the dropdown.

How would someone need to be compiling the emulator in this new form?, have tried on getting this recent build compiled, neither of these two seem to work, any idea?

Fedora 39 x86_64 using latest git code

Starting emusc:

$ LD_LIBRARY_PATH=/usr/local/lib64 emusc -p
QSocketNotifier: Can only be used with threads started with QThread
EmuSC: Audio output [PulseAudio] successfully initialized
 -> s16le 2ch 44100Hz
EmuSC: MIDI sequencer [ALSA] client started at address 128

Emusc starts up and seems fine.

But checking with aplaymidi, it does not see the device:

$ aplaymidi -l
 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0

Regardless, using aplaymidi to play a MIDI file seems to do something:

$ aplaymidi -p 128:0 CANYON.MID

The emusc display changes:

And there are a lot of emusc log messages, but no sound:

EmuSC: MIDI input event [Port subscribed]
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
Polyphonic key pressure not implemented (ch=, key=12, value=)
Polyphonic key pressure not implemented (ch=, key=12, value=)
Polyphonic key pressure not implemented (ch=, key=12, value=)
Polyphonic key pressure not implemented (ch=, key=3, value=)
Polyphonic key pressure not implemented (ch=, key=3, value=)
Polyphonic key pressure not implemented (ch=, key=3, value=)
Polyphonic key pressure not implemented (ch=, key=2, value=)
Polyphonic key pressure not implemented (ch=, key=2, value=)
Polyphonic key pressure not implemented (ch=, key=2, value=)
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit
EmuSC: New note on ignored due to voice limit

The above errors just continue flowing as long as aplaymidi is running.

Hello! Phenomenal work so far, I've been trying to compile this under Windows and I get a "unable to create config directory" error. Is there a way I can fix that?

Also, I did test this under Linux and it sounds wonderful. But I've noticed some issues with the pitch correction related stuff. Like with DOOM's E1M1, the Overdrive Guitar and Distortion Guitar samples are slightly off-tune. I think the Ride Bell also is pitched a bit high, as if the root key value was incorrect.

If there is any way I could help too, please let me know. I was working on an SC-55 SoundFont before but gave up after realizing the SoundFont 2.0 standard couldn't represent this particular synth.

Hi,

I'm having trouble compiling emusc on macOS 14. Here's the output:

[  7%] Linking CXX executable emusc.app/Contents/MacOS/emusc
ld: Undefined symbols:
  EmuSC::Wavetable::_sineTable, referenced from:
      EmuSC::Wavetable::next_sample() in libemusc.a[16](wavetable.cc.o)
      EmuSC::Wavetable::next_sample() in libemusc.a[16](wavetable.cc.o)
      EmuSC::Wavetable::next_sample() in libemusc.a[16](wavetable.cc.o)
      EmuSC::Wavetable::next_sample() in libemusc.a[16](wavetable.cc.o)
      EmuSC::Wavetable::next_sample() in libemusc.a[16](wavetable.cc.o)
      EmuSC::Wavetable::next_sample() in libemusc.a[16](wavetable.cc.o)
      EmuSC::Wavetable::next_sample() in libemusc.a[16](wavetable.cc.o)
      ...
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/emusc.app/Contents/MacOS/emusc] Error 1
make[1]: *** [src/CMakeFiles/emusc-client.dir/all] Error 2
make: *** [all] Error 2

Any ideas?

Andreas

On Debian 11 during initialization, it displays:

EmuSC: Configuration file found at /home/*****/.config/emusc/emusc.conf
EmuSC: SC-55 control ROM found [version=1.21 date=91/08]
EmuSC: PCM ROM(s) found and decrypted [version=0.20 date=1990-09-12]
EmuSC: GS mode initialized
EmuSC: MIDI sequencer [ALSA] client started at address 128
EmuSC: Error during initialization:
  -> [ALSA] Can't set interleaved mode. Operation not permitted

It's a way to add asio support on Windows x64? To play it in real time ...
Stupid question? Sorry ...
Thanks

Hey, I saw your project on a Github search and I was curious about it due to it being an interesting thing you're tackling with this, that is the emulation of proper SC in the future instead of needing to rely on soundfonts which would make things like mt32-pi but instead sc55-pi possible and all! And I was wondering if support for the SD series could also be considered in the farther future? (After the SC-series, or at least SC-55 and SC-88 have been dealt with) since SD-series also are part of the Sound Canvas series by Edirol/Roland and all.

Cheers!
MetalMaxMX

I'd like to add some information to your excellent research.

Drum set

This table shows the correspondence between the program number and the internal drum set number.

As a side note, the SC-33 also has "AC." hidden drum sets, which are assigned to program numbers 112-115 respectively.

Initial values

Initial values of the internal state. The SC-55 stores its internal state at 0x8000-0x905F in its RAM. This area is sent and received by bulk dump transmission and reception.

Since these initial values are the same as the internal representation of the bulk dump message, omit a description of the individual bytes.

SysEx

The SysEx definition area consists of the above 5 tables. Each table consists of the following 10-byte areas for each address.

SysEx definitions (10 bytes)

• The set of SysEx definitions ends with the terminator 00 00.
• "SysEx (Patch Part 2n) definitions" don't have the terminator. But, the first two bytes of the SysEx definition immediately following it are 00 00, so there seems to be no problem without a terminator.

Hello!! after seeing this amazing compile and gotten it to work with the mk 1 rom.
the 'ooh' bank seem to play every sound in the rom.

In EmuSC there seems to be no resample filtering. I don't know if it works on your system or not, so I can't know if there is no resample filtering on your system.
On my system it sounds like if you took a high-quality sound and applied a bit-crusher to it, that's the kind of sound I hear.
Maybe you're just being faithful to the original system but I don't know.

Without resample filtering the sound feels very electronic or digital.

I propose to add:

• JACK Audio support
• CMake compilation model

Just wanted to check in on this project. I noticed that the readme still says that the project is "in an early development stage", although there hasn't really been an update to the readme in at least a year. Does that still remain accurate? If not, what kind of stage would you say the project is in currently?

The Roland CM-300 is basically an SC-55, but without any advanced controls.

Hi, I selected Qt audio engine instead of Core Audio and then emusc.app started crashing on startup.

I found where QSettings stores preferences (~/Library/Preferences/com.emusc.EmuSC.plist) and removed the Audio.system value. Also on macOS, you have to run killall -u $USER cfprefsd to prevent the plist from being cached.

Maybe add this tip to troubleshooting section.

An error in run_synth will not be returned to main.

i have my roms, i have my folder, put the roms into the program

clicked on the power-on, now it doesn't work, refuses to start.

It's not really an issue and more of a genuine interest.
As you might already know, there's Nuked-SC55 emulator, which despite being in early stage, already sounds great. And so, I want to clarify the differences between your projects to avoid possible confusion in the future.

When MIDI note-off events arrive near simultaneously, sometimes notes get stuck. (macOS)

SCC-1 is an SC-55 as a PC add-in card. Would be worth adding support for it. SCC-1A is the SC-55 MK2 equivalent card. I've started to add support for this, It looks like it mostly works. I would like some assistance with it.
This is the output I get, All I did was add two new entries in the enums for control roms and updated the control rom scan for SCC1... I'm playing Wing Commander 3 DOS Midis (made for Sound Canvas/work in EMUSC) and they do playback with the SCC-1 Roms! Just getting this illegal drum set message.

EmuSC: SCC-1 control ROM found [version==1.3 date=]
EmuSC: PCM ROM(s) found and decrypted [version=1.20 date=1991-01-11]
EmuSC: GS mode initialized
EmuSC: MIDI sequencer [ALSA] client started at address 128
EmuSC: Audio output [PulseAudio] successfully initialized
-> s16le 2ch 44100Hz
EmuSC: MIDI input event [Port subscribed]
EmuSC: Illegal program for drum set (48)
EmuSC: Illegal program for drum set (48)

I know this is pretty early to ask but how possible is it to implement a feature that outputs the MIDI playback to .WAV and other formats? I ask because whenever I do livestreams or make videos, I tend to batch convert them to MP3s for easier playback. I would've recorded all of the MIDIs but that would take a long time.

Also nice to see a emulator for the SC-55 being developed btw.

I have built EmuSC and used the bundle script, but I get this error upon launching.

Built using Windows 10 x64

I can't in any way compile the project for Windows with MinGW64 (MSYS2). On Windows it is much more practical and functional to compile with Visual Studio (and vcpkg).
Other projects make use of CMake which, reading on the internet, seems more versatile than the method used now. But I'm not an expert so I might be wrong.

Right after powering it on, it crashes and give me a segfault. Also, to even get it to compile I had to add a custom M_PI definition.
Followed the instructions.

I realise that it's most likely on my part, but I have this issue when trying to power up EmuSC.

Control ROM version is 1.21. Maybe another version should be used?

I have compiled this for Win x64. In spite of using EmuSC in combination with the correct SC-55 ROM files and loopMIDI (properly configured), I am not getting any music output.

The software work's great in the start and seems alright, but if there come's multiple instruments's, it will eventually crackle and pop in the audio, is that being worked on? it could be a memory issue in likely plausible cause.

I know somebody on discord who would gladly aid with a real sc 55.

Just wanted to bring more attention to things, but first off. The biggest thing appears to be the samples.

The way the samples are done I think is something interesting in itself. Every sample has tuning data for both the base sample and loop split. This was a big issue during the making of my SoundFont and why I ceased the development entirely.

This here may help you. I fiddled with a Distortion Guitar sample and I had the base sample without the loop set at 18654Hz for note A#3, but correcting the loop to a SCVA recorded sample, the rate for just the loop by itself had to be moved down to 18589Hz.

So converting it back to the rate of the sample back to 32000Hz as determined, the rate of the loop would be 31889Hz for that particular sample. It being 32000Hz and only having the loop starts and ends won't stop the detuning, best example can be heard in At Doom's Gate (d_e1m1.mid) where the guitars sound a bit off.

Other issues besides this? One of them would be the root keys. I'd noticed it more for the drums, as the toms and cymbals would sound too high or low pitched. Later I think it'd be good to add interpolation features for the samples. Right now it seems to just be linear, but sinc interpolation would 100% help it sound as smooth like the module outputs it.

I hope to see more progress and improvement soon! I'm curious to see how you'll tackle the reverb and chorus, but this project is definitely one of the most exciting haha.

Hi there! 🙂

First off, great idea for a project! I'm in regular contact with Kitrinx (who as you know worked on the ROM reverse-engineering with NRS) and there have been discussions between us about using this knowledge to try and create a new SC-55 synth (the idea of extending Munt or hacking unofficial extensions into the SoundFont spec for FluidSynth were bounced around), but we have been too distracted with other things to get started, so it was great to come across this repo.

I've been working on a project called mt32-pi which is a baremetal Raspberry Pi-based MT-32/SoundFont synth based on Munt and FluidSynth. FluidSynth is obviously great at what it does, but the SC-55 has more advanced envelopes and other features that aren't possible to do within the SoundFont spec, so it is still very desirable to get a better SC-55 emulation into the project.

I appreciate it's very early days for EmuSC, but I've already had a look at the code to see what it would take to get it ported to baremetal.

I'd love to see the core synth engine decoupled from any front-end, application, or file IO stuff so that it can be integrated into other applications more easily - in other words, it'd be great to be able to compile a "libemusc.a" and just have a bunch of headers that give me an API to initialize the synth, set some config options, hand it some MIDI data, and pull out some audio samples. It's already pretty close to being this way, but I'd have to replace the Config class with something that doesn't throw exceptions or write default config files to disk. Being able to handle ROM loading manually would be useful, e.g. initialize Control/PCM ROM objects with my own file paths (or even byte arrays that I've filled myself), and then pass those to the Synth object.

It'd also be great to see everything namespaced under EmuSC:: to help keep external code separate from integrators' code.

Munt's API design is quite friendly for integrating it as a library, so maybe it could serve as some inspiration for EmuSC's design?

Anyway - just some ideas from the perspective of someone who'd be interested in integrating this work as it matures - again, I appreciate it's early days and very much work-in-progress. 🙂

Cheers, and keep up the great work!

On my system, when choosing Casio MIDI device, the input packets are of length 6 and instead of data indices 0, 1, 2 the correct data is in data[3], data[4], and data[5].

If I changed the code in emusc/emusc/src/midi_input_core.cc to

send_midi_event(data[3], data[4], data[5]);

then my Casio MIDI keyboard worked

Congrats on the first release! Now with a new release out, perhaps more reports and contributors could step and help in with the codebase! I would just like to know something though.

Is there going to be any roadmap of how the software will be developed from now on? What features will be next? What needs to be done? At least, like a form of checklist or something in order to gauge how far we are and what else is required for a better emulator.

One more thing. The emulator is currently targeted for the SC-series, in particular, the SC-55 series and beyond. An user at Vogons had an image of all the ROMs that were compatible for this emulator and I was wondering but one of those also had the SC-88 in the cards. Does that mean that compatibility with the SC-88 could be something to consider in the future?

Cheers!
MetalMaxMX.

Not really an issue here, since it's most likely my own stupidity, but when I assign MIDI input device and EmuSC (To specify, I installed latest pre-release, build-202205042314) seems to work, I receive no sound in FSMP.
Though, I might expect that it would sound exactly the same as the latest 0.1.8 build, so I probably wouldn't lose much.

P.S.: I really hope the work on EmuSC hasn't stopped, because I didn't really hear any news about it in 3 months already.

When switching to another song, EmuSC lowers sound by 1 semitone. But when switching to yet another song, EmuSC tries to return to normal tone after a couple of seconds while song plays and then it just goes out of tune.

On the topic of CPU issues and regressions, I think it would be really useful to have some kind of utility for benchmarking performance and testing for regressions.

This doesn't have to be formal test code or integrated into Github actions for now. It could be a little script or C++ file.
It just needs to render some MIDI fixtures to WAV files and spit out some perf stats comparing local changes to master.

Then we'll be in a good position to improve performance.

The advanced version of this would automatically run against pull requests and attach its output to the PR, but again, that's not really necessary.

WDYT?

After running

cmake . -DCMAKE_PREFIX_PATH=/opt/homebrew/opt/qt@5

The command succeed with output

-- 
--  EmuSC client interface summary: 
-- -===============================-
-- 
-- Platform: macOS
--  * Build bundle: 
-- 
-- Qt version: Qt5
-- 
-- Audio APIs:
--  * ALSA  : no
--  * Core  : yes
--  * Jack  : no
--  * Null  : yes
--  * Pulse : no
--  * Qt    : yes
--  * WAV   : yes
--  * Win32 : no
-- 
-- MIDI APIs:
--  * ALSA  : no
--  * Core  : yes
--  * Win32 : no
-- 
-- Make sure all needed APIs are found before you continue
-- 
-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/djmusic/PROJECTS/EMUSC/emusc/emusc

But then when running

open src/emusc.ap

The error is:

The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10827 "kLSNoExecutableErr: The executable is missing" UserInfo={_LSLine=4129, _LSFunction=_LSOpenStuffCallLocal}

And if I try to read the contents of the bundle, I find that the Contents/MacOS folder is empty

ls src/emusc.app/Contents/MacOS

Any ideas?

Right now the library is licensed under LGPLv3 which makes it not usable by GPLv2-licensed emulators.

It ideally should get licensed under LGPLv2.1+. The mt32emu library is licensed under that for instance. It would allow the library to be used in GPLv2-licensed emulators like DOSBox-X, dosbox-staging, PCem and 86Box.

(I do see potential problems with re-licensing code from this PR: #19. I think a revert here is better, or if not feasible, a rewrite, if it didn't happen already.)

autoconf does not add -std=c++11 for clang
https://stackoverflow.com/a/37726436/1430535

The first time instructions tell me that I need to configure the ROM files, and when I go to preferences I see the place to configure this. But I don't know what a ROM file is or where to find it? Have tried to look a bit in various folders in the project but not able to find anything related.

After launching the app and configuring ROM files, I quit the app, but then upon relaunching it, it would not start, but gave error:

libEmuSC: GS sound map initialized
zsh: segmentation fault  ./emusc.app/Contents/MacOS/emusc

Perhaps related to old issue: #16

Whenever I turn the synth off and then back on, it does not use the value of the Volume knob, instead it uses a starting value. It does this without changing the value of the knob itself. To fix this, I turn the knob a bit every time after I "power cycle" the synth through the power button.

Linux hpzbookfireflyg9 6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) x86_64 GNU/Linux
Debian 13 Trixie.
Built from sourcecode.
QT/PulseAudio/Alsa drivers.
44100/48000 KHz tested, tried changing buffer size to 0/7500/75000/750000. No luck on any of them.
System is running Wayland and Pipewire audio. Audacious plays back MP3s without issues.
aplaymidi -p128:0 file.mid, and pmidi -p128:0 file.mid tested with Hocus Pocus Track 6 midi. As well as other files (including Duke Nukem Grabbag).

Please don't mention things like "downloading ROM files from the internet" for your own safety.

README in libemusc says:

In order to emulate the Sound Canvas you need the original control ROM and the PCM ROM(s). These ROM files can be extracted from a physical unit by desoldering the ROM chips and read their content.

Does the project aim to emulate a CPU and execute binary instructions from the control ROM? Or only extract relevant instrument parameters from the control ROM, to be used in conjunction with sample ROM data? (In effect, a high-level/functional emulation.)

This would be obvious from the source code, but I thought it would be good to say up front in the README as part of stated project goals.