Copying from within a tuplet bracket to the same or another or to a normal rest produces strange results

Here is an even worse one:

Open bug3 (enclosed)

Select one 1/8 triplet. Shift click to select both notes. Cut. Then paste onto another 1/8 triplet rest. Mayhem!!

Windows XP, MuseScore 1.1

Conclusion: You can't cut/paste triplets reliably, so the only way to do it is delete and recreate, and that's very very clumsy.

Here is a picture of the mayhem created:
NOT FOUND: 01

I was copying one note only, I guess that's what you refer to as partial.

Yes, it causes incredible mess and corruption. The two examples I posted here are the simplest that can demonstrate the problem.

Can you point us to the issue you reported, please.

In reply to schepers:

Since MuseScore has no way to move notes around in a bar, the only way to change the rhythm and put them into a different place is by cut & paste. If the destination rest has the same length as the source note, there is no reason to disable this operation.

in reply to chen lung:
The first of these posts reports the second issue I reported, just with a far more complicated score.
http://musescore.org/en/node/9297
http://musescore.org/en/node/9909

I only tired triplets, since triplets are widely used in jazz/swing/blues. IMHO they represent 99.37% of all tuplets.

I tried the nighly build R5253 and it behaves just the same as 1.1, which is rather sad, since these issue causes corruption and need for rework/recapture.

I forgot to mention that undo also behaves strangely after the triplet paste problem.

The various reports go back to the beginning of 2011, so about one year ago.
The issue is marked "critical" and causes serious corruption.
The issue is easily reproducible with one single note or two notes (and a few rests) in the entire score.

Should that not be something high on the list of issues to fix?

The second issue reported her is a duplicate of #9909/#9297, the first issue isn't.
This report is easier to understand.
IMHO it doesn't matter as long as the issue is addressed and not dormant like in the last year.

Well, I reported two issues. For the first issue I submitted "bug 2" and it looks like this:
NOT FOUND: 01
NOT FOUND: 02

The second issue (which has been reported before in #9909) uses "bug 3" and looks like this:
NOT FOUND: 03
NOT FOUND: 04

Marc Sabatella reproduced the issues.

They both exist in Nightly Build R5253.

So I don't share your assessment that the bug will be fixed. As far as I can see, it's not been addressed.

With all due respect.
This is NOT a duplicate.
As far as I can see, issue 1 has not been reported before.
Can it be changed back to "active" so it gets some attention one day?

You're talking about very basic functionality here: "Cut and paste". And that crashes or corrupts your document.

In reply to Werner:

Do I understand this correctly: It won't be possible to cut and paste a single note or chord which is part of a tuplet onto a rest of equal length?

No one wants them to cross barlines. It's just necessary to move them to a location with has the same duration.

I looked at it in the nightly build: Before the copy the note has 160 ticks, after the copy it's 320. So surely there is room for improvement.

In reply to Chen Lung:
1) No idea, as I said, triplets make 99.73% of all tuplets. You try it.
2) Cut/paste is just as bad as Copy/paste
3) See below.
NOT FOUND: 01

ad 3) Same result in the nightly built. The pasted note has 320 ticks, the original one 640.

Chen Lung:

1) OK, just for you. I did it with quintuplets. I copied one from the first bar to somewhere in the second bar. Seems like the length of the copied note results in a 1/4 note.
NOT FOUND: 01
3) I pasted on to the second rest, not the first one. Pasting onto the first one looks like this:
NOT FOUND: 02

And with quaver triplets it looks like this:
NOT FOUND: 03

3) the minim was pasted (of course)

As for the crotchets, they are fine, no surprise since everything is pasted as crotchet :-(
NOT FOUND: 01

Sorry, not true.

In R5253 you can observe it in the debugger.
A 1/8 triplet has 160 ticks, sometimes it pastes as 320 ticks, so 2 1/8 triplets, sometimes as 480 ticks, so a crotchet.
And a chord of two notes of 160 ticks pastes as 240 ticks, so a straight 1/8.
Take a look at comment #15, there you can see the two cases. Nothing is pasted as a crotchet. It's somewhat random.

I think my initial heading "MuseScore becomes confused when copying triplets" was correct.

How nice, now we're discussing how to make the title more descriptive. I think we all understand what the problem is. But I'll give it another try.

Copying any set of notes to a different location (within reason) is essential. It's a very necessary feature and must not be disabled. Moving (by cut and paste) a "partial" triplet to a different location in the bar, for example, to where a rest of equal length is, it a normal and desirable operation required frequently to change the rhythm.

I tuplet is nothing strange, it's just a set of notes, which don't fall into the "natural" subdivision of the bar. But of course, it should be possible to move them elsewhere.

In fact, you can clearly define what should happen. Any note with face value 1/8 should be copied as 1/8 note always. If it comes from a triplet and is copied into a triplet, it maintains its original length. If it is copied into a straight section, it becomes a straight 1/8 and so on. The rules are pretty clear. You could issue a warning if the copy changes the effective duration of the note, or even disallow the operation.

Can you tell me how to change bar 1 to bar 2 without deleting the chords and entering them again.
NOT FOUND: 01

My old boss used to say: "What conceivable is achievable". I never quite agreed, but I don't see any reason at all why "it will not be possible to handle parts of a tuplet". It handles them now, only badly. It's just data structures under the hood, and any operation transforms the initial data structure into a different one. That's data processing. There is no magic to it ... and nothing is impossible.

And it's open source, so any C++ programmer could download it, build it and fix it, right? That's the idea.

I'm getting bored by wasting time on the semantics of this. I think the issue is pretty clear.

I thought you understand the issue perfectly well. You even submitted test cases yourself. I'll give a brief summary:

The aim is to move notes from within a tuplet bracket to somewhere else, either inside the same tuplet, or into another or to somewhere outside a tuplet. We need this so we can change rhythm (see the picture in comment #32).

Sadly, strange things happen as shown in comment #15 and also in your test cases in comment #23:
1/8 triplets (160 ticks) pastes as 320 ticks, double the length. Or when pasting two notes, they paste as 240 ticks, so a straight 1/8 note (comment #27). In your example with minims (1/2) in a triplet (640 ticks), they get pasted as crotchets (1/4) (320 ticks). When pasting to outside a triplet, an 1/8 triplet (160 ticks) gets pasted as a straight crotchet (1/4) (480 ticks).

The list of strange things could be continued. Take your example with quavers (1/8) in #23. A single note gets pasted as a straight crotchet when copied onto an outside rest. But when you start with a chord of two notes, in MuseScore 1.1 nothing gets copied, in R5253 one of the two selected notes gets copied.

There is not much point to give any more detail. Someone needs to take a close look at how tuplets are handled in copy/cut/paste situations.

To the title "Copying from within a tuplet bracket to the same or another or to a normal rest produces strange results" now accurately reflects the problem.

There is news on this.
In the trunk the following bug was fixed: //musescore.org/en/node/3482 .
So since R5263 single notes from a triplet are now copied correctly. The person who said it can't be done wasn't right after all. ;-)

Sadly chords (more than one note) still don't copy correctly.

Further discussion regarding this problem can be found here:
//musescore-developer.685061.n2.nabble.com/Tuplet-logic-td7273953.html

The fix will be either to disallow tuplet-chord copying or to allow a single chord to be copied.

As stated in comment #43, copying a single note from a tuplet works now in trunk can branch 1.2.

In R5311 Werner checked in a fix to disallow the copying of partial tuplets. This will avoid the corruption discussed in the first comments of this post.

I will post a patch for the branch 1.2 soon.

Quoting from the mailing list:

Werner:
A selection can start at the beginning of a tuplet (and not in middle or end) and end at the last element of a tuplet (or outside of a tuplet of course). To select parts of a tuplet the nesting level of nested tuplets must be considered. Additional code is needed to transform chord/rest values.

===

So in brief: for now it won't work. Keep in mind that single notes always copy correctly.

The patch in R5311 checked in by Werner is not correct. See mailing list discussion for details. Sadly it also breaks the ability to select and copy the entire tuplet, which worked before.

Here is the correct patch for the trunk.

Here is the patch for the branch 1.2. The code is now exactly as in the trunk.
I tested it. "Partial" tuplets can't be copied, full tuplets can.

I have a suggestion to make:
I'd like to close all tuplet bugs, so this one and the following:
issue #9909: Copying single tuplet pastes as standard note and produces tied mess upon undo
issue #9297: Copying single tuplet pastes as standard note and produces tied mess upon undo
issue #14658: Cut or Copy on single tuplet has no effect

Instead we should create one new feature request: Need the ability to copy a chord from inside a tuplet to elsewhere.
Note: this works already for single notes.

If you agree, I'll proceed with processing the issues.

... to the user to let him know that it can't copy a partial tuplet if it's not a single note that's copied.

I think we should, but then we would have to translate the message into 43 languages, right?

The code is here (scoreview.cpp):

void ScoreView::normalCopy()
{
if (!_score->selection().canCopy()) {
printf("cannot copy selection: intersects a tuplet\n");
return;
}
...


Perhaps it's not too late for a patch ;-)

This one will give the user a message as requested in comment #51.

Other messages in the system say:

No note selected: Please select a single note and retry operation
No note or rest selected: Please select a single note or rest and retry operation
Please select a single note or slur and retry operation
Please select one or more staves and retry operation

So it's quite consistent with those.

Actually, I chose the message, so I like it. It fits well into the context:
NOT FOUND: 01

It's still broken in the trunk. In fact, in the trunk you can't even select a complete tuplet any more. See comment #49.

The patch from comment #49 is still waiting to be committed.

For consistency with version 1.2 we should issue the same error message when a "partial" tuplet is selected (same patch as in comment #53).

Here are patches to correct the partial tuplet test, so what Chen Lung reported here cannot happen any more.

Previously the test only worked for one instrument and one voice. Now it works for any number of instruments and voices.

Regarding step 2:
Since the C in the bass of the piano is the last note in the bar, the selection is extended to the end of the bar, therefore selecting the entire tuplet. So it's a feature.
While selecting:
NOT FOUND: 01
After letting go of the mouse button:
NOT FOUND: 02

There is nothing I can do. The selection is extended to the end of the measure, the system shows it. The tuplet is fully selected, therefore no warning.

#14658: Cut or Copy on single tuplet has no effect is a duplicate of this bug.

Partial selection of a tuplet will give a message in 1.2, for the trunk a patch is provided in comment #65 (and another one in #67 to check partial tuplets in multiple instruments/voices). The patch (patches) is (are) awaiting acceptance.

And once the patches are accepted I'm very much looking forward to closing this issue, since it has become way too long.

On the 10th and 11th of March (one month ago) two patches were submitted for the trunk in comments #65 and #67. The respective versions of these patches for the branch have already been tested and accepted long ago (2nd/11th of March, comments #59 and #68). The patches for the trunk are still awaiting acceptance.

Please apply the patches now to finally close this issue.

IMHO this has nothing to do with cut and paste (refer to the title of the issue), so I suggest to move this issue elsewhere.

This issue here has become way toooooo long, so all that's left to do here is to accept the patches (which are over one month old) and then close this issue.

As I explained in comment #76: There were two patches. The one from comment #65 is still waiting to be committed.