tuplet formatting oddity
I was transcribing some music with very intricate rhythms in two of the voices, and I noticed that the vertical alignment of the notes wasn't what I was expecting. I boiled it down to the following example:
Both of these voices have exactly the same rhythm, despite the difference in notation, and I'd expect the notes to line up. They play back (and export to mp3, MIDI, etc.) correctly.
Comments
Which version are you using? Can you attach the actual score please?
In reply to Which version are you using?… by mike320
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4785, revision: c1a5e4c
In reply to OS: Windows 10 (10.0), Arch… by ghicks
If you click each note, you will see the rounding error for the beat of each note in the 9-let compared to the correct beat in the triplet.
I haven't downloaded the master since this was supposed to be fixed, perhaps one of the programmers could use this as a test to see if the fractions fix the rounding errors on the ticks in this file as it should.
The collision of brackets seems to be described in #279049: Tuplet of tuplets doesn't auto align. I've created a link to that issue and will next insert a comment so someone will look at the bug and decide if it's the same issue or a new one.
In reply to If you click each note, you… by mike320
Lines up correctly in master. This is AFAIK the first such case "in the wild" where I have seen the real life benefit of the change in representation of timing from "ticks" to "fractions" that will come with 3.1
Bracket autoplace issue does indeed seem to be the same, we're just not that sophisticated yet.
In reply to Lines up correctly in master… by Marc Sabatella
@ghicks deserves a gold star. This is the best example of the rounding issue that I've known about almost as long as I've been using the program. Hearing it is fixed in master (aka the future 3.1) is great news. I think this will make it possible to fix a multitude of bugs related to tuplets and hopefully local time signatures.
Also, it would be nice if the collision-avoidance code could figure out a way not to have the two tuplet brackets in the upper voice interfere with each other. I know this can be fixed by using the Inspector, but it really shouldn't be necessary.
In reply to Also, it would be nice if… by ghicks
The collision of the brackets was the reason I asked which version. It definitely shouldn't happen in version 3. I'll look at your score and comment on both shortly.