New Instrument Selection Menu for the Create Score Dialogue

• Jan 14, 2013 - 12:46
S5 - Suggestion

During my work on making the Instruments.xml file MusicXML 3.0 comptabile it has become increasingly clear that the current 2 layer Instrument list we have in the Create Score dialogue is becoming increasingly confusing and unwieldy, particularly with the "More" box checked.

This has been discussed in this thread in the forum:

The conclusions this discussion has come to is that we need a completely new system designing, and I am proposing the following as a replacement.

We build a 3 layer menu tree with expandable More buttons in each Instrument group - the structure woul look like this

All Instruments
      Instrument Section
            Instrument Group
                  " " " " " "
                  " " " " " "
                  " " " " " "
                  More (displays instruments with the Extended tag set)
      Instrument Section
            Instrument Group
                  " " " " " "
                  " " " " " "
                  " " " " " "

Instrument Genres listed here

The beginnings of the new Instruments.xml file which would feed this structure is attached.

Genres are Currently listed at the end of the file, and instruments added by means of 1 or more Genre tags in the Instrument definition.

I will develop the new Instruments.xml file required to drive this, and MarkRS is prepared to handle the C++ programming side.

Further comments and suggestions to make this happen successfully are welcome.

Attachment Size
NewInstruments.xml 21.2 KB


I'm not that much into the MusicXML format, I've read the thread quickly, but there's one thing that I'd like to ask: would it be possible to have some kind of preferred instrument already selected or something like that? So that one doesn't have to search for the instrument each time?
Maybe this is offtopic here and should discuss it on that thread?

No, discussing it here is fine :)

That is the purpose of the Genres

These will be lists of popular instrument combinations, and the idea is that you should be able to produce your own by simply adding its label to the file, and then tagging the instruments you want in that list accordingly.

There has been some talk of an editor inside MuseScore for the instrument list to achieve this without delving into MuseScore's murky depths, and perhaps this may become part of this project :)

Also, of course if you are really creating music for largely the same sort of ensemble, creating a template is the way to go. But if its more a matter of constantly coming up with different combinations of the same basic set of instruments, then templates don't help so much - but the ability to customize your own genre list in the instruments.xml file (not MusicXML per se) would be great for this sort of thing.

These are just my still somewhat random thoughts on the subject. All the "shoulds" are entirely negotiable :)

I must admit I'm not absolutely clear what we're trying to achieve here. It seems there are two things going on, one is accomodating the new MusicXML format, but the other? Making it easier for people to pick the instruments they want?

It appears that part of the XML standard is that ids for any specific element don't occur more than once in a file (

I'm a bit confused by your "MusicXML id" element. It doesn't look right, it's not a normal XML format, and I'm not sure what you mean by it.

If the/a goal is to make selection of instruments easier, then selecting "style of display" (eg "orchestral", "jazz", "my own") is the way to go, I'd've thought. For example a dropdown box below the list, set it to "Orchestral" and you get... well, the existing display as far as I can see, &tc.
That tends to imply that users would need to be given the ability to set up their own grouping definitions.
Asking users to write proper XML is probably a step too far, the program ought to do it for them, yes a built in editor.
That tends to suggest there's a "my own file" that modifies the "MuseScore supplied file". The current i/f has space for two files, does anyone know what that's about?

"Preferred instrument(s)" shouldn't be part of the xml, they should be part of the user "profile".

MarkRS, you're right, I was more talking about the instruments dialog than the xml.
Anyway, to reply to Marc Sabatella, using a template is even slower, as it requires me to open a file dialog, search and choose the template, etc.
I mean, suppose I often write Piano scores, then I'd like to create a new Piano score almost directly, with few clicks. That would be just a shortcut. I see templates for when you have complex starding scores, anyway nothing like an empty piano or guitar score. This is more a userfriendly feature than something about standards and formats.
It could be the third choice after "Create from scratch" and "from template".

I agree with MarkRS that
""Preferred instrument(s)" shouldn't be part of the xml, they should be part of the user "profile"."
The user should not be able to change the default instrument file (from within MuseScore). But I am in favor of an editor for creating user favorites which is appended to the instrument list (but kept in a separate user file). The user favorites file could have a very simple format since it only need to contain the instrument IDs.

I guess that if it's kept as XML, it could be merged using some XML-library before being parsed, so that in the end it looks like a single file for the application code.

I dont understand why using a template requires use of a file dialog. The template dialog comes up immediately after the initial dialog in the new score wizard, if you choose the template option. So it's the exact same number of clicks to reach the list of templates as it is to reach the list of instruments to select from. And then just a single click to select a template, as opposed to multiple clicks to select instrumenta. For any but single-instrument scores, using a template is always faster - assuming, of course, you have an appropriate template. But if you need to make many changes after loading the template, then indeed, creating from scratch could be faster - and the proposed changes will make this option more manageable.

I sometimes write my post too quickly :)
It may gets longer if you i.e. have a collection of templates where you have to search for the particular template.
What I'm trying to say is a separate, faster way to create an empty score, catching the use case where a user doesn't write complex multi-instrumenti scores - so a template would just mean having an empty file with a single instrument - but it almost writes scores for the same instrument - I'm thinking about the several times I read about teachers here writing exercises, or myself too when I just want to toy with the software but not write any serious score, I just find it long to go through the current wizard.
As another example, when creating a score from scratch, the instrument selection is like I'm debating, but from then you can directly click "Finish", skipping choosing time and key in the following wizard page, making it quick from there.

To address some of the issues MarkRS has brought up.

First of all regarding the "MusicXML id" tag - it looks wrong because it is wrong!

I inadvertently introduced a space into it early on in the proceedings - It wasn't until I started building the new file in Notepad++ that the syntax colouring alerted me to this fact. In the current Instruments.xml file this has now been rectified to "MusicXMLid". It's function is purely compatibility with MusicXML 3.0, being a means by which MuseScore can translate the MusicXML 3 Sound List id into it's own format, and vice-versa when importing and exporting MusicXML files. The history of this is here:

Your ideas about a dropdown box where you select the particular list of instruments required is another way of representing this other than the folding/unfolding tree menu. Personally I prefer the tree menu as it is easy to structure, and, I believe, already has a widget in the QT library, thus saving time on dialogue box design.

The main aim of this is to make the instrument choosing process less confusing and unwieldy.

Ultimately the addition of an editor from within MuseScore is desirable, and has already been mentioned as part of the wish-list. Until it is implemented though, users will have to hack the Instruments.xml file directly, which is the current state of play.

A search box, I believe is nearly here, and will be submitted as a Pull request during the next few days.

I'm sorry to jump in here if it's not the right place (please correct me, if it isn't).

What about instruments that aren't on that list (link )? I think I know of a few more.

Well, I certainly wouldn't be opposed to also having some sort of hierarchical structure to the template list. If you really have so many they are hard to find. I doubt most people do, though. As for scores for a single instrument, that really isn't common except for a few particular instruments that are typically played unaccompanied, so it wouldnt be that bad to have separate templates for each of them, but as I said, indeed, this special unusual case is one in which the create from scratch option is no worse than using a template. And the propsal greatly simplifies the task of selecting the instrument. That is, we agree it takes too long in the existing implementation, and that's why we are proposing improving this. So I'm not sure what your point is?

As for teachers writing exercsies, that,s actually a classic example where a template *is* quite useful even though there is nly instrument. That's because there are normally quite a few things you would want set up differently in a sheet of exercises versus in "regular" music - different formatting, different options in terms of courtesy key and time signatures, etc. and playback wouldn't normally matter, so there's really no harm having just single "generic" exercise template that you could use equally well for trumpet as for shakuhachi. Also, for there are the "lead sheet" templates that provide another very useful form of single-instrument score.

Templates are clearly not the solution for all problems, but I definitely get the sense you are not taking advantage of them as much as you could, and that probably colors your thinking here.

I think Instruments.xml primarily.

I don't fully understand the MusicXML aspect, but I imagine it would be connected to Instruments.xml afterwards?

Thought you guys would like to know that Phase 2 of this process is now complete - I sent the pull request for completion of XML 3 compatibility of the old file about 15 minutes ago.

This opens up the real possibility that we could get this into MuseScore 2 :)

Herewith the proposed DTD for the new Instruments XML file.

I have currently removed the Articulations from the beginning of the file.

This is because I'm not convinced global articulation styles should be part of it, particularly as there is a child articulation element in some of the defined instruments.

Possibly they should have their own file together with default ornament and grace note definitions.

Let me know your thoughts.

Attachment Size
NewInstruments-schema.xml 4.05 KB

1/ If I understand well, (please correct me) we would be adding one more element in the hierarchy of the tree. We currently have "Instrument Group" and "Instrument" and we would add "Instrument Section" on top of instrument group
Instrument group is currently the type of the instrument among

  • Woodwind
  • Brass
  • Untuned Percussion
  • Tuned Percussion
  • Keyboards
  • Vocal
  • Plucked
  • Strings

According to this comment (and one after), the "Instrument section" would be:

  • Orchestral
  • Rock & Pop
  • Sound Effects
  • Ethnic
  • Early Music
  • Military
  • All

3/ Genre. What is it? In DTD I miss the genre definition. I see the genre tag in instruments definition but I don't see the "Instrument Genres listed here"

4/ I would not remove the global articulations. It's a way to define a default for all instruments, and it's fine

What is currently projected is for the Instrument sections to be the same as the existing Instrument Groups ie

  • Woodwind
  • Brass
  • Untuned Percussion
  • Tuned Percussion
  • Keyboards
  • Vocal
  • Plucked
  • Strings

To which would be added:

  • Synthesizers

The instrument groups within would then be categorised into instrument families so the Woodwind group would be split into

  • Flutes
  • Double Reed
  • Single Reed
  • Bagpipes
  • Free Reed

Brass splits into

  • Horns
  • Trumpets
  • Trombones
  • Tubas

and so on.

This means the user has access to a list categorised by sound families, which most composers would find useful.

The genres are a means of generating lists of instruments according to a particular style of music, and consist of one or more genre tags in the instrument definition such as "Orchestral", "Folk", "Jazz" etc.

My current thinking, though, is that maybe genre tags are not necessary if the user is presented with a set of templates to choose from initially rather than the current Choose Instruments dialogue, so common formats like "Lead Sheet", "Piano Vocal Score", "SATB", "Concert Band", "Full Orchestra", "Guitar Band" etc are available at the click of a mouse, with of course the ability to add custom Templates as and when necessary.

The final choice would be "Custom" which would open the Choose Instruments dialogue.

This is a departure from what we have been doing so far, but I feel would make for a less intimidating introduction to the software for the first-time user.

Synthesisers is a tricky one.

Sometimes it would come under keyboards, but you have instruments such as the SynthAxe and EWI.

Which is why Synthesizers needs its own section,

It would then have these sub-sections:

  • Keyboard
  • Mallet
  • Percussion
  • Guitar

and any others we find are necessary

There are also things like the Ondes-Martenot and Theremin and other weird electronic instruments which may need to be categorised here.

Not really most Electronic instruments behave and sound very differently from their real counterparts.

Maybe we should call the section Electronic Instruments rather than synthesisers then it would cover Vocoders and Stylophones (remember them?)

The problem with categorising them elsewhere is that Synthesizers in particular are capable of producing a wide range of sounds which can cross the existing classifications, but are distinct because they are not acoustic in origin, and therefore sound subtly different from acoustic instruments.

Moreover synths can modify sounds in a way impossible for acoustic instruments (even with microphones) so they really need their own section.

One thing that needs clarifying is the official terms for the 2 broad classifications of percussion instruments.

Should it be Unpitched/Pitched

or Untuned/Tuned ??

Personally I would favour the former as there are a number of instruments in the drum family which can (and should) be tuned but would not be regarded as pitched instruments.

I think Electronic Instruments might be better.

Regarding the terms pitched and tuned, neither seem great. Can anyone suggest a better way to refer to them?

This is too much for me... If the user doesn't choose to use a template, creating a piano + flute score would take a lot of clicks (6 if I'm following). I do like the genre ideas of genre/tags though.
What about the following.

  1. Keep the existing instrument group + instrument
  2. Add genre / tags for each instrument and separately. A genre is a string (to display in the UI) and an id to be referenced in the Instrument
  3. Add a combo at the top to filter the instrument list by tags. This combo would also replace the "show more" checkbox. Tags could be "all", "most used", "jazz", "orchestra" etc...
  4. The searchbox would always search in "All"

The existing dialogue is fine until you click the "All" button.

This is when the extra category layer would come into its own.

So we could keep the current dialogue for the standard instrument list - that would just require the UI code to miss out the InstrumentGroup tags in the standard list.

You could then have the InstrumentGroup tags appear as options in the combo box you mentioned.

I do think it is important to have a file structure designed to cover different ways of choosing instruments, and the extra InstrumentGroup tag helps to achieve that, together with being able to add genre tags to each instrument.

The genre tag would also enable the user to have their own custom list of instruments they use most often, and ultimately an editor would be a good plan.

If we can have a data structure that is capable of meeting the different needs of users, then the UI can be built to read the file according to what the user wants to have displayed.

I still think it would add a layer of complexity, and that's not good for the user. Checking the "All" button will change the tree stucture? it sounds unexpected to me. Will it also pop the Combo?

I do think it is important to have a file structure designed to cover different ways of choosing instruments
I disagree again. I do think that the UI should come first and should not be too much customizable but just good and easy to use for any user. One good way is better than several bad ones. I would advocate a simpler UI and not a more complex one.

From my perspective, the advantage of any of this comes in for small ensemble music. If you often write for small ensembles where the specific instrumentation varies from piece to piece but the instruments all come from a relatively small set of instruments typical of a particular genre, then this could still be a pretty big win, I think. Rght now I think some of the instrument family lists - woodwinds especially, to a lesser degree pitched & unpitched percussion - are uncomfortably long, making it take longer than it should to scroll around and find the instruments you want. And having to click open each instrument family group one by one adds another layer of complexity.

But depending on the specifics of how it is implemented, I could certainly see the cure being worse than the disease, so I do also share lasconic's concern. I'd like to see an actual count of how many clicks - including scroll actions - are actually required to construct a variety of typical scores, using the current and proposed systems.

I think probably the way forward is for MarkRS to write some code and then we can make a test build available from a GitHub clone specially built for the purpose.

As I said - the impact on the instruments.xml file itself is not great - I'll upload a copy here once I have finished populating it.

The clever bit will be in the parsing routines which interpret the file for the UI, which as both lasconic and Marc have pointed out is crucial to the experience of the user.

Jumping in a bit late on this, but here's my two cents' worth.

The hierarchical arrangement instrument-type=>instrument-group=>instruments being proposed for the Instrument List UI would definitely make locating instruments easier. It's the same structure I use to organize my library of soundfonts.

No one seems yet to have mentioned that the lists of actual instruments need to be organized in a consistent manner, either alphabetically or by pitch range, preferably a combination of both. One or two clicks more or less in the UI doesn't make a hill of beans, really, but if the user has to read through a scattered list in order to find the desired instrument, now that's an annoyance and a time-waster.

The Genre idea has merit. I generally work with the standard set of Classical/Romantic orchestral instruments, and being presented only with these would certainly speed up instrument selection. I rarely need saxes, for example, so not having them clutter up the selection would be nice. Conversely, I need both B-flat and A Clarinets, B-flat and C trumpets, etc. and it would be useful to have those right up front, so to speak. Furthermore, when I do want to arrange for a jazz combo, it would be nice not to have to wade through piccolos, bass clarinets, and contrabassoons to get to my horns.

Templates, generally, are an equivocal convenience, at least when pre-supplied. Somehow, they never, ever fit my needs. The Chamber Orchestra template, for example, has (most of) the right instruments, but I'd certainly never write woodwind or brass pairs on two separate staves!

I believe what would be far more useful than worrying about existing templates is a simple method for creating them. In the Instruments dialogue, a "Save as template" button would be a huge asset. The way things are set up now (in 1.3), I have to save frequent setups as blank .mcsz files and move them into the templates directory in order to get them into the templates list. One-click shopping would be very nice.

It sounds to me like genres and templates might turn out to be very similar in usage.

FWIW, I'm intending to make am editing facility for genres. Would that fit your request/though/vision?

The list is currently not sorted programmatically at all, just being presented in the order that the instruments are entered into the xml file. That might turn out to be sub-optimal I suppose.

In usage as I envisage it, genres and templates would serve different functions. Perhaps I should say reflect differing methodologies. Genres would be terrific convenience when setting up scores from scratch or adding instruments to an existing score. Templates, at least the way I use them, are specific score setups requiring no editing, just "load and start engraving". Not really all that similar in usage, and serving two discrete, useful functions.

On the subject of templates generally, I think a lot of care needs to go into any that ship with Musescore as part of the package. I don't tend to use the templates provided by any application (say, a video editor or a word processor) because they almost always need to be edited; the time spent tweaking a template usually exceeds the time spent setting things up from scratch.

Regardless, templates need to reflect a conservative aesthetic while adhereing as closely as possible to contemporary standards, down to the last detail. Users, especially new users or ones with limited formal training, are pre-disposed to think of templates as models of correct style, and to write to the template instead of adjusting infelicities.

As an example—and an example only, one I've mentioned in another post—the Chamber Orchestra template splits everything but the Fr. Horns into separate staves (one staff for Flute I., one staff for Flute II., etc). While this is acceptable in that it conveys musical intent clearly, common practice dictates only one score staff per doubled instrument section. Those without a lot of experience may opt to use the template as-is, leading to a proliferation of needlessly dense scores that are sure to bug the hell out of conductors. One wants to make certain that the convience afforded by shipped templates doesn't lead to sloppy score engraving, or to the belief that the template is necessarily a reflection of "how it's done correctly" (unless, of course, it is).

It's clear to me the Chamber Orchestra template (sorry to pick on it; I don't really object to it as much as it sounds) has been set up as it is in order to make the generation of parts possible. Was this wise? Methinks not. It prioritizes a function of the program (splitting scores into parts) over established score notation, which is not a good idea. (Being able to extract individual voices from a staff, now that that would be a good idea!)

Just something to think about when getting into the whole area of templates.