Multiple instruments per part

[joeberkovitz]

This issue notes the need to support multiple instruments within a given part.

MusicXML supports this feature through score-instrument and instrument, as well as other features.

[mogenslundholm]

I wonder if we need this because I think it is a rather complex part of MusicXML.
Instead we could have a way to merge two parts when shown in the score, e.g.
<merge>Sopran</merge> or maybe rather <part merge="Sopran"> ....
Does anybody see new problems with this solution?

[joeberkovitz]

@mogenslundholm please explain why you feel this is a complex part of MusicXML so we can understand the problem being solved. There is no stipulation that this feature be identical to MusicXML, but I think we need to have a good reason to change the approach, and work with clear proposals.

I'm still a little unclear on what you're proposing here. It sounds like you would like to include one part's complete content within another part. What happens to the merged part -- does it automatically disappear, because it was merged into a different part? I feel a little uncomfortable with this, because the situation is symmetrical, yet one part is the "main" part while the other is merged into it.

Another approach might be somewhat like what Dorico does, where there is a 2-level hierarchy of instruments and parts, and each part can include (merge) material from various different instruments. Different layouts for the music may merge instruments in different ways.

Note that material from different instruments can overlap and collide in a "merged" model, so that needs to be thought about too.

[cyrilcoutelier]

I suppose the multi instruments per parts will also used for the percussion parts, and when there are percussive sounds within a pitched part right?

[mogenslundholm]

This is why I feel this is complicatede: Extra processing is needed for every single note, since every note has an instrument - and crossreference tables are needed to look up data for the instrument for every note. Other complications come due to my implementation - I use a set of notes, but with multiple instruments in one part we may have two of the same note.

I see this as a two level solution - one part (<part>) for each instrument defines the music. In the graphical appearence these parts may be shown merged (might be like Dorico). The problems in the merge process seem to me to be the same as the multiple instrument solution - the stems can be used to tell which voice/instrument it is. Properly a complicated processing is needed to avoid overlapping.

The score example illustrates this: Bass voice has stems up, tenor have down stems. But a whole note has no stem, so the notewriter has added an unauthorised line to tell that here the voices are crossing each other.

[clnoel]

The fundamental issue I see here is the following:

Are we really showing multiple instruments in the same <part> element, or are we instead wanting multiple <part> elements to show on the same staff?

If we define this problem the second way, then we can give each instrument its own <part>, with default upstem/downstem or notehead rules. Then we can define a <system-layout> that puts the multiple parts on one staff, with different upstem/downstem or notehead rules.

In your example, @mogenslundholm, we would define two parts, one for tenor, one for bass, and in the <system-layout>, we specify that the staff has both parts with the bass part stem-down and the tenor part stem-up. The extra line can either be encoded in the <system-layout> or the bass <part>, depending on whether the encoder feels that it should show even if the bass part is extracted to its own staff.

This makes it much easier to split parts and assign midi instruments to parts, but is harder to encode since we are no longer encoding each note then deciding which part it belongs to. Also I feel there is some disagreement about how much of the information available in a piece of print music belongs in the part/sequence/event/note, and how much belongs to layout or audio generation.

[shoogle]

I agree with @clnoel. The order should be:

1. Define parts, and notes that belong to them.
2. Define staves, and specify how parts are shared between them.

It should be possible to move parts between staves midway through a score, such as having separate staves for Tenors and Bass when only men are singing, but combining them onto a single staff when Sopranos and Altos are also singing. These "part redistribution" events could be put in the <global> element along with time signatures, key signatures, and tempi.

[joeberkovitz]

@shoogle @clnoel To me, the part/staff approach makes a lot of sense. Parts have musical continuity but may be assigned arbitrarily (and in a changing manner) to staves in a specific realization, using the definition of "realization" in #138.

This more flexible approach opens a question, though, about whether MNX-Common continues to support the existing MusicXML model. In today's model, the <part> element bundles both parts and staves into a single concept, while the <instrument> feature distinguishes multiple sounds within the content in the parts/staves. The two models seem hard to reconcile, because one cannot reliably use <instrument> designations to reverse-engineer a set of parts with musical continuity: there is not always going to be enough information.

@mdgood It would be good to hear your thoughts on this compatibility question... and @dspreadbury, it seems that your experience with Dorico could provide some ideas on what this model means for implementors.

[mogenslundholm]

Could a solution to "multiple instruments" be something like this: The existing <part>-definition is renamed to <instrument ..>. A new <part ...> definition contains one or more <instrument...>-definitions? (and instrument-name and instrument-sound may be put into the instrument-definition)

  <part style="y: above;" name="Voice">
     <instrument name="Sopran" sound="voice.aa">
       <directions>
         ...
       </directions>
       <sequence>
         <event value="/4">
           <note pitch="G4">
              ...        
           </note>
         </event>
         ...
     </instrument>
     <instrument name="Alt" sound="voice.aa">
       ...
     </instrument>
  </part>

Look forward to hear more about Dorico .

[mogenslundholm]

OBS: This comment is misplaced. Moved it to #143. Didn't delete it because there were comments.

…

__________________________ I did a first step in making a program to process MNX-files - a simple program to convert the test file "FaurReveSample-common.xml" to Midi. It would be nice to have a very big example file to test the performance, but so far it seems to me that the program has high performance, due to the simplicity of the program. MNX is easy to process - so far. Much depends on the specification of Multiple Instruments(#104), Grace Notes, Lyrics and Structural Elements. Hope to hear about how /Dorico/ has solved it. Working with this /MNX to Midi/-converter raises some questions. Bring these here to promote discussion and record ideas. Importing the produced Midi-file into /Notation Composer/ looks good - except for the wrong accidentals (Due to Midi-conversion). 1. In an event: Can more than one instances of a pitch occur? Are pitches in a event different? Hope so, because then the notes can be a "set of notes". This gives an effective implementation. A tune that has two of the same note is the intro that /Jimi Hendrix /played in "/Hey Joe/", but they should go to two sequences anyway. 2. Key Fifths: /MusicXml/ has two ways to specify the key: Either the "number of fifths" or "which fifths". Two ways to do a thing more than doubles the code and testing. The two ways are never equally used, so that the one solution is often poorly tested. With only one way to do it, this solution is tested all the time. Since the first way (Specifying number of fifths) is insufficient, I think that only the last solution (specifying each fifth) will do. 3. Tuplet: The test-file, "FaurReveSample-common.xml", that I have, uses "normal" and "actual" instead of "inner" and "outer". By the way - wasn't it better to have a ratio instead, i.e. "3/2"? (But "inner" and "outer" are intuitive, while I would not be sure if I should multiply with or divide by the ratio) 4. Duration measure="yes"? Wasn't it better to just specify the actual duration? 5. Dottet notes: Why use "d" - why not "." - more intuitive. 6. The duration - shouldn't it rather be "1/4" instead of "/4"? 7. Noting the note pitch G1. One or two octaves more? I.e. should G1 be noted G3 instead? No - not needed. 8. Could some requirements be more tight? E.g. Format = Unicode. (instead of either Ansi or "UTF8 little endian" or "UTF8 big endian" or ... ) 9. In a sequence: why value? Everything is values. Why not "time" or "duration" 10. Event ID's in the first test file are almost half of the file. Is it neccesary? Or is the intension that only the needed ID's should be present? 11. Identifying the changes in the manual. How to view changes (I am a Github novice). 12. (Off topic) Single/Begin/End: In XML the symbols may appear as "single", "begin" or "end" definitions e.g. Single definition: "<note pitch="G4"/>", or Begin definition: "<note pitch="G4">" and End definition "</note>". Are we to decide how to do it or does XML require that the single definition is equivalent to "<note pitch="G4"></note> ? /Mogens

[shoogle]

@mogenslundholm, let's try to stay on-topic and not go into too much detail too soon. I agree with many of the points you make about syntax (e.g. "1/4" instead of "/4") but that is not relevent to this discussion. Please create a new issue(s) to discuss those points (and check for existing issues first).

This discussion is specifically about how the definitions of part, instrument, staff and sequence are related, and where to define the notes that belong to each. Your example of the Sopranos and Altos sharing a part raises a question about where to draw the line between:

• Parts (vocal or instrumental)
• Sections (vocal or instrumental)
• Independent instruments (or singers) that just happen to be written on the same staff.

I would like to see instruments grouped by human performer, then by section, then by immediate family, then by "part", then by extended family, and finally by ensemble. For example:

• Instruments: there are three flutes and one piccolo
• Performers: the person playing Flute 3 is also to play the Piccolo
• Parts: Flute 1 and Flute 2 share a printed part, Flute 3 and the Piccolo share a part (obviously)
• Immediate family: the flutes and piccolos are both members of the flute family
• Extended family: the flute family is part of the woodwind family of instruments
• Ensemble: there are three orchestras playing at once, and the above instruments belong to Ochestra 1.

The heirachy could work like this:

<Ensemble name="Orchestra 1">
  <InstrumentGroup name="Woodwind">
    <InstrumentGroup name="Flutes">
      <Part name="Flutes 1, 2">
        <Performer name="Flute 1"><Instrument name="Flute"/></Performer>
        <Performer name="Flute 2"><Instrument name="Flute"/></Performer>
      </Part>
      <Part name="Flute 3, Piccolo">
        <Performer name="Flute 3, Piccolo">
          <Instrument name="Flute"/>
          <Instrument name="Piccolo"/>
        </Performer>
      </Part>
    </InstrumentGroup>
    <!--more woodwind groups-->
  </InstrumentGroup>
  <!--more instrument families-->
</Ensemble>
<!--more orchestras/bands/choirs/ensembles-->

It might not be necessary to define all of those relationships explicitly in each file. For example, the "immediate" and "extended" instrument families could be defined in the MNX specification rather than in each file (although defining them in the file makes it easy to bracket the staves together).

It also might not always be possible to define the relationships as a strict heirachy. For example, what if a single person is asked to play instruments from two different families? In this case it might be necessary to define performers separately and assign an ID to each one.

[shoogle]

When it comes to defining the actual notes, the question is whether similar instruments can share a common sequence of notes, or whether it is necessary to define the notes separately for every instrument? Here are some of the more tricky situations we would have to deal with...

1. Shared staff in the score, separate staves in the parts

a) Individual instruments (usually wind instruments)

b) Instrumental sections (usually strings)

One staff (usually used in the full score, or for a short divisi)

Two staves (usually used in the parts, or for a long divisi)

Note: a single staff is always used in both the score and the parts for systems with no divisi.

2. Ambiguous distribution of notes

a) Individual instruments/singers

b) Instrumental/vocal sections

3. Overlapping pitches

4. Instrument changes and overlapping parts

Notice the man's sings "I love" while the woman is still singing "you". I have seen overlaps like this occur in professionally engraved scores, such as this edition of Phantom of the Opera (Click "look inside" to see a preview. An example occurs on the final page of "Think Of Me".)

5. Redistribution of parts between staves

The following examples are from the Pirates of Penzance, Chappell edition (plate 23731), which is in the public domain.

At the end of the Act I finale, the characters of Mabel, Edith and Kate (all of whom have had separate staves earlier in the piece), are explicitly instructed to sing with the "girls" (i.e. the female chorus):

A few bars later, the chorus of girls splits into sopranos and "contraltos", and the soloists are told which group to sing with:

A few bars later, Kate stays with the contraltos on the bottom line, but Edith switches to the soprano line. Mabel gets a whole line to herself, but she continues to share the staff with the others.

After another few measures, Mabel rejoins Edith and the sopranos, while Kate stays with the contraltos.

[clnoel]

@shoogle I feel like situations 1, 2, 4 and 5 have been sorted in #185. Although the "labels" of the part switching in "situations" 4 & 5 might need some discussion (left-side labels are being discussed in #277, and I've proposed "over" as an option for labels in layouts there).

As to situation 3, the choice of whether to have "3 Flutes" be a part with a simple layout, or have 3 parts ("Flute 1", "Flute 2", "Flute 3") with a complex set of layouts would have to be on the creating program. As long as we weren't trying to make a separate "part" score for each flute part, I would go ahead and stick with "3 Flutes". If you were trying to make a separate part score for each flute part, the creating program would either already know which part went with which each note, or the editor would have to guess... which would be true for anybody playing or reading this piece anyway.

Do you see any other issues that we haven't covered elsewhere? Would you like me to write up sample mnx for the solutions to the above situations, to demonstrate how the -layout system solves these problems?