Request option to copy system elements with copy/paste

• Jan 26, 2017 - 23:59
S5 - Suggestion

There are several bugs with copy + paste.

If you select an entire piece to copy into another, none of the following things are copied:
* clef changes in a line
* tempi
* rehearsal marks

If you copy several measures over the top of some existing measures that contain slurs, the slurs in the target are not removed first. So it's common to end up with multiple super-imposed slurs

Same with dynamic markings (e.g mp, ff etc) and hairpins.


Title Copy Paste, metadata not copied, other copy paste bugs Request option to copy clefs, key signatures, and other elements with copy/paste

Most of what you describe is not a bug - it's the way it is designed to work. Much of the time you don't *want* those other things copied. Of course, some times you do. So there is an existing feature request to add that capability with respect to time signatures specifically - see #16332: Copy and paste honoring actual time signatures of selection . I don't see a similar request for other elements, so I'll leave this open for that purpose.

Rehearsal marks in particular you'd almost never want copied - who wants to letter M's in their piece? Also you don't normally want system text of any kind - and that included tempo markings as well - copied when copying notes from the top staff (where they are actually attached) to other staves.

Ultimately we could consider adding more options to the copy command, or other copy commands, or possibly consider using the Selection Filter to exclude these elements.

The slur issue is covered in #45361: copy/paste and "R" do not delete slurs or lines in target measures. It's less clear why one would expect dynamics to be automatically deleted on copy, but I guess that could also be considered a possible feature request for future consideration. Probably best to start a discussion on the Support forum about that first, to see if people think of this as a bug, and if not, how they'd like to see a possible feature to look.

Title Request option to copy clefs, key signatures, and other elements with copy/paste Copy Paste, metadata not copied, other copy paste bugs

Other things that don't copy are system text, bar lines and time signatures. What all of these have in common are that they are system items rather than staff specific. They are also excluded from the selection filter tool.

For consistency's sake I think it is best that MS does this. What if it allowed for copying of key or time signatures? If you were only copying half of the staves, which one would you want on the pasted lines? MS made that decision (because it had to make one) so you must work with that. If it didn't chose only one, then it would have to make them local time and key signatures which would lead to massive problems afterwards.

The double slurs and dynamics are annoying.

Title Copy Paste, metadata not copied, other copy paste bugs Request option to copy clefs, key signatures, and other elements with copy/paste

@marc, we were typing at the same time and I posted last. Sorry.

maybe we need another selection mode then.

Because when I put a suite together, I do the pieces in independent files (else UI becomes too sluggish) then put them all together in a single file at the end.

It's a lot of work (and risks mistakes) to have to re-enter tempi, clef changes (e.g. bass -> tenor for celli), time signatures (which is destructive change, so need to re-factor all notes that were split over barlines etc), rehearsal markers etc.

Ctrl-A in a score could be argued it should select all these things too, or pop a warning, or option about what you want to select (maybe make that warning optional so it can be made unintrusive).

Also, before you mention "Album", I need control over page breaks etc between movts in the parts, and didn't see a way to do this. Also I've found trying to use the Album feature usually crashes.

I am in complete agreement about large files becoming unbearably sluggish so I break them down into multiple files and do make mistakes in recreating the system items. This is preferable to lines becoming impossible to copy or paste from because MS sees a local time signature on the line.

In editing a large score I tried making a work area file where I make my edits and then paste them to the proper measures in the main file. Both files are open at the same time and I turn off auto save to prevent 5 minute saves every 10 minutes. It shows promise as a work around for making a large score until 3.0 comes out and the sluggish behavior should be greatly improved due to internal workings that are being improved.

Note that 3.0 will already have significant performance improvements with large scores. So you won't need to rely on copy / paste for this.

Feel free to ask in the Support forum about your problems using the Album feature. It actually should work well for this purpose. Nothing about albums should limit use of page breaks or parts.

I think if you have a line that starts in 4/4, has some bars in the middle in 3/4 it's incorrect to not copy these over.

I don't understand why it would be deemed impossible?

Just difficult I guess if you have existing measures there in a different time signature, but destruction of the information is a problem. An option would be to ask the user what the desired result is (e.g. apply the time signatures in the destination or not).

If you paste 4/4 into 3/4 a lot of the notes are changed, any that go over the barline are split. When you correct the time signature, this splitting isn't reverted, so you also have to correct every note that got damaged this way, which can be a note or 2 per bar. This can be a lot of work.

A work area would be great if you could open multiple scores in multiple monitors. Or multiple instances of MS. Hard to do clipboard cross platform maybe?

With the Album feature, I didn't see any way to control page breaking? It's common to want to start a movt on the same page that the previous one finishes on.

actually that reminds me of another bug....

if you extend a note (e.g. add a quaver to a minim with N 4 +) then the note doesn't behave the same as other notes, and some functions don't work on it. I've had to delete the extension, apply the change then re-add the extension a lot of times.

Struggling to think exactly what transformations don't work on these ones though sorry, I should submit another bug on that if there isn't one already.

Actually there's another one relating to copy paste.

If you have a score with parts, if you paste things into the score which has slurs, often the slurs won't show up in the parts, just the score.

I understand various items need different positioning information between the part and the score, but not different existence? I've seen one pathological bug relating to difference in attributes between score and parts relating to tremolo between 2 notes. I found one case I'd set it in the part, it would unset it in the score and vice versa - couldn't get it set in both for the life of me.

Sometimes have to resort to deleting all the parts and re-creating them to get everything into them (seems some stuff is copied in on part creation).

But I love this program, and spend a lot of time in it, so don't think I'm not grateful :)

As I stated above, the problem really lies in copying part of a file (like 7 out of ten lines) or pasting fewer lines than exist in the destination. MS does not know what your intentions are, so it (through the programmers) has to make a decision. The decision is made because if you paste a 3/4 time signature on some lines in an otherwise 4/4 piece it becomes impossible to copy or pasted anything on those lines after after the time change. You cannot change this except to delete everything that was pasted. This is a limitation of local time signatures. You can test this out with something more reasonable (like 4/4 and 2/2 time where the bars are the same). Write some music on 2 lines. Add some notes on one of the lines and then ctrl-drag the other time signature to an empty measure and add notes to the 2nd time signature. Copy a measure from the first time signature and try to paste it into the 2nd time signature, it won't let you. MS (and its programmers) does not want to put you in this situation. Changing the time signature back to the other time signature does not fix the problem, and it won't let you delete the local time signature. You don't want this to happen.

I hope this helps you understand why you request is ill advised. I am only a user like you and wish none of this were true, but it is a reality that we must live with. I'm holding out for 3.0 to make entering large files much easier.

I don't program in C++ or qt, but I have some programming experience in C. I wouldn't mind having a discussion with someone working on this issue about how MS looks tuplets to see if a better solution could be found. I am extremely good with math.

#12 You can view 2 score side by side or stacked top over bottom in the view menu. That's how I do my work area I make for myself.

You can't have 2 instances of the same version running, but I currently have an instance of 2.0.3 and an instance of 2.1-dev open at the same time so I can see if functionality is the same. As far as I can tell all scores are cross compatible, but there are features I have not and probably will not use. And you can copy from one and paste to the other.

I would not use 2.1-dev for large scores because it has debugging data that slows it down.

I think it should let you.

If you have a selection of 12 bars, say 4 bars of 4/4, followed by 4 bars of 3/4 followed by 4 bars of 4/4.

The thing is what to do on paste. There's 2 modes for paste, insert and overwrite.

In insert mode, you'd be creating new measures. These measures would be inserted into all parts at the same location, so the sequence of measures could easily be copied from the source.

In overwrite mode, it would need to go through the sequence of time signatures in the source and apply those to the relevant parts of the destination. this could require addition of measures, but that shouldn't be a problem either.

I'm assuming 1 bar number in all parts must have the same time signature? So it just becomes a matter of figuring out what the intent is, and if all else fails it may be better to ask the user rather than silently discard information (current approach) or prevent the operation (which has other consequences).

I know it's a pain to code such things, but it's possible. I am a C++ developer, the only thing that stopped me from working in MS codebase is the environment, qt etc, which I understand is necessary for X-platform.

If tuplets were fixed, none of what I said about local time signatures would be an issue and all your requests would become simplified and not cause 99.9% of users to freak because they can't copy or paste measures.

ah sorry, missed that point. Yeah tuplets are problematic.

I had some 6-tuplets in one part which broke MS3.0 (ended up with some bars having different time signatures) until I split them into triplets.

So are they done with a time signature hack?

Anyway to be clear, it doesn't prevent me from copy paste, it just leaves things out which causes me a lot of extra work.

I guess I should have another look at the album thing. There are other reasons why it would be best if we could keep files separate, but there's also overall formatting issues with keeping them separate that combining the files deals with.

Again, nothing about an album limits you with respect to page breaks. Once you join the scores, the resulting score is a perfect normal score you can add or delete page breaks from like any other score. Again, if you are having trouble with this, please ask for help in the support forum.

Title Request option to copy clefs, key signatures, and other elements with copy/paste #21

I think you should consider build in a function to select all the system text etc. and copy it.

For example i m writing a Song in AABA where you have time signiture changes etc. in the A section etc. so i would want to copy all that information in the following A-sections.

No matter how many times you tell people "the complete impossibility of copying and pasting tempo markings is a feature, not a bug," people aren't going to start feeling this is a feature.

Just because one sometimes doesn't want to copy tempo markings &c is no reason to make it impossible. Rather than trying to read minds about what people do and don't want copied, the right thing is to let them decide via the selection filter. If you feel the selection filter shouldn't be set to 'all' by default, that's another matter.

When using the TempoChanges plugin to patch over MuseScore's faulty support for rit/accel, it's easy to end up with literally hundreds of tempo changes, and saying 'just recreate them all in your other score by hand' is lousy.

Nobody claims it to be a feature, it is not a bug though, but a lacking feature (something that isn't yet implemented), hence this issue is a feature request.

Right, to be clear: there are two useful features. One is to copy music without the other stuff - very important in many cases The other is to copy music with the other stuff. That's also useful in many cases. Right now, MuseScore supports the first feature. It doesn't support the second. Eventually, I would hope to see the second feature added, but the first feature must remain, it's vital as well.

Dear Musescore devellopers,

please do add this feature soon. I am very grateful for the existence of Musescore but the impossibility of really copying or duplicating music is so frustrating and we people have been begging for it for so long.


"Copy the other stuff" must include time-signatures and measure-lengths. The inabilty to just copy an extent of measures as they are, even one whole score into another, is a glaring long-term deficit, regardless of the indisputable utility of "just copy notes/rests".

Title Request option to copy clefs, key signatures, and other elements with copy/paste Request option to copy system elements with copy/paste
Reproducibility Always  
Type Graphical (UI) Functional

I've been searching for this for years just to see if it's already fixed and every time I try to search it I get more and more frustrated. I can understand that being asked for the same thing dozens of times is annoying but the answers sound more and more like excuses being told year after year.

I don't want this to sound like an attack or destructive criticism (it may come the other way because of the language barrier). I think we all know that it is a very requested feature (even if some people call it a bug changing the discussion every single time about the topic of it being a bug or not is just going out of topic, loosing time and making the comments look toxic) and most of us think that how it works now is also useful. That doesn't mean that limiting it to be like it is now should be considered a expected thing because it's how people want it to be "most of the time". It's counterintuitive and impractical in many many contexts and the filter solution that has ben suggested a bunch of times seems like a perfect implementation of both "features".

To wrap this I wan to say that I love musescore, the community and all the dev work, I just find this topic really frustrating (mainly because of all the comment posts in the last 5+ years) and sorry if this has sounded rude or aggressive, it's not my intention with this post at all.

In reply to by Pedro16797

I don't work for MuseScore -- in fact, almost nobody does. The effort is by and large volunteer. And there are few product schedules, or "Release so-and-so will have this major feature" (unless it's already being worked on). The feature you mention, straightforward copy/paste of arbitrary score, is an obvious missing one. It's not yet done because it's difficult and nobody has taken it upon themselves to do it, not because there's a conspiracy against it or "powers that be have decided against it for now." There is no "request list" in which this stands (and heaven knows, I have wanted it for years) and from which it has been excised. The bottom line is, "if you have the necessary skills, and would like to implement it, please help us and do." This is the open-source paradigm: It has problems as well as features.

Marc, did I get this right?

In reply to by BSG

I know there are limitations and that it's hard to implement and help is needed. I also know this is not in a list of things to dismiss because of a weird conspiracy.

What I see is lots of comments in multiple posts with answers that instead of acknowledging the limitations ramble around minor details unrelated to the question (like the definition of bug for example).

I would love to know how to solve it and help to give back to the community what MS has given to me but I have a lot of time constraints and not enough experience programming. Maybe in the future if this is still around ;)

In reply to by BSG

@BSG Actually, if you want this feature so badly, why not implement it yourself ;-) You've authored a plugin (plugins?), and I suppose based on your self-description, you surely have the skills to do so. I'm curious (and surprised) why you still haven't contributed directly to MuseScore code given your will of devoting time into MuseScore ;-)

In reply to by BSG

A possible limit on this feature that I would happily accept would be that it would work by full measures only.
So your selection could only be a continuous set of measures, and paste could only be done "between" two measure (or on top of a selection of full measures, thèse measures being replaced that the clipboard content).
There is no need to make philosophy on what must happen when you copy from half of a 6/8 measure on top of the second beat of a 5/4 measure.

FWIW, it wouldn't be all that hard to get most of this working. The info is there in the clipboard when we go to paste, we just currently skip it. Right Actually honoring the system elements, barlines, and key signatures shouldn't be hard. The time signatures would be trickier, because right now we rely on doing some time calculations before we've completely read the clipboard. But trickier isn't the same as impossible. It's just a question of a sufficiently motivated person finding the time to do it.

Same request.

Like other users, I do not understand why there is reluctance to implement this, allowing to copy all elements instead of skipping some of them.

A way to manage this function could be a "special paste" menu, with tick boxes allowing to specify what should be copied or not.

I understand that this function should better be limited to entire measures to avoid strange effects.

A simple example: I am programming a score to warm up before singing.
The score is composted of 21 groups of 5 measures, separated by a double bar and preceded by the key signature.
Each group is 1/2 tone higher or lower than the preceding one.
My idea was to build one group in CMaj, end with a double bar and then copy/paste/transpose by 1/2 tone 20 times.
No problem with notes, but due to the copy/paste limitation, I spent most of the time in selecting single measures to inject key signatures and double bars.

In reply to by BSG

I read in another post that some elements were just filtered out, but I understand now that this is done to avoid side effects.
At this stage, I am still just a user, regularly improving "score coding" skills, but still in the learning phase.

So not ready yet to contribute to the coding (not even knowing in which language it is developed).

In reply to by Jojo-Schmitz

I will add to that that it is extremely sophisticated so-called "modern" C++, requiring very substantial knowledge of modern programming and application-building paradigms. It is not at all something for beginning or non-programmers to even think about.

In reply to by Howard-C

No, it is not sarcasm. As you know, I am a professional programmer with decades of experience on (once) state-of-the-art projects, and I had to brush up on C++11/14 just to read the source. Anyone without full understanding of C++ templates in all their C++11 complexity, for one, better not try. Let alone the dark forest of Qt and trying to debug into it. It's certainly not a criticism; it is utterly reasonable that state-of-the-art tools and techniques be employed by a state-of-the-art product. That fact alone (that this is a professional-quality, state-of-the-art product) should discourage tinkerers.

If you want to write a fugue and have only a vague idea what one is, you can post your work (t)here; breaking an operative application with broad usage, like aviation, is quite a different matter.

In reply to by BSG

I'm glad it's not sarcasm, but I'm also surprised that while more and more newcomers are clearly taking up some coding and creating PRs (think of it, we have 214 open now) and doing not a bad job, the first thing you thought of was to discourage them in a most absolute tune.

In reply to by Howard-C

I assume that these submitters have the requisite skills or their code will not work or even compile. Fortunately, advanced programming skill is not uncommon these days, but it is just that, advanced. I should encourage myself, as you have noted. If one can make code that compiles and works and meets peer review, more power to that person. Those with the requisite skills should be encouraged, but those lacking those skills shouldn't be. There really is a difference.

In reply to by BSG

I understand that writing a fugue requires requisite skills, that's why I would never write something randomly and call that a fugue without learning. But look at me -- up until now, my curricular study of C++ (and programming) only lasted for a semester (and a half, which is from a special course during summer vacation), but that was where I started coding for MuseScore, and I learn something new everyday. I of course cannot guarantee that I have the ability to implement anything you can think of, but I can now understand most of the code and realize many things I've come up with from core libmscore algorithm improvements to mscore interface designs. I managed to go through this with the generous help and encouragement of the developer community. And yes, I've decided to take up more courses in university to dig deeper largely because of this experience. So, it's not like I'm bragging in front of someone as experienced as you, but I'm just showing that discouraging won't help and encouraging can potentially help both new contributors and MuseScore source code. And it's not like anyone can directly modify the code, good or bad. There're reviewers and maintainers after all.

In reply to by Jojo-Schmitz

Thank you for the information. Unfortunately, I have no experience in this language.

I used many other languages in my (passed) professional life, and I am still doing some developments in my private life, but not in C++. Huge developments (ATM software) were developed in C++ and ADA, but in the last 15 years, I was rather taking care of managing the development teams ;-).

I seize this opportunity to send a warm thanks to all those who have C++ coding skills and offer their time to the Musescore community.