TABs do not (properly?) support transposition

@mtherieau: thanks for the reply. However, I think it would be better to stick to the specific issue: GTP import may be faulty (number of strings, tuning, what to do when there more strings than lines, ...), in which case other issues should be filed.

But, assuming the current import as an original score (with its standard tuning and all), assigning frets with the method proposed in the thread quoted above:

1) fret numbers come out different;
2) the bottom note of the G#-based chords results outside of the instrument range (even taking into account the 7th string);
3) it is nor possible to fret all the notes of the 6-note chords (again, even taking into account the 7th string);

so the score seems to imply a different system.

Before changing the test ref. score, I want to be sure we are not dealing with a different convention or practice and that the proposed method is not only one among several possibilities.

The issue I am referring to is the following:

Current master (fix for displaying of extra string already merged) renders that GTP4 file with no transposition in the TAB:

NOT FOUND: 1

My transposition fix (not yet merged) renders it according to your request for transposition:

NOT FOUND: 2

In both cases, 6-semitone-up transposition and standard tuning (+ 7th string in B) are assumed (whether this is correct or not is a different issue, relating to GTP import, not to tab rendering); given that transposition, that tuning and that notes:

1) Which example is correct?

2) The second example -- which I assume you would consider correct -- has no way to fret the bottom note of each chord (rendered in red), as it becomes outside of the instrument range, or to fit 6 notes in the 5 available strings (as the 2 top strings cannot be used); what is wrong? the chords or the fretting?

3) Are we sure ("beyond any reasonable doubt", as the saying goes) the first example (no transposition in TAB) does not refer to some practice also in use?

If we can answer these questions, I can complete the fix, correct the GTP test files if necessary and push the patch.

Thanks,

M.

@mtherieau #7: thanks for the reply. As I cannot find a way to match your notes with my results, I suspect there is something wrong in GTP import and I'll alert the GTP resident expert; possibly there is some sign problem (transp. up implemented as down, or something like this) which, as the particular transposition in that piece is by half an octave, results in the octave shift you observed.

To get clean of any GTP problems, I started from scratch with the following parameters (same as above, but to summarize):

1) Up transposition by 6 semitones
2) Tuning DADGAD (bottom to top, isn't it?)
3) (no 7th string, but this is irrelevant as it is not used)

and I entered in the TAB staff the fretting indicated in the fret diagram. This is the result with Concert Pitch OFF:

NOT FOUND: 1

and this is the result with Concert Pitch ON:

NOT FOUND: 2

Note that the standard staff looks like the opposite of previous MuseScore examples:

*) with Concert Pitch OFF, notes (which are transposed) correspond to frets (example: top string is [transposed] D, fret 2 = E);

*) with Concert Pitch ON, notes (actual pitches) are shifted in rapport to frets (example: top string actually G#, fret 2 = A#).

Does it look correct? Can we cast it in bronze?

Thanks,

M.

P.S.: Of course, the screen shots above refer to the fix I am implementing, not to the current master; so, they will obviously not match what you'd find if you try the same with you MS copy.

PR pushed: https://github.com/musescore/MuseScore/pull/1754

Now waiting for Travis to crunch and for merging...