musescore / MuseScore

MuseScore is an open source and free music notation software. For support, contribution, bug reports, visit MuseScore.org. Fork and make pull requests!
https://musescore.org
Other
12.39k stars 2.68k forks source link

Copy/paste in bars with local time signatures #25070

Open Dima-S-Jr opened 1 month ago

Dima-S-Jr commented 1 month ago

Your idea

I suggest making it possible to copy/paste content in bars with the same local time signatures.

Problem to be solved

At the moment, it is not possible in MuseScore Studio to copy the contents of a bar with a local time signature and paste this content into a bar with the same local time signature:

https://github.com/user-attachments/assets/5e196974-6762-43c6-b658-ba2d357f1857

The copy/paste function is very often used when writing music in notation software. It would be one thing if I were trying to copy the contents of a bar into a bar with a different time signature. But it's a completely different matter when the user wants to copy the contents of a bar into a bar with the same time signature. Why is this unavailable? Moreover, when the user tries to paste the copied content, nothing happens (it would be more logical to show at least some kind of pop-up message to the user, something like "it is impossible to insert in bar with a different time signature" or something like that).

Prior art

No response

Additional context

No response

Checklist

FrancRos31 commented 1 month ago

Seems more like a bug than a new feature.

bkunda commented 1 month ago

@cbjeukendrup this could be a good one to tackle as part of our copy-paste improvements :-)

cbjeukendrup commented 1 month ago

Yes. It becomes a bit scary though when you copy this:

Scherm­afbeelding 2024-10-08 om 15 21 40

and try to paste here:

Scherm­afbeelding 2024-10-08 om 15 22 33

because, if the expected behaviour would be this:

Scherm­afbeelding 2024-10-08 om 15 23 31

then the end of the pasted area is at a different position at each staff, and that feels... weird.

For the MVP, we can of course try to detect such weird edge cases, and refuse to do anything with them. However, we may want to think a little bit about it, because it might influence the decision whether pasting should happen per staff or per segment, which is quite fundamental.

MarcSabatella commented 1 month ago

To me, the MVP would be just allowing a basic copy of ranges within a given local area. So if the global time signature is 2/4 and the bottom 3/4, allowing copy of 2/4 content to other 2/4 measures, and 3/4 content to other 3/4 measures. Actually copying the time signatures too as per other requests would of course be a nice option, but right now copy/paste is disabled completely and first priority should be addressing that. Says the person who disabled it just before release of 2.0 because there were bugs we didn't have time to fix before release, and is a bit embarrassed that another nine years hasn't proven to be enough time either!

ApocalypticSalad commented 1 month ago

Moreover, when the user tries to paste the copied content, nothing happens (it would be more logical to show at least some kind of pop-up message to the user, something like "it is impossible to insert in bar with a different time signature" or something like that).

There actually is a pop-up for when you attempt to paste notes into a bar with a local time signature.

Image

The problem there is that copying notes from a bar with a local time signature silently fails. If there's something already in your clipboard, it stays there. So in your video, you actually had nothing to paste.

Of course, this minor correction is largely irrelevant to the overall request. Looking forward to seeing this fixed, the current situation makes working with an extended local time signature section... painful.

Dima-S-Jr commented 3 weeks ago

because, if the expected behaviour would be this:

374575130-e048c601-b29f-42f1-a1e7-64c9ba4828cc

then the end of the pasted area is at a different position at each staff, and that feels... weird.

I suppose the expected behavior should be like this: Снимок экрана (714) I think this behavior is correct from the point of view of meter equivalence, because in fact local time signatures assume equivalent beats, and the contents with local time signatures can actually be written as tuplets.