Copy/paste to/from passage with local time signatures produces corruption.

• Mar 21, 2015 - 00:32
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

Ubuntu 14.04, GIT commit: 1108286

Copying from a "normal" measure to a measure with a local time signature works OK, but copying from a locally stretched measure to a normal measure, or to another locally stretched measure, produces corruption.

We will probably choose to live with this for 2.0

Comments

• Oct 12, 2015 - 11:41

I understand how easily copying and pasting across different time scales can raise corner cases complex to deal with.

For instance, in the original use case which prompted the devs to add the local time feature (the 26th Goldberg variation, see the relevant handbook page ), the ratio from the top to the bottom staff is 2/3 (3 semiquavers of the top staff equal 2 of the bottom staff); copying from top to bottom would involve creating triplets and the opposite would involve creating duplets. And we all know how much of a pain on the neck tuplets are.

However, another use case recently surfaced which normally would not raise this kind of problems. It has to do with the halving (or dividing by four) of the note values which is employed in some Renaissance editions (a more specific use case is hinted at here ). Agreed, it is a rather specialistic use case, but so it is the other one quoted above.

That said, would it make any sense to attempt to solve the issue at least for cases which do not involve tuplets?

Reply

• Oct 12, 2015 - 14:04
Title Copy / paste to/from passage with local time signatures produces corruption. ⇒ Copy/paste to/from passage with local time signatures produces corruption.

Reply

• Oct 12, 2015 - 14:44

Indeed, worth solving for sure. I didn't see an "easy" solution at the time I was working on this area of the code, even for the non-tuplet cases. I didn't even see an "easy" way to disallow the operation or I'd have done that. But I'm sure it's *possible*.

Reply

• Nov 30, 2015 - 21:57

I was starting to look ahead and think about what it would take to actually support this, when it occured to me there would probably always need to be limitations. Consider: selecting one measure across two different staves with two different time signatures, then trying to paste that to a different part of the score where the destination staves had the same time signature. Other than converting something to tuplets, there would be no sensible way to handle that. And yet converting everyting to tuplets is unlikely to work very often either, nor is it what would probably be wanted most of the time. So even deciding on the right semantics would be tricky, I think.

Reply

• Dec 1, 2015 - 02:21

FWIW, IMHO (two in a row!) the "cheap fix" is perfectly reasonable. However, though I can't read the code, it looks like there's possibly no warning to go with it? I'm thinking of something analogous to the situation of copying with an incomplete tuplet selected, or pasting into a tuplet.

Reply

• Dec 1, 2015 - 15:56

By returning "false", this triggers a dialog further upstream. Unfortunately, as my comment in the PR mentions, this means the message isn't specific - it's the same generic message about tuplets you'd see if you tried to paste a tuplet across a barline. We do eventually need to refactor the code so we can generate more specific error messages. There are a bunch of other places where this happens; we should deal with them together.

Reply

• Mar 14, 2016 - 11:37

I will merge the PR and try to come up with a better message in both master and 2.0.3.

To answer Miwarre in #4. Yes, it would be good to make it work in the "easy cases" if possible. That should probably be addressed in another issue, and in another PR.

Reply