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.29k stars 2.66k forks source link

Copy and paste discrete notes with their rhythmic pattern #19046

Open ShibuyaCyana opened 1 year ago

ShibuyaCyana commented 1 year ago

Your idea

See section below

Problem to be solved

Say I want to make the left picture into the right one: image

The most straightforward way coming to my mind is to selecting all these low A's then cut and paste, sadly it doesn't work, I have to copy-paste the whole bar and delete useless chords one by one.

Due to things like issue #19045, when writing for piano I sometimes prefer to work in a single staff at first and split it some way afterwards, but not able to copy & paste discretely selected notes like that make it much slower; and lacking box selection ability (#15282) makes the last step of deletion even harder to complete.

There's an action called 'move selected note/rest to staff above/below' but it's for cross-staff beams...

Prior art

In a DAW I can simply copy and paste any selected notes in any topology shape, and their duration relative position will be kept. Not strictly a prior art from notation software tho.

Additional context

Tried this on MS 3.x and it doens't work either.

macias commented 11 months ago

Since I was redirected here with my report that "copy & paste chord over rest does not work" maybe I explain briefly how IMHO the workflow should be in such scenario.

  1. User selects notes (source).
  2. User executes copy (or cut) action.
  3. User selects rest (target)
  4. User executes paste action.
  5. Program checks if the source length matches the target length -- say 1/4 to 1/4 (it would be a match) or 1/8 to 1/4 (mismatch).
  6. In case of match notes are pasted.
  7. Important: in case of mismatch there is feedback for user (maybe slide-in notification) stating the length is not the same (or something similar).

Currently there is no (6) or (7) implemented. I.e. program does not reacts nor does not display any error.

MarcSabatella commented 11 months ago

One problem in any such scenarios is, how to handle non-simple selections: for instance, a selection containing one note from one chord in one voice, another note from another chord in another voice, another note on a different beat in a different measure, and another note on a different staff entirely. The other problem is, how to handle non-empty destinations.

The general case is basically impossible to handle. The question is how to design a system that does reasonable things for the reasonable cases (and to tell the difference). It's not impossible, but it's far from trivial, and that's where the difficulty lies.

ShibuyaCyana commented 11 months ago

Yes, it will be difficult if we want to include every possibilities and user intention, but not that difficult in this case (at least design wise). We already can paste a time region to anywhere, it's not a delicate system, just overwriting anything on the target staff, but enough for my original FR usecase. It's an equivalent of deleting every note that is not in selection, copy the rest as a region and paste to target area.

For more complicated behavior, here is a discussion about it. It's far from a complete design but I believe the original PRE developer was thinking more or less the same way and had already implemented some of them. From the same thread:

I did write an update for MuseScore 4 about two years ago now which both ports the old code and adds some new features including many of the points discussed above.

macias commented 11 months ago

@MarcSabatella I didn't it cover, because I thought it was obvious -- they are in different position entirely so it is case (7). Again, it is not only for what should work, but also what should happen if operation is blocked. Currently there is no feedback. So behaviour internally does not change, action is block, but visually it should inform user about it. IMHO.

Or maybe I rephrase -- feedback is useful for the user to know what is going on (without it is just guessing). As for the features if we start with "non-supported" basket with cases A, B, C, D...K, anything we move from this basket to the "supported" one is beneficial, because it broaden the usage of the program or provide greater ease of using it. It does not have to be "all the items at once", even covering one scenario is helpful.

Ash-86 commented 1 month ago

I just stumbled upon this and thought i'd share a plugin i recently wrote that did just what is discussed here. Works across multiple voices and staves. Here are some demos.

https://github.com/user-attachments/assets/450b78e9-40bd-43f7-9cf8-5d643bd7e7c8

https://github.com/user-attachments/assets/bb2a7d7e-840d-453c-b4d4-ff006ac3b20f