qsynth: Issues with MIDI Bank select

[Sixty4ce (Sixtyforce)]

Hi there!

I've ran across an issue with this MacPorts version of Qsynth that I've not encountered on Linux. Using a MIDI and matching soundfont that I extracted from a Nintendo DS game, the Linux version plays the song just fine, but the macOS version does not, seemingly ignoring the program change and bank select parameters being fed to it, with everything mapped to the same synth when it's not supposed to be.

I don't know if this is an issue with this version of Qsynth in particular, if it's the macOS version of WINE, if it's coremidi itself, I'm not really sure. But if someone could point me in the right direction somehow, that'd be lovely.

Thanks!

(Early 2015 MacBook Pro running macOS 12 Monterey)

Linux (Correct synths)

macOS (Incorrect synths)

[RJVB (René Bertin)]

Why does the screenshot say QSynth2 while the version in MacPorts (0.5.7) says QSynth1 for me? You mention WINE, are you in fact running an MSWin version of QSynth under that emulator?

What happens if you point the fluidsynth executable itself to the soundfont and MIDI file in question?

Anyway, this has to be an issue with either qsynth or fluidsynth, and ought probably be reported upstream. And I'm sure I've said this before: I never understood the point of qsynth, probably because the GUI isn't intuitive to me. So TBH I am not even certain what the preset dialog is supposed to show - the local presets or whatever is defined in the MIDI file.

[Sixty4ce (Sixtyforce)]

Replying to RJVB:

Why does the screenshot say QSynth2 while the version in MacPorts (0.5.7) says QSynth1 for me? You mention WINE, are you in fact running an MSWin version of QSynth under that emulator?

No, I'm definitely using the MacPorts version of Qsynth. It's just that Qsynth lets you run more than one synth engine. On Linux, I have Qsynth1 set up with a Microsoft GS replica soundfont, and Qsynth2 is set up with that extracted soundfont. I thought that maybe using the soundfont on a second synth engine would make it work better, but that was quite a silly long shot (Qsynth1 is muted and unused at the moment on macOS). I am running TMIDI (Tom's MIDI Player) in WINE though, which I also do on Linux (TMIDI in WINE with Linux Qsynth) because it's got the best support for niche MIDI features like SysEx that are crucial for old Roland/Yamaha boxes and their related emulators, plus it's very stable and doesn't have any lag issues. I have absolutely no compatibility issues with this Linux Qsynth/WINE TMIDI combo on Linux, so I presumed the problem to be with the MacPorts version in particular.

What happens if you point the fluidsynth executable itself to the soundfont and MIDI file in question?

I wouldn't know, because I actually don't know where that would be stored. If you could give me a file location to look in, that'd be fantastic thanks!

Anyway, this has to be an issue with either qsynth or fluidsynth, and ought probably be reported upstream. And I'm sure I've said this before: I never understood the point of qsynth, probably because the GUI isn't intuitive to me. So TBH I am not even certain what the preset dialog is supposed to show - the local presets or whatever is defined in the MIDI file.

It's meant to show what the MIDI file is specifying, and the fact that it's not means that Qsynth is ignoring it. Right now, it means that every synth in the song that I'm playing (from Mario Kart DS) is mapped to a lead synth, when there's also supposed to be drums, bass, piano, organs, etc. The dialogue there is meant to illustrate that Linux shows them all mapped correctly, with their corresponding program change numbers as defined by the MIDI, but the MacPorts version does not.

I also wasn't sure if I should report it upstream, given that the MacPorts version is, just that, a port, a community-maintained project and probably not supported by the Qsynth dev(s). But if it is, and they're willing to listen, then I might shoot them a message about it as well. But I thought it better safe than sorry to leave a ticket here first just in case.

[RJVB (René Bertin)]

Replying to Sixty4ce:

It's just that Qsynth lets you run more than one synth engine.

Right, I realised that too, later.

What happens if you point the fluidsynth executable itself to the soundfont and MIDI file in question?

I wouldn't know, because I actually don't know where that would be stored. If you could give me a file location to look in, that'd be fantastic thanks!

?? Surely you know where you put your soundfont and the MIDI file! Assuming they're in the same directory the easiest thing to do would be to chdir into that directory in your favourite terminal application, and type fluidsynth followed by the names of the soundfont file and the MIDI file.

It's meant to show what the MIDI file is specifying, and the fact that it's not means that Qsynth is ignoring it.

It's a list of presets so if you happen to have a preset called "default" (on your Mac but not on Linux) it's quite possible that it will show that one rather than whatever the song calls for.

I also wasn't sure if I should report it upstream, given that the MacPorts version is, just that, a port, a community-maintained project and probably not supported by the Qsynth dev(s). But if it is, and they're willing to listen, then I might shoot them a message about it as well.

Having a port of a project doesn't make it a specific MacPorts version. In fact, that would be against MacPorts dogma if I interpret correctly what some people have been trying to tell me. In the case of this particular port the only tweaks are to the build system so that it generates a proper Mac app bundle, and as far as I can see many of those tweaks have been incorporated upstream. It looks like the current version (1.0.2) doesn't really require any patching anymore So a priori, anything that doesn't work as it should is an upstream issue.

I'll attach a patch to upgrade the current port version to the latest upstream release, adding a (proper) legacy-Qt patch AND ONLY TESTED ON LINUX (not at my Mac at the moment). If you want, please check if the issue persists in that version and if it does, report it upstream and let them decide if they want to bother trying to fix it. NB: if the patched port fails in the destroot stage you will be able to find the app bundle somewhere in the build directory: most likely in open `port work qsynth`/build/src .

(And Mojca can use this patch to upgrade the port, whether this fixes the issue or not.)

[RJVB (René Bertin)]

(cd port dir qsynth ; patch -Np3 -i qsynth-057-102.diff)