The changes work, with one caveat: you should keep the midi prefixes in the preferences query:

portname = s.value("midi/input_port", midihub.default_input(), str)
pollingtime = s.value("midi/polling_time", 10, int)

because without doing this, the default port is always chosen.

Or (and I think this is the best option, since they seem redundant) remove them from the preferences as well (and also remove the 'player' prefix from 'player/output_port', since it only appears in one place in the code).

Or (and I think this is the best option, since they seem redundant) remove them from the preferences as well (and also remove the 'player' prefix from 'player/output_port', since it only appears in one place in the code).

I agree: the prefixes don't seem to add any value.

Good catch. I removed the redundant prefixes and added some code to automatically clean up the config files.

Note the couple remaining uses of prefixes are deliberate:

# This line from frescobaldi/miditool/widget.py...
p = QSettings().value("midi/output_port", midihub.default_output(), str)

# is equivalent to...
s = QSettings()
s.beginGroup("midi")
p = s.value("output_port", midihub.default_output(), str)

Note the couple remaining uses of prefixes are deliberate:

# This line from frescobaldi/miditool/widget.py...
p = QSettings().value("midi/output_port", midihub.default_output(), str)

# is equivalent to...
s = QSettings()
s.beginGroup("midi")
p = s.value("output_port", midihub.default_output(), str)

Yes, I know about this equivalence. But I had the impression - I may be wrong of course - that this could not be true in macOS. Otherwise, why MIDI settings worked fine on Linux and Windows but not on macOS?
@inkandpaper-app may know this better than me.

I wasn't sure what was happening, but it seemed like an extra /midi/ was appearing in the preferences file without the beginGroup line. However with these changes everything seems to be working fine.

I wasn't sure what was happening, but it seemed like an extra /midi/ was appearing in the preferences file without the beginGroup line.

The extra /midi/ was present on all platforms because the preferences code used both beginGroup() and prefixes.

I can't do a MIDI input test before Monday night. But if you tested it already and feel confident about this PR, feel free to merge it. I want this to be part of the next release.

I've tested it briefly, but since this isn't a feature I regularly use I'd rather wait for more feedback before merging.

FYI, @ksnortum sent me an improved version of LY_REG_EXPR that I'd also like to try at some point.

I've tested it briefly, but since this isn't a feature I regularly use I'd rather wait for more feedback before merging.

I haven't had time to test it yet.

I've launched the workflow to build the Windows and macOS packages and I will ask some users who reported problems with MIDI input to test these packages.

@bmjcode As far as I can see, I can manually trigger the GitHub Action workflows only on branches pushed to the upstream repository. This time I pushed your midiinput branch to the upstream repository (and I'll have to remember to delete it once this PR is merged). As you have push access on the upstream repository, why don't you make a habit of always pushing there so we can easily run the workflows if needed as in this case? Branches are deleted once the PRs are merged so it's not going to mess around the active branches.

As you have push access on the upstream repository, why don't you make a habit of always pushing there so we can easily run the workflows if needed as in this case?

Yeah, I've been meaning to switch that over but just hadn't gotten around to it yet.

FYI, @ksnortum sent me an improved version of LY_REG_EXPR that I'd also like to try at some point.

@bmjcode Do you want to try it later? Can we merge this now?
The macOS user who reported the problem tested this PR and confirmed that it's been solved.

@fedelibre Let's merge this now so it's working in this release. We'll save further improvements for the next one.