Supports 'standard' configuration for bass string notations in historic tablatures (lutes and other plucked instruments, as well as viols), both of the French and of the Italian style. This should fill the last 'big hole' in historic TAB support.
Bass strings (or bourdons) are extra strings in addition to the 6 'standard' strings, which are not represented by tab lines and were indicated by other typograhic devices in historic sources. Among the innumerable variations shown in sources, this implementation supports the following styles, chosen to be general enough to suit the majority of cases, without requiring new parameters in the TAB style dialogue box:
- French: the first 4 bass courses are indicated by a fret mark in the 'seventh' TAB position (below bottom string) with 0, 1, 2 or 3 slashes prefixed; other bass courses are indicated, also in the 'seventh' TAB position, by the string number (from 4 on) and cannot contain a fret mark (as they didn't in historic sources).
- Italian: the first 2 bass courses are indicated by a fret mark in the 'seventh' TAB position (abover top string) with 1 or 2 'ledger lines' underneath; other bass courses are indicated, also in the 'seventh' TAB position, by the string number (from 9 on) and cannot contain a fret mark (as they didn't in historic sources). Rhythm marks above these indication are raised to leave room for them.
Both styles do not blindly assume that French style is top-to-bottom and Italian is 'upside-down' -- as historic sources are -- but adapt to the actual string order of the TAB. The choice between the two styles depends on the TAB using numbers or letters for the fret marks.
The implementation does not try to detect if the TAB is really of a historic style and applies either bass string notation whenever more strings are used than there are TAB lines. If this proves unsuitable to modern usage, some better heuristics can probably be found.
For a discussion and some screen shots, see: https://musescore.org/en/node/67261
**Note entry**
During TAB note entry, if the instruments has more strings than the TAB has lines, the string cursor can be moved outside of the TAB body, one position below for 'top-to-bottom' TAB's and one position above for 'upside-down' TAB's.
Further up or down movements add, to the 'blue cursor rectangle', markers indicating which is the actual target string (the cursor does not actually move), equal to the marks a note in that string will receive (slashes, ledger lines or string ordinal, according to the style and the string); during input the user will then receive the same info as when reading entered notes.
Other Notes:
- the `InputStatus::_string` variable, holding the current target TAB string in TAB note entry, changed meaning from the __visual__ string index to the __physical__ string index: this allows a better containment of the peculiarities of the individual TAB styles within the `StaffStyle` class, leaving other classes somehow freer of concern about TAB visual order and other peculiarities. As this variable is only used with TAB's, this change should not affect other functions.
- Some calculation for rhythm symbols have been moved from `TabDurationSymbol::draw()` to `TabDurationSymbol::layout()`, hopefully speeding up the drawing process.
- In fonts for historic styles, '10' has been replaced by 'X' both in fret numbers and in string ordinals, as this is more common in historic sources. Currently, this is not configurable; an additional style parameter could be added in future, if there will be enough request for it.
__Background__:
In the original TAB implementation, the "Stems above / below" setting was followed when there was only one voice, while with multiple voices, voice 1 stems were always above and voice 2 stems always below.
In issue https://musescore.org/en/node/63561 the OP reported that:
- with multiple voices, stems in TAB did not follow the "Stems above / below" setting;
- extra space was allocated for voice 2 stems.
Both issues were more apparent than real, because the example provided casually had no stems in voice 2 (all whole notes). With the commit 33797cd6c5 :
- voice 1 stems are forced to be below or down according to the setting even for multi-voice cases and voice 2 stems on the opposite side;
- additional distance is allocated above the TAB staff (but not below) if stems are above or there are multiple voices or below (but not above) if stems are below and there is only voice 1.
__Issues__:
1a) The original stem directions were __by design__, assuming that with multiple voices notes of voice 1 tend to be above and notes of voice 2 tend to be below; then it is more sensible to put voice 1 stems above and voice 2 stems below, limiting the "Stems above / below" setting to the single voice case only.
1b) Stem direction controls slurs and tie placement and users are complaining that, with multiple voices, stems, slurs and ties are placed unexpectedly. See issue https://musescore.org/en/node/69846 and forum post https://musescore.org/en/node/69821 .
2) About additional staff distance allocation, with multiple voices it has to be allocated __both__ above and below, as stems may appear both above and below.
__Fix__:
1) This patch fixes 1) by restoring the original stem direction computation (single voice: follow "Stems above / below" setting | multiple voices: voice 1 unconditionally above and voice 2 below) when tab is configured to have stems beside the staff and also when it is configured to have __no stems at all_ (so that slurs and ties occur in expected positions).
2) It corrects additional staff distance allocation for the multiple voice case. No resources are spent to check the odd case when one voice casually has no stems over the entire system (in which case, additional distance on that side could in theory be spared).
Fixes two aspects of tie layout in TAB described in the issue:
- ties might be too short; fixed by borrowing into `Chord::layoutTablature()` and adapting the code in `Chord::layoutPitched()`
- ties did not adapt to fret font size and position; fixed by parameterizing `Tie::slurPos()`
*) Old scores:
- grace_before-to-note glissandi in old scores are read correctly.
*) New glissandi involving graces
- In all cases, the ending note is identified correctly in the main chord, in the next main chord, in the graces-after of the main chord, in the graces-before of the next chord, whichever comes first.
- Spacing of cases involving graces-before is correct.
*) Spacing of cases involving graces-after.
It is not always optimal, as layout of graces-after pushes them as to the right as possible.
So, for instance, when a glissando is added between a grace-after of a chord and the next chord, the additional spacing added before the next chord to accommodate the gliss. is skipped by the grace-after.
I took the decision to ignore such cases as the usage of grace-after and of glissando has a very little intersection. Those cases will need manual adjusting.
- Implemented as a sub-class of `SLine`.
- Anchor type changed from CHORD to NOTE: allows to attach glissando start and end points to individual notes, rather than generically to chords (with note within the chord chosen by the program).
- The Glissando element is now stored in the `Note::_spannerFor` list.
- `Chord::_glissando` has been removed and replaced by a `bool _endsGlissando`, recording whether the chord is at the end of glissando (as gliss.-end chords require more space if mid-measure or system-initial).
- Debugger UI for `Chord` updated accordingly.
- Glissando in now save into score file as a spanner, within the initial note, and with appropriate `<endSpanner>` tag in the Glissando ending note.
- Existing scores with the old Glissando file format are correctly read back.
Notes:
- MusicXML import/export of the new Glissando implementation NOT IMPLEMENTED.
- This version can read scores from older versions, but older versions **cannot read** scored from this version (they do not expect a <Glissando> tag within a Note). Does this require a NEW FILE VERSION NUMBER?
- This implementation would allow rather easily to move the start and end anchors around (as for slurs) to override the note/chord chosen by the program when the glissando is initially created; but the UI for this is not implemented yet.
Adds code and UI support to force display of a repeated rhythm symbol
- never (default and previous implementation)
- at new system
- at new measure
- always
The setting is written to the score file only if different form the default.
An attempt to improve the layout of grace notes after chord. It probably does not cover all the possible interactions with other score elements, particularly in tight scores, but it should achieve reasonable results for common cases with a rather simple algorithm.
For some discussion and examples, see the original issue at http://musescore.org/en/node/15022 and the forum thread at http://musescore.org/en/node/45346
The Articulation class has been chosen because these symbols behave much like other articulations. The class already contains a number of symbols which are not really neither articulations or ornaments.
The new symbols have been grouped together with the somehow related cello thumb position symbol, at the end of the ArticulationType enum and set to `ArticulationShowIn::TABLATURE` only.
A specific case for them has been added in the `Chord::layoutArticulation()` method, as they do not follow the rules of other articulations.
If a chord contains an interval of a second (i.e. with flipped note heads) but the flipped note head(s) require no ledger lines, lines wide as the entire chords are generated.
Fixed by constructing ledger lines in two passes each from the 'outside' of the chord toward the staff, once for lines below and once for lines above the staff
See http://musescore.org/en/node/22235 for details and a sample. The commit should fix both issues in the post
NOTE: I had to remove the 'experimental' feature to avoid collision between ledger lines and accidentals: the relevant test is there, but what to do in this case is much more complex than before.
