MakeMusic
SmartMusic Finale Garritan MusicXML

XML taxonomy: Flat or hierarchical? Enumerations or strings?

Moderator: Michael Good

XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Michael Good » Mon Jan 31, 2011 2:26 pm

The great discussion we have had on the initial taxonomy proposal leads to some fundamental questions about how to represent the instrument sound taxonomy with XML structures in the MusicXML framework. I think there are two main issues here:

1) Should instrument sounds be represented with no XML hierarchy, a single-level hierarchy, or a multiple-level hierarchy?

2) Should instrument sounds include standard values represented by enumerations plus extensions as string values? Or should all sound elements be string values, not enumerations?

My initial proposal was 1) a single-level hierarchy and 2) using enumerations. For instance, here was the initial example for representing a solo Eb clarinet. I have changed the element name from instrument-type to instrument-sound based on our previous discussions:

<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<instrument-sound>
<wind>
<standard-wind>clarinet</standard-wind>
<instrument-key>eflat</instrument-key>
</wind>
</instrument-sound>
<!-- solo and ensemble are already in MusicXML 2.0 -->
<solo/>
</score-instrument>

In this example, the standard-wind element is an enumeration. There would be a parallel other-wind element available with string values to make things extensible.

This is a one-level hierarchy: all the instrument names are classified under a single set of instrument types. That level of the hierarchy corresponds to a partial flattening of the top two levels in either the Sibelius or capella hierarchies.

(The instrument-key could be redone as pitch plus accidental, or expanded to a more general instrument attribute element. These issues seem relatively independent of the two main representation questions.)

Joe and Michael raised concerns about representing the hierarchy so explicitly with MusicXML elements. Another possibility would be to use strings for all the IDs. These could be SoundWorld strings, capella strings, or something similar with an implied hierarchy:

<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<!-- For this example, use the Sibelius Standard SoundWorld ID -->
<instrument-sound>wind.clarinets.eb</instrument-sound>
<solo/>
</score-instrument>

Another alternative would be to make the instrument-type element more hierarchical within the MusicXML structure. For instance, if we use the capella representation for solo Eb clarinet, it could look like this:

<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<instrument-sound>
<wind>
<wood>
<single-reed>
<standard-single-reed>clarinet</standard-single-reed>
<instrument-size>eb</instrument-size>
</single-reed>
</wood>
</wind>
</instrument-sound>
<solo/>
</score-instrument>

Here we have three levels of hierarchy rather than a single level. With the XML format we could have hierarchical elements at different levels of depth for different top-level instrument families, if desired.

With any of these hierarchical approaches, I think we could use either the enumeration or string approach. I don't think the enumeration approach would work well without having any hierarchy elements.

I would be very interested in hearing feedback on these two issues:

1) What's the best level of hierarchy for the MusicXML sound definitions: 0, 1, or multiple levels? 2) Should there be a combination of enumeration and string elements, or just strings?

Thanks very much for your continued help in working through these complex design issues to get something that works well for diverse MusicXML applications.

Best regards,

Michael Good Recordare LLC
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Craig Sapp » Mon Jan 31, 2011 4:37 pm

Hi Michael,

Michael Good wrote:(The instrument-key could be redone as pitch plus accidental, or expanded to a more general instrument attribute element. These issues seem relatively independent of the two main representation questions.)

Regarding transposition, I think that it would be useful to allow the transposition of the instrument to be explicitly encoded in the instrument description. Consider a fairly comprehensive list of all transposing instruments sorted by transposition interval (some instruments which I have never heard of and will never hear):
<http://en.wikipedia.org/wiki/Transposing_instrument>
Instruments should not only be given a key, but also a transposing direction (up or down), plus an octave count adjustment for very high or very low transposing instruments.

Instruments which "transpose up" will "sound down" and vice versa, so it gets confusing. For a B-flat clarinet, if they play a written middle C (C4) in the transposed part, you will hear a B-flat 3 (major second below the written pitch). Conversely if you want a B-flat clarinet to play middle C, you write in its part a D4. Thus the
"transposing direction" which is consistent for a B-flat clarinet is down, since it "sounds down", although it is "written up".

For for a B-flat clarinet:
Key: B-flat
Direction: down
Octave: 0

For a B-flat bass clarinet (sounding down a major ninth below the written pitch):
Key: B-flat
Direction: down
Octave: -1

Piccolo trumpet in B-flat (sounding up a minor seventh above the written pitch):
Key: B-flat
Direction: up
Octave: 0

Piccolo (flute) sounding up an octave:
Key: C
Direction: up
Octave: 1

Double Bass: (sounding an octave lower than written):
Key: C
Direction: down
Octave: -1

A more compact description of the transposition could be made with an interval:
B-flat clarinet: sounds down a major second from a transposed part.
B-flat bass clarinet: sounds down an octave and a major second a transposed part.
piccolo trumpet: sounds up a minor second from a transpose part.
piccolo flute: sounds up an octave from a transposed part.
double bass: sounds down an octave from a transposed part.

Both MuseData and Humdrum use intervals to describe the transposition
(more as a description of the musical data rather than of the instrument). In Humdrum, which is for music analysis and not printed, scores are always written in concert pitch, and the transposition is encoded as the interval needed to construct a transposed part (up a major second for a B-flat clarinet) which is describing the transposition interval in the reverse direction (so the direction of the transposition interval is switched).

A less verbose way of encoding the interval would be to specify the key of the instrument and the 12-tone steps needed to transpose a transposed part into sounding pitch
B-flat clarinet: -2, B-flat
B-flat bass clarinet: -14, B-flat
B-flat piccolo trumpet: +10, B-flat
C piccolo flute: +12, C
C double bass: -12, C Both the key and semitone transposition needed to get from transposing to sounding are need for exotic transpositions which are only theoretical or contrived, such as Clarinet in A#. If you exclude these cases, then just the number of semi-tones is sufficient to determine the key of the instrument and its correct transposition.
B-flat clarinet: -2
B-flat bass clarinet: -14
B-flat piccolo trumpet: +10
C piccolo flute: +12
C double bass: -12

Implementation:

Joe Berkovitz wrote:<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<instrument-sound>
<wind>
<standard-wind>clarinet</standard-wind>
</wind>

+ <instrument-key>eflat</instrument-key>
+ <transpose-to-sound>+3</transpose-to-sound>
Somebody wrote:</instrument-sound>
<!-- solo and ensemble are already in MusicXML 2.0 -->
<solo/>
</score-instrument>

Note: <instrument-key> is not a property of the instrument class
(<wind>) but of the instrument so it should not be placed on that level of the hierarchy. For the transposition, it would be useful to be careful about the direction of the transposition, hence I put
"transpose-to-sound" rather than "transpose", since the direction of the transposition would be dependent on whether going from sound to written or written to sound.

For music analysis purposes, another thing which might be slightly useful is to consider encoding the original instrument as well as encoding the intended instrument. For example, the clarinet part for Beethoven's first symphony was originally written for a Clarinet in C.
But since C clarinets are rare, it is often played on B-flat clarinets. For analytical purpose this information is interesting, since the fingerings of the b-flat transposition might be more difficult. And if someone does automatic fingering difficulty analysis on all clarinet parts in Beethoven's symphonies, and discovers that Beethoven wrote much harder clarinet parts when he wrote in C major... Likewise, Mozart's clarinet concerto was originally written for Basset Horn, but is now typically played on an A clarinet which does not have the same range, so there are a lot of jumps by a seventh in the A clarinet part which transposes up an octave whenever the notes get too low to play.

Another more degenerate case is cello parts written in the treble clef. In a now obsolete method, pitches written for the cello in treble clef were transposed down one octave (but no transposition when written in the bass clef). In other words they were written in the double treble clef (modern vocal tenor clef), but only a single G clef was written, with the transposition encoded implicitly in the convention. Brass instruments like the French horn also had this property, I think. But I would say that this is a property of the musical data rather than the instrument.

-=+Craig
Craig Sapp
 
Posts: 28
Joined: March, 2014
Reputation: 0

RE: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Michael Good » Mon Jan 31, 2011 5:24 pm

Hi Craig,

Thanks for the feedback.

The transpose element in the attributes.mod module already represents transposition comprehensively. It represents what must be added to the written pitch to get the correct sounding pitch including chromatic steps, diatonic steps, and octave displacement.

MusicXML 3.0 will not change this. The only time we will add a possibly redundant feature will be to fix a feature that just doesn't work correctly in MusicXML 2.0. In particular, we need to remove the limitation of one midi-device element per score-part. The best way to do that might be with a redundant element, deprecating the older element.

The instrument taxonomy's purpose is to make playback and file exchange more accurate for MusicXML files in a world of virtual instruments. The instrument-key / instrument-size element is intended to help refine what sound should be used, not to indicate transposition for transposition's sake. The key or size is an identifier, not a transposition representation. The initial example used a string, rather than a pitch/alter combination, just to avoid this type of confusion.

Best regards,

Michael Good Recordare LLC
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Hartmut Lemmel » Mon Jan 31, 2011 5:45 pm

Dear Michael and List,

I would strongly prefer a single string (capella or Sibelius like) with a built in hierarchy.

> <score-instrument>
> <instrument-name>Eb Clarinet</instrument-name>
> <instrument-sound>wind.clarinets.eb</instrument-sound>
> <solo/>
> </score-instrument>

The possibility of sound substitution (enabled by the hierarchy) is not only needed to switch from one sound library to another. The same mechanism is used to ensure backward compatibility of the music files. If a file is saved in ten years and contains an instrument which is not yet known nowadays by any program or library, capella 2010 can still deal with it, and knows approximately what type of instrument it is. This is not possible with flat instrument IDs.

One could hard-code the lower levels of the hierarchy in the MusicXML structure and allow flexibility only in the details, which would be coded in a string. But from my point of view, this mixed strategy just complicates the format and doesn't bring much benefit.

Additional informations like solo/ensemble, pitch range, standard articulation etc. are fine in separate XML elements.

But I would leave the instrument key as part of the <instrument-sound> string, because it just specifies a certain instrument and has no stand-alone meaning or musical relevance. It is quite random which instrument is called by its key and which has a certain name like bassetthorn. For some unknown reason the bassetthorn is not called F clarinet, although it would be systematic. So let's define the eb clarinet as something like
"wind.wood.singlereed.clarinet.eb" and then forget about the eb. The bassetthorn would be "wind.wood.singlereed.clarinet.bassetthorn".

The notated transposition is something different! I guess it is already part of MusicXML 2.0 anyway. It often differs from the instrument's fundamental, e.g. the alto recorder is an F instrument, the trombone is a Bb instrument but both are always notated in C. The most confuse instrument is probably the french horn, which is usually in both F and Bb, and the player has to read all transpositions you can think of. (I am playing it.)

Coming back to the World Instruments: I haven't classified them yet with capella genericSound IDs. I have just looked through and can tell that they can all be nicely integrated.

Best wishes, Hartmut
Hartmut Lemmel
 
Posts: 6
Joined: March, 2014
Reputation: 0

Re: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Craig Sapp » Mon Jan 31, 2011 8:48 pm

Hi Michael,

On Mon, Jan 31, 2011 > The instrument taxonomy's purpose is to make playback and file exchange more
Michael Good wrote:accurate for MusicXML files in a world of virtual instruments. The instrument-key / instrument-size element is intended to help refine what sound should be used, not to indicate transposition for transposition's sake. The key or size is an identifier, not a transposition representation. The initial example used a string, rather than a pitch/alter combination, just to avoid this type of confusion.

That all sounds good, then The main case I can foresee difficulty is when the score is written in concert pitch, and you want to generate transposed parts automatically. Can this case currently be handled with MusicXML? There will be no <transpose> information in the <attributes> for the part (since it is in sounding score), and so there is no information about the transposition for the instrument.

Another related case might be that you want to verify that the transposition of the part is correct for the instrument. If someone was sloppy and changed the name of the instrument without changing the transposition (such as changing from E-flat clarinet to B-flat clarinet, but not adjusting the transposition).

-=+Craig
Craig Sapp
 
Posts: 28
Joined: March, 2014
Reputation: 0

Re: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Henry Howey » Tue Feb 01, 2011 7:43 am

This is a Sibelius problem? Finale already can do this.


Somebody wrote:Hi Michael,

On Mon, Jan 31, 2011 >> The instrument taxonomy's purpose is to make playback and file exchange more
Michael Good wrote:accurate for MusicXML files in a world of virtual instruments. The instrument-key / instrument-size element is intended to help refine what sound should be used, not to indicate transposition for transposition's sake. The key or size is an identifier, not a transposition representation. The initial example used a string, rather than a pitch/alter combination, just to avoid this type of confusion.

That all sounds good, then The main case I can foresee difficulty is when the score is written in concert pitch, and you want to generate transposed parts automatically. Can this case currently be handled with MusicXML? There will be no <transpose> information in the <attributes> for the part (since it is in sounding score), and so there is no information about the transposition for the instrument.

Another related case might be that you want to verify that the transposition of the part is correct for the instrument. If someone was sloppy and changed the name of the instrument without changing the transposition (such as changing from E-flat clarinet to B-flat clarinet, but not adjusting the transposition).

-=+Craig
Henry Howey
 
Posts: 26
Joined: March, 2014
Reputation: 0

Re: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Joe Berkovitz » Tue Feb 01, 2011 8:51 am

Michael Good wrote:The great discussion we have had on the initial taxonomy proposal leads to some fundamental questions about how to represent the instrument sound taxonomy with XML structures in the MusicXML framework. I think there are two main issues here:

1) Should instrument sounds be represented with no XML hierarchy, a single-level hierarchy, or a multiple-level hierarchy?

There should be no XML hierarchy in the sense of specific MusicXML elements encoding parts of the taxonomy. Said another way, the MusicXML schema should not itself encode any particular taxonomy. For maximum flexibility the taxonomy itself should be described in a separate specification, and all MusicXML needs to do is to provide a vehicle for referring to nodes in that taxonomy.

This is similar to the difference between the SoundWorld specification and the specific S3W taxonomy, which is one of many possible taxonomies. The MusicXML schema should be supplying the equivalent of a generic system for describing sounds (like SoundWorld does), not "burning in" a particular classification scheme into the XSD for all time.

The exact approach to representing nodes in MusicXML doesn't matter a lot to me so long as the above principle is observed.

We could have something like this (my personal favorite):

<score-instrument>
<instrument-sound>wind/flutes/flute</instrument-sound>
...

Or like this: <score-instrument>
<instrument-sound>
<instrument-node>wind</instrument-node>
<instrument-node>flutes</instrument-node>
<instrument-node>flute</instrument-node>
</instrument-sound>
...

What I do not want to see is:

<instrument-sound>
<wind>
<flutes>flute</flutes>
</wind>

That's something I believe we'd live to regret.

Michael Good wrote:2) Should instrument sounds include standard values represented by enumerations plus extensions as string values? Or should all sound elements be string values, not enumerations?

Please, no enumerations for exactly the same reason. Let's have a taxonomy that is completely separable from the MusicXML XSD. It will need to evolve and change, and we don't want to be going changing the XSD every time that needs to happen.

Everything should be string values.

For clarity, read on...

Michael Good wrote:Joe and Michael raised concerns about representing the hierarchy so explicitly with MusicXML elements. Another possibility would be to use strings for all the IDs. These could be SoundWorld strings, capella strings, or something similar with an implied hierarchy:

<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<!-- For this example, use the Sibelius Standard SoundWorld ID -->
<instrument-sound>wind.clarinets.eb</instrument-sound>
<solo/>
</score-instrument>

This example would be fine with me.

Michael Good wrote:Another alternative would be to make the instrument-type element more hierarchical within the MusicXML structure. For instance, if we use the capella representation for solo Eb clarinet, it could look like this:

<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<instrument-sound>
<wind>
<wood>
<single-reed>
<standard-single-reed>clarinet</standard-single-reed>
<instrument-size>eb</instrument-size>
</single-reed>
</wood>
</wind>
</instrument-sound>
<solo/>
</score-instrument>

Doesn't work, since that schema now encodes a specific taxonomy.

... . . . Joe

Joe Berkovitz President Noteflight LLC 84 Hamilton St, Cambridge, MA 02139 phone: +1 978 314 6271 www.noteflight.com
Joe Berkovitz
 
Posts: 79
Joined: March, 2014
Reputation: 0

RE: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Michael Good » Wed Feb 02, 2011 11:30 am

Hi all,

Thank you for the great discussion and feedback. We seem to have consensus that the instrument sound:

1) Should be a flat representation, not a hierarchy, and 2) Should be a string, not an enumeration.

Most likely this will be done by adding an instrument-sound element as in my previous email example:

<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<!-- For this example, use the Sibelius Standard SoundWorld ID -->
<instrument-sound>wind.clarinets.eb</instrument-sound>
<solo/>
</score-instrument>

If you think those are the right choices, please let us know why very soon! Until now, I don't believe anyone (except me) has advocated for either a hierarchical or an enumeration approach.

We also seem to have consensus that for MusicXML's purposes, the different elements of sound that are combined into a single Sibelius SoundWorld ID should be separated into different areas. This is similar to the structure of capella genericSound IDs and my initial proposal of divisions between instrument-sound, solo/ensemble, and sound elements.

I think one of the attractions of the string approach is that it is then easy to create a mapping between MusicXML's instrument list and the instrument list for any other program that uses string IDs. So I agree with Mark that we don't want to spend a lot of time on the exact details of the instrument taxonomy (e.g., should keyboard be a top-level category or not).

I do think we need a standard listing of instruments in order to facilitate interchange between programs. I imagine we could do that with a simple XML file that includes the MusicXML instrument listing, which can be updated independently of the MusicXML 3.0 schema and DTD.

Michael and Cecil have proposed having some reasoning or explicit representation about fallback choices within the MusicXML format. This is something I think is best left to individual applications. I believe that MusicXML should list a standardized instrument ID together with information that identifies the particular playback device being used, whether a General MIDI sound or a virtual instrument patch. For fallback, I would assume that an application would convert the MusicXML ID into its own ID via a single map lookup, and then use its own fallback logic based on its own internal ID.

There were several interesting related points and suggestions raised in the replies that I will respond to individually.

Thanks again for the great discussion!

Best regards,

Michael Good Recordare LLC
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

RE: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Henry Howey » Wed Feb 02, 2011 11:47 am

I just bought the Garritan World instruments collection.

I'll be loading them soon.

As I am not a programmer, I cannot comment on the processes; however, I am a musicologist with an early training in ethnomusicology.

When an undergraduate I was in The American Wind Symphony where we performed works by Nigerian composers for western wind instruments and traditional Nigerian percussion instruments. I believe the scores for these works may still reside in the Peters rental catalog. If so, I will try to re-create one of them with FINALE as they are a mixture of two traditions. Should they be available, they might serve as a test of the viability of the taxonomy.

Henry Howey Professor of Music Sam Houston State University Box 2208 Huntsville, TX 77341
(936) 294-1364
http://www.shsu.edu/music/faculty/howey.php Owner of FINALE Discussion List

Somebody wrote:Date: Wed, 2 Feb 2011 09:30:33 -0800 strings?

Hi all,

Thank you for the great discussion and feedback. We seem to have consensus that the instrument sound:

1) Should be a flat representation, not a hierarchy, and 2) Should be a string, not an enumeration.

Most likely this will be done by adding an instrument-sound element as in my previous email example:

<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<!-- For this example, use the Sibelius Standard SoundWorld ID -->
<instrument-sound>wind.clarinets.eb</instrument-sound>
<solo/>
</score-instrument>

If you think those are the right choices, please let us know why very soon! Until now, I don't believe anyone (except me) has advocated for either a hierarchical or an enumeration approach.

We also seem to have consensus that for MusicXML's purposes, the different elements of sound that are combined into a single Sibelius SoundWorld ID should be separated into different areas. This is similar to the structure of capella genericSound IDs and my initial proposal of divisions between instrument-sound, solo/ensemble, and sound elements.

I think one of the attractions of the string approach is that it is then easy to create a mapping between MusicXML's instrument list and the instrument list for any other program that uses string IDs. So I agree with Mark that we don't want to spend a lot of time on the exact details of the instrument taxonomy (e.g., should keyboard be a top-level category or not).

I do think we need a standard listing of instruments in order to facilitate interchange between programs. I imagine we could do that with a simple XML file that includes the MusicXML instrument listing, which can be updated independently of the MusicXML 3.0 schema and DTD.

Michael and Cecil have proposed having some reasoning or explicit representation about fallback choices within the MusicXML format. This is something I think is best left to individual applications. I believe that MusicXML should list a standardized instrument ID together with information that identifies the particular playback device being used, whether a General MIDI sound or a virtual instrument patch. For fallback, I would assume that an application would convert the MusicXML ID into its own ID via a single map lookup, and then use its own fallback logic based on its own internal ID.

There were several interesting related points and suggestions raised in the replies that I will respond to individually.

Thanks again for the great discussion!

Best regards,

Michael Good Recordare LLC
Henry Howey
 
Posts: 26
Joined: March, 2014
Reputation: 0

Re: XML taxonomy: Flat or hierarchical? Enumerations or strings?

Postby Reinhold Kainhofer » Wed Feb 02, 2011 11:50 am

Am Mittwoch, 2. Februar 2011, um 18:30:33 schrieb Michael Good:
Michael Good wrote:Hi all,

Thank you for the great discussion and feedback. We seem to have consensus that the instrument sound:

1) Should be a flat representation, not a hierarchy, and 2) Should be a string, not an enumeration.

Most likely this will be done by adding an instrument-sound element as in my previous email example:

<score-instrument>
<instrument-name>Eb Clarinet</instrument-name>
<!-- For this example, use the Sibelius Standard SoundWorld ID -->
<instrument-sound>wind.clarinets.eb</instrument-sound>
<solo/>
</score-instrument>

As you said, MusicXML needs a proper way to express an instrument's transposition (if the score is given in concert pitch). I don't think encoding this as "eb" is really helpful, as this requires yet another specification how the pitch is encoded. To me it would make much more sense to encode it really as an XML pitch, just like the transposition in the score. That way, importers can automatically determine the correct written and/or concert pitch for the instrument without having to implement yet another parser for the instrument- sound string.

Cheers, Reinhold

-- Reinhold Kainhofer, , http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
Reinhold Kainhofer
 
Posts: 70
Joined: March, 2014
Reputation: 0

Next

Who is online

Users browsing this forum: No registered users and 2 guests