musescore / musescore/MuseScore

Clean up the work with `Instruments`, `Parts` and `Excerpts`, their names/titles, and Instrument changes

Open
#10,128 9 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
15.1k
Forks
3.3k
Avg merge
2d 2h
Merged PRs (30d)
91

Description

Terms used in the code
To prevent misunderstandings, let's recall some definitions from earlier discussions. The monospace font indicates that I refer to the term as used in the code, while the normal font is used to refer to daily-life terms that are (or should be) also used in the UI.

  • An Instrument is a representation of an instance of a physical instrument, like Flute, Piccolo, Violin, etc.. Each Instrument has a name.
  • A Part has the same role as a Player in Dorico; i.e. it represents a person (or a group of persons playing the same voice) that plays one Instrument at a time, but may switch to another Instrument during the piece. Examples of Parts are a violin player, a violins section, and a flutist who switches to the piccolo for some bars. In daily life, one may say that a certain score has three instruments, but in the code, we would say that that Score has three Parts. Each Part has a name.
  • An Excerpt may be regarded the same way as a Layout in Dorico. It represents a score that contains only a selection of the Parts from the full score (MasterScore). In daily life, we tend to refer to Excerpts as "parts" (which we also do in the UI). Each Excerpt has a name.
    The selection of Parts may technically be empty, but in practice, this serves little purpose.
    In by far the most cases, an Excerpt contains only one Part, and the title of the Excerpt equals the name of the Part.
    However, Excerpts containing more than one Part are not uncommon. For instance, for a piece for orchestra and choir, one may want to create an Excerpt containing only the four choir Parts. Or, for a violin sonata, the pianist will probably like to see the violin Part printed in his Excerpt too (but in this case, the full score could also have been used).

No one-to-one relations
It is important to realize that there is not necessarily a one-to-one relation between Instruments and Parts, nor between Parts and Excerpts.

  • An Instrument is played in only one Part;
  • A Part may be performed on one or more Instruments alternately;
  • A Part is printed in one or more Excerpts;
  • An Excerpt displays zero or more Parts.

In fact, there is nothing new or difficult about this, but we should make sure to keep this in mind always. Currently, there are quite some places in MU4 where we assume one-to-one relations, and many of them actually stem from MU3.

Problems

  • 1. The Instruments panel (which actually shows a list of Parts) does not have the ability to indicate that a Part has multiple Instruments.
  • 2. MU4 does not seem to support instrument changes in any way; not even in the MU3 way. There is no way to select the instrument to be used after the instrument change; you can only enter a custom text for the "instrument change" element.
  • 3. Changing the "name on score" or "abbreviated name" of an instrument in the popup in the Instruments panel only affects the first Instrument of a Part. There is no way to affect other Instruments.
  • 4. The text "Part name" in that same popup is confusing. In this instance, it refers to a Part, but in other instances, it refers to an Excerpt (for example, in the "parts dialog").
  • 5. When clicking the "Replace instrument" button in that same popup, (which will currently always replace the first Instrument only), the part name is overridden with the name of the newly selected Instrument. This is not always desirable, see below. (See #10014, where this got implemented; see #9745, which not completely valid because of this.)
  • 6. Similarly, there are plans to rename the Excerpt when replacing the Instrument of the Part contained in that Excerpt. This is even less often desirable, see below. (See #10122, which is not completely valid because of this.)

Three kinds of names
As can be concluded from the above, there are three names: the name of an Instrument, of a Part and of an Excerpt. In some cases, it is desirable that the names of the things higher in the hierarchy are updated automatically when the name of a thing lower in the hierarchy is changed, and in some cases not.

Proposed behaviour for changing names
For every situation, MuseScore is (or should be) able to provide an auto-generated name. Some examples of auto-generated names (these are not definitive proposals, only for illustration):

  • For Parts:

    Names of Instruments contained in Part Auto-generated name for Part
    { "Violin" } "Violin"
    { "Flute", "Piccolo" } "Flute and Piccolo"
    { "Triangle", "Glockenspiel", "Xylophon" } "Triangle, Glockenspiel and Xylophone"

    (Note: if the full score contains multiple Parts playing the same kind of instrument, you will want to number those instruments, e.g. Violin 1 and Violin 2. The numbering seems to be added to the name of the Instrument, so would be automatically propagated to the Part name, so we would not need to account for that when generating the Part name.)

  • For Excerpts:

    Names of Parts contained in Excerpt Auto-generated name for Excerpt
    ∅ (empty set) "New part"
    { "Violin" } "Violin"
    { "Flute and Piccolo", "Oboe" } "Flute and Piccolo, Oboe"

So, for the behaviour for automatically changing the name of the parent item when the name of a child is changed, I would propose the following.

  1. Auto-generate a name for the parent for the old situation (i.e. before the child was renamed).
  2. If the actual name of the parent equals that auto-generated name, the user has apparently never modified the name (or changed it back to the default).
    • If this is the case, auto-generate a name for the parent for the new situation, and assign this name to the parent.
    • Otherwise, the user has apparently customized the name, and we're not going to override that, just to be safe.

This should happen when the name of the child is changed directly as well as indirectly. So, if the name of a Part is changed because the name of one of its Instruments changed (or an Instrument got added, deleted or replaced, for example by adding an instrument change), the name of the Excerpts containing that Part should be reconsidered too.

A small complication...
... is that the names of Instruments and Parts are "per-Excerpt". So when you change the name of an Instrument or Part in the full score, that changed name will not be reflected in all Excerpts, or vice versa. This raises the question: at which version of the Part names should an Excerpt look, to determine its auto-generated name? I would answer, just the version of the Excerpt itself.

So why are #10014, #9745 and #10122 not completely valid?

  • Because #10014 only takes the first Instrument of the Part into account;
  • Because #9745 suggests that the name of the Part should always be updated when (the names of) its Instruments are changed, as if those names were the same thing, but they aren't;
  • Because #10122 suggests that the name of the Excerpt should always be updated when (the names of) its Parts are changed, as if those names were the same thing, but they aren't.

Conclusion
This is probably a much too verbose explanation about a relatively simple problem, but I wanted to be thorough about this, hoping to eliminate all possible confusion about this topic for good, also for new contributors who might be currently diving into this.

@Tantacrul and @bkunda It would be great if you could think about a design for the instruments changes inspector, as well as a revision of the Instruments panel popup, to eliminate the confusing situation that the "Name on score" and "Abbreviated name" field refer to the first Instrument in that Part, while the "Part name" field refers to the Part that contains it (not to be confused with the Excerpt (or "part" in its daily-life meaning)).

Future
Once the problems mentioned in this task are sorted out, there will still be questions. I know that it was initially planned to have a clear hierarchy in the Instruments Panel like Part -> Instruments -> Staves. In the early days of the Instruments panel, this was actually implemented, but it got removed in PR #7045.

The feature of playing multiple Instruments alternately in one Part was then called "doubling". Personally, I was a bit confused by this term, because I thought that it meant something like "linked" instruments, e.g. multiple instruments playing the same notes simultaneously. Indeed, on Wikipedia, both meanings are mentioned. Maybe we can ultimately find a less ambiguous term.

However, this hierarchical structure of the Instruments panel would not be possible anyway in the current situation. Currently, a Part has a list of which Instrument plays at which moment in the piece, and a fixed list of Staves for the whole piece. The list of Instruments is completely independent from the list of Staves, and the list of Staves is initialized to the list of staves desirable for the first Instrument. But in the case of an instrument change, this list of staves is untouched. This is problematic for example when a percussionist would ever need to switch from a Glockenspiel (one staff) to a Celesta (two staves). The Celesta will have only one staff. We might have to make compatibility-breaking changes to get this fixed properly.

Anyway, let's first get the problems mentioned in this task done, and then look further.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or concrete entry points are named; begin by locating the Instruments panel, instrument-changes inspector, and the Part/Excerpt/Instrument model. Use the six listed problems and proposed name-propagation rules as the scope, and consider the work done only when those relationships and naming behaviors are handled consistently.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
design, desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.