French Tablature: some letters don't work

• Apr 4, 2014 - 15:08


The French tablature (used in France in the sixteenth and England in the seventeenth in France, England and the Netherlands, and Germany in the eighteenth) uses letters.

I noticed a bug on the notation of this Tab (​​on the last Nightly)

The first six frets are shown correctly:

- a: open string
- b: first fret
- c: second " "
- d: third
- e: fourth
- f: fifth
- g: sixth

The trouble starts here.

- The seventh fret should be indicated by h: replaced by "a". Conflict with Crescendo key?

- The eighth by i (ditto, replaced by "a"). Conflict with Instruments key?

Important to know: there is no j in the tab French: the letters i and j are often interchangeable in old French. This prevents very possible confusion.

- Same errors for the last three frets: l (fret 10), m (fret 11) n (12 fret, the octave). All replaced by "a".

I have attached three files that specify all.

Attachment Size
Tab. lettres Fr.mscz 2.18 KB
tab française.jpg 82.82 KB
tab lettres.jpg 40.85 KB


Please will you report problems with nightlies either in the issue tracker or the Technology Preview forum.

Support and Bug Reports is supposed to be for stable releases.

This prevents confusion by some users because they can't find a feature present in the nightlies but not the 1.x stable release.

*) H: The issue with 'h' is indeed a shortcut conflict with another function (crescendo, in this case) being assigned the same keystroke in the default setup. Possible solutions:

  • the user who regularly needs French tablatures redefines the Crescendo shortcut to something else (but should be informed in some way of the need to do so);
  • a different shortcut for Crescendo is provided as a default
  • the Crescendo shortcut is limited to non-tablature edit mode

*) I/J: The default letter shortcut for the 8th fret is [J], as [I] is already used by default setup for [I]nstrument (as it can be discovered by looking at the "Edit | Preferences | Shortcuts" dlg box).

*) M-...: Shortcut for frets greater than 9 are not even defined. Possible solution:

  • Shortcuts for frets greater than 9 (10 - 13?) are defined in the code, but not assigned any key by default; the user needing this feature may assign the key(s) he prefer (and manually resolve the conflicts which would arise almost inevitably).

However, I cannot confirm that a wrong letter is entered by using one of those key strokes; rather, nothing is entered as the shortcut is simply reject by the framework.

As a (temporary?) work-around, note that both number and letter shortcuts are always active during tablature entry, as they refer to the fret value regardless of how this value is displayed. So, the 10th fret can always be entered with [1] + [0] (and so on for higher frets) and will be correctly displayed with digits or letter according to the staff setup.

In general, shortcuts for tablatures have always been a source of problems and, as far as I know, no definitive solution has been found and proposed.

The number of needed shortcuts is relatively high (about two dozens for the fret values only, plus other to move around in the tab, to select/change the note duration value, to increase/decrease the pitch or string of a note, etc.) and many obvious choices for these actions are already assigned to general programme functions.

Currently, a partial solution is implemented which 'filters' shortcuts according to the programme mode; for instance, shortcuts to enter notes based on pitch ("A", "B", ...) or on interval ("Add a second above", "Add a third above", ...) are disabled in tab. entry mode, as they have little use in tabs. Some of them have been disabled just because their default keystroke happens to be 'needed' for tablatures (like "enharmonic up", to 'free' the [J] key). In addition, this requires special code and setting juggling at each change of programme state, as Qt shortcut machinery has no notion of "state" (see // ).

This is rather clearly sub-optimal, but I've run out of solutions and I still hope someone will come up with a genial breakthrough. Anybody volunteers?



In reply to by Miwarre

I think better shortcuts for hairpins would be > and <, esp if seen international. And then having h as an alternative for b. Not sure though these could be set in a portable manner, considering the various different keyboard layouts

In reply to by Jojo-Schmitz

Thanks Jojo, good idea!

'>' and '<' are "wandering keys", placed in very different points in different keyboards. A quick test with my Italian keyboard revealed that:

1) it is not possible to define '>' as a shortcut using the "Edit "Preferences | Shortcuts" dlg box: in the Italian keyboard, '>' is placed as a [Shift]ed '<' and the dialogue for capturing shortcuts chokes on it, as the resulting shortcut does not work.

2) HOWEVER, by defining '>' directly in the shortcut XML data, everything works as expected (the '<' and '>' characters are defined in the XML files as "<" and ">" resp.).

So, internal definitions should work. Anybody else mind to test with his own keyboard?

HOWEVER, the problem is more general; it does not make much sense to inhibit a shortcut in this or that mode only because the default (and presumably most obvious) key assigned to it in some mode conflicts with the default (and again presumably most obvious) key assigned to another shortcut in another mode.

The 'final solution' would be to have really separate and independent 'shortcut spaces' for the different modes; this would require a good deal of framework refactoring (and Qt juggling) though (and would also raise intriguing problems on how to represent all of this in the Preference | Shortcuts dlg box!), likely to be too late for 2.0...



In reply to by Miwarre

See also #17813: Keyboard locale-aware keyboard shortcuts
Other than that: the German keybord too has > as Shift-'&lt';
The Shortcuts should better recode the '&gt'; (and also '_', which is Shift-'-' on my Keyboard, as well asl all the Shift-'n' from the top row and probably some others) alone and leave it to the user how that is entered., a '>' remains just that, regardles what key presses are neded to produce it

In reply to by robert leleu

I'm convinced we are facing a twofold issue here:

1) Whether a given key stroke (combination) can be entered in the "Preference | Shortcut" dlg box and, once entered, is properly recognized.

We know that some combinations cannot be entered or, if apparently entered, in the end they do not work. This is an issue with the shortcut dlg box code (and possibly the underlying Qt framework), not with the shortcut themselves.

2) Whether a given key stroke (combination), if used in the default shortcut definition XML file (i.e. without going through the shortcut dlg box), is properly managed by the program or not on a variety of keyboards.

This might be an issue with the individual shortcut (for instance if it uses a key not existent on some keyboards: I would have problems with a shortcut using, say, 'ß', as this key does not exist on my Italian PC keyboard).

Or it may be an issue with the programme code dealing with actions and shortcuts.

In this particular case, I suspect that '<' and '>' may exhibit problems under 1) but should work fine under 2), as they are pretty basic ASCII characters. I think it is at least worth trying.



In reply to by [DELETED] 5

Same for }, only that this is in by default, but adding it won't work, on a German keybards that'd be AltGR+0, it gets recorded as Ctrl+Alt+}
Anyway, < and > are much better than h and H, so why not putting them into the defaults?
Who wants h and H to work, can add them?

In reply to by [DELETED] 5

Sorry to insist, but I think it is important to distinguish between the classes of problems.

As far as I can tell on my Linux installation (and assuming it is the same on Windows):

  • '>' cannot be defined as a new shortcut key
  • but it does work if it there since the beginning (i.e. in the data file)

So, this key can be used in the data files (default setup).

Of course in addition, it would be nice to fix the dlg box for capturing new shortcut keys, so that it also covers similar cases on all platforms.

Thanks for the patience,


In reply to by Jojo-Schmitz

Sure. And there are probably many other cases, some more or less general and some specific to individual keyboard layouts.

Each of them is a reason to try to fix the current implementation of the key stroke capturing dlg box.

At the same time, none of them is a structural reason for not using it in the default shortcut setup file (then, there might be convenience reasons, of course).


In reply to by Miwarre

Hello Miware,

Thank you very much for your reply so detailed, and totally makes me happy :-)

In fact, what you call as a temporary workaround suits me completely.

You should enter the Tab with numbers (ranging up to number 24), then amend choosing letters via Staff Type -> Full Configuration.

And we get the following result: perfect! With standard letters or Renaissance style. I'm thrilled. Thank you again Miwarre. You lit my Sunday!

Attachment Size
numbers.jpg 47.63 KB
lettres standard.jpg 40.02 KB
renaissance letters.jpg 41.09 KB

Do you still have an unanswered question? Please log in first to post your question.