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

• Jul 10, 2020 - 13:22
Reported version
S3 - Major

OS: macOS High Sierra (10.13),
Arch.: x86_64, MuseScore version (64-bit):,
revision: b5add95

Step to reproduce: (see the attached file)

1.Add staff text to the note from the palette
2.Right-click staff text and select staff text Properties…
3.Select Capo Settings Tab, tick Capo Settings and change the numerical value of Capo fret:

Musical Notation are transposed, but Chord Symbols Playback not.

Capo playback

Attachment Size
capo_settings1.mscz 8.61 KB


Title Capo Playback is not transposed in Chord Symbols Playback Capo settings applied via staff text do not affect chord symbols
Workaround No Yes

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 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, 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.

In reply to by Jojo-Schmitz

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
=>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.

In reply to by Marc Sabatella

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

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

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 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):, revision: f3d36a3

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

Thanks, scorster