MakeMusic
SmartMusic Finale Garritan MusicXML

Invisible tuplets

Moderator: Michael Good

Invisible tuplets

Postby Philip Taylor » Tue Oct 29, 2002 5:54 am

In my MusicXML importer, I've now got to the stage where I can correctly import at least the basic content of all of the examples on the Recordare site. I've come across a problem with tuplets though which seems to be insuperable.

In the Schubert example (SchbAvMaSample.xml) the right-hand piano part is written with six hextuplets per measure. In line with normal musical practice, the tuplets are only notated on the first measure. This poses no problem for a human musician, since it's obvious that the established rhythm continues through the piece. My program produces abc where the measures don't add up because the tuplets are missing.

Of course I can look at the <duration> elements, and I can see that each of the 24 notes and rests in the measure has a duration which is 2/3 of that implied by it's note type. That implies that there are tuplets present, but not where they are. 24 notes in the time of 16 could be represented as eight triplets (wrong), four hextuplets
(right) or as any of several combinations of 3- 6- and 9- tuplets
(all wrong).

I can't see any easy general solution to this.

Would it not be easier in MusicXML to notate these tuplets, but mark them as invisible using the printout entity? That doesn't currently include "print-tuplet" as an option, but it's something to consider for future versions.

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

RE: Invisible tuplets

Postby Michael Good » Tue Oct 29, 2002 11:38 am

Hi Phil,

Thanks for your suggestion. The <time-modification> element is intended to help in this situation where the tuplets are not notated. In the Schubert Ave Maria example, for instance, they indicate that these are sextuplets vs. the alternatives. It seems this should be enough to make sure that the measures add up correctly. Is there something else that you need that this element is not providing?

We are indeed planning to expand the definition of the tuplet element in MusicXML 0.7 to handle many cases that MusicXML does not support so well right now, such as nested tuplets. You will then be able to explicitly indicate an invisible tuplet. But even then, it will be common for invisible tuplets to be encoded by simply omitting the <tuplet> element and relying on the <time-modification> element.

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

RE: Invisible tuplets

Postby Philip Taylor » Tue Oct 29, 2002 12:58 pm

Michael Good wrote:Thanks for your suggestion. The <time-modification> element is intended to help in this situation where the tuplets are not notated. In the Schubert Ave Maria example, for instance, they indicate that these are sextuplets vs. the alternatives. It seems this should be enough to make sure that the measures add up correctly. Is there something else that you need that this element is not providing?

I'm having a little difficulty figuring out where the tuplets start and end, since every note is marked as:
<time-modification>
<actual-notes>6</actual-notes>
<normal-notes>4</normal-notes>
</time-modification>

Can I take it that in the absence of a <normal-type> element, that
"actual-notes" actually means the real number of notes in the tuplet?

In abc, tuplets can be written with three numbers (p:q:r, where p is <actual-notes>, q is <normal-notes>, and r is the actual number of notes to include in the tuplet. This is good for rhythmically- complex music, as you can (for example) write a triplet over four equal notes, and have them all played at 2/3 of their normal time. I don't quite see how to do that in MusicXML.

Michael Good wrote:We are indeed planning to expand the definition of the tuplet element in MusicXML 0.7 to handle many cases that MusicXML does not support so well right now, such as nested tuplets. You will then be able to explicitly indicate an invisible tuplet. But even then, it will be common for invisible tuplets to be encoded by simply omitting the <tuplet> element and relying on the <time-modification> element.

OK.

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

RE: Invisible tuplets

Postby Michael Good » Sat Nov 02, 2002 8:31 pm

Hi Phil,

In the normal case for non-nested tuplets, the first time you see a <time-modification> element gives you information about how far forward in musical time the tuplet lasts. So you can use that to determine when the tuplet ends. You can't assume that the <actual-notes> value is the real number of notes in the tuplet for cases like an eighth-note tuplet, where the first note is an eighth but the second is a quarter. The second note should have a <normal-type> element, but not the first note.

It will be better to have this explicitly encoded, and 0.7 should help in this respect. But I don't think the usual cases are too hard in 0.6c
- it's handling the more complex cases that gets either tricky or impossible.

I don't understand the example of "a triplet over four equal notes, and have them all played at 2/3 of their normal time." If this is tuplet in 4 against 3, they would play back in 3/4 of their normal time. Maybe you could send me a GIF via private e-mail (no attachments on this list) showing what you are trying to do?

Thanks,

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

RE: Invisible tuplets

Postby Philip Taylor » Sun Nov 03, 2002 5:31 am

Michael Good wrote:In the normal case for non-nested tuplets, the first time you see a <time-modification> element gives you information about how far forward in musical time the tuplet lasts. So you can use that to determine when the tuplet ends. You can't assume that the <actual-notes> value is the real number of notes in the tuplet for cases like an eighth-note tuplet, where the first note is an eighth but the second is a quarter. The second note should have a <normal-type> element, but not the first note.

OK, so in other words, I have to accumulate notes into the tuplet group until their total (notated) musical times add up to the value given in <actual-notes>. A little awkward, since it means that I then have to go back in the output to insert the correct values into the tuplet symbol (which in abc precedes the tuplet), but not insuperable.

Michael Good wrote:It will be better to have this explicitly encoded, and 0.7 should help in this respect. But I don't think the usual cases are too hard in 0.6c
- it's handling the more complex cases that gets either tricky or impossible.

I don't understand the example of "a triplet over four equal notes, and have them all played at 2/3 of their normal time." If this is tuplet in 4 against 3, they would play back in 3/4 of their normal time. Maybe you could send me a GIF via private e-mail (no attachments on this list) showing what you are trying to do?

It wasn't a real case, just something off the top of my head. I don't think you're likely to encounter anything as complex outside of African drum music. I have, however, seen cases of duplets written over more than two notes. This is simpler though, as a duplet (play two notes in the time of three) effectively means that all the notes are to be played as if dotted.

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

Who is online

Users browsing this forum: No registered users and 2 guests

cron