MakeMusic
SmartMusic Finale Garritan MusicXML

Can the same part identifier occur more than once in partwise MusicXML?

Moderator: Michael Good

Can the same part identifier occur more than once in partwise MusicXML?

Postby Philip Taylor » Fri Oct 04, 2002 5:48 am

Can the same part identifier occur more than once in partwise MusicXML?

The reason why I ask is that I'm planning an abc <-> MusicXML converter, and although it's quite legal for abc to be laid out in either partwise or timewise order, neither is the preferred option for multivoice abc. Since abc is intended to be human-readable, it tends to be laid out with one line of text corresponding to one line of music. If this were directly converted to MusicXML it would look like this:

<score-partwise>
<part-list>
<score-part id="P1">
<part-name>First Part</part-name>
</score-part>
<score-part id="P2">
<part-name>Second Part</part-name>
</score-part>
</part-list>
<part id="P1">
<-- First four measures of part 1 here -->
</part>
<part id="P2">
<-- First four measures of part 2 here -->
</part>
<part id="P1">
<-- Second four measures of part 1 here -->
</part>
<part id="P2">
<-- Second four measures of part 2 here -->
</part>
<-- and so on -->
</score-partwise>

Is that legal?

Of course I can rearrange the abc before parsing it, or write my parser so that it parses one complete part at a time to output the MusicXML in the conventional order, but it would be simplest to do the above if it's supported.

Phil Taylor www.barfly.dial.pipex.com
Philip Taylor
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: Can the same part identifier occur more than once in partwise MusicXML?

Postby John Lynch » Fri Oct 04, 2002 7:11 am

Hi Phil,

Just so you know, I'm a few days away from releasing the first version of a freeware abc2xml translator, as well as an XSL script that does xml2abc as well. abc2xml is a Win32 executable at this point, but the code should be very portable. The XSL xml2abc script should of course work on any platform and is easy to invoke from the command line or in other ways with an XSL processor.

That being said, the first versions will not support multiple voices, in part because, as you well know, it's not completely standardized under ABC. I'm planning on working from your multivoice.txt writeup to help resolve the differences when I add it, so thanks for that.

Adding multiple voice support to xml2abc should be pretty easy actually, but I had planned outputting each entire voice separately, though I suppose as you point out the other way is probably preferable and more human-friendly. I'll have to rethink that.

I don't think what you're suggesting will work, although Michael is of course the voice of authority. I was planning on having the parser re-arrange the lines since I do parse entire tunes before writing out the MusicXML. I suspect that's the only way to do it really. Time-wise MusicXml is sort of closer to what you're describing, although not quite there either, unless you wanted to buffer multiple ABC lines in memory and output one measure at a time for each voice.

Anyway, you might hold off a few days and try out what I'm releasing. I don't have access to a Mac for porting, but I'd be happy to send you the source code if you wanted to give it a shot.

Regards, John



Philip Taylor wrote:Can the same part identifier occur more than once in partwise MusicXML?

The reason why I ask is that I'm planning an abc <-> MusicXML converter, and although it's quite legal for abc to be laid out in either partwise or timewise order, neither is the preferred option for multivoice abc. Since abc is intended to be human-readable, it tends to be laid out with one line of text corresponding to one line of music. If this were directly converted to MusicXML it would look like this:

<score-partwise>
<part-list>
<score-part id="P1">
<part-name>First Part</part-name>
</score-part>
<score-part id="P2">
<part-name>Second Part</part-name>
</score-part>
</part-list>
<part id="P1">
<-- First four measures of part 1 here -->
</part>
<part id="P2">
<-- First four measures of part 2 here -->
</part>
<part id="P1">
<-- Second four measures of part 1 here -->
</part>
<part id="P2">
<-- Second four measures of part 2 here -->
</part>
<-- and so on -->
</score-partwise>

Is that legal?

Of course I can rearrange the abc before parsing it, or write my parser so that it parses one complete part at a time to output the MusicXML in the conventional order, but it would be simplest to do the above if it's supported.

Phil Taylor www.barfly.dial.pipex.com
John Lynch
 
Posts: 9
Joined: March, 2014
Reputation: 0

RE: Can the same part identifier occur more than once in partwise MusicXML?

Postby Michael Good » Fri Oct 04, 2002 11:35 am

Hi Phil,

You can arrange MusicXML so that the parts are output one at a time, or the measures are output one at a time. But you cannot do this in-between representation that you suggest here. It is probably syntactically OK, but it goes against the semantics of the MusicXML spec.

The id attribute in the <score-part> is an ID, so that is what is unique. The id attribute in the <part> is an IDREF pointing to the score-part. But that is for the use of the timewise representation, where each part is repeated within higher-level measures. In a partwise representation, the part IDs should be unique. The line breaks in abc should be represented with a <print new-system="yes"/> element at the start of the first measure on the new line.

I hope that clarifies things. Let me know if you have further questions. We are really looking forward to having abc <-> MusicXML converters available on both the PC and the Mac!

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: Can the same part identifier occur more than once in partwise MusicXML?

Postby Philip Taylor » Fri Oct 04, 2002 2:14 pm

Hi John,

John Lynch wrote:Just so you know, I'm a few days away from releasing the first version of a freeware abc2xml translator, as well as an XSL script that does xml2abc as well. abc2xml is a Win32 executable at this point, but the code should be very portable. The XSL xml2abc script should of course work on any platform and is easy to invoke from the command line or in other ways with an XSL processor.

Yes, I read your posts on the list archive. You have already asked most of the questions which originally occurred to me on reading through the MusicXML tutorial, so that was useful.

John Lynch wrote:That being said, the first versions will not support multiple voices, in part because, as you well know, it's not completely standardized under ABC. I'm planning on working from your multivoice.txt writeup to help resolve the differences when I add it, so thanks for that.

I need to update it as it's getting a bit dated. Fortunately the various apps are coming closer together. BarFly now supports abcm2ps's %%staves directive if the data is not where it expects it (in V: fields in the header) and abcm2ps supports 'up' and
'down' for stem directions
(again in V: fields in the header). You could probably get away with supporting those two programs, since BarFly only runs on Macs, and abcm2ps runs everywhere else but the Mac.

John Lynch wrote:Adding multiple voice support to xml2abc should be pretty easy actually, but I had planned outputting each entire voice separately, though I suppose as you point out the other way is probably preferable and more human-friendly. I'll have to rethink that.

I don't think what you're suggesting will work, although Michael is of course the voice of authority. I was planning on having the parser re-arrange the lines since I do parse entire tunes before writing out the MusicXML. I suspect that's the only way to do it really. Time-wise MusicXml is sort of closer to what you're describing, although not quite there either, unless you wanted to buffer multiple ABC lines in memory and output one measure at a time for each voice.

I think you're probably right, but we'll see what Michael says.

John Lynch wrote:Anyway, you might hold off a few days and try out what I'm releasing. I don't have access to a Mac for porting, but I'd be happy to send you the source code if you wanted to give it a shot.

I'd love to take a look at your code, but I don't think I'll be able to use it, since my translation routines have to be 100% compatible with what BarFly does now. Parsing abc is much harder (I think) than parsing MusicXML, so I want to use my existing abc parsers and divert the output to creating XML. BarFly has two separate parsers for playing and drawing the staff notation; they work quite differently, as the play parser uses stress programming to make the music swing, and expands macros to play ornaments while the display parser knows about beams and other such elements which are irrelevant to playing. It has no persistent internal data structures to represent the music, and the output of the parsers is normally sent directly to Quicktime (for playing) or drawn on the screen. I'll have to use both of them to create the MusicXML.

Cheers

Phil Taylor www.barfly.dial.pipex.com
Philip Taylor
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: Can the same part identifier occur more than once in partwise MusicXML?

Postby John Lynch » Fri Oct 04, 2002 4:45 pm

Hi Phil,

Thanks for the update on the multi-voice stuff. I'll have to take a close look at abcm2ps, since it seems to support the most typesetting features and is obviously in active development.

Philip Taylor wrote:I'd love to take a look at your code, but I don't think I'll be able to use it, since my translation routines have to be 100% compatible with what BarFly does now.

Makes sense. I've definitely learned there are "dialects" of ABC, unfortunately, and at this point my parser is on the strict end of the spectrum anyway. Let me know if you have any questions, though. I do think that the xml2abc XSL script is a good start, is easily extensible to multi-voice, and is obviously portable. As I said, muli-part should be pretty easy, but multi-voice sounds tricky, with the various backup and forward elements. Math and variables are not XSL's strong points. Anyway, have a look when I release it in a few days.

Philip Taylor wrote:Parsing abc is much harder (I think) than parsing MusicXML, so I want to use my existing abc parsers and divert the output to creating XML.

Parsing ABC is a huge pain in the rear compared to XML, for sure. One of the great things about an XML-based format is that there are tons of parsers already out there that you can use for just about any source language. As well as tools like XSL, which make things like generating reports and doing transformations (adding notes, notations, etc.) on MusicXML data really easy. I'm going to include a couple of simple examples of this with the abc2xml distribution.

Philip Taylor wrote:BarFly has two separate parsers for playing and drawing the staff notation; they work quite differently, as the play parser uses stress programming to make the music swing, and expands macros to play ornaments while the display parser knows about beams and other such elements which are irrelevant to playing. It has no persistent internal data structures to represent the music, and the output of the parsers is normally sent directly to Quicktime (for playing) or drawn on the screen. I'll have to use both of them to create the MusicXML.

Hmm, so are you going to be outputting things like realizations of ornaments and such into the MusicXML file? I'd sort of thought that any conversion of ABC to MusicXML should be more strictly notation-based, then converting that MusicXML file into a "fully-realized", compelling MIDI file would be the work of a more sophisticated (and more generally applicable), MusicXML to MIDI translator, that would realize the ornaments and infer articulations and dynamics and whatnot from the notation information.

Maybe not, I'm still a little unclear on just how much playback info should be encoded in the MusicXML file, vs. inferred from the notation. In the MusicXML tutorial it seems to indicate the other way around (i.e. the emphasis is on the MIDI-compatible data), although that seems odd to me. It seems to me that MusicXML is more useful as a notation-oriented standard that can also contain playback "hints", rather than playback information that can also contain notation information. I suppose the ideal MusicXML file would contain full notation information, as well as all the sound cues for exactly how it should be played back, and an XML->MIDI translator would have a really easy job with it, having to infer very little. Anyway...

Michael, any update on the MusicXML->MIDI translator so we can see how it should be done :)?

Best of luck, John
John Lynch
 
Posts: 9
Joined: March, 2014
Reputation: 0

RE: Can the same part identifier occur more than once in partwise MusicXML?

Postby Philip Taylor » Fri Oct 04, 2002 6:32 pm

Michael Good wrote:You can arrange MusicXML so that the parts are output one at a time, or the measures are output one at a time. But you cannot do this in-between representation that you suggest here. It is probably syntactically OK, but it goes against the semantics of the MusicXML spec.

OK. I thought that would probably be the case, but it was worth a try:-) I'll just have to do it the hard way...

Phil Taylor www.barfly.dial.pipex.com
Philip Taylor
 
Posts: 24
Joined: March, 2014
Reputation: 0

Who is online

Users browsing this forum: No registered users and 2 guests

cron