Request option to copy system elements with copy/paste (ALL ELEMENTS)

Time signatur changes and repeat barlines are not copied either

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.

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.

---

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

I think all the settings are correct now.

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.

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.

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.

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.

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.

Came up again in https://musescore.org/en/node/269357

.

Came up again https://musescore.org/es/node/276565

and in https://musescore.org/en/node/276622 too

Came up again in #285072: Tempos are not copied

Came up again in https://musescore.org/en/node/293352.

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.

Like by adding those elements to the selection filter, but off by default

Yes, but then also a way to set the filter to default, not just all/none selected

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.

Please.

"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".

Came up again in https://musescore.org/en/node/298120

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.

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?

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 ;)

@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 ;-)

I don't want it that badly, but, you're right, I should contribute to the core code.

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.

It could work like with tupplets, displaying a message telling you that you can't select only a part of it

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.

It's not that there's a reluctance or refusal -- it's just hard to do, and hard to get it right (design-wise). If you have significant coding skills, feel free to help.

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).

It is C++

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.

I don't know if that's supposed to be sarcasm or not, but either case, may I point out it's not helping at all?

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.

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.

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.

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.

That's pretty amazing IMO. Maybe, as often, I am wrong (again, not being sarcastic). You should try writing fugues. Your talent is extremely amazing (and, no, I'm not being sarcastic).

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.

Dear Developers!
I like Musescore so much! And i switched from finale to this program. But i need this feature so many times... Please put it in the filter that we can choose if we want a 1:1 copy or only copy the notes.

Anyway.... you did just an awesome work with Musescore!

I registered specifically just so I could comment on this.

The ability to copy and paste passages WITH time signatures (etc.) is VITALLY needed.

I have no idea why anyone would ever say "most of the time you do not want to copy that stuff". What? That is precisely backwards. I have a passage with the time signature changing in every other bar. If I copy-paste it somewhere, it makes NO SENSE if the time signatures are NOT also copied. Similarly, capturing anything with the MIDI input is non-sensical if you can not MOVE the notes afterwards.

MuseScore has a TON of different features -- but the whole point of a scorewriter is to be able to make a readable, useful score, efficiently. What's needed is the ability to input and edit notes, move them up/down/forward/backward. If there are repeats, repeat marks are needed. If there are "repeats" that have some slight variation, there's no other way except to have the almost same thing appear again on the sheet. I can not possibly understand how a computer program requires that you actually input the exact same information again. That is like making a text editor and saying "no, copy-pasting text is not implemented because usually you don't want to do that. Just type the same thing again if that's what you need". Anyone think that makes sense?

Take this as constructive criticism please. I'm a computer programmer myself (but no, I won't implement this myself because I have other things to work on). If this is something that's "incredibly complicated" to achieve, then the entire design of the program must be flawed. But what I'm mostly protesting here has nothing to do with programming, it has to do with statements like "no, you don't want to do that" and dismissing the whole thing for years. That's incredibly presumptuous, there are many, MANY people who want to do EXACTLY that.

Best regards, thanks and good luck to anyone working on the software.

"that stuff" means more than time signatures. it also includes things like tempo markings, rehearsal marks, voltas, etc. Especially consider copying form one staff to another, not from one measure to another. And indeed, when looked at in the big picture like that, you will see that indeed, most copy operations are not of the sort where system elements should be copied. Otherwise we'd have the initial tempo duplicated umpteen times through the score.

But it's probably true that time signature changes within a selection make sense to copy at least as often as not, and are thus probably different from almost every other type of marking discussed here. Time signature changes are inherently less common in the general world of music than tempo markings, rehearsal marks, etc, again supporting the idea that truly, "msot" of the time you don't want "that stuff" copied - really, it's time signatures primarily where you do, other "stuff" generally not. So it's entirely possible whatever scheme is devised, might default one way for time signature, another way for the other markings discussed here. Unfortunately, implementation-wise, copying the time signatures (and thus rewriting the measures) is somewhat more difficult than the rest, most of which is actually trivial.

Just for your information: in the application that I used before switching to Musescore, there was a "special paste" function where the user could tick boxes to tell what to copy.
- Notes and silences
- Symbols
- Keys
- Time signatures
- Key Signatures
- Text
- Chords
- Lyrics
- Voices (separated tickboxes for voices 1, 2, 3, 4, 5, 6, 7, 8)

In this way the responsibility is moved to the user.

Elements not mentioned in the list, e.g. loops were simply ignored.
The effort to insert loop instructions later is probably lower than to fix issues/misunderstanding.

Indeed, and we have View / Selection Filter that serves pretty much the same purpose - except "system"-level elements like key/time signatures, repeats and tempo texts, are not part of that. Only "normal" elements like staff text, chord symbols, lyrics, etc - and yes, also the ability to select by voice.

Assuming we do eventually implement the ability to copy system elements too, it seems quite natural we'd use that same Selection Filter to control it, probably defaulting to including time signatures but excluding the others.

I totally agree with Flying Roger. Let the user decide what they want copy and what not. I need so many times a 1:1 copy with ALL system elements. But that's not possible! And i can't understand why... And i see, i'm not the only one who can't understand this.

It's not currently possible, simply because none of the volunteers who work on the software have yet made it a priority. Too many more pressing things to work on. I have no doubt this will come in time, though. No one denies it would be a useful feature sometimes.

I hope volunteers, etc. work on this issue. It is a drag to re-input double bars, repeat bars, voltas, everything, etc. on the pasted version. All elements should be copied and pasted.

Additional information: I found that it copies everything on the same score, if you add another instrument or instruments, above or below. But it won't copy voltas, or barlines to measures forward. Sibelius does the same type copying and paste function too.

Well, no, it does not, not really. Those elements are system elements, so apply to all staves in a system anyhow.

Hmm, actually, that maybe is a good clue for implementation. Copying system text - including tempo, rehearsal marks, etc - would be trivial, really just a matter of removing the code that skips them (letting it instead be controlled by selection filter). And that doesn't even come up when adding a staff. But barlines, key signature, and time signatures do require some special handling when adding a staff, and some or most of that special handling might turn out to be something that could be leveraged here. The hardest part would remain time signatures, though, since that requires figuring out how to rewrite what's already there. I mean, we do have code for that too, it's what gets executed when you change time signatures, but figuring out exactly how to apply it is almost certainly the trickiest part of any of this. I still suspect it's not all that hard though.

If I may put my oar in here, I think the use case that Adrien identified in January 2017 (assembling a suite) is an important one, and perhaps its simplifying assumptions could make this a less complex need to address, viz.: appending a selection (or if simpler, appending an entire score), with all its elements, to the end of an existing score. I frequently need to do something similar: assemble a group of exercises or examples from existing scores in a new document. Always appending entire measures would seem to eliminate the complexities of merging material, copying partial measures, reconciling differences in system/staff structure, etc. It would be reasonable to require the source and target document structures to match. Perhaps a plug-in could suffice. Preserving all those voltas, barline types, system text, etc. (and especially the many lines that I must use in guitar notation) would save me a lot of time in these situations.

Yes, 1000 x yes.
Please do NOT make a philosophisical discussion on what is the sense to paste 3/4 measures into 4/4 ones. It just will never have a sense and that discussion is useless.
The "copy all" option only needs to work by INSERTING the copied measures where you paste. So in the example of the preexisting 4/4 measures, they will simply be pushed further in the score when you paste the 3/4 extract. If some of these 4/4 measures needed to be deleted, up to the user who is the only one to know which ones to delete them.
Finally, it certainly would make sense to limit that "copy all" functionality to whole measures only, and the paste action can happily be limited to work only between existing measures.
Conclusion : I would extend as much as possible the current selection filter, but would stay in the sphere of what makes sense to be pasted on existing measures without philosophical question, i.e. without time signature.
Next to that, there would be a "copy measures" option (contrary to the existing copy that could be called copy content), and that copy measure would be the Graal copy all, and pasting from that would Insert the copied measures.
To simplify we can also just say that items spanning copied measures and non copied ones, such as a line or hairpin that would start in the copied zone but end further would simply be ignored. Only items fully contained in copied zone would be copied.

I think the problem is what Marc Sabatella said before: "It's not currently possible, simply because none of the volunteers who work on the software have yet made it a priority." This thread is 3 years old now and if this feature don't get a priority soon, i think we can wait a long time again.

"Insert plus copy" is an entirely separate issue, not related at all to this thread, because it whatever use it has (saving the few seconds it takes to insert the measure manually) applies just as surely to simple cases that don't involve system elements, barline styles, changing key or time signatures, etc. Which is to say, a separate "insert plus copy" function should be available completely independent of a "copy including system elements" function. Either is useful to some degree without the other, having both is better still.

Most likely there is already an open suggestion for the "insert plus copy" function - I remember it coming up once or twice before. Feel free to add comments to that thread and link to this one.

The general objection that has been given for years to the "copy all" functionality is:

Difficult because what does it mean to paste some time signature(s) onto other time signature(s)...

And users would say:

Please find something because my piece includes 128 alternating 2/4 and 3/4 measures and I can't understand that a computer program isn't able to duplicate that.

The issue with time signature is that copying the time signature means really copying the measure structure itself rather than the measure content. So what we need is a new command copy structure. Now we are still left with the issue of the paste command: it is well nice to have been able to copy the structure, but how do we do to paste it, i.e. how do we solve this age-old question: pasting 3/4 measure onto 4/4 ones doesn't make sense? Well there I say: when one wants to copy the structure rather than (or in addition to) the content, the paste action should simply insert the copied measures instead of finding a meaning to something that hasn't.
That's all.

And by the way we can perfectly imagine 3 copy functionalities:
1 - the good old copy that we have always known - could be called copy content, paste behaviour after that copy is to overwrite/merge onto preexisting measures like today.
2 - a new copy structure command that makes paste inserting the structure, but does not copy the content
3 - a copy all that combines 1 + 2, with of course the same paste behaviour as 2: because the structure is copied, the paste will insert and not overwrite/merge
And that doesn't mean to have 3 copy commands per se. Just the current one where filter would include a flag structure to switch between 1 and 2 would do the job.

I think maybe you misunderstand the statements made. First, no one to my knowledge has ever "objected" to supporting this feature. People have pointed out that implementation is complicated because of time signatures, but that complication doesn't go away just because you are inserting new measures as well.

So again, yes, I get that a copy structure command is useful. I also get that an "insert and copy" command is useful. Again, either is potentially useful on its own, even better to have both. So really, there are four copy modes that are potentially useful - the four combinations of those two options. You left out insert and copy without structure.

This zombie thread does keep reviving! I don't think anybody believes there's a conspiracy. We all understand that it's a complex problem, and that somebody would need to step forward and take it on. These latest comments are trying to carve out a simpler sub-problem with a straightforward solution. Obviously, a comprehensive orthogonal design, addressing all aspects of copy/paste in all situations, would be lovely. But in the meantime, there are some common simpler use cases. In the current pandemic, many developers worldwide may have some spare time. If we can describe this more narrow need crisply enough, perhaps that will motivate somebody to address it.

that implementation is complicated because of time signatures, but that complication doesn't go away just because you are inserting new measures as well

In that case I may have explained my idea quite badly, because if you insert instead of overwrite, copying measures with time signature is already possible right now by using existing MuseScore commands, so I'm pretty sure it is simple to program a new command that would do that for us.
Please consider as an example the attached scores, before_copy and after_copy.
Goal is, starting from before_copy score, to copy measures 2 and 3 (in 2/4 & 3/4) between measures 4 and 5.
How to do it (well sorry Marc, of course you know how to do it otherwise who would know it, but I want to be crystal clear):
A-click on the first note of measure 5 (a D)
B-compute the "length" to insert: 1x2/4 + 1x3/4 = 5/4
C-compute the number of measure(s) to cover these 5/4 in the 5th measure time signature: 4/4 => we need 1,25 4/4 measure
D-truncate that number => 1
E-insert 1 (1 being the number computed in previous step) measure
F-measure 5 has now become measure 6
G-put a 4/4 time signature in that measure 6 (to protect it from the changes that we will do in the previous one(s))
H-go at beginning of inserted measure(s) (well here only one)
I-put time signatures one by one to prepare the measures identical to what we need to copy: 2/4 then 3/4
J-finally copy the content from measure 2 & 3 and paste it in the newly inserted measures
K-and, not applicable here, if the last part of the pasted fragment would be in 4/4, we need to remove the 4/4 time signature added at step G, we wouldn't need it anymore

And I know, truncating 1,25 4/4 measure and inserting 1 only works for some combination of time signatures to insert.
The correct algorithm is to round that number up, making it 2 (and not 1) measures to insert, and after putting the correct time signatures on the inserted measures to delete the remaining unused fragment.

Well, yes, it's the "put time signatures in one by one" that's the tricky part. You can do it, but it's one at a time 0 and in the process, you might end up with extra measures you need to delete, etc. There is code indeed to do all of these things, yes, accessing that code within the copy/paste functions is by no means trivial. If it were, it would be just as trivial to do it in place as to do it on freshly inserted measures.

What did the feature "Albums" do in combining files? Musescore doesn't do anymore. Too bad.
Hadley

The album feature solved one small part of the more general problem here - the specific case where you had multiple movements in separate files and then decided later to join them. It is a feature we'd definitely like to bring back, but hopefully in a better form, the original was extremely limited and buggy. Plus, one of the main reasons people resorted to albums was because MuseScore 2 was horrifically slow with large scores, but that's no longer an issue. Still, for assembling songbooks of hundreds of short songs that you really want to keep separate anyhow, it is missed indeed.

But even if the issue in this thread were addressed I don't think anyone would consider copy and paste a viable workaround for that case. Who wants to copy and paste hundreds of songs together? The album feature was better suited to that.

As for the technical details of how the album feature worked, it didn't have nearly the same complications because the scores were always appended end to end, no rewriting of existing measures or inserting anything in the middle. And yet, it was crazy full of limitations and bugs, which is why it was removed. Which doesn't really bode well for the much more complex problem being discussed here, but still, I think it's possible to define the behavior in a way that is implementable and maintainable without too much difficulty.

Oh definitely, and like I said, the album feature is something we'd want to bring back. But like I also said, copy and paste is really a poor substitute for album even if it worked, And also as I said, the need to put movements in separate files has all but disappeared in MuseScore 3, since it is very fast with large scores compared to MuseScore 2. So to me, none of this discussion of the album feature is really all that relevant here.

This was linked from my other post, so I'm going to post the same question here as the previous discussion does not appear to cover my specific case:

It would be really cool to have the option to copy line and page breaks from one part to another, or one MSCZ to another. There are a lot of times where I'm writing similar or near-identical parts and I always have to manually add the line and page breaks so that the parts look pretty.

This could be done similarly to other programs that have paste options like "Paste values only" / "Paste without formatting" where one could choose to paste with or without various kinds of formatting.

I am interested in being able to have the time signatures in the copy/paste

This has been an ongoing issue from the beginning. Taking time signatures with a passage when copy/pasting is MUST HAVE functionality.

I hoped so much that this feature was included in this version.

Hoping to see this is included soon. I've been getting into midi editing recently and this would be the most helpful thing in the world for Musescore. I know you guys are busy with Musescore 4 though, so best of luck.

Relates to #311174: [EPIC] UI/UX issues and suggestions

I support that!

Came up again in https://musescore.org/en/node/312218

In my view, an option to copy/paste time signatures and other elements along with notes is a MuseScore feature conspicuous by it's absence - please add it ASAP because, when working with changing time signatures, the current situation is a real workflow-killer. Thank you.

You say that much of the time you don't want "those other things" copied (without citing any evidence for your statement, by the way; makes me think that maybe it's just your opinion...?). You mention rehearsal marks in particular. The way Sibelius does it is to not copy the value of the rehearsal mark, but its existence in the score, also renaming subsequent rehearsal marks. I can think of other ways to keep copied rehearsal marks without duplicating names - append a character to each copied one, for example. I also don't agree that much of the time you wouldn't want time signatures or key signatures copied; not copying time signatures screws up the metrical organization of what you're copying and not copying key signatures removes or confuses the composer's tonal intent. I also disagree about not wanting to copy system text such as tempo markings. Is the copied music to get its tempo from wherever it happens to be pasted? If the copied music keeps its original tempo but the tempo marking is not shown (unless the tempo is the same, of course), that will confuse the composer when he/she hears the playback. If the tempo marking is copied, the composer is reminded about that and can keep it or remove it - i.e., it's helpful to show it in the copied music. From the user's point of view, a few more checkboxes can be added to the copy/paste filter to enable all these things to be selected or not; from the musescore developer's point of view, this might possibly entail a little bit of work to implement.... But in my opinion it would be very useful to be able to keep these system elements with the copied music. Thanks for your time.

The word "much" is subjective, so it's kind of true by default that "much" of the time one won't want the system elements copied. That doesn't mean it isn't also true that "much" of the time you do :-). But f you want a specific example where I think almost no one would, consider the very first measure, you have a time signature, key signature, and tempo marking. You want those copied every time you copy the first measure of a piece? Almost certainly not. Of course, we could special case that. Beyond that, it's subjective, sometimes one does, other times one doesn't, and it should be clear both are valuable use cases that should be supported. no one has ever argued otherwise - every single person involved in this discussion acknowledges that. So, don't worry that anyone thinks this wouldn't be a good feature to have some day. It's just a matter of finding someone who values it enough to take the time to do so.

For rehearsal marks, indeed, the way to go would be to resequence them, we have that code already so we could invoke that automatically.

In answer to your very good point, "you have a time signature, key signature, and tempo marking. You want those copied every time you copy the first measure of a piece? Almost certainly not.", if you're copying a passage - even the first measures - to a place where (some of) the system elements are different than in the passage being copied, then I think you would want those explicitly pasted in with the passage.

For example, suppose your piece starts out in D major, 4/4 time, quarter note = 120 and you want to copy the first few bars of that to a place in the piece where the key is C minor, 6/8 time and dotted-quarter note = 60. I'd think you would want to have the copied passage keep its original key signature, time signature (and bar lines) and tempo, wouldn't you? But if you're copying the passage to a location where the system elements are the same as the copied passage, then you would not need or want to explicitly paste in the redundant system elements along with the passage.

I find incredible the number of posts related to this request.
However, this is an opensource application so, as Marc Sabatella wrote, the function can only be implemented if one of the developers find it useful (for himself) or is kind enough to develop it (for the many users who requested it).

As long as this is not implemented, I simply use one of this workaround:
- export as non compressed music xml,
- locate the measures to copy and copy/paste in the xml file
- perform the copy/paste there, making sure that I copy the measures in each of the parts.

I tried this recently and... Yes, it works!
All elements are copied and Musescore is smart enough to renumber the measures when importing.

Of course, I need to reapply any formatting/style change as this information is Musescore specific and therefore not exported in music xml file. So, I would only use this method to copy significant parts of the score including time signature or key signature changes, preferably during the initial encoding, before making any cosmetic tuning.

I am sure that many developers will be horrified ;-)
Personally, I do not like to be stuck with a missing function or a bug.
Therefore, I am keen to find a workaround and have it available until the issue is solved.

Of course, another option is to export, perform the copy/paste in another application, and reimport.
But why use another software if your favourite is Musescore ? ;-)

Yes, there are indeed some special situations where you want the initial tempo etc copied, but presumably you also see that this is the exception. Imagine writing Twinkle Twinkle Little Star and copying the first four bars to the last four - the sort of mundane copying that happens all the time. But indeed, in the less common camse where the copy is meant to indicate a return to the original tempo etc, you would want them copied. That is why it is important to support both semantics.

So you are saying that you don't always want to copy all elements? MuseScore manages that already well. You can copy only chord symbols, or only a voice, ... No problem.
That's absolutely no reason to not copy when that's what the user is requesting.

You're preaching to the choir. There is no one in the entire history of the many threads on this subject who has ever even suggested this would not be a good feature to add someday. We're merely pointing out the existing behavior is also worth having. If someone were to implement the new features, it would be welcomed by everyone. It's just a question of someone finding the necessary motivation and time to get it done.

Being able to copy time signatures besides other stuff is a must-have, and not having that is a huge restriction. Nearly 100% of the time I want to copy something I also want to copy time signatures. I don't understand why this hasn't been implemented after years.
Let's say you have a (long) part with many time signature changes and you want to copy that part, now you have to manually do every time signature change before which is just unnecessary work, time and pain (even when only copying a few bars). I think it is really quite common that you want to copy parts exactly like they are ("with everything"). Obviously if the beginning of what you want to copy and the bar before where you want to paste it have the same time signature, then usually this time signature doesn't have to be shown again. This a very simple rule (no change to the bar before, then it doesn't have to be shown). I'd say when copying a full bar or more in more than 50% of the cases you want to copy the time signature too (going near 100% when copying 2, 3, ..., 8, ..., 16,... bars). Same with other parameters.
(For clefs: If copying from the same staff to the same staff, you almost every time want to copy the clef change too. Another simple rule.)
Having a selection filter, where you can choose what you want to copy - including time signature, clef etc- would be an easy way to address this (including the rules above, so that time signature is automatically selected when copying more than a bar). Even without these rules, being able to select these things for copy would be a massive gain. Also, it would be easier if you can select what you want to copy after you selected the passage, and don't have to do it before.

Many of the classical scores I am working with have constantly varying time signatures - there are passages where it changes every 1-2 measures for several pages. When I want to copy such a passage it's rather nightmarish to rebuild the measures because of the destruction caused.

I'll also note that elements that are marked invisible (e.g. rests in some secondary voices) are made visible when copying.

@bebobebo:
Unfortunately, this is a long outstanding issue that no developper had been willing to pick up so far.
I shared a workaround in my post (Flying Roger • Nov 14, 2020 - 14:36).
It involves editing an xml file, but it worked for me.
I prefer this way rather than exporting to another application, perform the copy/paste and import all back.

I am always happy about a new release. Then I always look first whether this feature was built in. Almost like a child opening the presents at Christmas :)

Could we have that from Google Summer of Code 2021?

Excellent idea, I'll suggest it! Normally I'd say it's too small for GSoC, but it's a scaled-down GSoC this year anyhow. Might still be too small on its own, but could be combined with something else.

Hi guys. At the beginning I thought that I am not able to copy time signatures and repetitions. But then I came to the thread here. This is a must have feature. If you write contemporary music and have a different time signature in every bar, then copy that part again later, you will go crazy. Because you have to add everything manually. Pleeeeease add this feauture.

I'm desperate for this. I often jump around between different time signatures, but it becomes very messy and confusing when I want to re-use a section because I have to go through all the new bars and add the time signatures back in. PLEASE make it possible to copy and paste all elements of a bar/phrase (but particularly time signatures!).

Copy/paste definitely needs improving in Musescore - I noticed recently that you can't copy and paste passages of music with anchored lines easily because the anchors get replaced but it just discards the lines/slurs.

@Rudiemmentaler @citizensheep

Well said.  +1!

I'd agree it is important to be able to copy & paste a range selection that includes time signatures and have the time signatures copied into the new pasted section, but it is a tricky one as it can only really work sensibly if a) the copied range includes ALL staves and a range of complete measures, and that you paste it (on to the first staff) at the beginning of a measure. Even then there are complications if you paste onto a block of existing music that's longer than the range being pasted. E.g. if you select a range that's one measure of 3/4 (all staves) and paste it onto an existing 4/4 measure that has notes in it, then what should happen - create a 1/4 measure to fill the gap? Rewrite all the remaining music into 3/4? Actually being able to paste in "insert" mode (shifting all existing measures right) would be pretty handy too.
I think the basic logic to support this shouldn't be too difficult though doing it efficiently might be an issue if it's an extended selection from a large score with a large number of time signatures and pasted near the beginning.

Hi Dylan,
I think that everybody is well aware that copying absolutely everything, meaning also the measure "structure" makes it incredibly complex to paste "into" something existing.
For example, what sense could be given to pasting a bunch of 3/4 2/4 measures into a 6/8 passage??
HOWEVER... 99% of the requests here would be perfectly satisfied with a very simple functionality allowing to insert the fully copied measures!

A "paste insert" function would definitely be useful for clipboard selections that were a range of whole measures across all staves. In principle it could be used for some other cases, but getting that much supported would be a good start. Unfortunately I can't see something like that being added until after the initial MU4 release (at which point I'd be more than happy to have a go at it).

The measures to be copied don't need to be complete,as there is no problem with leaving rests at the end. If you paste a 3/4 measure into 4/4 then you're just leaving a rest at the end.

The biggest problem with pasting without time-signature changes - aside from the work of manually reinserting them - is the broken and misshapen tuplets, slurs, lines and other decorations. As the shape of a slur cannot currently be copied there can be dozens, if not hundreds of elements in a copied section that may need to be manually re-built. Currently, it can be faster to copy measures one at a time than to do the after-surgery on a sequence of measures.

I'm not sure I agree that most requests would be satisfied with an insert mode. In fact for me that would pretty rarely be the case - I'm usually copying between sections o a piece I've already set up. Only the special case of time signature changes might this seem like enough, but all the other things - key signature changes, clef changes, barlines, tempo markings etc - those all would pretty much need to work with an existing destination to be very useful.

On the other hand, I also don't think it's particularly difficult to implement any of this except the time signature aspect - and even that isn't actually likely to be all that involved, since we already have utility functions to rewrite measures.

It's really just a matter of someone actually taking the time to do it than any particular technical hurdles. So I'd much rather see it done well & completely.

I strongly disagree Marc.
There are tons of comments here above for which a copy all / insert copied measures would do exactly what is requested.
That feature is so simple (the most brave users are actually trying to diy by copy/paste in XML) and so basic in any software since the end of the 70's that saying "So I'd much rather see it done well & completely." feels insulting for the users requesting it.

Which examples do you mean? I don't see very many examples at all, just reading between the lines based on one's own experience and expectation.

For me personally, I would say an insert feature would be useful at best 20% of the time I might want to copy all elements. Considering that the work involved is practically identical, why advocate blocking out a significant number of use cases? It makes no sense. it's no hard to solve the more generally, so I continue to maintain that's what should be done. I fail to see how it insults anyone to say the solution should solve everyone's problems, not just their own specific use case. On the contrary, it's saying that use cases other than your own are not important enough to solve despite being trivially easy that is insulting.

Marc Sabatella wrote> I'm not sure I agree that most requests would be satisfied with an insert mode.

For the record, I'd be THRILLED with the addition of an insert Paste!! That would save me LOTS of time when I need to duplicate a highly structured section. And that need arises quite frequently in my workflow when creating compositions, educational materials and arrangements.

And to your point, I think most people most of the time would want to "see it done well & completely."

scorster

Over a period of many years requests like the following have appeared in this thread:

@fifivi
Being able to copy time signatures besides other stuff is a must-have, and not having that is a huge restriction.

@ bebobebo • Jan 23, 2021 - 11:17
Many of the classical scores I am working with have constantly varying time signatures - there are passages where it changes every 1-2 measures for several pages. When I want to copy such a passage it's rather nightmarish to rebuild the measures because of the destruction caused.
I'll also note that elements that are marked invisible (e.g. rests in some secondary voices) are made visible when copying.

@ This is a must have feature. If you write contemporary music and have a different time signature in every bar, then copy that part again later, you will go crazy. Because you have to add everything manually.

This a summary of the subsequent discussion:

@Adrien de Croy
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.

@Pedro16797
[Paraphrased: Leaving copy-paste limitied to its present behavior shouldn’t be considered adequate just] because it's [what] people want … "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".

@Marc Sabatella
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.

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

@manfred-manfred
The ability to copy and paste passages WITH time signatures (etc.) is VITALLY needed. I have no idea why anyone would ever say "most of the time you do not want to copy that stuff" … That is like making a text editor and saying "no, copy-pasting text is not implemented because usually you don't want to do that.

@Flying Roger • Mar 13, 2020 - 15:28
In reply to "that stuff" means more than… by Marc Sabatella

Just for your information: in the application that I used before switching to Musescore, there was a "special paste" function where the user could tick boxes to tell what to copy.
- Notes and silences
- Symbols
- Keys
- Time signatures
- Key Signatures
- Text
- Chords
- Lyrics
- Voices (separated tickboxes for voices 1, 2, 3, 4, 5, 6, 7, 8)
In this way the responsibility is moved to the user.

@Marc Sabatella
The hardest part would remain time signatures, though, since that requires figuring out how to rewrite what's already there.

@frfanchaThe "copy all" option only needs to work by INSERTING the copied measures where you paste. It certainly would make sense to limit that "copy all" functionality to whole measures only, and the paste action can happily be limited to work only between existing measures. Items spanning copied measures and non copied ones, such as a line or hairpin that would start in the copied zone but end further would simply be ignore.

The issue with time signature is that copying the time signature means really copying the measure structure itself rather than the measure content. So what we need is a new command copy structure. Now we are still left with the issue of the paste command: it is well nice to have been able to copy the structure, but how do we do to paste it, i.e. how do we solve this age-old question: pasting 3/4 measure onto 4/4 ones doesn't make sense? Well there I say: when one wants to copy the structure rather than (or in addition to) the content, the paste action should simply insert the copied measures instead of finding a meaning to something that hasn't.
That's all.

@Marc Sabatella
no one to my knowledge has ever "objected" to supporting this feature.

@spinality
Always appending [or inserting] entire measures would seem to eliminate the complexities of merging material, copying partial measures, reconciling differences in system/staff structure, etc. Preserving all those voltas, barline types, system text, etc. (and especially the many lines that I must use in guitar notation) would save me a lot of time

@tmclint I don't agree that much of the time you wouldn't want time signatures or key signatures copied; not copying time signatures screws up the metrical organization of what you're copying and not copying key signatures removes or confuses the composer's tonal intent.

@Marc Sabatella
There is no one in the entire history of the many threads on this subject who has ever even suggested this would not be a good feature to add someday. We're merely pointing out the existing behavior is also worth having.

@Marc Sabatella
a separate "insert plus copy" function should be available completely independent of a "copy including system elements" function. Either is useful to some degree without the other, having both is better still.

@frfancha
In reply to I'd agree it is important to… by Dylan Nicholson1

I think that everybody is well aware that copying absolutely everything, meaning also the measure "structure" makes it incredibly complex to paste "into" something existing.

@Dylan Nicholson1
A "paste insert" function would definitely be useful for clipboard selections that were a range of whole measures across all staves.

@Marc Sabatella
I'm not sure I agree that most requests would be satisfied with an insert mode.

I think most people would be happy with just a 1:1 copy with all the elements and time signatures, etc.

I can't I agree with Marc that it's "no harder" to support the general case. Paste-insert when the range is whole measures across all staves and the target is the start of a measure in staff 1 is relatively trivial - I could probably have it working in an hour. A general paste-preserving-time- signatures-as-best-as- possible-where-it- makes-sense command would have a lot more special cases to deal with and likely to cause unexpected behavior in corner cases (e.g. rewriting existing material that you wanted left in the current time signature).
Preserving slur curvature (and grip adjustments for lines in general) is something I've already fixed in MU4 but I don't believe it's been merged.

The part I said was no harder is everything except time signatures. The work of preserving tempo changes, voltas, barlines, key changes, etc - all that work needs to be done anyhow to support the proposed insert mode. So it's trivial to also support it in a normal paste. But indeed, doing this for the time signature changes as well is a little more work. Not a lot, once you really inside how the paste code and how the time signature rewrite code works. But maybe an additional 30-40 lines of code, sure. To me, absolutely positively worth it. And in any case, definitely the design for how the paste & insert feature would work should account now for how it would also work without the insert, so we don't invent commands dialogs and implementing code that needs to be redone because we didn't consider how to support the more general case right from the beginning. It's a mistake we've made over and over in the past and I don't want to see us make that mistake again on something as important as this.

An additional 30-40 lines of code that could take several days to get right easily!
The copy/paste code in general is pretty messy, I have made some progress towards cleaning it up, but inevitably you introduce some unexpected changes. The functions for single element selections, list selections and range selections are all quite different (and in fact copying single time/key signatures/barlines is already supported - but not voltas and quite a lot of other lines oddly). One of the changes I'd started on is to ensure pasting list selections support all elements, in which case "single element" paste need not be a special case, it's just pasting a 1-element list. But I quickly started running into weird issues with the way, for instance, the current paste works for Figured bass (which I never fully, ahem, figured out).
New code to support "inserting" whole measures with all associated elements probably wouldn't involve changing much of the existing logic, though I'd have to dig deeper to determine that for certain.
BTW I don't really understand why key signatures & tempo changes (and markers too, I notice) are not copied currently - they're actually pretty simple to support. Barlines/voltas I can understand would introduce some complications - in fact arguably even when inserting whole measures they might not behave as expected.
Also we'd have to expand the selection filter to include all element types, and decide whether it really made sense for all element types to be selected by default.
At any rate it's definitely an area I'm keen to get back into, but the MU4 codebase really has to settle down a lot first, it has rather more serious issues that need sorting out before I can get back to this.

BTW, the work I'd done on allowing copying all lines, including voltas, generic system text lines (which oddly don't exist in the MU4 palette), etc. etc. is now merged to MU4, but at this stage it only covers single element selection. Note that includes copying the "shape"/extent of slurs etc. as far as is possible (whereas 3.6 ignores everything about a slur you've copied and just adds a generic slur between the note you pasted onto and its subsequent note). List & range selection are different beasts entirely.

I believe system text lines had been implemented in 3.x after if got split off of master

Will this sort of shape/extent preservation code be invoked in general re-layouts e.g. when stretching/contracting measures? I notice that many of the breakages of slurs, lines and some other elements seen in copying also occur when the layout changes.

I had a transcription I was working on this week where there was a measure or two hanging over onto the next page. My attempts to shrink the page ended up with very ugly inverted slurs and all the diagonal lines indicating voice or finger movements between stave had reverted to horizontal. This is not a one-off experience.

Why key signatures, barlines, etc are not currently copied - you're right it's simple to do; it's just that in many cases you don't want it. Before the selection filter existed, we had to guess what people might want copied or not, and it was decided the cases where you didn't want these exceeded those where you did, based on just a few forum discussions but no real data. Now, with the selection filter, there's no excuse for this being hard-coded like that. But indeed, it would be important to consider what the defaults are. This is why I keep saying, please, let's consider designs that are general enough to handle not just the case of insert-copy but really think through the whole problem.

I guess some people are focused primarily on the time signature aspect of this, but that is only one part of the puzzle - and realistically the one that comes up for the fewest number of people, and is also the hardest to solve. When it comes up in any given score, it comes up often, and it's a royal pain to work around, so I can see why there is such vocal support for anything that would solve just that portion of the problem even if it didn't address the more general cases at all. But the vast majority of scores don't contain time signature changes at all, and yet double barlines, voltas, tempo markings, and key changes are all over the place in most music. Being able to copy these elements is just as important to a great number of people who don't create mixed-meter music, and doing so in-place is far more natural to how I - and, I think, most people dealing with this type of music - would expect it to work.

For barlines, of course, it only makes sense if the measure structures match, but aside from that it shouldn't be especially difficult. The main complication is the extent to which barlines are generated automatically and how links are handled, but again, this needs to be solved for the insert case as well.

For what it's worth, I almost never want to paste in-place, unless combining voices. I otherwise always insert blank measures, place key signature and time signature at the end (to return to the original in case changed via the paste), and then paste new material over the new measures. This simulates a paste-insert. I then reformat and trim. Otherwise, there are too many situations where strange artifacts might creep in. This is analogous to how I paste with non-musical documents: I paste into an inserted blank area, and then integrate the material. Perhaps my use cases are abnormal but this is what seems most reliable and intuitive.

The change re slur shape shouldn't impact anything other than copy & paste, but I did put in a bunch of logic to ensure the shape info is only copied if it makes sense - based on the stem direction of the source vs destination notes. Otherwise as you say you can get some very ugly slurs (which can still happen now if you flip stems, even if automatically when transposing).

I'm more than happy to do a design session on what's most needed and what we can and can't realistically improve for MU4. I wrote up some notes on supporting all element types for list selection but I think for range selection we'd definitely need to modify/ expand the selection filter (which shouldn't be hard at all).
BTW I don't necessary agree you'd never want to copy rehearsal marks, but I'd expect them to be resequenced - i.e. you're copying the fact that you want a rehearsal mark at this point, not which exactly mark it is. But interestingly that's not what happens now when you copy & paste a single rehearsal mark. Actually I would think default behaviour of the text any rehearsal mark is as per measure numbers, i.e. "show the next logical rehearsal mark", obviously with the ability to override as needed.

Good point regarding copy with resequence for rehearsal marks! it's kind of like how we transposed notes & chord symbols on paste.

I've been following this thread and I'm thrilled that this subject is receiving so much attention. For me, this is the last major missing feature between musescore and the major commercial scoring products like Finale and Sibelius. I eagerly look forward to having time signatures copied and pasted along with the music!

Oh no! I'm working on a huge file (a hymnal with more than 600 hymns) I'm almost done, but it got sluggish and I just needed to add some system text, so I had the brilliant idea to break the file in two parts and join everything back later. I worked all day yesterday on Hymns 1-320 and the same today on 321-636.
Now I found out that I can't copy/paste system text! I'm so sad right now...
I don't even need to change mesures, clefs or anything like that, just paste lots of text indications.
Any workaround?

Other than using a text editor? You can copy system elements individually, though I don't know about between scores, and not very practical if you have 100s of them.
I guess the question is why do you need it to be one mscz file?

For distribution purposes, I need one PDF only for each instrumental part.
So... two full days of work wasted, it didn't cross my mind such a limitation existed. I hope someday a new feature is added to solve this.
(And before anyone says it's easier to join the PDFs later, sadly, in this project that won't be practical, but thanks anyway)

I found half a workaround: Exporting the file as MusicXML 'system text' gets converted into 'staff text' so it can then be copied back as a placeholder, marking where to write again the 'system text' that's needed.
It could be a little help for this situation only.

Joining PDFs is pretty straightforward though?

More a bug or the MusicXML export, or maybe shortcoming of the MusicXML format itself though. And won't help in all other cases this issue ís about

For joining PDFs I use (an older version of) PDFSaM and am quite happy with it.

Yes I know, thanks! (Thats why I tried to preempt that question). I do join PDFs quite a lot and it's easy... Just not helpful in this case.

I'm checking the list of issues and this one seems to be the 3rd as per number of replies!

https://musescore.org/en/project/issues/musescore?text=&tags=&status=10…

I have to say I'm baffled as to how joining two mscx's to create a single PDF is fine but joining two PDFs to create the same result isn't...
(and note I'm not pretending for a second this is anything more than a workaround, but as it is, from what I've seen with v4.0 so far, I'd be very hesitant about trying to edit an 600 page score file!).

Okay, okay, lots of explanations that I'm trying to avoid, but I might as well procrastinate a couple of minutes.

I need a master-file with the whole project, wich is 636 SATB hymns. (Just the notes, no lyrics)
Each one has a title, and four elements of system text: A symbol indicating where to stop if you use the first measures as introduction; another symbol close to the end if you decide to use the last measures as introduction; the word "Chorus" half the way in, in most of the cases; and a final indication for the number of repeats.

I'm in Brazil, the idea is to offer a way to use this material in poor little chuches with just a few random instruments in any possible combination without the need to print anything, I already did this two years ago with a selection of 83 hymns and the result was excellent.

So, just as marching bands of old used that little lyre on top of the instruments with a mini-score, I'm exporting this in a landscape ratio of 16x9 so the file can be opened on any cellphone screen still with a decent size and presenting all the information needed to play without having to turn pages (That's why lyrics are not included) Also, I make another PDF for printing with 3 hymns per page, but the main idea is to play from the cellphone screen.

Once the master-file is ready I hide 3 voices and export 1 and get 4 files that can be used by instruments in C, then I also export Soprano and Alto one octave higher, tenor in the other clef and at least the 3 upper voices for C clef for viola players, so, I get around 10 differnt files in 16x9 format and another 10 in A4 (which is the standard here unlike letter) Then I do almost the same in Bb, Eb, and F, (except the part of C clef)

As there are no proof-readers involved the project is bound to have errors and will need future corrections, (This is also important) And finally, a musician should need to have on his/her cellphone only two or three files, no more. So any day, depending on who else showed up, it's just a matter of choosing: Do I want to play soprano today? alto? soprano one octave higher? etc, and then opening the PDF will have any number requested just there, no need to close the file and open "Volume 2" or anything like that.

Well I hope the explanation of the project was clear, and that is evident now why I prefer to do all the work again but keep a single master-file which I can also edit and correct in the future. Thanks for the interest, I hope this inspires other people to do similar projects.

Sounds complicated. But I actually think being able to take 2 mscx files and combine them into a single one should be relatively straightforward with a bit of scripting - providing you can safely assume all the style info etc. is the same between them. If it's just a one-off and there's only 4 staves you could even do it with a text editor (ideally one that has smart navigation/selection for XML files), just by copying all <Measure> elements from under each <Staff> element in file 2 into the corresponding element in file 1.

I believe such a script - or a couple different version even - already exists. Could be good to ask on the Discord chat.

To me, the main advantage of being able to glue together two MSCX files rather than two PDF files is actually quite simple to explain: the ability to put multiple songs on one page. Or at least, to start the second mid-page and have it flow naturally from there.

But that's actually a different feature. Onbe shouldn't need to resort to copying and pasting to do this - we simply need to bring back the album feature. Removal of that was shortsighted, not taking advantage of the world done last year to reimplement an improved version is even worse. Two major mistakes, I think we owe it to the community not to release MuseScore 4 without that.

But also, sure, along the way, the copy/paste thing that is actually the subject here :-). but that could wait until post-4.0 IMHO, since it would not involve any changes to file format etc.

Hi,
I see this discussion has been going on since 2017, though nothing on the topic since this past August. So I'm chiming in here.

I want to add my wish for this feature. I was just working on a simple guitar/tab score with time signature changes and was frustrated by the time signature not being copied. Yes, I know that's a very simple case compared to complicated multi-staff scores.

I disagree that Copy/Insert would only be useful a small fraction of the time. And I read that I'm not alone in that disagreement. I and the other people would be thrilled to have it. If Copy/Paste into existing measures is hard, but Copy/Insert is not, (as has been stated), then why not do the simple thing that will help us? I know that may lead to other requests or complaints that it's not sufficient, but isn't it better than having nothing at all? To me, it is.

Thanks,
Ross

I hope that this feature will be included in the new version. Would be great!

FWIW, I think everybody agrees this (copy/insert) would be a good idea. It’s a question of somebody deciding to take the project on. Open source development involves a different kind of goal setting and planning vs. the way a commercial product evolves. There is no full-time team working continuously against a priority-ordered feature list. I, too, hope somebody decides to tackle this one soon; but alas it won’t be me.

And to be clear: while I did express some reservations with doing half-jobs, this isn't meant to say we couldn't do the copy/insert first. Just that in so doing, we should first think through and design how the dialog & controls would work for the more general case too, so we don't end up with either two incompatible interfaces for this or else needing to rip out the first nd replace it with a new one, rewrite the documentation, etc. I'd like us to think the whole problem through from a UI design perspective, then actually solve the easy part in a way that will allow the harder part to be done later without requiring throwing away the first part and its documentation and accumulated user experience.

Another situation where one would likely want rehearsal marks and other structural elements cut/copied is when using Paste Half Duration or Paste Double Duration to change a piece from cut time to 4/4 or vice versa.

One aspect of the current (3.6.2) behavior related to this issue does seem to be a bug: When you Select All, MuseScore does not highlight time signatures, repeats, and other elements that are not part of the selection. But it misleadingly does highlight rehearsal marks and tempo indicators, even though these things are also not included in the selection (and indeed are left behind if you then Cut).

If developers think this is a separate enough issue to warrant its own bug report, I'll file one for it.

It's an inconsistency indeed. But, there are multiple levels of what it could mean for something to be part of a selection. Whether it gets copied to the clipboard, whether it's affected by the Delete command, whether it is active when applying properties via the Inspector, whether it is active when applying keyboard commands like "V" to toggle visibility, etc. These aren't necessarily all the same. And while one hand it might seem like they "should" be, we generally value doing what the user most often expects in any given situation over consistency just for the sake of consistency.

None of which is to say the current behavior for regarding any of those specific actions on any of those specific element types is actually optimum. Just that the inconsistency isn't an issue in itself.

Need this feature desperately. This is one of the few features that makes Musescore seem like an amateur version of commercial products like Finale and Sibelius. Basic stuff like this really needs to be added. Hoping for that in MS4.

In Microsoft Word you can copy/paste or copy/paste+shift which removes formatting. In sibelius, you select a passage and if you want to add time signatures/barlines you click a barline too. The selection changes color and now you know that you are literally copying all information.

Just adding to the choir. Please prioritize this one.

@Marc Sabatella: "we generally value doing what the user most often expects in any given situation over consistency just for the sake of consistency." Fair. Still, I was more speaking from an expectation standpoint than a consistency-for-the-sake-of-consistency one. That is, as a user, what I expect is for the highlighting of a selection to tell me what will be affected by the next action. What's a situation where a user would expect something other than this?

My point is, different commands affect different elements elven give the same selection, because certain element types are not affected by certain commands. So unless we know which command the user will invoke next, we can’t know what to highlight. It’s certainly possible we could tweak this one way or another, but that’s really a separate discussion best suited for the forum.

Very much missing the ability to copy and paste passages including alternating time signatures. Lots and lots of time re-writing the same time signature change over and over.

This topic will be turning 6 years old soon. It's arguably the software's worst problem. Could the implementation work be crowdfunded or something?

I really hope they implement this soon. It works in all other music notation program. If you have bars with different time signatures, you're getting crazy... But maybe is crowdfunding a solution.

Version 4 is out and we still can't copy/paste time signatures. It's like having a wordprocessor that eliminates all the formatting with each copy and paste of a text. But we have nice soundfonts and a Hub now...

I agree I cannot understand why they don't implement this

Really need this as well! :) I'd definitely chip in on a crowd funding of "Paste" vs "Paste without formatting" as well!

Just a thought - would a good solution here be an entirely separate "measure copy/select" tool? This tool would ignore whatever you have in your selection filter, and just copies absolutely everything. In this mode, you can also only select whole measures. That could probably help with the implementation as well, as copying the measure properties gets icky if you've selected only parts of a measure.

I'm a programmer, lmk if you would like a PR on this!

That's definitely an interesting idea! In general though, new functionality like this would need to go through a design stage with input from the official design team on how it should work, before implementation can be considered. I'd recommend heading to Discord and/or GitHub to start a discussion on this topic.

Is it still not possible to copy/paste rehearsal marks, repeat sign, etc?
Musescore 4 crashed really hard today and I had to rearrange a giant project now I will have to reinsert all rehearsal marks and repeat signs, it will be so time consuming. That's sad.

Chiming in to say I also support this feature. I'm currently transcribing a song where the best way to notate what's happening is alternating bars of 6/4 and 7/4. I could notate it in 13/4 but that would make it much much more difficult to read.

This issue tracker has been discontinued so better report it on GitHub

+1

Hi, I just wanted to ask if you have in mind to implement a 1:1 copy? Or is there now a new method to copy everything including system elements? Thank you.

Again: This issue tracker has been discontinued so better report it on GitHub

I couldn't find anything on GitHub for this... Anyone aware of a reference on GitHub for this ?

There is https://github.com/musescore/MuseScore/issues/15590, dealing with Time & key signatures, repeats, and tempo markings

I saw that one. I didn't mention the barlines. I'm going to add that to that issue.