musescore / musescore/MuseScore
Clean up the work with `Instruments`, `Parts` and `Excerpts`, their names/titles, and Instrument changes
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
Instrumentis a representation of an instance of a physical instrument, like Flute, Piccolo, Violin, etc.. EachInstrumenthas a name. - A
Parthas 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 oneInstrumentat a time, but may switch to anotherInstrumentduring the piece. Examples ofPartsare 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 thatScorehas threeParts. EachParthas a name. - An
Excerptmay be regarded the same way as a Layout in Dorico. It represents a score that contains only a selection of thePartsfrom the full score (MasterScore). In daily life, we tend to refer toExcerptsas "parts" (which we also do in the UI). EachExcerpthas a name.
The selection ofPartsmay technically be empty, but in practice, this serves little purpose.
In by far the most cases, anExcerptcontains only onePart, and the title of theExcerptequals the name of thePart.
However,Excerptscontaining more than onePartare not uncommon. For instance, for a piece for orchestra and choir, one may want to create anExcerptcontaining only the four choirParts. Or, for a violin sonata, the pianist will probably like to see the violinPartprinted in hisExcerpttoo (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
Instrumentis played in only onePart; - A
Partmay be performed on one or moreInstrumentsalternately; - A
Partis printed in one or moreExcerpts; - An
Excerptdisplays zero or moreParts.
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 aParthas multipleInstruments. - 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
Instrumentof aPart. There is no way to affect otherInstruments. - 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 anExcerpt(for example, in the "parts dialog"). - 5. When clicking the "Replace instrument" button in that same popup, (which will currently always replace the first
Instrumentonly), the part name is overridden with the name of the newly selectedInstrument. 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
Excerptwhen replacing theInstrumentof thePartcontained in thatExcerpt. 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 Instrumentscontained inPartAuto-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
Partsplaying 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 theInstrument, so would be automatically propagated to thePartname, so we would not need to account for that when generating thePartname.) -
For
Excerpts:Names of Partscontained inExcerptAuto-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.
- Auto-generate a name for the parent for the old situation (i.e. before the child was renamed).
- 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
Instrumentof thePartinto account; - Because #9745 suggests that the name of the
Partshould always be updated when (the names of) itsInstrumentsare changed, as if those names were the same thing, but they aren't; - Because #10122 suggests that the name of the
Excerptshould always be updated when (the names of) itsPartsare 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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