Addressing the portamento issue

[spessasus]

So,
#705, #1232, #1311 and #1456 all point to one thing: Fluidsynth should have a "quirky" portamento mode to work with older MIDI files.

Now what is a "quirky" mode? It's the mode that would work with the old GS & XG MIDI files, which seems to use only the MSB portion of the portamento time and is sort of "exponential."

Clues we have:

• @johnnovak already did some experimenting on the topic with a real SC-55
• BASSMIDI seems to work fine with the MIDIs that use portamento, though the only thing I found was this thread in which Ian is very vague about the way it has been implemented.

I understand that the current portamento mode is important and needs to stay, so something like a toggle (-o synth.portamento=quirky?) could work. The default would be standard which is the current behavior, and quirky would be this strange portamento time mode.

I'll try to look deeper into it as I want to implement that special portamento time in my synth as well, so I'll post any discoveries I make here.

[johnnovak]

@spessasus Probably Roland invented that weird curve, so probably all Sound Canvas modules use that. Then all other modules thst aimed to be somewhat GS standard compatible (e.g. the Yamaha MU series). So probably gs or roland-old is a better name that quirky which doesn't say much 😆

[spessasus]

That's fair, though some Yamaha XG MIDIs I have also seem to use the same portamento time logic as they work fine on BASSMIDI. That's why it would not be only GS but also XG? Or do they just share the logic?

[derselbst]

I vote against introducing yet another setting for this. People will still play these files, they will still sound wrong, and people will report issues.

Instead, can't we just make this dependent on synth.midi-bank-select ? It seems that this behavior should be triggered with gs and xg bank modes. Also keep in mind that this mode is selected automatically, when a SysEx message is received.

[spessasus]

Since gsis the default mode, you're effectively proposing making this portamento the default behavior. While I'm not against that, I thought you'd be against changing the default portamento behavior, as you've mentioned in one of the issues that people rely on the current implementation. That would break a lot of things, wouldn't it?

[derselbst]

Well... yeah. It's tricky. If a MIDI has a GM system on message or people select a different bank-selection mode, you'll get the previous behavior. I admit, I'm having twisted minds here. @jjceresa Do you have an opinion on how we should deal with portamento time 7bit vs 14bit?

[spessasus]

Alright, I think I may have something working here.

So I've just implemented that portamento in spessasynth that seems to work fine with all portamento files I have (including the now infamous game08.mid.

The way it calculates the time in seconds is the following:

timeSeconds = linearInterpolate(johnsTable) * keyDistance / 24;
So I linearly interpolate that table John made and multiply it by keyDistance divided by two octaves. Why? I just kept changing values until it sounded fine :-)

If someone with an SC-55 can confirm that it works correctly, then fluidsynth can use the same logic as well for the gs portamento mode.

I've attached two more files that make use of portamento. Both XG:
portamento.zip

Thoughts?

[spessasus]

Linking the relevant code for reference:

https://github.com/spessasus/SpessaSynth/blob/master/src%2Fspessasynth_lib%2Fsynthetizer%2Fworklet_system%2Fworklet_methods%2Fportamento_time.js

[johnnovak]

Great work @spessasus 🎉 Glad to see you could make of my reverse-engineered portamento curve data!

If someone with an SC-55 can confirm that it works correctly, then fluidsynth can use the same logic as well for the gs portamento mode.

I have two SC-55 units, so I could run through some MIDI test cases for you, but it's a lot simpler if you just used Nuked SC-55 for testing. Not sure if you're familiar with the project, it's a low level Roland SC series emulation, so needs original ROM dumps, etc. Very similar to Munt for the MT-32.

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

I've done extensive Nuked SC-55 & hardware comparison, and it has 100% accuracy, so test your portamento stuff with it with full confidence!

I created a CLAP plugin version of the thing that you can then load into REAPER, so yeah, you can use that too for testing:
https://github.com/johnnovak/Nuked-SC55-CLAP/

Lastly, I've added support to DOSBox Staging for my Nuked-SC55-CLAP plugin, so you can also test it there in a DOS environment or with games if you want. Scroll down to Manual testing / Usage in the long top description for setup info.
dosbox-staging/dosbox-staging#4090

[spessasus]

@derselbst I think I may have a solution to the portamento mode.

It still would be a synth parameter, preferably synth.porta-mode or synth.portamento with two values fluid and legacy.

It defaults to fluid which is the current behavior. legacy would be the XG/GS 7-bit portamento time.

And now there are two solutions:

Automatic switching

This solution would switch the mode to legacy once the system has been changed to GS or XG explicitly via SysEx messages. This means that using synth.midi-bank-select=gs would not trigger the legacy mode. (It can be turned on by passing synth.porta-mode=legacy though)

Explicitly stating the porta-mode to be fluid disables this behavior. Also if the portamento time LSB is received at any point, the synth instance is switched back to fluid permamently as it's a clear indicator of the user intending to use the complete resolution.

This way if the user uses fluid portamento, I don't think that they will be sending GS or XG resets, given that they can (probably) interface with the synth directly if they are using its portamento model.

Pro: should "just work" most of the time.

Con: if user is sending XG/GS resets, this will trigger legacy by default. So, a breaking change. Though only MSB and XG/GS + fluid portamento would be quite a rare use case.

Warning

This solution prints out a warning to the console. Legacy portamento detected: consider using synth.porta-mode=legacy for correct playback.

Same conditions as above, except instead of changing portamento mode, we print out a warning, hinting the option to the user.

Pro: Not a breaking change.

Con: Would only work in the CLI, as programs like Qsynth wouldn't display the warning.

Thoughts?

[johnnovak]

The problem is many DOS games don't send a GS reset. Or the person who created some MIDI recording assumes GS mode and they don't include a GS reset at the start of the MIDI. Or the game sends the GS reset sysex from the code, but the MIDI files in the game data don't contain embedded GS resets (this is common). So "naive" MIDI rips won't contain them either. Then whatever MIDI player you use to play them back might or might not send a GS reset before playing a tune.

So yes, such auto-detection might work in many scenarios, but it's far from a 100% solution. It's rather error-prone given the above factors.

The other thing, the Sound Canvas devices and the Yamaha MU series can be put into GS or GM mode via SysEx. What then? I haven't tested this, but I would bet on it these devices have identical portamento behaviour in both GS and GM modes.

You could test this with NukedSC55, but to sum it up, at least from my perspective which is using FluidSynth in DOSBox Staging, it seems setting this as a startup config option is the only reliable way.

IMO, a flaky automatic behaviour is worse than clear explicitly configured behaviour.

[spessasus]

Alright, so solution number 2 (warning) would be good, but I just had another idea, a very simple one.

If nothing is set, assume legacy.

If at any point the synth receives portamento time LSB, it switches to fluid.

Here's why.

As we estabilished earlier, GS/XG portamento only uses MSB. Fluid's portamento uses both. So if the user uses fluidsynth's portamento, they will almost certainly send an LSB, because MSB only allows 0.123 second intervals which is not really precise enough with fast portamentos.

If the user doesn't send an LSB and intends to use the fluidsynth portamento mode, at worst there won't be any portamento at all, since 1 is extremely short in the GS/XG time. But that's way better than the horribly detuned saw in game08, isn't it? Still, that's a breaking change...

What do you think about this one? Or should we just stick to the warning in console?

[johnnovak]

In all honesty, we will just set the config param at startup. Unless switching the unit into GM mode changes the behaviour, in which case we'll need to intercept the GS/GM reset sysex and reconfigure FS. So yeah GM mode is a question mark.

I think that LSB trick might be good general behaviour for FS, just our use case in Staging is a bit different.

[spessasus]

GM mode would not change anything. This trick would always be on if the user has not explicitly specified the synth.porta-mode. DOSBox could always specify legacy so it would be off.

[derselbst]

Ok, so to summarize the discussion so far: @spessasus is suggesting to introduce a new tri-state setting:

• auto mode is the default and would use 7bit portamento time MSB, unless it sees an LSB event (on any midi channel), in which case it would switch the entire synth engine over to 14bit portamento time,
• legacy mode (more precise name appreciated), which would stick to 7bit portamento time MSB, and
• fluid mode (more precise name appreciated as well), which would stick to 14 bit MSB+LSB portamento time.

Correct so far?

(pinging @jjceresa again)

[johnnovak]

While linear is a good name, I have to remind you that this weird portamento is also present on XG devices and MIDI files (see fluid's test files). So Roland or sound canvas is not a good name.

Well, Roland invented it. Then other manufacturers like Yamaha copied that in their XG standard. But it's "Roland portamento", copied by Yamaha.

[spessasus]

That's true, but the user who doesn't know that and wants to play an XG file would have no idea that this is the mode they want to use. How about xg-gs? I think it's descriptive enough and tells the user that this is the mode they want to choose if they want to play GS or XG MIDIs.

@derselbst what are your thoughts?

[johnnovak]

Good point. xg-gs or gs-xg sounds fine to me, yeah. gs-xg is better; GS came first, and it's A-Z order.

[derselbst]

So, xg-gs for 7bit MSB convex Roland curve, and something like linear14 for fluid's MSB+LSB mode?

[spessasus]

I think just linearshould be enough honestly.

[spessasus]

Here's a new XG MIDI file that uses portamento on channels 11 and 12 (counting from 0). Useful for testing.

MegaMan6_MrX_XG.zip

[derselbst]

Sounds like we have a plan. Will be tracked and implemented in #1517.