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

• Jan 26, 2017 - 23:59
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Status
active
Regression
No
Workaround
No
Project

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.


Comments

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.

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

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.

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.

In reply to 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.

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.

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

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.

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.

In reply to by spinality

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.

In reply to by Marc Sabatella

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.

In reply to by Marc Sabatella

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.

In reply to by Marc Sabatella

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

Attachment Size
before_copy.mscz 6.38 KB
after_copy.mscz 7.02 KB

In reply to by frfancha

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.

In reply to by frfancha

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.

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.

One key aspect that I wanted was for new movements to be able to start on the same page (layout) as the end of a previous one. Many many parts for things like symphonies are laid out like this. Having large blank spaces on a page because the prior movt had only 2 staves on a page and you couldn't resume the next movt on the same page is problematic for proper setting of page turns etc. So cut and paste was the only solution to this where you could fully specify the layout of the collection of movements in the parts and optimise page turns and paper usage.

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.