12/8 Quadruplets
Hi all,
I'm writing out a band part from the score and was wondering if you could help me with a problem I've run into.
The time signature is 12/8 and is beat as four groups of three quavers (eighth notes). I have set up the tuplets with a ratio of 4 to 6 -- which should be 4 semiquavers played in the time of 6.
Why does MuseScore require the quaver circled in red to have a dot? Within the tuplet it is double the length of the semiquavers so shouldn't be required to have a dot.
Thanks for your help!
| Attachment | Size |
|---|---|
| musescore..PNG | 54.13 KB |
Comments
Hi, I don't use ratio in this case, I simply makes my measure full with 4 dotted quater rests (cause 12/8) .On a dotted quater rest I click CTRL+4, it appears 4 eight rests, I write my notes , but not with double eight notes, with simply eight notes. In 12/8 we have 3 eight notes in a time, so in a tuplet of 4 notes it will be 4 eight notes, not sixteen notes. And in your case, you must get, for the special tuplet 1 eight-1 four (a black in french)- 1 eight
See my picture
![junk_1.png]( "junk_1.png")
In reply to Hi, I don't use ratio in… by Raymond Wicquart
I would like to match the original as much as I can and it's written with sixteenths there.
In reply to I would like to match the… by artturnip
You really need to attach the actual musescore score rather than a picture, but I suspect it's fixed for version 3.1.
In reply to You really need to attach… by mike320
It is indeed fixed in 3,1, thanks for the help!
In reply to It is indeed fixed in 3,1,… by artturnip
This is a very much under the hood fix that will likely not get its proper fanfair, but someone totally rewrote the way tuplets are handled in general. This has greatly reduced the number of corruptions as a result. Broad testing after the release of 3.1 will give us a better idea of anything it broke (besides a couple of things that have already been fixed).
In reply to This is a very much under… by mike320
I'll expand on this a little, because it's interesting (to some of us, anyhow) and maybe it will be useful to refer back to this in the future as the subject comes up.
The changes in question were by Werner, the original developer of MuseScore, and while the main benefit has to do with tuplets, the change really has to do with the fundamental way we measure time.
Previously, we used a MIDI-based scheme in which the basic unit of time was the "tick", and quarter note was defined as being 480 ticks. Why 480? Because that's how most MIDI-based software does it. It's evenly divisible by 2, 4, 8, 16, and 32, so you can represent 8th, 16th, 32nd, 64th, and 128th notes, but also by 3 and 5, so you can get triplets and quintuplets, as well as multiples of those (sextuplets, ten-tuplets, etc). But you will note that 480 is not divisible by 7, or 9, or 64, or lots of other things that might be musically useful. So many tuplets ended up needing to have their note values rounded off. Not a problem if you are just using these values for playback, as is the case for most MIDI software - no one can tell the difference between a septuplet played as 68+68+68+69+69+69+69 versus one played as 68.58+68.57+68.57+68.57+68.57+68.57+68.57. But, this rounding off gives fits to notation software, as you end up with a gap between beat one and two if beat one is a sextuplet represented using ticks that only add up to 476 ticks instead 480, or overlap if the ticks add up to 483, etc.
So, Werner changed the way we measure time from based on ticks to being based on fractions. A quarter note is now represented as 1/4, not 480. And the duration of each note of a septuplet is exactly 1/4 * 1/7 - not 68, not 69, not 68.57142857142857... A septuplet is now guaranteed to add up to exactly the same length as a quarter note (or whatever it is supposed to add up to).
For the amount of code that had to change in order for this to happen, it is incredible to me - and a testament to the time and care Werner took in making this change - that almost nothing broke when his changes got merged a few months ago. I think maybe three or four little things broke and were found by users testing nightly builds, then maybe a couple of other bugs were reported by users of the first beta, and all of these problems were fixed more or less instantly (and they tend to be very easy fixes).
As @mike320 notes, I'm sure it won't get its proper fanfare in general, but I think it's one of the great "behind the scenes" success stories of MuseScore.