Part versus Instrument
There are several places within MuseScore where the term "part" and "instrument" are used interchangeably, other places where a distinction exists. Also, the relationship between either of these and a "staff" is not always clear. This probably needs to be cleaned up.
Here's my understanding.
Staff - what you actually see on the score. The top "Staff Properties" portion of the "Staff Properties" seems to be correctly labelled in that these settings affect just the current staff. These settings include the staff type, size, and line color & visibility.
Instrument - an abstraction that defines a set of one or more related staves that can be assigned additional properties as a group. The "Part Properties" section of the Staff Properties" dialog should probably really be "Instrument Properties" as these settings should affect all staves for the current instrument, but not necessarily all in the current part. This includes the playback sound(s) that appear in the Mixer, the long & short names, transposition, and usable range.
Part - an abstraction that defines sets for one or more related instruments that can be displayed as a separate score in a tab alongside the main score tab. Normally, each part contains one instrument - this is the behavior of the "New All" button in File / Parts. However, you can manually define parts containing multiple instruments. It occurs to me this could be useful to define temporary subsets of staves to work on (like just the strings in an orchestral score). The only really relevant part attribute is the title displayed on the tab.
If this understanding is correct, then I think there are a couple of things off:
- the "Part Properties" section of the "Staff Properties" dialog should be renamed "Instrument Properties"
- the "Part Name" field within that dialog should probably be renamed "Instrument Name", and the behavior should be changed to only affect the current instrument (see below).
- Currently, the tab for the part is labelled using the "Part Title" from File / Parts, but the part itself is labelled using the "Part Name" (the field I say should be renamed "Instrument Name") of the first instrument included within the part. I think the Part Title should be used here as well. When generating parts automatically via "New All", this defaults to the "Part Name "(sic), so its only multi-instrument parts that would be affected by such a change, I believe. Otherwise, you end up with your "strings" part being labelled "Violin I".
Comments?
Comments
Sounds good to me. I stumbled across this while translating these terms.
This is a good thing to clarify. What you have suggested sounds correct, but I think it also depends on point of view. Are you defining the terms in order to bring clarity and organisation to the code, or is it to make it clearer to the user what the different terms imply? If we're lucky, the two will coincide.
If I were arranging a piano piece for an ensemble, then I would probably have a set of known instruments in mind. Thus parts and instruments would be interchangeable. However, if one of the instruments became unavailable I might well be happy giving the 'part' to a different instrument. Which indicates that even to an arranger 'parts' and 'instruments' can be separated.
And as we both know, chordal work can be separated into 'voices', which appear as 'parts' that might be for a group of the same instrument.
Clarity is certainly needed for both programmer and user. The programmer so that they know what they are working with and the user so that they find the program consistent and predictable.
Do we have a glossary anywhere? If not perhaps one should be started.
In reply to Part vs Instrument by cwhysall
These are good points. I'm primarily concerned with making sure the UI is consistent, and I do think this will help clarify things for the user. It will also make it easier to document.
In reply to These are good points. I'm by Marc Sabatella
Also check the Dynamic Range of a dynamic text in the inspector.
In the code, a Part (as previously defined) is an Excerpt.
Instruments (as previously defined) is more or less a Part...
A Part has a partname (used in the mixer), can be made invisible (in the instruments dialog) and has a list of staves. A Part can have several Instruments along the tick timeline. An Instrument (in the code) is then what we can see in instruments.xml (a range, a midi program, a short name, a long name etc...). The Part inherits some elements from the instrument at tick 0.
In reply to Also check the Dynamic Range by [DELETED] 5
"Excerpt" - yes, that's another term worth knowing in this context. The internal name for what is exposed in UI as Part in File / Parts. I hope to keep that term internal :-).
The more I think about it, the more it seems to me there is no easy way to be consistent while also using the most natural terms, because our language itself (well, mine anyhow; I can't speak for French :-) is not so logical.
The term "instrument" itself is problematic because, as you observe, it is used to refer to a group of settings in instruments.xml. There is only one "Violin" instrument in this abstract sense, but of course a score might have several "instances" of this instrument. And it is quite natural to refer to each of these instances as a "part", even though it is possible that in File / Parts we might in fact have one Part containing all violin instances, and the same instance might in fact be included in multiple Parts.
Still chewing on this. I'm now leaning toward thinking it's OK to keep using the term "Part" to refer to "instance of an instrument" (which is what we basically in Staff Properties end elsewhere) and am wondering if instead we could somehow clarify File / Parts.
Also trying to think through how the Mixer fits in. Currently, the Mixer entries are populated using the Part Name for each instrument. Given that I said I think Part Name should be renamed Instrument Name, this makes sense. Although I'm now hedging on whether "Instrument Name" is actually the most sensible name given the potential for confusion with "Long Instrument Name" and "Short Instrument Name". I seem to recall that "Part Name" itself was a relatively recent change, and it's probably a better choice than whatever it was before. But "Part" is a misnomer since it means something else with respect to File / Parts. But I don't have a better suggestion right now.
The actual behavior of "Part Name" is "Name that appears in Mixer and on top left corner of any part that includes this as the first instrument". I propose divorcing those two concepts - I think the "Part Title" as defined in File / Parts makes more sense as the text to display on the top left corner of the part. So what we are currently calling "Part Name" is really "Mixer entry name". Not that I would propose actually calling it that. Is this name used anywhere else?
Not to open another can of worms, but "Mixer entry" has a more common name: "Channel name". Unfortunately, the Mixer currently uses the word "channel" to mean something rather different, which is unfortunate as well, but not inconsistent, so I'm not interested in messing with that.
Final (for now) note: I guess the confusion between part and instrument in the UI comes from the fact that the term "part" is actually used in the code in many places where "instrument" (or some other abstraction wrapped around an instrument) is really meant. I couldn't care less about cleaning up the terminology in the code; I just want use of "Part" in the UI to be limited to actual parts in the File / Parts sense. Which is to say, honoring the possibility that a part might actually contain multiple instruments.
In reply to Also trying to think through by Marc Sabatella
In a score, you could have the same instrument with many parts. The visible name (long/short) should be instrumentName+partNumber, eg. "Violin #1", but every part should have a UUID key to be identified. The name, long or short, as a label to an unique key.
In reply to In a score you could have the by dm474
A UUID would resolve it. I do not know whether MuseScore uses such a concept internally as I haven't studied the code. What I would be keen to avoid as someone who has started writing plugins is mysterious alpha-numeric strings such as litter the Windows registry (CLSID etc).
If such things were employed within MuseScore it would need a clean, human-readable API.
But terminology alone does get confusing, largely because of the undisciplined way we use terms in our everyday language.
Take the term 'voice', for example. In MuseScore we know that we can have four 'voices' on a staff. But each 'voice' can, and in fact does, contain chords of one or more notes.
To a musicologist, each individual note in a chord is a 'voice': you would need three human voices to sing a three note chord, for example.
And in my Explode Parts plugin I am currently working with that dilemma in trying to explode individual notes from separate 'voices'.
It seems to me that there is a tree structure here, and perhaps someone with a clearer mind than my fuzzy old thing and an understanding of the internals of MuseScore could draw it up?