w3c / musicxml

MusicXML specification
508 stars 57 forks source link

Should a grace note affect the duration of the next note in a measure? #432

Open GeorgeTailor opened 2 years ago

GeorgeTailor commented 2 years ago

Hello everyone! As per spec, grace element cannot have any children, and the duration element spec does not mention anything in that regard, but note element spec says that the notes with grace should not have a duration. Given the above it is not clear how exactly the next note's duration should be calculated. Should the grace note's duration be accounted for during playback? If yes, how grace note affects the notes around it?

Very similar situation comes up when working with plop and scoop elements, such articulation should begin before the actual note is played at a given time, but again, does it affect the duration of other notes in the measure and if yes, how?

I think the spec should bring some more clarifications into this topic as different software can solve these problems differently.

mdgood commented 2 years ago

I think the <grace> element situation is clear, as the make-time, steal-time-previous, and steal-time-following attributes are used to guide playback. Please let us know if there is something unclear in the specification of those attributes. The appoggiatura example makes use of the steal-time-following attribute.

We do not have any playback specified for the <plop>, <scoop>, <doit>, and <falloff> elements. Perhaps we could add something like the attributes used for the <bend> element. But <plop> and <scoop> would need the ability to specify playback before the main note, like the <grace> element allows.

GeorgeTailor commented 2 years ago

thinking out loud

thanks for the eхplanation about the grace element, I missed the attributes section of the element. However, it doesn't really solve the problem, since all of those attributes are optional, and the grace note does not have any duration. Maybe defining some default value for steal-time-following/steal-time-previous is an option? Also slash attribute doesn't have a default value as well. I think adding a default value for steal-time-following when slash=yes (note before beat) and default for steal-time-previous when slash=no (note on beat) makes sense. That way it kind of maintains backward compatibility and doesn't completely change the spec.

Regarding the plop, scoop, doit and falloff elements, do you mean something like this:

<note>
...
  <notations>
   <articulations>
    <falloff start="75"/> <!-- The percentage of the duration of a note, telling when to start falloff. Default is 75. -->
   </articulations>
  </notations>
...
</note>
<note>
...
  <notations>
   <articulations>
    <doit start="75"/> <!-- The percentage of the duration of a note, telling when to start doit. Default is 75. -->
   </articulations>
  </notations>
...
</note>

the above are not problematic, we are in a conteхt of a note and we know eхactly for how long the note plays. However, the eхamples for scoop and plop wouldn't work:

<note>
...
  <notations>
   <articulations>
    <scoop steal="25"/> <!-- Indicates the percentage of time to steal from the previous note for the scoop playback. Default is 25. -->
   </articulations>
  </notations>
...
</note>
<note>
...
  <notations>
   <articulations>
    <plop steal="25"/> <!-- Indicates the percentage of time to steal from the previous note for the plop playback. Default is 25. -->
   </articulations>
  </notations>
...
</note>

The problem here is that note before the note with a scoop can vary in duration, 25% from a quarter note and 25% from a 16th note can introduce major audible differences in the length of the scoop and plop.