Wrong error message when using 'copy' on a selection in a local time signature
Reported version
3.5
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
I am trying to copy a couple of measures of notes (ctrl-c) but I get this weird message I don't even know what it means. I am using the latest stable version 3.5.1.
Maybe this is a related issue but I can't copy/paste the treble staff into the bass staff. It lets me do the copy, but not the paste. Might have something to do with local time signatures, though I don't know why local time signatures would be a problem - I am pasting into the same time signature.
The workaround is to reenter the notes in the new location but it is ridiculous to have to do that.
Comments
As i unbderstand, you hope that eight notes will be converted to triplet, which is not possible (in the present version of musescore) : for that reason you get the error message.
Well, no, check the error messages, esp. the first, it talks about "select complete tuplet/temolo", which obviously is a wrong message, as the selection doesn't contain any tuplet or tremolo.
The 2nd error though indeed is by design currently, and the error message "cannot paste in local time signature is (almost) correct ("in" should be "into" IMHO though)
In reply to Well, no, check the error… by Jojo-Schmitz
Thank you all for looking into this, however I don't understand why it is by design that you can't paste into a local time signature. I am copying from a 12/8 INTO a 12/8. I can see not allowing it if I am copying from a 12/8 and pasting into a 4/4.
It is by design insofar as this is not implemented. Another issue, and "Suggestion", vs. that wrong error message.
In reply to It is by design insofar as… by Jojo-Schmitz
OK, got it.
I possibly encountered a somewhat similar error in Finale 10-15 years ago. It turned out to be how note durations were represented in the note database. In Finale I was using something like 7:4 and while the base 'unit' [the beat] was 4096, easily and equally divisible by 2, 4, 8, 16 etc, however when handling tuplets – even triplets, the division into equal size units was not possible. There was always a remainder.
It took the people at Coda a while to figure out how to handle this problem, because the coding had to be generalizable, not so comfortable with nested tuplets [3:5 inside 7:9]. As I recall, an engineer told me that the numbers did not add up to the required duration and may have raised a check-sum error.
This is far beyond my level of making this work.
Kevin
Just to clarify a few things here:
the reason it isn't implemented is that the initial implementation was discovered to create massive corruptions, and we discovered it only days before the 2.0 release, so we made the decision to disable it rather than delay the release
the reason the error message is so misleading is that a string freeze was in effect by then, so no new error messages were allowed, so we re-used the closest we could find\
the reason none of this has been fixed since is there were too many higher priorities
back then, we too might have had issues with inability to handle divisions exactly (480 "ticks" per beat, can't be divided evenly by 7 for instance), but now that we represent everything in fractions directly, no particular reason this should present any problems anymore
no reason it couldn't be looked at again for MuseScore 4, but we'd need something to happen that hasn't happened in the five years since MuseScore 2 - someone with the right combination of expertise, motivation, and availability to step forward to work on it
Thank you.
Yes, then there are two issues, the functionality and the notification. I'm not concerned with the notification.
I agree with your last point, aka, assignment of available resources. There are likely many 'music technology / code writers' out there who could do this. The problem, as always, is finding them.
•• I don't know enough about these communities, but a request through the International Computer Music Association, cec-conference, or perhaps even AUDITORY might find the right person / people, if the request is written in the correct way. I will think about this for a while and ask around a little. For more on this, email is better for me than a forum discussion.
Kevin
In reply to Just to clarify a few things… by Marc Sabatella
Mark, I appreciate giving us the honest history lesson about why this issue wasn't implemented. I also appreciate the honesty as to why it hasn't been looked at since. I hope it can be fixed in Musescore 4.