MakeMusic
SmartMusic Finale Garritan MusicXML

<voice> element within the <forward> element

Moderator: Michael Good

<voice> element within the <forward> element

Postby Frank Weinstock » Thu Feb 07, 2013 3:33 pm

Dear collective wisdom,

I'm clearly missing something here: Could somebody please explain the need for a <voice> element within the <forward> element? I understand very well the concept of voice as it applies to the <note> element, but can't find a way to apply it to <forward>.

Within <forward>, does it mean "we are jumping ahead x durations so that we can input note(s) for voice y"? If so, isn't that information explicitly set by the subsequent <note>'s <voice> element? If that is indeed the case, it seems like I might as well ignore the contents of <forward>'s <voice> element.

Thanks in advance for any clarification!

All best, Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati
Frank Weinstock
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: <voice> element within the <forward> element

Postby Joe Berkovitz » Fri Feb 08, 2013 8:53 am

For exactly the reasons you gave, I have found that <voice> within <forward> serves no useful purpose. In any case it is optional and is omitted by most exporting programs, and one must make one's way with whatever fragments of a voice are found to occur in a measure, in whatever order. That's the reality on the ground.

I have asked before on this list for consideration of a tighter approach to voices that would place each voice's content in a single element, in monotonically increasing order (in which case <forward> would occur
*within* a containing element describing a single voice). However Michael wants to keep the specification loose and able to accommodate MIDI-like data. The net result is that importing programs must take on any sort of polyphony they find, however fragmented or jumbled its description might be.

A small but relevant piece of MusicXML trivia: the rarely-used Open Score Format specification (embraced by few companies other than Yamaha) prescribed a subset of MusicXML which mandated that <forward> elements
*must* contain a <voice> child, but offered no justification for this requirement. I'm sure Michael remembers why.

…Joe


Frank Weinstock wrote:Dear collective wisdom,

I'm clearly missing something here: Could somebody please explain the need for a <voice> element within the <forward> element? I understand very well the concept of voice as it applies to the <note> element, but can't find a way to apply it to <forward>.

Within <forward>, does it mean "we are jumping ahead x durations so that we can input note(s) for voice y"? If so, isn't that information explicitly set by the subsequent <note>'s <voice> element? If that is indeed the case, it seems like I might as well ignore the contents of <forward>'s <voice> element.

Thanks in advance for any clarification!

All best, Frank

****************

Frank Weinstock Professor Emeritus of Piano College-Conservatory of Music University of Cincinnati
Joe Berkovitz
 
Posts: 79
Joined: March, 2014
Reputation: 0

Re: <voice> element within the <forward> element

Postby Michael Good » Wed Feb 13, 2013 10:46 pm

Hi Frank and Joe,

If all <note> and <forward> elements have a <voice> element, then you should be able to import polyphony with a less complex and more accurate algorithm than if they are not. It means that each <forward> element can be treated like an invisible rest.

My recollection is that a lot of the restrictions in the OSF PVG profile were to enhanced automated QA when dealing with large volumes of scores.

Best regards,

Michael Good MakeMusic, Inc.


Joe Berkovitz wrote:For exactly the reasons you gave, I have found that <voice> within <forward> serves no useful purpose. In any case it is optional and is omitted by most exporting programs, and one must make one's way with whatever fragments of a voice are found to occur in a measure, in whatever order. That's the reality on the ground.

I have asked before on this list for consideration of a tighter approach to voices that would place each voice's content in a single element, in monotonically increasing order (in which case <forward> would occur
*within* a containing element describing a single voice). However Michael wants to keep the specification loose and able to accommodate MIDI-like data. The net result is that importing programs must take on any sort of polyphony they find, however fragmented or jumbled its description might be.

A small but relevant piece of MusicXML trivia: the rarely-used Open Score Format specification (embraced by few companies other than Yamaha) prescribed a subset of MusicXML which mandated that <forward> elements
*must* contain a <voice> child, but offered no justification for this requirement. I'm sure Michael remembers why.

Å Joe


Frank Weinstock wrote:Dear collective wisdom,

I'm clearly missing something here: Could somebody please explain the need for a <voice> element within the <forward> element? I understand very well the concept of voice as it applies to the <note> element, but can't find a way to apply it to <forward>.

Within <forward>, does it mean "we are jumping ahead x durations so that we can input note(s) for voice y"? If so, isn't that information explicitly set by the subsequent <note>'s <voice> element? If that is indeed the case, it seems like I might as well ignore the contents of <forward>'s <voice> element.

Thanks in advance for any clarification!

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

Who is online

Users browsing this forum: No registered users and 2 guests