Open ShibuyaCyana opened 1 year 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.
Currently there is no (6) or (7) implemented. I.e. program does not reacts nor does not display any error.
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.
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.
@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.
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
Your idea
See section below
Problem to be solved
Say I want to make the left picture into the right one:
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.