Standard staff linked to TAB staff shows wrong notes on some combination of mouse+kbd note entering.

Hello,

To give a new angle to the arrival of this bug: once the correct treble clef 8vb placed, we see that the open strings are shown correctly.
But all fretted notes (for example, on the strings 1 and 4) are inaccurate, and proceed by jumping octaves.

Finally, I come to identify (yesterday!) the origin of the result posted in comment # 1 : with a serie of identical notes while numbers differed in the tab staff.

It starts with how to proceed with the entry of notes. I have made ​​a habit, for three months that I regularly attends the Tab section of the Nigthlies, to use the mouse. I enter a number, and if necessary (number higher than 0), I apply a correction immediately with the numbers on the keypad. All is ok, all time, and pleasant to use.

It is also faster for me to do so.
1) because, by default, the mouse enters the number 0 – or « a » for French tab (the open strings can be very numerous in a score for plucked instruments, so no need to use the arrows)
2) I find tedious also to use the arrows when you're forced to make several back and forth, sometimes separated by several strings.

This method, with the mouse, works really well when the standard staff is linked immediately, at the creation of the score : Tab + standard. ( It works well also, of course, with a single tab staff.)

I just realized that this was not the case when the standard staff is linked afterwards, to a tab staff already filled.
To illustrate this, here are two screenshots that summarize everything.
- I proceeded to enter notes in three ways, as you can read in the text above staffs.

- Then I link (via the key "I") a standard staff.

Result: the second way, with the entry with the mouse, and correction afterwards, does not work. (It completely corresponds to the illustration of comment # 1 )

-Same result, of course, with letters :

In my opinion (except error of my part), it is here that this little (?) bug takes his source: the correction is “forgotten”, is not taken into account when adding linked standard staff.

Remain only the numbers 0 initially entered with the mouse, with the consequence of this serie of "E" notes on the first string, while the numbers (or letters) are still growing!

Really hoping that this correction can be corrected! Thus, the result would be the same - for the unity of behavior -, in the three cases: a) single tab staff, b) tab staff + linked standard staff, and c) tab staff with standard staff added and linked afterwards.

Therefore, the Tabs section would then become a wonderful place for any musician using tabs. For me, this exception aside, is already the case. I feel at home!

Latest evolution in progress: a clue, as well as a workaround.
- Enter numbers (or letters) with the second way, described in comment #3, namely entry "0 or a" by mouse and correct if necessary.
- Select the tab staff, and just go up a semitone (up arrow)

-Result: this single action "unlocks" the situation.
Then go down the same semitone, and you will find the original notes, and a normal use with linked staves.

Hello Miwarre and Jojo-Schmitz,

I saw the patch, but it does not work, even with the latest Nigthlies. I just tried again, with the last Nigthtly ("e9e0e34") and the bug is not fixed at all.

I recall that occurs in a particular case, with the use of the mouse. Briefly, the steps to reproduce it:
- Create a single Tab staff
- Enter the number 0 (the default number applied by the mouse) on the first string for example. Then, if you want another number (2 or 3 or 4 ...), make an immediate correction by pressing the appropriate number on the keypad.

On my example, I did:
- 0 (mouse)
- then 1 (0 mouse + 1 keypad)
- then O mouse
- then 2 (0 mouse + 2 keypad), etc. (up to 5-6, on this example)

- Then go to Instruments ("I" key) to link standard staff.
As you can see, the standard staff is wrong.

- As I wrote this morning, just select the entire Tab staff and tranposer a semitone (and then down, if you want), so that the Standard staff becomes correct.

Yes Miwarre, it is. You have fully understood and established a perfect picture of what happens in all circumstances. (And you were right to correct the title of this thread, because I could not do it.)

I totally agree with your analysis. Except on one point when you say "the last procedure is the slowest and most cumbersome of all".

For my part, I find:
a) the use of open strings is common or very common for fretted instruments. So, with the mouse, the fret 0 is generated immediatly, which saves time.
b) personally, I find it faster to point the mouse cursor on the right string (especially when going from one extreme to the other, and especially when we are ten strings or more!), rather than continually playing with the up and down arrows (:

For priority, I also agree with you, but I think this aspect should be reported. For a consistent behavior (since this procedure works fine when the staves are linked to the creation of a new score), I think it should be fixed. Thanks ;)

Indeed, thank you, the regression of July 29 (probably from, or near, the Nightly, "ccb04e0"), whose effect was to display, like the original bug, two Tab staff, had escaped my vigilance.

It reappears now a Tab staff and a Treble clef ( when you know that the adaptation is necessary, the change to a Treble clef 8vb is not so complicated to make)

Marc, we can not really say that the issue has been partially addressed.

The problem with the clefs had been treated (by Miwarre, I think?) there are several weeks at least. It is for this reason that he has reclassified the title of the issue, as can be seen in the comment # 8.

The update of this morning concerned a regression appeared on July 29, which resulted in a return to the initial point during these last two days. (And only for the clefs)

The issue about "wrong notes on some combination of mouse + kbd Note entering" remains active.

So that was that! As I started to guess in the comment # 9 (EDIT) : http://musescore.org/en/node/30231

I am able to exactly replicate the first false result of chen lung by entering notes with a mix. mouse / kbd.

And if necessary, this provides evidence that some users are using this way to enter notes/numbers in the tablature.

So we can close this thread. http://musescore.org/fr/node/30231

And ask nicely to Maurizio, please, fix this issue: http://musescore.org/en/node/25867

Because we feared something more serious, and spend a lot of time to understand. Thanks Maurizio ;)

"but it's probably the most discoverable, so I suspect a lot of people will run into this."

I have exactly the same thought. But not only concerning the neophytes. Chen lung is not a neophyte, of course, he nevertheless used this way of doing.

Like me also, as I've said, when I have to enter notes for a multi-stringed instrument, and sometimes at other times, depending on the configuration of the piece, or a measure, or some notes...
So it's inevitably to risk this kind of errors, significant in terms of results displayed, if this issue is not fixed.

Right. That's incredible!
How did we miss such a issue?