Capo settings applied via staff text do not affect chord symbol playback

Relates to #310930: [EPIC] Issues with Chord Symbols playback

Came up again in https://musescore.org/en/node/315066

See also https://musescore.org/en/node/314129

Or better #314129: Chord symbol playback ignores staff text capo setting

Actually, it's rather worse - the chord symbol display doesn't reflect the capo either. It seems the staff text method of applying capo settings just doesn't apply to chord symbols, period. Better to use the Style method if you wish to use capo with chord symbols.

"the chord symbol display doesn't reflect the capo either" = ?
"the Style method" = ?

Style method: Format > Style > Chord Symbols > Capo fret position

The style setting has been the supported method of applying capo for many years. The staff text method was added only recently, and it seems, incompletely.

Well, 'recently' only in the British sense (they tend to claim a medieval Brige to have been build just recently ;-)) , it happened more than 2 years ago already (via PR https://github.com/musescore/MuseScore/pull/3882, issue #274839: Capo for Fretted Instruments) so it is in MuseScore 3.0, and so long before chord symbols playback.
Not sure though what it does though, or rather what it did prior to chord symbols playback.
Edit: ah, that setting does transpose the notes (in the staff) up by the number of semitones corresponding to the set fret position. It does nothing to the chord symbols, bnot to their disaplay nor to their sound.
The style setting though does nothing to the notes in staff nor to the sound of the chord symbols, it just adds the 'transposed up' chord symbols in parens.

Ok tested the style capo fret position.

-That style seems to affect the full score, how is that compatible with the capo property of the text which affects notes starting from the text anchor?

-Behaviour of that setting seems in contradiction to the (quite natural) behaviour of the text setting.
=>enter notes c c c
=>add text capo 2 to the 2nd c => you still see c c c but you hear c d d => OK
But...
=>enter chords C C C
=>use style chord capo 2
=> you still hear C C C and see C (Bb) ??? Should hear D D D (And see C)

I would say, expecting the original style setting to behave like the more recent staff text functionality is backwards - the question is, why wasn't the newer staff text functionality designed to work more like the already-existing chord symbol functionality, and why didn't it include chord symbol support? I'm guessing it was simply a matter of the two features being developed independently by different people with different goals.

As for the "recentness" of the staff text functionality, I mean in comparison the style functionality which was in place years before. The style functionality is used for chord symbols, not for the tablature - indeed, I think it may have predated tablature support, or at least been developed independently, which is why the option only affects chord symbols and not notation.

I would agree it's better to have capo information associated with a staff than as a score style. So I'd definitely favor a design in the future that phased out the older style setting and incorporated its functionality into the staff text paradigm - or whatever might replace this for MuseScore 4.

FWIW, though, I would argue the direction of application of the style setting is much more natural. You enter chords the way you want them to sound. Then, later, if you decide they might be easier to play if you instead used a capo, you can play with different capo settings to see which yields the most playable series of chords.

I strongly disagree with the direction of application of the style setting, but in case that one is considered the "correct" one, then the direction of application of the text capo property must be changed to be aligned because applying in one direction by one setting and the reverse direction by another one is certainly wrong.

So, you never enter the real chords first then decide on what capo setting will support it best? This to me seems the no-brainer way most people would compose. What is the real world use case for doing it differently?

I imagine that some people find some keys easier to compose in than others, and this may be partly because they find some chords easier to play than others. The capo allows you to think of your music in a certain key, but have it be automatically transposed at the time of performance. And this is exactly what the capo text does. The capo style setting has the opposite goal, so it makes sense that it works in the opposite direction. As for the bug about the playback of chord symbols not being adjusted to account for capo settings from staff text, the fix is rather easy. See https://github.com/mattmcclinch/MuseScore/commit/559c0e8.

Looks good to me, please PR it

See https://github.com/musescore/MuseScore/pull/7700.

.

Fixed in branch master, commit cebccd1419

_Fix #307704: Capo settings applied via staff text do not affect chord symbols

Resolves: https://musescore.org/en/node/307704._

Automatically closed -- issue fixed for 2 weeks with no activity.

For 3.x see https://github.com/musescore/MuseScore/pull/7871

The following points about capo and chord symbols have been noted many times.

In MuseScore 3.6, after the addition of a capo (applied via Staff Text), MuseScore raises the playback of the notation however it does not adjust chord symbol playback accordingly. Like many, I think the ideal default behavior would raise the playback pitch of each chord symbol x semitones, where x = the capoed fret.

This has been fixed in MuseScore 4.1 and implemented in the manner I've described.

I'm working mainly in MuseScore 3.7 but I can't test for myself because, deployment issues on MacOS, presently I can't run any recent releases. Can anyone tell me if the Chord Symbol playback issue has been addressed in MuseScore 3.7?

BLUSHING Update: I just tested in my relatively old 3.7.0.4524440406 and capoed Chord Symbol playback is indeed appropriately transposed! So ... the fix is in. THANKS!
OS: macOS 10.16, Arch.: x86_64, MuseScore version (64-bit): 3.7.0.4524440406, revision: f3d36a3

Here's the fix also alive and' well in MuseScore 4.1

https://musescore.com/user/35880724/scores/13498645

Thanks, scorster

As mentioned, capoed chord symbols weren't transposing in MS3.6, but gratefully that was fixed in 3.7 evolution.

Unfortunately it appears the chord symbols do not transpose on MuseScore.com after uploading my3.7 test score.

https://musescore.com/user/35880724/scores/13500163

scorster

Of course not, as the backend there is (based on) 3.6.2
Nothing I could do to fix that, unfortunately