MakeMusic
SmartMusic Finale Garritan MusicXML

modes

Moderator: Michael Good

modes

Postby John Lynch » Wed Sep 11, 2002 2:06 pm

Hello,

I'm nearing completion on the first version of an ABC to MusicXML converter. Michael has been gracious in answering my questions along the way, but some of them seemed relevant to the larger list, so here goes: Is there support for modes besides major and minor in the MusicXML spec? Lots of folks tunes (most of what is in ABC) are modal, of course, but at the moment I'm just mapping the mode to the equivalent
(enharmonic) major or minor key. So all of the notes are correct, but this approach loses information. For analysis and such, I'd think the fact that a tune is actually in D Mixolydian (vs. G major which is how it currently appears in my MusicXML output), is important. Am I missing something?

I just tried doing something like: <key>
<fifths>2</fifths>
<mode>mixolydian</mode>
</key>

but to no avail. It would be pretty easy to support by the way, since the different (major-scale based) modes correspond to an equivalent major key. Each mode can be represented as a shift of a certain amount around the circle of fifths, e.g. mixolydian is the same notes as the key one fifth down; so for D Mix, get fifths=2 for D, then shift by -1 to get equivalent key of G major. Easy enough to do, it would just be nice if it were the reading program's responsibility, so the original tune mode is saved. Or allow the key description mode to have a name and explicit "fifths-offset" value or whatever to make it the writing program's responsibility.

My apologies if this is all obvious and/or already handled in the spec.

Thanks,

John Michael answered:

Currently the <mode> is defined as major/minor, but we have thought of adding the other modes too. This is something we can't test with Dolet for Finale, since all Finale understands is major and minor. Currently, anything it doesn't understand is assumed to be major. So we have been waiting for software that could make use of modes before officially supporting it in MusicXML. Your abc converter could be just what we are looking for in this area!

The fifths is the number of sharps or flats in the key signature, so for D Mixolydian, you would want a fifths value of 1 (for one sharp) rather than 2 (as in D major, but not D minor). Unless I am misunderstanding how your modal tune is notated?

It seems you should be able to include the mode in your output even if it isn't official MusicXML without affecting the Finale import. An import/export will lose the mode information that Finale doesn't understand, but the import should display the notation OK.

My reply:

Yes, normally the modal tune is notated as the major key that is enharmonic to the mode in question. So in the example above, the tune would really just be notated: <key>
<fifths>1<fifths/>
<key>

I suppose I could just add:
<mode>mixolydian</mode>
to that.

At the moment adding the "minor" specification doesn't seem to affect the fifths value, i.e. D minor is: <key>
<fifths>-1</fifths>
<mode>minor</mode>
</key>
I suppose the other modes should work the same. So the fifths value indicates the major key whose scale contains the notes of the tune, and a mode such as mixolydian is mostly informational.

I guess the question is just one of where the work of mapping modes to major keys goes. If I have 5-600 reels that I want to analyze once they are in XML, and I want to analyze something about all the D Mixolydian tunes, I (or my querying program) need to know as a MusicXML query user that D Mixolydian is really represented by the corresponding major key in the fifths element, and a mode element of "mixolydian". So I need to do the mapping, since "D" doesn't really show up anywhere. That's absolutely fine, of course, but I guess it should be stated as such in the spec and the other modes should have
"official" versions as far as capitalization and such.

The other option would be for it to the reading program's responsibility to the mapping. This is pretty much what the ABC spec calls for: the tune transcriber can just say "Dmix" for key, and it's up to the reading program to figure out a key signature from that. It does seem more in keeping with the MusicXML spec, however, to make things as explicit as possible in the XML file itself, and have the fifths value correspond directly to a key signature.

Thanks, John
John Lynch
 
Posts: 9
Joined: March, 2014
Reputation: 0

Re: modes

Postby Neil Jennings » Wed Sep 11, 2002 3:07 pm

The modes may be unimportant in terms of key signature, but when generating chords to accompany a melody, which my HARMONY program does, it is important to know which mode the tune is in.

(Harmony does import and export abc, and supports most, but not all, of its features)


Date: 11 September 2002 21:15


John Lynch wrote:Hello,

I'm nearing completion on the first version of an ABC to MusicXML converter. Michael has been gracious in answering my questions along the way, but some of them seemed relevant to the larger list, so here goes: Is there support for modes besides major and minor in the MusicXML spec? Lots of folks tunes (most of what is in ABC) are modal, of course, but at the moment I'm just mapping the mode to the equivalent
(enharmonic) major or minor key. So all of the notes are correct, but this approach loses information. For analysis and such, I'd think the fact that a tune is actually in D Mixolydian (vs. G major which is how it currently appears in my MusicXML output), is important. Am I missing something?

I just tried doing something like: <key>
<fifths>2</fifths>
<mode>mixolydian</mode>
</key>

but to no avail. It would be pretty easy to support by the way, since the different (major-scale based) modes correspond to an equivalent major key. Each mode can be represented as a shift of a certain amount around the circle of fifths, e.g. mixolydian is the same notes as the key one fifth down; so for D Mix, get fifths=2 for D, then shift by -1 to get equivalent key of G major. Easy enough to do, it would just be nice if it were the reading program's responsibility, so the original tune mode is saved. Or allow the key description mode to have a name and explicit "fifths-offset" value or whatever to make it the writing program's responsibility.

My apologies if this is all obvious and/or already handled in the spec.

Thanks,

John Michael answered:

Currently the <mode> is defined as major/minor, but we have thought of adding the other modes too. This is something we can't test with Dolet for Finale, since all Finale understands is major and minor. Currently, anything it doesn't understand is assumed to be major. So we have been waiting for software that could make use of modes before officially supporting it in MusicXML. Your abc converter could be just what we are looking for in this area!

The fifths is the number of sharps or flats in the key signature, so for D Mixolydian, you would want a fifths value of 1 (for one sharp) rather than 2 (as in D major, but not D minor). Unless I am misunderstanding how your modal tune is notated?

It seems you should be able to include the mode in your output even if it isn't official MusicXML without affecting the Finale import. An import/export will lose the mode information that Finale doesn't understand, but the import should display the notation OK.

My reply:

Yes, normally the modal tune is notated as the major key that is enharmonic to the mode in question. So in the example above, the tune would really just be notated: <key>
<fifths>1<fifths/>
<key>

I suppose I could just add: <mode>mixolydian</mode>
to that.

At the moment adding the "minor" specification doesn't seem to affect the fifths value, i.e. D minor is: <key>
<fifths>-1</fifths>
<mode>minor</mode>
</key>
I suppose the other modes should work the same. So the fifths value indicates the major key whose scale contains the notes of the tune, and a mode such as mixolydian is mostly informational.

I guess the question is just one of where the work of mapping modes to major keys goes. If I have 5-600 reels that I want to analyze once they are in XML, and I want to analyze something about all the D Mixolydian tunes, I (or my querying program) need to know as a MusicXML query user that D Mixolydian is really represented by the corresponding major key in the fifths element, and a mode element of "mixolydian". So I need to do the mapping, since "D" doesn't really show up anywhere. That's absolutely fine, of course, but I guess it should be stated as such in the spec and the other modes should have
"official" versions as far as capitalization and such.

The other option would be for it to the reading program's responsibility to the mapping. This is pretty much what the ABC spec calls for: the tune transcriber can just say "Dmix" for key, and it's up to the reading program to figure out a key signature from that. It does seem more in keeping with the MusicXML spec, however, to make things as explicit as possible in the XML file itself, and have the fifths value correspond directly to a key signature.

Thanks, John
Neil Jennings
 
Posts: 16
Joined: March, 2014
Reputation: 0

RE: modes

Postby Michael Good » Wed Sep 11, 2002 3:43 pm

We can certainly add more modes to the definition of the <mode> element, especially now that we have several programs that want to use this information.

Currently only "major" and "minor" are defined in the MusicXML spec. To that we could add:

dorian
phrygian
lydian
mixolydian
locrian

Would it be helpful to add "ionian" and "aeolian" as well? Are there other suggestions?

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

Re: modes

Postby John Lynch » Wed Sep 11, 2002 4:31 pm

I would think "ionian" and "aeolian" would be useful at least in academic use, so the more the merrier I say.

Also, moving from folk to jazz, there are some other interesting modes that arise, though I don't know if entire tunes are ever written in them. I'm thinking of modes built on the melodic minor scale for instance, such as "Lydian dominant".

If you did want to represent such a mode in MusicXML, you would have to use the key- step, key-alter elements (e.g. F Lydian dominant uses the C melodic minor scale which has E-flat as the only altered note). From the DTD, it appears that the key-alter element is incompatible with a mode specification at the moment. Again, I don't really know if that's the sort of thing you would ever want to represent at a tune level, but maybe by making a mode specification compatible with the key-step,key-alter ones you cover your bases.

BTW Neil, you're probably aware of it, but ABCMus is a free/shareware program that does a passable job of adding chords to ABC files if you want to compare outputs.

John




Neil Jennings wrote:The modes may be unimportant in terms of key signature, but when generating chords to accompany a melody, which my HARMONY program does, it is important to know which mode the tune is in.

(Harmony does import and export abc, and supports most, but not all, of its features)
John Lynch
 
Posts: 9
Joined: March, 2014
Reputation: 0

RE: modes

Postby Neil Jennings » Thu Sep 12, 2002 2:57 am

Aeolian would be necessary, as it is one of the most common (white note scale on A), and a 'natural' minor. Ionian would be useful in rare instances for a white-note scale on C that does not resolve like a major key.

Locrian is maybe the least used.

Michael Good wrote:We can certainly add more modes to the definition of the <mode> element, especially now that we have several programs that want to use this information.

Currently only "major" and "minor" are defined in the MusicXML spec. To that we could add:

dorian phrygian lydian mixolydian locrian

Would it be helpful to add "ionian" and "aeolian" as well? Are there other suggestions?

Thanks, Michael
Neil Jennings
 
Posts: 16
Joined: March, 2014
Reputation: 0

Re: modes

Postby Nick Didkovsky » Thu Sep 12, 2002 7:35 am

I realize I am going to sound like an XML newbie with this question, and rightfully so, since I am one. And so, having nothing to lose, here goes...

The modes discussion brought up something I've been wondering about for a while in MusicXML. Is it absolutely required that every tag is defined? Why isn't it ok to use an undefined tag, which a particular implementation of an xml parser simply skips if it doesn't recognize it? This behavior would be similar to web browsers that skip html tags they don't understand instead of failing on the entire page load.

For example, let's say I wrote "wedge" for an articulation to a MusicXML file. Tomorrow or a year from now, "wedge" might be supported. Meanwhile, shouldn't a MusicXML parser forgive the unrecognized tag, maybe throw a warning, but continue? Similarly for the modes discussion. If it doesn't recognize Aeolian today, what would be wrong with simply skipping it as an unrecognized tag, throwing a warning to the user, and continuing?

Best, Nick




Neil Jennings wrote:Aeolian would be necessary, as it is one of the most common (white note scale on A), and a 'natural' minor. Ionian would be useful in rare instances for a white-note scale on C that does not resolve like a major key.

Locrian is maybe the least used.

Michael Good wrote:>We can certainly add more modes to the definition of the <mode> element, especially now that we have several programs that want to use this information.

Currently only "major" and "minor" are defined in the MusicXML spec. To that we could add:

dorian phrygian lydian mixolydian locrian

Would it be helpful to add "ionian" and "aeolian" as well? Are there other suggestions?

Thanks, Michael

-- Doctor Nerve Home Page, http://www.doctornerve.org Interactive Computer Music, http://www.punosmusic.com Java Music Specification Language, http://www.algomusic.com
Nick Didkovsky
 
Posts: 43
Joined: March, 2014
Reputation: 0

RE: modes

Postby Paul Mindrup » Thu Sep 12, 2002 9:01 am

One of the "advantages" of XML is that it's not forgiving like HTML. The specification says that a parser must throw an error if a document is not well-formed.

Paul


Nick Didkovsky wrote:I realize I am going to sound like an XML newbie with this question, and rightfully so, since I am one. And so, having nothing to lose, here goes...

The modes discussion brought up something I've been wondering about for a while in MusicXML. Is it absolutely required that every tag is defined? Why isn't it ok to use an undefined tag, which a particular implementation of an xml parser simply skips if it doesn't recognize it? This behavior would be similar to web browsers that skip html tags they don't understand instead of failing on the entire page load.

For example, let's say I wrote "wedge" for an articulation to a MusicXML file. Tomorrow or a year from now, "wedge" might be supported. Meanwhile, shouldn't a MusicXML parser forgive the unrecognized tag, maybe throw a warning, but continue? Similarly for the modes discussion. If it doesn't recognize Aeolian today, what would be wrong with simply skipping it as an unrecognized tag, throwing a warning to the user, and continuing?

Best, Nick




Neil Jennings wrote:Aeolian would be necessary, as it is one of the most common (white note scale on A), and a 'natural' minor. Ionian would be useful in rare instances for a white-note scale on C that does not resolve like a major key.

Locrian is maybe the least used.


-- Doctor Nerve Home Page, http://www.doctornerve.org Interactive Computer Music, http://www.punosmusic.com Java Music Specification Language, http://www.algomusic.com
Paul Mindrup
 
Posts: 16
Joined: March, 2014
Reputation: 0

Re: modes

Postby Nick Didkovsky » Thu Sep 12, 2002 9:50 am

Thanks Paul - I can certainly see the advantage of a rigorous grammar Nick


Paul Mindrup wrote:One of the "advantages" of XML is that it's not forgiving like HTML. The specification says that a parser must throw an error if a document is not well-formed.

Paul

Nick Didkovsky wrote:I realize I am going to sound like an XML newbie with this question, and rightfully so, since I am one. And so, having nothing to lose, here goes...

The modes discussion brought up something I've been wondering about for a while in MusicXML. Is it absolutely required that every tag is defined? Why isn't it ok to use an undefined tag, which a particular implementation of an xml parser simply skips if it doesn't recognize it? This behavior would be similar to web browsers that skip html tags they don't understand instead of failing on the entire page load.

For example, let's say I wrote "wedge" for an articulation to a MusicXML file. Tomorrow or a year from now, "wedge" might be supported. Meanwhile, shouldn't a MusicXML parser forgive the unrecognized tag, maybe throw a warning, but continue? Similarly for the modes discussion. If it doesn't recognize Aeolian today, what would be wrong with simply skipping it as an unrecognized tag, throwing a warning to the user, and continuing?

Best, Nick





-- Doctor Nerve Home Page, http://www.doctornerve.org Interactive Computer Music, http://www.punosmusic.com Java Music Specification Language, http://www.algomusic.com

-- Doctor Nerve Home Page, http://www.doctornerve.org Interactive Computer Music, http://www.punosmusic.com Java Music Specification Language, http://www.algomusic.com
Nick Didkovsky
 
Posts: 43
Joined: March, 2014
Reputation: 0

Who is online

Users browsing this forum: No registered users and 2 guests

cron