Incorrect results with stacked SoundFonts

[stuerp]

Hi,

I'm trying to add support for stacked SoundFonts to my foobar2000 component foo_midi. Both the RMI and XMF file formats support embedded SoundFonts. The embedded SoundFont takes precedence over the base SoundFont specified by the user.

I still haven't ruled out programmer error but I've been able to reproduce the problem with the pre-built fluidsynth.exe

• Windows 11
• Version: 2.4.3
• Command line: .\fluidsynth.exe --no-midi-in --quiet -o synth.midi-bank-select=mma -v FluidR3_GM.sf2 Streetwise.dls Streetwise.mid
• FluidR3_GM.sf2 is a basic free GM soundfont
• Streetwise.dls and Streetwise.mid have been extracted from Streetwise.mxmf (available on demand)
• Streetwise.dls contains 1 instrument in bank CC32 0x06 CC0 0x79
• Streetwise.mid contains track 14 that starts with a CC0 0x79 and CC32 0x06 on channel 8 (1-based).

Expected result: The sequence plays correct.
Current result: The sequence plays except that channel 8 sound like a telephone which corresponds to the default 0x79 GM program "Telephone Ring"

Any pointers or help are much appreciated.

[derselbst]

I need the extracted MIDI and dls to comprehend what's going on.

[stuerp]

I need the extracted MIDI and dls to comprehend what's going on.

Of course. Thank you for your reply.

This archive contains the MID and DLS: Streetwise.zip

This archive contains a FLAC file posted as being rendered on a Nokia smartphone: Streetwise (2004 Version).zip

[stuerp]

If it can help: the x64 version of foo_midi appears to load the embedded DLS but the x86 version fails on fluid_synth_sfload() with FLUID_FAILED. None of the callbacks of fluid_sfloader_set_callbacks() however fail:

• fluid_sfloader_callback_open_t returns a file pointer
• The others return FLUID_OK or a valid file size.

[derselbst]

Are you using fluidsynth's precompiled Windows binaries? If so, support for libinstpatch has been disabled in the x86 builds due to this problem: https://dev.azure.com/tommbrt/tommbrt/_build/results?buildId=11822&view=logs&j=ae601b3d-8756-52a4-4bcc-59c4d24c3f8c&t=1e42d489-b2c6-5e77-903e-6d797975357c&l=154

I'm currently not having time to take a deeper look into it, as there exist other high priority issues here, sry.

Since libinstpatch is disabled, loading a DLS file will fail upon fluid_synth_sfload(). None of the other callbacks is expected to fail, as they only deal with pure file access.

Does the tune sound as expected in the x64 for you?

[stuerp]

Are you using fluidsynth's precompiled Windows binaries? If so, support for libinstpatch has been disabled in the x86 builds due to this problem: https://dev.azure.com/tommbrt/tommbrt/_build/results?buildId=11822&view=logs&j=ae601b3d-8756-52a4-4bcc-59c4d24c3f8c&t=1e42d489-b2c6-5e77-903e-6d797975357c&l=154

I'm currently not having time to take a deeper look into it, as there exist other high priority issues here, sry.

Since libinstpatch is disabled, loading a DLS file will fail upon fluid_synth_sfload(). None of the other callbacks is expected to fail, as they only deal with pure file access.

Yes, the FluidSynth binaries are an optional package and have to be installed by the user separately in a directory of choice. The DLL is loaded dynamically.

Does the tune sound as expected in the x64 for you?

No. In my eagerness to ask the question I made a few errors in the numbers of the original question but the problem is real. Here is a dump of the start of track 14:

Track 14: 14 channels,    24800 ticks,    31.96s
       0        0 ticks     0.00s ( 0)  F0 FF 03 20 42 72 69 67 68 74 20 50 69 61 6E 6F .. Meta Data                     Track Name " Bright Piano "
       1       16 ticks     0.02s ( 7)  B0 79 00                                           Control Change                Reset All Controllers
       2       17 ticks     0.02s ( 7)  B0 00 79                                           Control Change                Bank Select MSB 79
       3       18 ticks     0.02s ( 7)  B0 20 06                                           Control Change                Bank Select LSB 06
       4                          ( 7)  C0 01                                              Program Change                Bright Acoustic Piano
       5       22 ticks     0.02s ( 7)  B0 07 6D                                           Control Change                Channel Volume 109
       6     7680 ticks     7.68s ( 7)  90 4B 4A                                           Note On                       Note  75, Velocity  74
       7     7879 ticks     7.88s ( 7)  90 4B 00                                           Note On                       Note  75, Velocity   0
       8     8059 ticks     8.06s ( 7)  90 49 4A                                           Note On                       Note  73, Velocity  74
       9     8139 ticks     8.14s ( 7)  90 49 00                                           Note On                       Note  73, Velocity   0

As you can see a bank switch to CC0 79 CC32 06 is requested followed by a program change to instrument 1.
It is exactly that instrument that exists in the DLS.

Without the DLS it sounds like a telephone ring.

[derselbst]

I think I found your problem: The midi performs a GM SYSTEM ON via SysEx at the very beginning. This effectively overwrites your synth.midi-bank-select=mma back to gm, causing any CC0 and CC32 to be ignored. I don't find a log message for this, I'll see where to add one.

The telephone is caused by channel 16, which does indeed select a telefone, by choosing program 124.

So if you want to replace the telephone with the sample of the DLS, set the bank number of the DLS instrument to zero (or 15494) and preset number to 124. Actually, the bank number in the DLS doesn't matter, because in gm bank mode it stays zero for fluidsynth, so fluidsynth internally will just fall back to zero.

[stuerp]

I think I found your problem: The midi performs a GM SYSTEM ON via SysEx at the very beginning. This effectively overwrites your synth.midi-bank-select=mma back to gm, causing any CC0 and CC32 to be ignored. I don't find a log message for this, I'll see where to add one.

The telephone is caused by channel 16, which does indeed select a telefone, by choosing program 124.

So if you want to replace the telephone with the sample of the DLS, set the bank number of the DLS instrument to zero (or 15494) and preset number to 124. Actually, the bank number in the DLS doesn't matter, because in gm bank mode it stays zero for fluidsynth, so fluidsynth internally will just fall back to zero.

Makes sense. Am I right that any of those changes need to be performed in code through some snooping of the MIDI stream (which is no problem; I'm doing it in other scenarios too)? Surely this can't be expected from the user?

[derselbst]

You mean to interfere / avoid that system on message triggering the bank-selection change? In this case, the easiest way would be to avoid sending any sysex messages to fluidsynth. Alternatively you can filter out that particular sysex message, here's fluidsynth's parsing code:

fluidsynth/src/synth/fluid_synth.c

Lines 2075 to 2097 in 0461d75

	/* GM or GM2 system on */
	if(data[0] == MIDI_SYSEX_UNIV_NON_REALTIME
	&& (data[1] == synth->device_id || data[1] == MIDI_SYSEX_DEVICE_ID_ALL || synth->device_id == MIDI_SYSEX_DEVICE_ID_ALL)
	&& data[2] == MIDI_SYSEX_GM_ID)
	{
	if(handled)
	{
	*handled = TRUE;
	}
	if(!dryrun && (data[3] == MIDI_SYSEX_GM_ON
	|| data[3] == MIDI_SYSEX_GM2_ON))
	{
	int result;
	fluid_synth_api_enter(synth);
	synth->bank_select = FLUID_BANK_STYLE_GM;
	result = fluid_synth_system_reset_LOCAL(synth);
	if(synth->verbose)
	{
	FLUID_LOG(FLUID_INFO, "Processing SysEX GM / GM2 System ON message, bank selection mode is now gm.");
	}
	FLUID_API_RETURN(result);
	}
	return FLUID_OK;