French Tablature: some letters don't work
Hello,
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 |
Comments
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:
*) 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:
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 //github.com/musescore/MuseScore/blob/master/mscore/musescore.cpp#L2477 ).
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?
Thanks,
M.
In reply to Indeed. But... 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 I think better shortcuts for 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...
Thanks,
M.
In reply to Thanks Jojo, good idea! '>' by Miwarre
See also #17813: Keyboard locale-aware keyboard shortcuts
Other than that: the German keybord too has > as Shift-'<';
The Shortcuts should better recode the '>'; (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 Thanks Jojo, good idea! '>' by Miwarre
< is ALTGR+2 and > is ALTGR+3
and can't be used as shortcuts
I had similar problem with _ for melismas. _ is ALTGR+SPACE and didn't work. I had to modify my keyboard conf file to have _ in ALTGR+8, and it worked
In reply to same with French BÉPO keyboard 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.
Thanks,
M.
In reply to Possibly but... by Miwarre
Mac OSX 10.9, french keyboard, < an Shift+< (== ">") are working in Preferences->shortcuts and when used in the score.
Windows, > cannot be defined as a shortcut... it register Shift + < instead...
In reply to Mac OSX 10.9, french 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 Mac OSX 10.9, french 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):
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,
M.
In reply to Sorry to insist, but I think by Miwarre
Yes, you're right. But { and } are yet other examples of a shortcuts that do work, but can't get defined, on a non-US keyboard
In reply to Yes, you're right. But { and 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).
M.
In reply to Sure! by Miwarre
No disagreement here at all :-)
In reply to Indeed. But... 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!