Portamento Compatibility Patch for FluidSynth?

[KyleJ61782]

So I've been playing a lot of music through my mt32-pi and noticed that one of the Descent midis (which are generally broken, but can be fixed) uses portamento and it sounds horrible through mt32-pi. I noticed when played through my SC-8820 that it sounded much more musical and confirmed that with the command line FluidSynth tool that it sounds identical to the mt32-pi. However, that said, it does not sound particularly nice and doesn't replicate what can be heard through other synths like BassMidi or Roland.

Since these devices are likely to be used for retro computing and Roland, et. al. will be considered the likely high bar for sound, does it seem reasonable to patch FluidSynth so that it sounds closer to a Sound Canvas? I submitted a bug report (unknowingly a duplicate, actually) and they report that it works as designed. Here's the bug report: Messed up sawtooth channel in Descent game08.mid #705. They report that it's likely that Roland, et. al. treat portamento time as only a 7-bit value, and so it's going to be much shorter in duration than how FluidSynth will interpret it.

So...having said all that, I've patched FluidSynth myself and recorded the results. Here are all the comparisons using Game08.mid (can get it here) from Descent:

• FluidSynth portamento interpretation: https://drive.google.com/file/d/171h5Rw1DpnDDHqql0ZxPdbltPTiwXbH8/view?usp=share_link
• BassMidi portamento interpretation: https://drive.google.com/file/d/170xi-kHXCypR_fYRkUxBGk188b5u6QwI/view?usp=share_link
• FluidSynth portamento 7-bit patch interpretation: https://drive.google.com/file/d/17FM-7cTSnq6uRgR7k-yyDcOEUQsfz9S4/view?usp=share_link

Here's a link to the patch that will patch the mt32-pi source to include this different portamento interpretation: https://drive.google.com/file/d/17HyyTDC6IA6TXBK840NewxNsU4xY-HYT/view?usp=share_link

Thoughts?

[dwhinham]

This is quite interesting, thank you for the information and the patch. I wasn't aware of the differences in portamento behaviour.

So although most people are using FluidSynth as a stand-in for a SoundCanvas in the absence of a proper emulator (though https://github.com/skjelten/emusc is making some progress) I'm not sure maintaining a hacked version of FluidSynth to try and make it closer to an SC-55 is something I want to do here, because there are going to be more quirks and it's not really within the scope of the project.

I do understand that people use mt32-pi for games though, and they are going to want them to sound not broken.

Seeing as this quirk can be worked-around by manipulating the MIDI messages, this would be a good fit for the Lua scripting engine feature I've been thinking of adding. With it, you can hook MIDI events and filter them out or alter them before they get passed to the synth.

An example script which fixes this:

function OnMIDIShortMessage(status, data1, data2)
	local statusNybble = status & 0xF0

	-- Re-map portamento time MSB to LSB for compatiblity with SC-55
	if statusNybble == 0xB0 then
		-- CC #5 - Portamento Time MSB
		if data1 == 0x05 then
			-- Convert to LSB message
			data1 = 0x25

		-- CC #37 - Portamento Time LSB
		elseif data1 == 0x25 then
			-- Drop the message
			return
		end
	end

	return status, data1, data2
end

I'd prefer to go for this approach as it's more flexible and people can write/contribute their own scripts to do various things. You could even do fun stuff like transpose everything into a different key or replace instruments.

The example in the WIP Lua branch has some commented-out experimental things; there's even some code that turns mt32-pi into a crude drum machine: https://github.com/dwhinham/mt32-pi/blob/lua/mt32-pi.lua

[KyleJ61782]

I think that's a fantastic idea. Will that require increasing the hardware requirements at all? Or is there enough performance margin for all supported Pi devices?

[dwhinham]

I'm glad you like the idea!

Of course everything has a cost, but the Lua interpreter is very small and lightweight. Performance has been good enough for use in games over the decades so using it for basic MIDI processing should be quite efficient.

There is also LuaJIT which could be much faster with its just-in-time compiler but I haven't tried integrating this version yet. I'll have a look at some point.

I tend to do all my testing on the slowest Pi I own, which is the Pi Zero 2W, and no problems so far.

[KyleJ61782]

Excellent! I know that branch is in active development, but I'm thinking I'll probably pull that down and play with it. Because not maintaining a personal patch seems ideal. 😊