MS 3.5.1: Chord symbol playback wrongly enabled for pre-3.5 scores

• Oct 10, 2020 - 10:14
Reported version
3.5
Priority
P0 - Critical
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.1.293615790, revision: 12ab1d9

Open the attached score—which was created in MS 3.4.0. Play back the score.

Expected result: Chord symbol playback should be OFF? At least, according to the handbook. And this PR, https://github.com/musescore/MuseScore/pull/6259?
Actual result: Chord symbol playback is ON (also applies to MS 2 scores).

Attachment Size
chord_playback_issue.mscz 26.25 KB

Comments

Status active needs info

I was about to close this as a duplicate of the issue with the wrong 3.5.1 build being provided. But, even with what I believe to be the correct version installed, and after checking the advanced preference to be sure, I still was hearing chords play in older scores. Then I toggled it off and on and can no longer reproduce. So I'm not quite sure what to think.

Frequency Once Few
Status needs info active
Workaround No Yes

I can confirm this behavior too, with my scores. Including the workaround to toggle those settings. That workaround might give the hint at the real bug I guess

So the issue happens if the ini file does not have the setting

[score]
harmony\play\disableCompatibility=true

written to it, regardless that setting to be the default (and as such not needed/wanted being written to the in file). Once the setting has been toggled, it got written to the ini file and from then on takes effect.

Status PR created fixed

Fixed in branch 3.x, commit c7d336430f

_fix #311520: harmony playback preferences not honored until toggled

Resolves: https://musescore.org/en/node/311520

The new preferences for disabling playback of chord symbols work fine,
only ater you've toggled them at least once, which forces them
to be written to the ".ini" file.
Otherwise, they are not being initialized correctly.
This is apparently from the use of QSettings to access the preferences
from code within the libmscore folder.
This technique is used at least one other place,
but it is apparently not reliable with respect to default values.

This commit adds new members of MScore class
so mscore can write them and libmscore can read them.
That is the approach used by most other preferences
that need to be accessed from libmscore.

In addition, there was a logic error
when creating a new score from a template.
There was code to handle new scores created from old templates,
so they wouldn't have chord symbols forced off
by the compatibility setting.
This code was erroneously being triggered for new templates as well,
making it impossible to disable chord symbol playback via a template.
That is fixed by performing the same version check used
when reading the template._

Fix version
3.5.2