Some chords are wrong in linked Tab staff if the entry is made from bass to treble in the standard staff.
Nigthly, November 6 () / Windows7
1. Create a score: standard staff + linked Tab staff
2. Enter in the standard staff a chords progression, all in Voice1, in the direction bass string to treble string.
Expected result:
Actual result: some chords are badly displayed in tab staff (red frames). But if you enter the same chords progression in the direction treble string to bass string, the result is correct, as expected (green frames)
- With four notes
This issue occured on September 9. It is a side effect of the fix of this issue.
https://github.com/mgavioli/MuseScore/commit/8b4751534310a48155b536f25c…
| Attachment | Size |
|---|---|
| tab correct.jpg | 32.55 KB |
| result treble vs bass.jpg | 70.31 KB |
| chords four notes.jpg | 31.4 KB |
Comments
I didn't go through all the examples, but in the first one I looked at, the results seem to be "correct", just maybe "unexepcted" (and indeed, mostly "unplayable"). Is this true for all of them?
I think to changing the title soon. Because I have not taken all the full extent of the issue earlier.
Not only they are totally unexpected (compare relative to the 2.0 Beta 1, and it is understandable).
But, indeed, three of the four chords are actually unplayable, and all are unplayable with four notes! See the last attachment.
But also, worst, they are wrong, or rather they are "inverted" (I don't know the exact translation in English). It is "accords renversés", ou "renversement" in French. So:
- Second chord Dm (D/F/A), in standard staff, becomes: F-D-A in the Tab staff.
- Fifth chord G (G/B/D) becomes D-G-B
etc.
So, it is a major issue, undoubtedly.
Changing title.
A - Trying to summarize the issue. It happens when:
I) a TAB staff is linked to a standard staff
AND
II) notes are entered in the standard staff.
It does not happens if notes are entered in the TAB staff itself or if there are no linked staves and, for instance, chords are copied from a standard staff to a TAB staves or if a standard staff is converted to a TAB staff. In all these cases, the chords are fretted as expected.
B - There is a simple work-around: if working in the linked standard staff, enter notes from top to bottom.
C - This limitation comes from some design choices which are hard to dismiss:
1) The fretting algorithm assigns notes to strings/frets in a certain order (currently from the highest note to the lowest); changing the order would not solve the problem, as there would be a "wrong way" in any case.
2) The fretting algorithm tries not to touch at the current fretting, if there is one. This is important; otherwise, while adding a new note to a chord or while changing some note-to-string assignment in a TAB staff, there would be a risk to mess the notes already there.
D - In theory, it would be possible to add a secondary fretting algorithm to use with linked TAB staves when notes are entered in the a standard staff. In practice, things are not so easy, as carrying the necessary status and context information down to the specific fretting function is not obvious and there is a tangible risk to disrupt things currently working.
___________________________
For all there reasons, and after discussing with some fellow developers, I prefer to postpone this issue and focus on more urgent things.
Suggestions are welcome about where and how to document the input order limitation in the help system.
Thanks,
M.
"B - There is a simple work-around: if working in the linked standard staff, enter notes from top to bottom."
Unless it is totally unusual and against nature musically to ask to a musician to enter chords starting with the top note and ending with the bass. So I fear that this issue becomes recurring over time.
EDIT : And to understand: this issue was not present in the 2.0 Beta1. Why and how has she been introduced in the revised code from September 9?
At the risk of stepping in where it is not my place, let me try to explain based on my understanding:
I think that this is precisely because of the fix you mentioned earlier - the one that introduced the problem. In short, there are two conflicting goals here: the goal to preserve existing fret marks when adding new notes, and the desire to have "reasonable" fretting when entering chords bottom up. Basically, you can't have it both ways.
Consider the D-F-A chord in your example. Upon entering the "D", MuseScore assigns that to the D string, fret 0. Next, you enter an "F". The next higher string is a G, and you can't play F on the G string, so MuseScore cannot use that string. But it also cannot reassign the "D" string - it has already assigned that string to the D, and you specifically requested a couple of months ago that MuseScore not reassign strings as you add notes. So it has no choice but to assign the "F" to the "A" string, at fret 8. It is the right note in the right octave - there is nothing "wrong" here aside from the fact that no guitarist would choose to play it this way.
So unless you take back your request that MuseScore never change a string/fret once already assigned, there is really no way to have D-F-A fretted reasonably if you enter the notes bottom-to-top. MuseScore makes the most logical choice it can for the D, and then you are stuck with that choice unless you are willing to give up the request that MuseScore not reassign strings as you add notes.
What Miwarre writes above is that it might be possible to have two different fretting algorithms - one in which strings will not be automatically reassigned and another in which they can be - and to try to choose between the two algorithms based on whether the staves are linked or whatever. However, that would be a much more complex solution.
Ok, I try to understand and begin to make comparisons to better sum up the advantages and disadvantages of the previous and current situation. Thanks to not classify this issue for a few days, the time to examine all that closely.
First, thanks to Miwarre to have summarized the current situation in comment # 5. And noted that this issue occurs with linked staves and if the notes are entered in the standard staff.
I made some tests from a Nightly - August 17, then with the Beta1 - August 26 , and finally with a Nightly of the last day: by entering a few chords and then the same arpeggiated chords with the addition of a second voice on bass (with unison note)
My comments and proposals.
1) I humbly admit not having fully measured the difference between the entering note by note, i.e, a contrapuntic writing (melodic line, ginned chord, multi-voices ) and vertical writing (notes added one above the other: chords type). I use essentially the first manner.
2) That said, and considering the power and attraction of the “Linked staff” feature - particularly the configuration "standard staff + linked Tab linked ", that is the most common presentation in the publications, i.e. Standard + Tab -, there are very significant chances that this configuration will be widely used by users of MuseScore. Therefore, I think:
- It is not possible to be satisfy with the workaround, and continue showing the bad display in the Tab staff (for chords, but also with just two notes in “third” - eg D/F).
This is hardly acceptable, right? Not to mention that it will be most likely reported as a bug, as I did myself.
- Moreover, as written in my comment #6, it is not fair to ask to a musician to enter chords starting with the treble note to the bass (and some of them only, with a different behavior depending the position of the notes according to the strings.)
This is indefensible musically and an untenable position in the long term, I really do. So, for all these reasons, I believe it is an absolute priority, to my advice, to return and adopt, before an other possible improvement, to the behavior of the Beta 1.
3) Finally, in the case of arpeggios in a multi-voices context and adding a second voice, I did not ultimately found no decisive benefits with recent nightlies (in terms of number of operations to be conducted to make it playable on the instrument: invisibility of a voice, change the location of a note on a particular string etc.)
Thanks (hoping not to forget anything important)
Below, three files attached. We can see the number of different operations performed by selecting all the score (Ctrl + A). The advantages and disadvantages are finally enough balanced.
Except that the displayed chords are correct in the Tab staff with the Beta 1: this is really superior over any other argument.
Nightly August 17 chords and arpeggios 2 Voices.mscz
Test Beta1 chords and arpeggios 2 voices.mscz
Test Nightly November 17 chords and arpeggios 2 voices.mscz
A) The goal to have already-entered fretting (in whatever way it has been entered) stay fixed is there since almost the beginning of TAB support. If in previous revisions it was not always observed (I'm not sure of this, but I trust cadiz1 checks), it was a bug and this bug has been fixed.
B) Note there is another, rather easy, 'workaround', if a specific fretting is intended: enter the notes in the TAB itself!
C) cadiz1 comments about musicality are relevant; it is for there reasons that I urge this input peculiarity to be clearly and visibly documented in the help system. Suggestions about this are welcome.
D) I do not have TuxGuitar, but friends using it tell me it also exhibits different results in TAB if chords are entered bottom-to-top or top-to-bottom; so MS is not so strange, comparatively.
E) Expanding on B) above, I cannot but repeat what I have already said in other occasions: standard notation and TAB notation are two different notations, not simply two different typographic styles of the same things. There is no simple and linear 'translation' from one to another; and the linked staff machinery has this very problem, that it hides this fundamental distinction to the user, letting him to grow excessive expectations.
If a specific result is expected on one side, then enter the notes on that side and perhaps manually fix the other.
_________________________
I'm not saying that the current situation could not be improved; but simply that the issue is rather specific to a well-defined use case, and has workarounds. This is why I suggest it to be postponed.
Thanks,
M.
There is an alternative that has not been mentioned, and which could have my preference, now knowing this issue.
- This is to enter the notes into a single standard staff and THEN, in a second step, add a linked Tab staff. In this case, the displaying is correct.
Thus, you're not strictly in linked staves (at least, not in real time), but you're in a second time. And thus, no need to copy-paste.
EDIT: I do not quite see why displaying is incorrect when the linked staves work in real time, and why it becomes correct afterwards. This is beyond my understanding at this time!
Well, I just tried the same scenario with GP (note entry in the standard staff and linked Tab) Result: identical ! As you can see.
![GP.jpg]( "GP.jpg")
So unless a bright idea, we must consider the issue as too difficult to solve in the state?
Therefore, if Marc and Miwarre are agree, we can now classify this issue (with regret, for my part, because I thought rather "naively" that the Tab section became flawless!)
No one (no software) is perfect, unfortunately... ! :(
Well, I don't fully understand the possibilities or the complications with trying to come up with some scheme in which MuseScore sometimes tries to keep notes on the same string and sometimes does not. But I do understand that this is the problem that would need solving, otherwise you get exactly what you see above. So I remain fine with calling this "postponed".
FWIW, I do get a certain satisfaction out of seeing MuseScore struggle with this. I'm not a guitar player, but I occasionally write things for guitar or teach people who play guitar, and find myself needing to figure out how some combination of notes might be fretted. I end up doing more or less the same as MuseScore. I start fretting teh chord bottom to top, but then eventually reach a place where you just can't play some note on some string, so I have to give up and start over. Glad to see I'm not alone in finding this difficult! :-)
Just to bring a lighter note to this discussion, I play an instrument -- the viola da gamba -- which, with all its differences, has many similarity to the guitar: six strings, tuned almost the same, literature with frequent use of chords and so on.
Well, not only I often have to stop while reading new pieces to figure out how that damned chord is supposed to be fingered individually, but things get even more complex when several chords are chained (and the author even wrote legato, blame on him!) and crazy fingerings have to be used on a chord to free the fingers needed for the next chord! (ok, we have the added constrain that you can't 'jump' a string while bowing a chord: they have to be next to one another without 'holes')
I'm rather sure that no software can reasonably cope with such idiosyncrasies, unless it is very specialized to single cases (single instrument, single genre, ...), certainly not MuseScore as it is now.
Still, the issue is postponed, not abandoned! In the future, it can still be improved, if not solved completely.
Thanks,
M.
I discovered this issue with Dm chord recently. I had several on a test score side by side and they were different per the illustrations above. But I discovered you could edit the notes on the standard music staff and drag the note heads to reposition the ordering and the tab notations corrected. So if the three notes in the cord were entered top down 1,3, 2 meaning the F was added last, repositioning moved them as if the original input was 1,2, 3 with the F being entered second. So the notes retained some recognition of the order in which they were originally entered. To make sure it worked, I moved the two bottom note heads several tones and then put them back on the correct staff line and the bad fret numbers corrected.