Changing notes illogically changes / resets string in tab
Just open attached file and see instructions, you'll get the gist of the problem in 5 seconds if you're a guitar player :)
Extended description follows:
Setup: Have a linked musical and tab staff pair. Put any tabbed note on a fret >= where the next open string note would start (>= fret 5 on all strings except G string in standard tuning)
- Select the note that was created in the TAB staff, but by clicking on it in the upper ("musical") staff (the one that has, for instance, a treble or bass clef).
- Move it up or down.
Result:
The string is changed - as if the player was (and only will ever be) playing at position zero.
Expected result:
* Minimum Expectation, short(-tempered) version: "Don't change my string! (especially not if that suggests my hand needs to jump >5 frets around the fretboard)"
Well-mannered, extended version: The fret value in the tabbed staff is increased / decreased accordingly with every half step the note pitch is changed, until it hits a natural upper (=number of frets in String Data setting) or lower (=0) boundary - and only then moved on to the next higher string.
* Possible expectation: Instead of using a hard boundary limited by the physical hardware, the algorithm should allow for a feasible hand span width, i.e. +3/-3 frets away from the current position as a simple implementation before it changes strings. An even more sophisticated algorithm could take the neighbouring notes, finger markings (usually done with arabic number on top of the musical notes) or positional markings (usually done in roman numbers above the score) into account and deduct the finger span of the player in that playing position from the available information... but that is just me going crazy about a nice-to-have, potentially over-engineered algorithm. (but why not think big? ;) )
Could reproduce this in any score i worked on so far. Likely to be related to #165851: Fret value extends to different string.
| Attachment | Size |
|---|---|
| unwanted-string-change.mscz | 5.13 KB |
Comments
Have you discussed this with other guitar players? If I am understanding correctly, the basic behavior of changing strings is by design and relied upon by guitarists who do indeed expect changing pitch to always select the lowest position, not necessarily keep the same string. It's been like this for as long as we've had tablature and I don't recall anyone ever complaining about it.
On the other hand, I could envision a very simple algorithm that simply checked to see if the note was already at the lowest position, and if not, then and only then assume the user wants to keep the string. So in your example, the G is not currently in the lowest position, so it would stay on that that string. But if the note had instead been D# (same string, fret 4), then hitting up arrow would change it to the E string fret 0 as it currently does.
An algorithm that somehow checked hand position sounds nice, but given there is a one-click solution for moving notes to other strings, it also seems overkill, unless it also can be used more generally than just for this command. In which case it seems extremely useful.
In reply to Have you discussed this with… by Marc Sabatella
> Have you discussed this with other guitar players?
Honestly i haven't. Of course, we could post this into the forum and request for comments. However, the current behaviour objectively can interrupt an (otherwise nice) workflow in MuseScore, making it a real nuisance when transcribing something that is not played in higher frets. Issue #165851: Fret value extends to different string underlines this.
The algorithm as it is and was makes perfect sense for playing in position zero and we need to keep it consistent there. That's why I am totally in love with your answer:
> I could envision a very simple algorithm that simply checked to see if the note was already at the lowest position, and if not, then and only then assume the user wants to keep the string
That approach breathes the spirit of the K.I.S.S. principle and thus is a fantastic and highly effective iteration on this issue.
I like simple too :-)