Selecting notes in triplet quavers embedded in triplet crotchet

• Jul 2, 2016 - 14:53
Reported version
2.1
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
Tags
3.0
selection
easy

In the attached example it is not possible to select the first three notes using click on first note and shift-click on last, although it is possible to select them incrementally using click and then cmd-click (MacOS 10.11.5). The selection wrongly extends to the first four notes. The notes in question are a triplet embedded in another triplet. Selection in a simple triplet (as in the second half of the bar) is fine.

GIT commit: 3c7a69d

Attachment Size
TripletsInTriplets.mscz 4.18 KB

Comments

• Jul 2, 2016 - 19:34

For Windows OS (Win7 in my case) it appears to be possible to select any single or group of the notes in the inner triplet of the compound element. Individual 'list' selection is accomplished by CTL+Click for each note wanted; group selection is accomplished by holding shift while using the an arrow key.

You are correct in noting that using SHIFT+ --> extends the selection box to the first beat of the second group. To select only the notes you want, click on the LAST note, hold down Shift, and use the <-- (back/leftward arrow).

compound triplet selection.png

(Sorry, but for some reason the screen capture is not showing the blue editing box which appears around those three notes.)

Does this procedure work on Mac?

Reply

• Jul 2, 2016 - 21:07

Yes, on the Mac clicking on the last note of the triplet and then shift-click on the first works fine. So it is only when working forwards with either shift-click on last note or incrementally shift -right arrow that the problem arises. Thanks for your clarification.

Reply

• Jul 3, 2016 - 02:11

All right; at least the behaviour is consistent from one OS to another.

It does seem odd, however. I've tried analyzing under what circumstances the cursor makes that unwanted jump, and I haven't managed to define them yet. I thought it had to do with whole beats, but in that selection mode, the cursor normally moves forward or back one note at a time, regardless of note duration.

I note the same unwanted jump when the passage is re-written as a set of nonuplets instead of compound triplets. The first six notes select using SHIFT+ --> with no problem,

compound triplets as nonuplets.png

...but attempting to select the three 16th rests after them results in the cursor jumping to the first note of the following triplet.

compound triplets as nonuplets selection problem.png

Reply

• Jul 3, 2016 - 02:35

It would appear so. But it's not clear whether the fix of the copy/paste problem could have caused the selection issue somehow. I can't figure out if the selection issue existed prior and independently.

Reply

• Jul 12, 2018 - 19:28

Each of the nested triplet 8ths has a duration of 1/9 of a half note. 960/9 is approximately 106.6667.
The C begins on tick 0, and is 107 ticks long, ending on tick 107.
The D begins on tick 107, and is 107 ticks long, ending on tick 214.
The E begins on tick 214, and is 107 ticks long, ending on tick 321.
The F begins on tick 320, which is before the E ends, resulting in the F being selected when the range is extended to the E.

Taking a look at ChordRest::nextSegmentAfterCR(), we see this:

if (s->tick() >= tick() + actualTicks())
return s;

It can be changed to this:

if (s->tick() >= tick() + actualTicks() - 1)
return s;

And the problem goes away. Until a tick roundoff results in a calculation being off by more than 1.

This sort of calculation happens all throughout the code. In general, Fractions are preferred over ticks, but sometimes the use of ticks is unavoidable. If we could eliminate this dependence on ticks, we could correct all sorts of problems.

Reply