MakeMusic
SmartMusic Finale Garritan MusicXML

backup

Moderator: Michael Good

backup

Postby Philip Taylor » Mon Oct 14, 2002 11:16 am

Here I am in the midst of writing my MusicXML to abc importer module. First impressions are that MusicXML is delightfully easy to parse, after being used to abc, which being written by humans has some of the attributes of a natural language.

I have the code working to the point where I can import MusicXML created from abc by John's abc2xml, and get back essentially what I started with. Since the module can create multivoice abc, I can also deal with more complex examples, and I've been able to import multi-part files created by Virtual Composer - Bach, Scarlatti and Chopin.

When I come to look at the samples on the Recordare site, however, I come across my first real problem. I had foolishly assumed that the backup feature of MusicXML was something that would only be used occasionally, to deal with the odd measure which could not be represented as a linear sequence of notes. It's not easy to translate into abc, as I would have to create a whole new voice and fill it with rests back to the start of the piece. All of the piano music in the samples is represented in a single part, with every measure consisting first of the right hand notes, backup to the start of the measure, and then the left hand notes.

So my first question is, does the Dolet plugin have to represent piano music this way? Does the user have the option to make it use as many parts as necessary to represent the music linearly, rather than use one part per instrument?

Whether the answer to that is yes or no, I'm going to have to deal with the problem of MusicXML parts containing multiple voices at some point, and to do that I'm going to have to figure out how many abc voices I will need. The obvious way to do this seems to be to run through each part of the MusicXML in advance and find the highest numbered <voice>
tag. However, looking through the Mozart "An Chloe" example, I see that the piano part has <voice>1</voice> and <voice>3</voice>, but no <voice>2</voice>. So I guess I'm going to have to deal with discontinuous voice number allocations? Am I on the right track here? Is the <voice> tag even required when using backup, or am I going to have to figure out how many times the time-point is getting backed up over each measure without using that?

Phil Taylor
Philip Taylor
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: backup

Postby Michael Good » Mon Oct 14, 2002 11:44 am

Hi Phil,

For polyphonic piano parts, it would be very difficult to represent then in a notationally correct way without using the <backup> element. Sure, you could represent the right hand and left hand in different <part>
elements. But within either the left or right hand, classical piano music typically has many voices that come and go over time. So if you want to handle piano music, you need to handle <backup> elements.

You are correct that the <voice> element is not required when using the <backup>. Our Dolet importer has a couple of routines for assigning to Finale layers, which have a maximum of 4 per part. One relies on the <voice> element always being present and accurate, so we assign each note to a layer based on its voice. The other fallback method assigns the layers by brute force.

You should be pretty safe if you assign that you will have no more than 4 parts per a single staff. Finale actually supports the equivalent of 8 MusicXML voices per staff (2 voices * 4 layers), but we only support the 4 layers on import. It is very rare that this causes a problem.

I'm not checking e-mail too often this week, but please send on any further questions and I'll answer when I can.

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: backup

Postby Philip Taylor » Mon Oct 14, 2002 4:26 pm

Hi Michael,

Michael Good wrote:For polyphonic piano parts, it would be very difficult to represent then in a notationally correct way without using the <backup> element. Sure, you could represent the right hand and left hand in different <part>
elements. But within either the left or right hand, classical piano music typically has many voices that come and go over time. So if you want to handle piano music, you need to handle <backup> elements.

I knew I'd have to handle it eventually. There have been some proposals for incorporating something similar into abc, but the problem is that it conflicts with the overriding necessity to keep abc human-readable.

Michael Good wrote:You are correct that the <voice> element is not required when using the <backup>. Our Dolet importer has a couple of routines for assigning to Finale layers, which have a maximum of 4 per part. One relies on the <voice> element always being present and accurate, so we assign each note to a layer based on its voice. The other fallback method assigns the layers by brute force.

How do you check the accuracy of the <voice> elements, without going for the brute force method first?


Michael Good wrote:You should be pretty safe if you assign that you will have no more than 4 parts per a single staff. Finale actually supports the equivalent of 8 MusicXML voices per staff (2 voices * 4 layers), but we only support the 4 layers on import. It is very rare that this causes a problem.

The number of voices is not a problem, so long as I can figure out how many I'll need in advance. It would have been nice if that information had been recorded at the beginning of the file, in the part-list.

Michael Good wrote:I'm not checking e-mail too often this week, but please send on any further questions and I'll answer when I can.

Thanks a lot

Phil Taylor
Philip Taylor
 
Posts: 24
Joined: March, 2014
Reputation: 0

RE: backup

Postby Michael Good » Mon Oct 21, 2002 11:45 am

Hi Phil,

Sorry for the delay in answering this, but now that I'm back from ISMIR I should be answering e-mail more regularly.

We basically check the accuracy of the <voice> elements on a measure by measure basis. This involves making sure that a note in one <voice>
never starts before a preceding note in the same <voice> - in other words, that there hasn't been a <backup> between notes in the same voice that hasn't been matched by a corresponding <forward> element. We also do some global checks to make sure that <voice> elements are used consistently throughout a part within a piece.

The MusicXML format makes it easier to hand-encode and check polyphonic parts, and is similar to other formats that emphasize polyphonic music entry, like Finale and MuseData. The tradeoff is that it is more difficult to process for applications focused on monophonic music (like abc) or for musical analysis.

For many of these applications, there's no knowledge at any point of the maximum number of voices in use at any one time. For Finale, for instance, you know that there can be no more than 8 voices per staff, but you'd have to check the whole part note-by-note to know how many of those voices are actually used.

For your situation, it sounds like it might be easiest to assume 4 voices per staff, especially if there is an easy way to remove unused voices later.

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: backup

Postby Philip Taylor » Tue Oct 22, 2002 3:49 am

Hi Michael,

Michael Good wrote:Sorry for the delay in answering this, but now that I'm back from ISMIR I should be answering e-mail more regularly.

We basically check the accuracy of the <voice> elements on a measure by measure basis. This involves making sure that a note in one <voice>
never starts before a preceding note in the same <voice> - in other words, that there hasn't been a <backup> between notes in the same voice that hasn't been matched by a corresponding <forward> element. We also do some global checks to make sure that <voice> elements are used consistently throughout a part within a piece.

OK, that makes sense.

Michael Good wrote:The MusicXML format makes it easier to hand-encode and check polyphonic parts, and is similar to other formats that emphasize polyphonic music entry, like Finale and MuseData. The tradeoff is that it is more difficult to process for applications focused on monophonic music (like abc) or for musical analysis.

For many of these applications, there's no knowledge at any point of the maximum number of voices in use at any one time. For Finale, for instance, you know that there can be no more than 8 voices per staff, but you'd have to check the whole part note-by-note to know how many of those voices are actually used.

For your situation, it sounds like it might be easiest to assume 4 voices per staff, especially if there is an easy way to remove unused voices later.

Right, that's the way I'm going at the moment. I started out trying to do the conversion directly from MusicXML text to abc text. This worked OK for MusicXML with only one voice per part, and I even got it to work for some of the examples with two voices per part, but for more voices, and especially when you can't rely on finding explicit <voice> numbers it was never going to work. I presume that <backup> can operate over multiple measures, partial measures, across repeat bars and metre or key changes? If so, would you find these elements repeated within each voice, or do they follow implicitly from voice 1?

To deal with all that I'm having to use an intermediate data structure which will allow me to easily get at elements I have already parsed so I can sort out which voice goes where, then finally translate that to abc. More work than I anticipated, but it can be done.

Phil Taylor
Philip Taylor
 
Posts: 24
Joined: March, 2014
Reputation: 0

RE: backup

Postby Michael Good » Tue Oct 22, 2002 10:21 am

Hi Phil,

A <backup> doesn't cross measure boundaries, nor does a <forward>. You can have key changes in the middle of a measure, like Brahms does in some music, in which case the key follows from its first occurrence within the measure. But that's a pretty unusual situation and I wouldn't worry about it.

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

RE: backup

Postby Philip Taylor » Tue Oct 22, 2002 3:23 pm

Michael Good wrote:A <backup> doesn't cross measure boundaries, nor does a <forward>. You can have key changes in the middle of a measure, like Brahms does in some music, in which case the key follows from its first occurrence within the measure. But that's a pretty unusual situation and I wouldn't worry about it.

That makes life a lot easier!

Cheers

Phil
Philip Taylor
 
Posts: 24
Joined: March, 2014
Reputation: 0

Who is online

Users browsing this forum: No registered users and 2 guests

cron