musescore / musescore/MuseScore

Tablature: power chords in drop tunings are fretted across open strings from the 5th fret up

Open
#34,690 0 comments 0 reactions 1 assignee View on GitHub

@sambeson is already working on this.

Since Aug 25, 2026.

community guitar
Dominant language
C++
Stars
15.1k
Forks
3.3k
Avg merge
2d 2h
Merged PRs (30d)
91

Description

Description

On a tablature staff in a drop tuning, a power chord written at the 5th fret or above is fretted across open strings instead of as the barre shape which is actually played.

Drop D (D2 A2 D3 G3 B3 E4), G power chord — G2, D3, G3:

      expected                    actual
e|------|                    e|------|
B|------|                    B|------|
G|------|                    G|--0---|   G3  (open G)
D|--5---|  G3                D|--0---|   D3  (open D)
A|--5---|  D3                A|------|
D|--5---|  G2                D|--5---|   G2

Both contain the same three pitches, so nothing is flagged as an error.

Why it matters

The second spelling is not unplayable — one finger at the 5th fret with two strings ringing open is easy enough. But it is a different guitar part:

  • open strings cannot be palm muted, which is the defining articulation of drop tuned power chord playing
  • a barre shape is movable; the same riff two frets up is the same grip. An open voicing has no shape to move, so a transposed passage has to be re-fingered from scratch
  • open strings sustain differently and cannot be choked, slid or given vibrato

Anyone reading it silently re-fingers it, which is manual work on every paste.

Steps to reproduce
  1. New score with a guitar that has both a standard and a tablature staff
  2. Staff/Part Properties → String Data → set the tuning to Drop D
  3. Enter or paste G2, D3, G3 on the standard staff
  4. Look at the tablature staff
Why the 5th fret

Below the 5th fret the correct shape appears by accident. For an F power chord at the 3rd fret, C3 cannot be played on the D string and F3 cannot be played on the G string, so every note is forced onto its only reachable string. At the 5th fret the open D and G strings become available for the first time, and are taken from there up.

It is not only about open strings, either. At the 6th fret the same chord comes out 6, 1, 1 — equally spread, with nothing on an open string at all. A chromatic riff G → G♯ → A comes out wrong, wrong, right.

Cause

StringData::convertPitch() takes a single pitch and returns the thinnest string which can reach it, which is always the lowest fret. It has no access to the other notes in the chord.

fretChords() has the whole chord in view but only intervenes on string conflicts, and this chord has none: the three notes are on three distinct strings, all in range.

There is an existing TODO in fretChords() describing the same gap:

// TODO : try to optimize used fret range, avoiding excessively open positions

along with minFret/maxFret, which are calculated just above it and never read.

Version

Reproduced on main (5decb273dd), Windows, self-built.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.