Banjo Fifth String

• Feb 3, 2021 - 13:56
Reported version
3.6
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

This issue has been reported several times. I will send a PR to github shortly. This describes the fixes in the PR.

The 5-string banjo's 5th string starts at the 5th fret. Valid tablature fret numbers are 0, 6, 7, 8...

The 5th string also has an optional capo, just for that string.

Musescore treats the 5th string like all other strings with fret numbers 0, 1, 2, 3...

If you write the fret number 10 on the 5th string, Musescore thinks it's 10 frets up from the nut. It should be 5 frets up. If the 5th string is tuned to G, the note at the 10th fret is a C (not F.) Also frets 1..5 are not even possible to play because the 5th string starts at the 5th fret.

To fix this:
1. No changes are required to musicxml or the Musescore file format.

  1. No changes are required to the Musescore UI.

  2. The StringData class was updated to support a new 'startFret' value for each string. This value is initialized when StringData is set on an Instrument object. 'startFret' will only be set for 5 string banjos and only on the 5th string.

  3. StringData::getPitch now handles the banjo 5th string by taking into account 'startFret'

  4. StringData::convertPitch now handles banjo 5th string better when converting notation to tab.

  5. All Guitar Pro imports (*.gp) were updated to adjust the fret number before computing the string/fret pitch. Guitar Pro files store banjo 5th string fret numbers as 0,1,2,3..

I will submit a PR with these fixes to github shortly.


Comments

To see this bug, create a D scale in 5 string banjo tab using any version of Musescore (e.g. 3.6.1 is current). Notice you can either get it to sound right and look wrong or sound wrong and look right. The problem is fretted 5th string notes. All guitarpro files with banjo tabs with fretted 5th string notes will import into the "sound right, look wrong" format.

Attachment Size
D_scale_3_6.mscz 5.11 KB
D_scale_3_6.PNG 8.04 KB

Not sure what's next? I rebased it to 3.x. I signed the CLA yesterday.
Do I need to "Resolve Conversation" on github or is that something you do?
Sorry for all the questions, never worked on a github open source project before.

I ran into troubles with my PR mostly because I don't understand GIT and I developed on 3.6.1 instead of 3.x. I ended up starting all over on 3.x and will do another PR shortly. This time only 3 file changes. I noticed "laturetab" is now on the CLA list.

Status active PR created

I deleted everything and started over. This time it worked. It's a simple fix (3 files) but it is really important in banjoland. Thanks for your patience.

In reply to by scorster

This fix adds a 'startFret' to every string object. For guitar strings, startFret will always be 0. For five string banjos, it will be 5 (or higher depending on the tuning). So making it work with partial capos on other strings and other instruments would be pretty easy. It would require some UI and file format changes. I don't believe musicxml supports partial capos.

Hi laturetab,

Nice work on StartFret!

It would be truly remarkable for "partial copyists" if you (or interested developers) can surmount the necessary UI and file format changes.

Please keep us posted ... perhaps in the other thread.

> I don't believe Musicxml supports partial capos.

I haven't looked but you're probably right that MusicXML doesn't support partial capoing. However, the lack of MusicXML support for such capo techniques would amount to a minor portability issue.

Transporting partial capo setting via MusicXML is definitely a worthy cause. But I've seen MusicXML fall short on basic matters because, as an esteemed colleague says, "One app can't throw or the other can't catch.

Doug Kerr recently posted an important message on MusicXML transport between Overture and MuseScore here.

Thanks!

scorster

Just reread a part you wrote:

>> For guitar strings, startFret will always be 0. For five string banjos, it will be 5 (or higher depending on the tuning).

Tuning and startFret should be independent. Right?

So there could be two scenarios:

a) Some banjos have moveable "5th string capos." So startFret could be 5, 6, 7 ...
AND of course the player can simultaneously vary 5th string tuning. Also true with guitar partial capo!

b) Many banjos don't have a moveable capo and therefore always have an "origin" at the 5th fret,
so start fret would always = 5. However the player can vary the tuning to mimic the effect of a capped string.

The difference between scenario a) and b) is insignificant ... except when the player frets notes on the 5th string. Then they become distinctly different beasts.

scorster

In reply to by scorster

Hi Scorster,
I agree with everything you posted above.

Musescore 4 is underway and some major UI changes are in the works. Support for partial capos should probably be added to that UI some day. I was hoping to get this banjo fix into the 3.x release builds and not messing with file formats and the UI/documentation was the best way to do that. However, the 'startFret' algorithm works for this and partial capos, so it will live on regardless of what path Musescore takes.

Status PR created fixed

Fixed in branch 3.x, commit 9caa77348e

_Fix #316896: Banjo fifth string fret numbers

The banjo 5th string starts at the 5th fret, so valid fret
numbers are 0,6,7,8... Musescore displays 0,1,2,3...

This fix requires no UI changes and no file format changes._

Fixed in branch 3.6.2, commit 3da35797e3

_Fix #316896: Banjo fifth string fret numbers

The banjo 5th string starts at the 5th fret, so valid fret
numbers are 0,6,7,8... Musescore displays 0,1,2,3...

This fix requires no UI changes and no file format changes._

Fixed in branch master, commit 25f55ae9a0

_Fix #316896: Banjo fifth string fret numbers

The banjo 5th string starts at the 5th fret, so valid fret
numbers are 0,6,7,8... Musescore displays 0,1,2,3...

This fix requires no UI changes and no file format changes._

Fix version
3.6.2