This commit removes some -Wempty-body, -Wmaybe-uninitialized, -Wunused-variable, and -Wstrict-overflow compiler warnings that arise on my x86-64 and ARM arch linux machines when compiling release.
These compiler warnings don't seem to cause any bugs, but since they pollute the build output, they make it harder to spot potentially important warnings that might arise, so I'm making these small changes to keep the build output clean.
The "empty-body" warnings occur because the Q_ASSERT statements are removed for release compiles, causing the else blocks to be empty. Surrounding the Q_ASSERT with brackets will let the compiler know we aren't unintentionally having an empty else body.
The "maybe-uninitialized" warnings are handled by assigning the variables to 0 either at initialization or in a switch default block.
The "unused-variable" warning is due to PeriodItem updatePeriods[] in preferences.cpp being defined but never used, so I've removed PeriodItem. Also a recent commit has an unused "int staves", which I've removed.
The "strict-overflow" warning is due to compiler wanting to perform an optimization which would cause signed overflow during a comparison operation. I've made the compiler happy by casting the barIndex'es into unsigned ints, so it doesn't have to worry.
This patch gives better control on lyrics dash management and it is intended to supersede https://github.com/musescore/MuseScore/pull/2213 which did not suit the taste of several forum users; for a discussion, see https://musescore.org/en/node/76021 .
Adds 3 new score style parameters:
- `lyricsDashMinLength` to control the minimum dash length (default: 0.4sp)
- `lyricsDashMaxLength` to control the maximum dash length (default: 0.8sp)
- `lyricsDashForce`: if set to __true__, a dash is always generated between two syllables of a word and, if there is not enough space for the min dash length, more space is added between the syllables to accommodate it; if set to __false__, no extra space is added and the two syllables are joined together (default: true)
The effect of the last parameter is exemplified by the following screen-shots:
Current situation (before this patch); if there is no room for the min dash length, the dash is skipped and some blank is left between syllables:
Patch with `lyricsDashForce = true`; chords are further spaced and a min-length dash is inserted:
Patch with `lyricsDashForce = false`: the second syllable is moved (slightly) to the left to reclaim the blank:
If a section break occurs on a non-measure MeasureBase object such as a vertical or horizontal frame, then the courtesy key or time signature should still not be displayed in the final actual measure of the section.
__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.
If a measure has, in one staff, a bar line with a custom sub-type, the sub-type is applied to the bar lines of all the staves of this measure.
Fixed in `Measure::read()`.
not there yet, as at least overloaded operators for |, &, |=, &= and ~ would be needed to make this fully working. And even then it'd require lots of explict casting. This is most probably not be worth the price...
and change to a better sentinel for end of list.
Also move the Q_DECLARE_METATYPE(Ms::ValueType) nearer to its
definition.
This should conclude the work on the enums in libmsore/mscore.h.
See http://musescore.org/en/node/14576 for discussion and examples.
1) Edited courtesy time sig (in any parameter: visibility, colour, text, ...) are saved to the score
2) When read back from file, such a time sig is not recognized as courtesy time sig
3) If the edited courtesy time sig no longer is at the end of a system, it is not removed.
The straight approach could have been to disable any editing of courtesy time sig. Rather than loosing this flexibility, I tried to improve the management of courtesy sigs:
1) not changed
2) when reading a time sig, if not at the beginning of a measure, now it is turned into a courtesy time sig
3) courtesy time sig removal now depends on its position in the system and not on the generated status.
This patch also do the same changes, in the same code areas, for courtesy key signs, as they behave in a very similar way.
Ambitus elements with accidental(s) are laid out misaligned with ambitus elements without accidental(s).
The new algorithm aligns the leftmost note heads of each ambitus and places accidentals accordingly.
When the actual duration of a measure is changed and either the starting or ending duration cannot be represented with a simple value (for instance 5/4) and the measure contains a single whole measure rest, a division by 0 results. See http://musescore.org/en/node/25165 for examples, discussion and analysis.
Fixed.
If the new measure value is different from the current time sig, rest(s) to represent the actual measure values are used instead of whole measure rests.
Fixed by analyzing brackets and bar line spans rather than only relying on start and stop staff Y offset (which is not set if the staff is not shown).
Note: there are still issues with measure numbers, but these belong more to system items than to bar lining.
Renames also the files hoding the class itself:
- libmscore/tablature.cpp => stringdata.cpp
- libmscore/tablature.h => stringdata.h
No actual change in the code, only updated references to stringdata.h in #include's.
Since the grace chords have been moved from a parent segment of their own to a parent chord, the fretting algorithm no longer 'sees' them correctly.
Fixed by extending the fretting algorithm to deal with chords not belonging to segments.
Refactoring the following names:
Classes:
Tablature => StringData
Member variables and methods:
Instrument::tablature() => stringData()
Instrument::setTablature() => setStringdata()
InstrumentTemplate::tablature => stringData
InstrumentData::_tablature => _stringData
InstrumentData::tablature() => stringData()
InstrumentData::setTablature() => setStringData()
There is no change in logic or program behaviour, only renaming.
1) Built-in staff types have been removed.
2) Presets are internally used as source for the staff types of a new score, to match data in Instruments.xml and as reference to check for modifications.
3) Each new score is given by default one staff type for each preset with the same name.
4) The Instrument page of the New Score Wizard lists (under the name of "Staff types") the default staff types applicable to the instrument (actually it lists the preset, as the score does not have any staff type yet).
5) The "Add | Instruments" dlg box lists all the staff types applicable to the instrument: = to the list of 4) + any user-created staff type.
6) The Staff Properties dlg box lists all the staff types applicable to the instrument: = list in 5)
7) The Staff Type Editor lists all the staff types
This should ensure consistency among the several lists of staff types and avoid duplication of similar items
Terminology:
7) A new staff type created in the editor is named by default with the group name ("Standard-", "Perc-", "Tab-") + the index of the new type in its group + the suffix "[*]" marking a user customisation. The user is anyway able to rename it, if he want.
8) The pitched staff type has been renamed everywhere (hopefully!) to "Standard"
9) The term 'preset' have been removed from the UI, except from the Staff Type Editor where it keeps its meaning of ready-made collections of parameters
The commit affects many files, but a fair number of them have only changes in names of literals. The files with significant code changes are:
libmscore/score.cpp
libmscore/stafftype.cpp/.h
mscore/editstafftype.cpp (code for naming a new staff type)
mscore/instrdialog.cpp (building type list)
Note: as score files store staff type indications as integer indices and the number and order of new default staff types is different from the old built-in types, there is a compatibility issue with old 2.0 score which use percussion and tab staves. In Score::read() (libmscore/scorefile.cpp), there is a rudimentary attempt to cope with this.Old scores will need manual fix anyway. There should not be any (new) compatibility issue with 1.x scores, as they did not use staff types.
