Roadmap?

[MetalMaxMX]

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.

[Grieferus]

Good idea! I'd also like to share some things that we currently know about SC-55 audio output.

1) Samples are encoded in DPCM format since, considering the tech of that time, applying X2 RIAA filter would be too costy on module's CPU. 2) There's clearly some sort of sinc interpolation in use. 3) μ-law is used for companding. 4) Postprocess lowpass filter can either be used as fade-in (Lower notes are clear with higher notes getting gradually lowfreq), fade-out (Lower notes are lowfreq with higher notes getting gradually clearer), or as a constant value.

[skjelten]

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.

Thanks, and I hope you are right about contributors. The task of implementing the synth emulation in libemusc is one kind of programming / reverse engineering, the task of implementing the GUI, audio output and MIDI input across 3 platforms is very different. But they add up to a lot for only one person with limited spare time.

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.

A status matrix of all the different parts of the synth audio generation, some documentation on the reverse engineering effort beyond Kitrinx's google sheets and a roadmap have been on my TODO list for as long as I can remember. It's just that it will take some effort to structure and write this properly, so I have delayed it (or procrastinated) until a future time where it is likely someone will read it.

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?

The intention was to make emusc flexible to support any sound canvas synth, and there are still some comments in the code about things to remember if we add support for the SC-88 gen. The reason for why all references to the SC-88 was removed from the project's README files was that I realized this would be too much for one person - and it makes sense to more or less complete the SC-55 before looking at later generations.

[skjelten]

Good idea! I'd also like to share some things that we currently know about SC-55 audio output.

1. Samples are encoded in DPCM format since, considering the tech of that time, applying X2 RIAA filter would be too costy on module's CPU.

2. There's clearly some sort of sinc interpolation in use.

3. μ-law is used for companding.

4. Postprocess lowpass filter can either be used as fade-in (Lower notes are clear with higher notes getting gradually lowfreq), fade-out (Lower notes are lowfreq with higher notes getting gradually clearer), or as a constant value.

I was not aware of some of these points.

Could you elaborate a bit on the background for number 2 (sinc interpolation)? Emusc currently does not have any proper resampling / interpolation, just using the "nearest neighbor" approach. My intention was to implement cubic interpolation, hoping that would be enough for now. Sinc interpolation would probably require the use of libsamplerate or libsoxr.

[Grieferus]

About sinc interpolation, it's just the first thing I've came up with, because it's the option in Falcosoft Soundfont Midi Player. I've never actually performed any tests regarding interpolation because... I'm just unable to.

[Grieferus]

As of the postprocess LFO, fade-in is Reed Organ, fade-out is Warm Pad and I'm yet to find the constant value.

Now that I think about, it might actually behave similarly to "scale tuning" parameter in soundfonts.

[skjelten]

As of the postprocess LFO, fade-in is Reed Organ, fade-out is Warm Pad and I'm yet to find the constant value.

Not sure if I am able to understand what you are trying to do: Are you searching in the partial definition spreadsheet to find the byte value that corresponds to the time it takes to complete LFO fade-in and fade-out?

[Grieferus]

As of the postprocess LFO, fade-in is Reed Organ, fade-out is Warm Pad and I'm yet to find the constant value.

Not sure if I am able to understand what you are trying to do: Are you searching in the partial definition spreadsheet to find the byte value that corresponds to the time it takes to complete LFO fade-in and fade-out?

No, it's pretty misleading way to explain why, I think, LFO in SC-55 is note-dependent.

[mmontag]

FYI when a parameter depends on a note value, I think this is usually called "key tracking."

Also here's an example of sinc resampling in fluidsynth https://github.com/FluidSynth/fluidsynth/blob/master/src/rvoice/fluid_rvoice_dsp.c#L383

[Grieferus]

FYI when a parameter depends on a note value, I think this is usually called "key tracking."

Also here's an example of sinc resampling in fluidsynth https://github.com/FluidSynth/fluidsynth/blob/master/src/rvoice/fluid_rvoice_dsp.c#L383

Didn't know that!

[skjelten]

FYI when a parameter depends on a note value, I think this is usually called "key tracking." Also here's an example of sinc resampling in fluidsynth https://github.com/FluidSynth/fluidsynth/blob/master/src/rvoice/fluid_rvoice_dsp.c#L383

Didn't know that!

In the world of Roland, I think the most used term is "key follow". That is at least the term used in their more detailed documentation, such as for the JD-800 (see e.g. envelope parameters on page 4), and in EmuSC code.

Since your last comment I have tried to document our control ROM findings in a more readable format than the source code in the wiki. If you look at the table describing the instrument parameters you can see which bytes are used for the LFO 1. If you compare this with Kitrinx's spreadsheet you can see the static LFO fade in values for the different instruments. When I was working on figuring out this parameter I plotted the time it took from a C4 note on to full LFO signal for different instruments that had different ROM values. I do not think that I tested the fade in with different note values.

[skjelten]

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.

As mention in my previous comment we now have a some wiki pages - including a roadmap page. Still very thin, but we have at least a start.

[MetalMaxMX]

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.

As mention in my previous comment we now have a some wiki pages - including a roadmap page. Still very thin, but we have at least a start.

Oh, awesome! How about a website for the project? Or do you think that fits better once the project is on a more completed state?

[skjelten]

I think the github README + wiki is OK for now. The only thing I am considering is to enable the discussion function in github to have a discussion forum outside "issues". Would make sense if anyone wants to discuss reverse engineering efforts or other technical aspects not really an issue.

[MetalMaxMX]

Awesome! Glad that discussions have been opened then! Perhaps I could open up a discussion about a few things (website, SC-88) down there as well. Feel free to close the issue now!

Cheers! MetalMaxMX.