Add Part Name element to instrument definitions in instruments.xml

• Aug 14, 2019 - 13:10
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project

The current situation is that trackName is used as the display name in the instrument selection dialogue if it is present. If it is not present the first longName is used. This is documented in https://musescore.org/en/developers-handbook/references/instruments.xml…

If present trackName is also used as the Part Name in the staff properties. If it is not present, longName is used. This is not documented in https://musescore.org/en/developers-handbook/references/instruments.xml…

If trackname is changed so that a more useful display name can be shown, the part name is also changed which may not be desired. My particular case is that I have created a Bass clarinet instrument definition which uses the bass clef rather than the G8vb clef when displayed at concert pitch. I have retained the standard Bass clarinet definition and differentiate between the two in the instrument list by seting the trackName in my custom version to "Bass clarinet (Concert=Bass clef)". However when I create a score using this custom instrument its default part name is Bass clarinet (Concert=Bass clef) rather than just Bass clarinet. The way that MuseScore displays the staff in concert pitch is just for my convenience when entering notation it is not of interest to someone using a score that I have created.

The suggestion:

A new element called partName should be added to the instrument description in instruments.xml and, if present, the value of this element should be used as the default Part name in the stave properties. If it is not present, then longName should be used. The use of trackName for the instrument list display as currently documented should be retained.


Comments

Workaround No Yes

I do not dismiss your suggestion, but you can get any name you want displayed in the part name.

When you generate parts, you can edit the part title before you press OK and the title in both the tab and the part will be what you type in this field. If you change your mind after generating the parts (clicking OK to accept) you have two options to fix the name.

First, double click the name in the part and edit it.

Second, go back to the Generate parts and edit this field before you click OK.

You may enter suggestions all you want, but it is advisable to allow some discussion on your ideas in the forum first. I don't think this is explicitly documented, but you can glean these procedures from the handbook. This is really a very simple method of doing what you are requesting. If you still want this suggestion keep it open, otherwise you may close it.

FYI, not a line of code in MuseScore is mine. Everything I know about the program I've learned in one of 3 ways. Reading the handbook, watching the forums and using the program. For example, when I started using the version 3 alpha release about a year ago, there was no documentation on any of the new features, including creating parts. Experimenting was how I mostly learned to use this feature though there were enough differences from version 2 that I remember I was involved in some discussions about generating parts. As a result, I was among those who contributed to this documentation.

In reply to by mike320

Point taken.

Perhaps I dwelt too much on my particular application. However, the current "by design" situation is unhelpful in some situations. trackName, if present, overides longName in seting the instrument display name but also propogates to the default part name. It seems to me to be an improvement if the instrument display name and default part name could be set separately, and that the partName, if present would overide trackName and longName in setting the default part name. There would be no obligation to add partName to any instrument definition and without it the behaviour would be what it is now.

And yes, I recognise the need to experiment as not everything is documented. I have experimented to find out how things actually work. Not all experiments reveal the information one is looking for. In this case it seeems to have revealed that the way things actually work can be improved. Of course this suggestion may have low priority for implementation as there is a workaround and there may be few other users who are bothered about it. But I think it is still a valid suggestion.