__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).
- 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.
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
In `Measure::layoutX()` and in `Score::computeMinWidth()` there is code to add room for dash padding in lyrics syllables, with a reference to `System::layoutLyrics()`.
As `System_layoutLLyrics()` no longer exists and as `LyricsLineSegment::layout()` now adjusts (and occasionally skips) dash width to actual note distance, this is now redundant and may in some cases interfere with the `LyricsLineSegment::layout()` calculations.
Some tests with rather dense polyphonic scores did show that some space may be gained, without raising any evident 'crowding' problem.
In small staves, some types of bar lines are drawn with small lines and some are not (mainly end bar lines). In addition all bar lines of a measure are left-aligned; when small and regular staves are mixed this looks untidy for mid-system bar lines and quite wrong for system-end bar lines. See http://musescore.org/en/node/44966 for a discussion and an example.
This patch tries to achieve the best-looking possible result:
- it lays out and draws all bar lines in small staves with small widths
- it right-aligns end bar lines, end-repeat bar lines and any bar line at system end
- it left-aligns start-repeat bar lines
- it centre-aligns any other bar line.
Implements melisma and dash lines for lyrics spanning several systems.
The melisma and dash line is based on the `SLine` class and its segments on the `LineSegment` class. Both the whole line and its segments are not selectable, marked as generated and not saved in the score file, which is not changed in any way.
For very wide dash segments, several dashes are drawn; the distance between the dashes is not configurable.
Lyrics layout code in `Measure` class and in `layout.cpp` file has been commented out as the lyrics line layout is all contained in the lyrics.cpp file
The line is registered with the `Score` (to have its layout delayed until all elements are positioned) with a mechanism similar to other `Spanner`'s, but in a different container (`_unmanagedSpanner`), as the owning `Lyrics` should decide when create, register, unregister and delete its line.
The line segments are registered with the `System` they belong to (to have them drawn), in the same way as other `Spanner`'s.
There is code for using the dash metrics of the lyrics font, but it is turned off via a conditional directive, as there does not seem to be a reliable way to determine the dash metrics; conventional values (determined by trials and errors and based on my taste!) are used when the conditional directive is off.
In old scores (1.x and transitional 2.0 scores, including templates and "My First Score"), regular bar lines are often needlessly stored in score files.
These bar lines are read back as non-generated, and may misbehave; for instance, may generate an extra 'courtesy' start-repeat at system end, if an start-repeat is added at the first measure of next system.
This fix normalizes bar line flags if, while reading them back, they are found to be normal.
Note: only a single line of code is changed in Measure::read() methods; the large number of affected files is due to test fixing.
In some engraving styles (mainly jazz), a double system initial bar line is used at structural articulations of the piece.
The PR supports this style, by adding a `_systemInitialBarLineStyle` variable to the `Measure` class which controls the style of the system bar line when the measure is the first of the system and by default it is set to NORMAL. This variable is not accessed directly; rather it is controlled by manipulating the system bar line. A system bar line can be edited:
- by dropping on it a bar line style from the palette (structural styles, like any repeat or END are ignored);
- by selecting it and double clicking a bar line style from the palette (same note as above).
It can be reset:
- by undo;
- by dropping on it (or selecting and double clicking) a NORMAL bar line style from the palette;
- by selecting and deleting it.
As the system bar line style is stored in the measure, if the first measure of a system changes (because of some other editing), the system bar line style will follow accordingly.
This PR should complete the revision of bar line flag managements.
- Make sure single bar line span changes affect both the `_customSpan` and the `_generated` flags.
- Make sure that manually bringing a custom-spanned bar line to default span resets the `_customSpan` flag and, if no other customization is in effect. the `_generated` flag.
- Deleting a measure bar line resets it to default configuration.
- Fix a missing initialization of `Measure::_endBarLineColor` variable.
- To simplify tests and debug, check boxes for the `BarLine::_customSpan` and the `BarLine::_customSubtype` have been added to the debugger dialogue box.
As far as system-initial bar lines are concerned, they were made un-editable by a recent commit (https://github.com/musescore/MuseScore/pull/1300). This PR add a few consistency changes:
- system-initial bar lines do not accept drops;
- they are not saved to score output files and are ignored when reading from them;
- their internal `_customSybtype` and _customSpan` flags are always false;
- they do not show up in the Inspector (if a system bar line is selected, the Inspector remains blank)
This PR DOES NOT include the special system-initial double bar management recently discussed. This will be part of a specific PR in the next days.
Together with previous PR's, this should ensure that:
- bar lines are written to a score output file only when some customization is in effect which cannot be reconstructed when reading back;
- any measure bar line can be edited;
- any measure bar line user edit is saved, written to the score file and read back properly;
- no system bar line edit is possible.
There are some inconsistencies in the current management of bar line `_generated` flag and user-modified type:
- Bar lines created by the New Score Wizard are flagged as non-generated, as well as bar lines of measures manually **appended** by the user, while bar lines of measures **inserted** are flagged as generated.
- If a generated bar line is individually changed of typed, it remains flagged as generated, it is not saved and the change is lost upon saving and re-loading.
- The management of the internal flag `BarLine::_customSubtype` is not always consistent.
- The `Measure::_endBarLineGenerated` flag was not always restored properly by undo.
This PR introduces the following fixes:
- The `_generated` flag is consistently used for bar lines whose type can be reconstructed from the context and then do not need to be saved to the output file.
- Normal bar lines are **always** created as generated: initially created by the Wizard, manually appended or inserted.
- Bar lines with custom type (i.e. different from the type which can be expected according to the bar line context) are always flagged as non-generated, ensuring the custom type is written to the output file.
- The `Measure::_endBarLineGenerated` flag is stored by `ChangeEndBarLineType()` and restore upon undo.
- Some test reference scores, based on the inconsistent bar line `_generated` flag, have been uniformed.
Notes:
- Tests about measure (and then bar line) appending, inserting and relative undo's are already included in the `tst_parts` test suite.
- Some inconsistencies remain in the management of custom bar line span and of system-initial bar lines: for the sake of simplicity, they will be dealt with in separate PR's.
