MakeMusic
SmartMusic Finale Garritan MusicXML

tuplets and divisions

Moderator: Michael Good

tuplets and divisions

Postby John Lynch » Wed Sep 11, 2002 7:21 pm

Hello,

I'm currently finishing up tuplet support and I'm wondering about the interaction of tuplets and the overall part <divisions> element.

Since tuplets essentially change the time base, you can end up with non-integer duration values for notes if you try to use one default value for the <divisions> element.

For example, if you use a value like 24 for your divisions, you're ok with triplet eighth notes, which are 3 notes in the space of 2, or 2/3 the length of normal eight notes, since 24 is divisible by 3. But if you have 5 eighths in the space of 2 or something, each note is 2/5 of normal length, so you'll end up with a non-integer duration value unless you change the divisions setting.

As far as I can see, there are three elements that must be specified properly for a tuplet: the duration, the time-modification element, and the tuplet notation element. Assuming the latter two are correct (they are independent of division issues), I can think of 4 approaches to figuring out the durations value and its corresponding divisions setting

1) Just use integer division and don't worry whether the durations values add up all the way to the full notes, since (I think) they're just for playback anyway and the nearest integer should be close enough if you use a reasonably high default divisions setting.

2) Output decimal numbers for durations. I think this defeats the whole purpose of having the divisions element, and is against spec, so it's probably out.

3) Output a new <attributes> element with a new <divisions> element before and after each tuplet. If you've only got one tuplet to worry about, it's easy to switch to a divisions value that will allow you to specify full durations as an integer. However, I don't know if changing the divisions value mid-measure is asking for trouble.

4) Make two passes through all the notes, keeping track of all the denominators for the notes (the 5s and 3s from above), then do a Least Common Multiple calculation to find the one divisions value that works for everything. This has the added benefit of finding the smallest divisions value that will work for a tune, whether tuplets exist or not. However it requires maintaining a list of all notes, since you don't really know each one's durations value until you know the final divisions setting.

Currently, I'm doing number 1. Number 3 would be the next easiest to implement, but I'm worried about changing the divisions attribute all over the place. Number 4 is obviously the
"right" answer, but I'm currently doing the translation in one pass and would prefer to avoid adding another if I could.

Is there another approach that I'm missing? Which of these approaches are workable?

Thanks, John
John Lynch
 
Posts: 9
Joined: March, 2014
Reputation: 0

RE: tuplets and divisions

Postby Michael Good » Thu Sep 12, 2002 12:44 am

Hi John,

#4 (computing the divisions for the whole piece using a least common denominator) is basically what we do when we export MusicXML from Finale in our Dolet plug-in. But for what you're doing, #3 (switching divisions mid-file for more complex tuplets) or a variation on it should be OK.

The Dolet plug-in does not correctly import music where you switch divisions mid-measure, and then do a <backup> over the division switch. But if you're doing single-line music in ABC, that wouldn't be a problem. If you change the divisions on measure boundaries, that would be even less of a problem for software reading the files.

If you start with a value like 24 for the divisions, and switch only when you get 128ths, triplet 64ths, or odd tuplets, you probably won't need to switch divisions that often anyway.

#1 (don't worry about the divisions adding up) is sub-optimal since it will cause problems with sequencer-type applications, or other applications that rely on <duration> more than <type>. #2 (using decimal values instead of integers) is the last choice for just the reasons you mention.

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

Re: tuplets and divisions

Postby Nick Didkovsky » Thu Sep 12, 2002 7:22 am

Hi Michael,


Michael Good wrote:If you start with a value like 24 for the divisions, and switch only when you get 128ths, triplet 64ths,

I've just been using divisions = 960 throughout every piece I export to MusicXML. Is there any reason *not* to do this?

Best, Nick

Doctor Nerve Home Page, http://www.doctornerve.org Interactive Computer Music, http://www.punosmusic.com Java Music Specification Language, http://www.algomusic.com
Nick Didkovsky
 
Posts: 43
Joined: March, 2014
Reputation: 0

RE: tuplets and divisions

Postby Michael Good » Thu Sep 12, 2002 10:35 am

Hi Nick,

Nick Didkovsky wrote:I've just been using divisions = 960 throughout every piece I export to MusicXML. Is there any reason *not* to do this?

A value of 960 won't handle septuplets and other more complex tuplets with an exact number of divisions. But one could argue that with a sufficiently high <divisions> value, John's choice #1 of not have everything exactly line up is not so bad. And if you're representing a musical performance, the <divisions> will diverge from the <type>
anyway.

Dolet tries to export the minimum number of divisions for two reasons:

1) Aesthetics - it's easier for a person to read the file with smaller division values.

2) Some software (e.g. MuseData) has problems with large duration values. MuseData expects you to change the <divisions> value in this case, but given the structure of the Dolet plug-in, it's easier to compute just one <divisions> value per part.

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

Re: tuplets and divisions

Postby Graham Jones » Sat Sep 28, 2002 6:34 am

I know I am joining this conversation a bit late...

In message , Michael Good writes
Michael Good wrote:Hi John,

#4 (computing the divisions for the whole piece using a least common denominator) is basically what we do when we export MusicXML from Finale in our Dolet plug-in.

SharpEye's MusicXML export uses this method too. For some scores, this could make the divisions a very big number. Is there a limit to the size of this number in MusicXML?

Graham

-- Graham Jones, author of SharpEye Music Reader
http://www.visiv.co.uk 21e Balnakeil, Durness, Lairg, Sutherland IV27 4PT, Scotland, UK
Graham Jones
 
Posts: 37
Joined: March, 2014
Reputation: 0

RE: tuplets and divisions

Postby Michael Good » Sun Sep 29, 2002 2:08 pm

Hi Graham,

For MIDI compatibility, the equivalent of MusicXML's divisions is stored as a 14-bit number. So for the most general use, it would probably be good not to use exceed 16383 for the divisions value.

You can clamp it to a lower value if you like. When Dolet for Finale exports to MusicXML, it does not exceed 1024 for the divisions value, since that is the "native" divisions unit within Finale.

Best regards, Michael



I know I am joining this conversation a bit late...

In message , Michael Good writes
Michael Good wrote:Hi John,

#4 (computing the divisions for the whole piece using a least common denominator) is basically what we do when we export MusicXML from Finale in our Dolet plug-in.

SharpEye's MusicXML export uses this method too. For some scores, this could make the divisions a very big number. Is there a limit to the size of this number in MusicXML?

Graham

-- Graham Jones, author of SharpEye Music Reader
http://www.visiv.co.uk 21e Balnakeil, Durness, Lairg, Sutherland IV27 4PT, Scotland, UK
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: tuplets and divisions

Postby Nick Didkovsky » Sun Jan 26, 2003 12:32 pm

Thanks Michael, Brian, and Graham, for your help. I got the tuplet stuff sorted out this morning and have successfully torture-tested it.
Very gratifying to see these impossible tuplets transcribed in Finale! Best, Nick
Nick Didkovsky
 
Posts: 43
Joined: March, 2014
Reputation: 0

Who is online

Users browsing this forum: No registered users and 2 guests

cron