[MacPorts] #71006: qsynth: Issues with MIDI Bank select

MacPorts noreply at macports.org
Wed Oct 2 15:26:10 UTC 2024


#71006: qsynth: Issues with MIDI Bank select
-----------------------+-----------------------------
  Reporter:  Sixty4ce  |      Owner:  RJVB
      Type:  defect    |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:  2.3.4
Resolution:            |   Keywords:  monterey x86_64
      Port:  qsynth    |
-----------------------+-----------------------------

Comment (by RJVB):

 Replying to [comment:4 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.)

-- 
Ticket URL: <https://trac.macports.org/ticket/71006#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list