Lines can't be pasted

I've reproduced the same problem. It's particularly painful in my case as I start with a line, and I add "hooks" to both ends. No big deal to do that once, then copy the line, and drag the ends as needed. But because the adjusted line (with the hooks) cannot be copied, every time I need a line (which is often in my genre), I need to drag a new line, then open the properties and add the hooks.

I looked into adding a special version of the Line into the Line palette; that is, one with my customizations, but no luck on that front.

If anyone knows a workaround to this problem, please post.

Thanks

Smarmit, if you want to add a custom line with hooks to the palette you can although it is a little technical and not really intended for casual users. It requires basic understanding of XML structure and use of a decent text editor. I give the instructions only because you asked for a workaround; not because I expect most users would actually want to do this.

1. Quit MuseScore
2. Search for the file mscore-palette.xml (on my computer it is C:\Documents and Settings\David Bolton\Local Settings\Application Data\MusE\MuseScore\mscore-palette.xml)
3. If the mscore-palette.xml file doesn't exist then it means you have never edited the palette. (Look how to do this on the forums, then repeat from step 1 above)
4. Open mscore-palette.xml using a decent text editor (Windows Notepad does not always read line breaks correctly so you will need a text editor such as "Notepad++" or one of many others)
5. Search for the cell called "line"
6. Look for the first </cell> after the line you found in step 5 above
7. Paste the following text after the line you found in step 6 above:
   

       <Cell name="Hooked Line">
         <TextLine>
           <beginHookHeight>1.5</beginHookHeight>
           <endHookHeight>1.5</endHookHeight>
           <lineWidth>0.15</lineWidth>
           <lineStyle>1</lineStyle>
           <lineColor r="0" g="0" b="0"/>
           <beginTextPlace>left</beginTextPlace>
           <continueTextPlace>left</continueTextPlace>
           <diagonal>1</diagonal>
           <length>291.685</length>
           </TextLine>
         </Cell>
   

8. Change any of the values listed above as desired
9. Restart MuseScore

Thank you very much Mr. Bolton. I will be doing this tonight. I'm a software engineer so I'm comfortable giving this a go.
Again, thank you! Another reason I try to use community software.

Just a follow up to say that this workaround worked perfectly. Thank you again!

For anyone on Mac, your mscore-palette.xml file is (as of 0.95) in ~/Library/Application Support/MuseScore/. Also, if you wanted this "hooked line" to remain horizontal even if you stretch the ends, then set element to '0' instead of '1'. Looks like MuseScore just removes it if set to '0' after a save anyway, so I suppose you could just leave it off altogether.

This is not intended to work, so it's not a bug :-)

but it would be great to be able to do it ^^

with the last nightly builds I was able to copy trill lines (as the one that are at the same place than hairpins) but not hairpins....

This was fixed and *did* work until recently. Apparently only hairpins are affected>

Fixed by lasconic in https://github.com/musescore/MuseScore/commit/b766748106f2d3c48d4ec7acf…

I can still reproduce.

1. Open attached score (produced in 1.3).
2. Click on Text Line.
3. 'Edit'>'Copy'.
4. Click on first note of Electric Guitar 1.
5. 'Edit'>'Paste'.

Result: The Text Line isn't pasted.

Using MuseScore 2.0 Nightly Build (b6480b7) - Mac 10.7.5.

The part that was fixed by lasconic was copy/paste of *regions containing hairpins*. I still don't think copy of individual hairpins was ever intended to work, although it makes a fine feature request. We allow individual element pasting currently for a very limited number of element types - articulations, lyrics, chord symbols are about it I think.

In case anyone else stumbles upon this, editing mscore-pallete.xml as in David's reply doesn't seem to work in 2.0 beta (for me at least)

Instead, create the line style in the score, then Ctrl+Shift+Drag it into the palette as per http://musescore.org/node/14974

Then right-click the cell, select properties and give it a name.

May need to restart Musescore for the image of the line to show up in the cell.

Also see http://musescore.org/it/node/46471

You can achieve the same result by duplication, ie: Press continuously Ctrl + Shift, then drag an element onto the desired note or measure.
More details here: #91651: Duplicating of elements with Ctrl + Shift + drag onto a score

So, issue rather closed (it's not by the usual process Copy-Past) ?
Or closed therefore by an other way? (faster!)

Came up again in #295069: Unsynced text content in lines beetween score and parts

I'm hoping to look at this for MU4.
The key problem I'd like to solve is that when you select a line that spans a certain duration (e.g. from the start of 1 4/4 measure to the start of the next), if you cut/copy it to the clipboard, you should then be able to paste it elsewhere into the score and a line with the same "spanning duration" would be created, with the begin and end points attached to the relevant time points. Essentially, the behaviour will be exactly the same as it is now when you paste a range that includes all elements that the line spans, except that only the line itself is pasted, without the notes/rests etc.
Note that CTRL+SHIFT+drag doesn't support this currently if the line spans multiple measures - whether I fix that too would depend on the degree to which the same code is involved.

NB my hope is to fix this for slurs too, but they seem to have some slightly different behaviour, e.g. they disappear when you paste over their final anchor position. Can't really see why they should be different though, given the way they're stored internally.

Interestingly hairpin elements seem to copy & paste just fine everywhere, and I can't see any reason why slurs/pedal markets/other types of lines etc. should be treated differently.

BTW from my initial investigations this is almost trivially easy to fix - it's just the way the code is written it treats all "Spanner" elements (hairpins, slurs, text lines etc. etc.) differently, even though the key functionality is the same for all of them. It seems the code can actually be simplified quite a lot while improving the outcome, which is a win-win, but testing it will take a while, all that special-case logic may well have been put there for a reason.

Trivial was a slight exaggeration, but basically by removing a lot of the special case checks for what could be pasted where and just treating all spanners the same, I've now managed to allow all spanning elements (slurs, hairpins, pedal markings, various other lines etc. etc) to be copied/cut and pasted almost anywhere.
The only slightly odd case is the ability to paste a slur onto a rest...for now I've disallowed but we could just allow it (it seems to work fine!). There are some other differences - e.g. currently if you cut/copy a slur that spans more than two notes and paste it onto another note, it's added just a slur from that note to the next. With my new changes the slur is always pasted with the original length - even if it that would mean it would extend past any notes and on to a rest instead. Given MuseScore normally doesn't allow creation of slurs that "attach" to where there are no notes, it might need some extra consideration - but basically we can reuse the same logic that's used when adding a slur to a range, where the slur always ends on the final note.
But note again that all this didn't really require writing any new code at all, just cleaning up/simplifying existing code, which is a good thing!

The other thing I'd like to change though is the ability to paste a spanner on to a range selection - my preferred behaviour would be for this behave exactly as though you pasted it onto the first chord/rest of the range, unless it's a slur, in which case, starting at the first note in the range, but truncated according to how far through the range that note was (so if you select a slur that spans from the first beat of a 4/4 measure to the last, copy it, then paste it onto a selected measure with a 1/4 note rest at the beginning, it's added across the remaining 3 notes). Will look at it tomorrow.

Still actually working on this as I keep finding exceptions/special case behaviour.
One is regarding slurs where the bezier points have been adjusted - once I'd added in the necessary code to ensure bezier control point information is actually preserved when pasting from the clipboard I noticed that it caused some very odd looking slurs when the stem directions didn't match the notes that the slur was originally attached to, so I added in some logic to ignore the control point information in that case.
But a bigger problem is that the MU4 inspector isn't fully implemented yet, meaning I can't test all the different properties of different types of lines.

Also I found CTRL+SHIFT+drag isn't working at all in MU4, might fix that separately.

FWIW, some of the special cases probably predate the Selection Filter and may have been an attempt to second-guess the most likely desired result. Now that it's generally possible to easily exclude individual line types, I'm inclined to think all lines except voltas and system lines should probably copy by default. Voltas and system lines ultimately should be possible to copy if/when we ever support a full copy with time signatures, tempo changes, repeats, etc.

Voltas and system lines work fine too with my changes (note, my changes only affect copying individual elements and pasting them on to notes/rests, not range selections that include lines).
But I did just notice that it's not copying any coordinate adjustments to the line start/end points, I think that should be straightforward to fix - it's needed if you wanted, for instance, to copy your example a pair of hairpins (\< \>) that should apply to a single note.

Ok, that took WAY too long to fix, basically because a lot of the existing code that cloned information for Text elements was buggy, and was obviously never being called, but I've got it working now - e.g. you can copy a pair of < > hairpins from one note to another either individually or together, and providing the measure widths are pretty similar it copies pretty well. If they're very different measure widths you'll likely need to do some tweaking afterwards, but it's still less working than creating them from scratch, esp. if you'd set a bunch of other properties.
Interestingly I noticed that in MU3 if you CTRL-select both hairpins and copy to the clipboard, it preserves their sizes when pasting, but not if you copy just one. Not sure why that is, and I'm actually a bit surprised it works at all in MU3, there must be more drift in the codebase than I thought.

What I've now noticed is that the logic for copying/pasting a list of individual elements is totally different, for no good reason that I can discern...looking into it now. I don't see why it can't just be treated as a series of individual element copy/pastes.

So there are some special cases for copying & pasting multiple symbols:
a) chord & fret symbols are supposed to be placed in the same "relative" time position (compared to the left-most symbol copied), even if there's no note/rest at that time position, which requires creating a new segment in the relevant measure

b) chord/fret symbols are transposed as needed if pasting between transposing instruments - but it does this when pasting a single symbol too, so no special case logic should be needed for copy/paste multiple

c) figured bass is always added to voice 1 regardless of what note you paste onto, but again it already works when pasting a single symbol, so no special case logic should be needed. However there is some special case logic around how figured base info is copied to the clipboard which I need to understand better

d) when pasting lyrics, it avoids adding them to rests. This definitely does seem key behaviour to preserve, even if it means individual lyric items can end up in quite different positions relative to other symbols that were initially at the same time position. Oddly though it doesn't work in reverse - if you select lyrics that are initially attached to notes separated by rests, then paste on to note that's the start of a continuous series of notes, it doesn't "squeeze" the lyrics as expected, instead leaving notes without any lyrics.

e) in general it appears to use "segment deltas" to determine where text (other than dynamics) and various other elements etc. should be pasted relative to the left-most one (which is always pasted at the time position of the selected note/rest when pasting) - and this is perhaps the most controversial issue, as it means if I take a passage of music where, for instance, the violins alternate between pizz one measure and arco the next, select just the pizz/arco markings, then paste them at the start of another measure, the pizz and arco elements reconfigure themselves according to whatever note lengths are at the new location. Again, I can see a use case for this behaviour but it really doesn't make sense for, e.g. Rehearsal Marks (assuming you'd copied more than one of them), however they're not supported by MU3 currently anyway. But I'll ensure this behaviour is preserved anyway. Also I don't really understand why you wouldn't want the same behaviour for dynamics?

Other than that, as far as I can see, 75% of the "special case" logic that exists purely for the case of CTRL+selecting multiple symbols, copying them to the clipboard then pasting them again doesn't need to be there, which means I can remove quite a lot of code AND add ensure that the operation works as expected for ALL element types, not just the few that have been coded for. But it will mean a lot of testing, and a decent chance that some operations might not work exactly the same way they do in MU3 (and note MU4 already has a number of bugs in this regards, e.g. on copying/pasting a chord symbol it showed E<fontface="Edwin"/>a7).

BTW I was thinking further about this and wondering if we shouldn't just have three behaviours:
a) for elements that can logically start at any position in a measure regardless of what notes/rests are there, i.e. spanners, chord symbols, fret diagrams, figured bass, possibly even notes/rests themselves, we paste them at exactly the same relative time location as they were initially (which may require creating new segments, and note that currently spanners can't start at hidden segments, but I'll see if that can be fixed)
b) for all other elements, which are always attached to notes/rests, they're applied according whatever ordinal position in the list of notes/rests they are originally copied from, which is more or less what happens with text, articulation and lyrics elements now - i.e. if I copy 3 symbols that are attached to the 1st, 3rd and 5th notes then paste onto another note/rest, they're applied to the 1st, 3rd & 5th note/rest at the new position, regardless of the durations. Currently there's special logic to skip over rests when pasting lyrics, but personally I'd think the logic should be "if the element was originally attached to a note, when pasted it should only ever be pasted on to a note". So if I copy 3 lyrics that are attached to a note, a rest then a note, when I paste somewhere, the 1st lyric must be attached to a note, the 2nd can either be to a note or rest, and the 3rd must be to a note. Or it could be that the lyric originally attached to a rest can only be pasted onto a rest for consistency - but my thinking is that while all types of symbols always make sense attached to notes, there's only really special cases where they do make sense attached to rests, and it's often as a workaround.
3) for elements that only make sense at the start of a measure (time signatures, rehearsal marks, barlines etc.), that might need some more thought, and maybe we don't support copying/pasting those until we have a sensible design - in particular trying to paste time signatures in combination with other elements at later time positions can cause significant complications. But barlines/rehearsal marks could just be pasted according to whatever relative measure number they are, e.g. if you select 3 rehearsal marks that are in measures 2 5 and 9 originally then paste somewhere in measure 10, they're pasted at the start of measures 10, 12 and 17, regardless of the measure lengths/time signature. Alternatively, we could just only paste them if their relative time position happens to fall at the start of a measure, but that could cause a situation where copying rehearsal numbers A, B & C then pasting them elsewhere causes A & C to appear but not B, because of a time signature change that means only A & C fall on the start of a measure.

That's definitely different to what happens now, especially for, say, dynamics (e.g. currently if you select two dynamics on subsequent 1/4 notes and paste onto a note with a longer duration, they get pasted on top of each other), but would seem to be an obvious improvement and should be less code to deal with (except perhaps supporting spanners attached to hidden segments).

Personally though I'd rather there be two different paste modes selected by the user:
a) paste according to relative time position. If that requires creating hidden segments to attach pasted symbols to, then just do so. Should probably be the default.
b) paste according to relative ordinal note/rest position - elements are reattached to the "nth" note/rest relative to where they were originally attached, regardless of duration.

Both are useful operations and in fact to use two different algorithms in the same paste operation (as can happen now) doesn't make a lot of sense, as for instance, you might select a passage of 1/4 notes where there's a lyric and a chord symbol for each note, then paste on to a passage of 1/2 notes later in the score - the chord symbols will keep their relative time position but the lyrics will be expanded across twice the original duration. Instead I'd propose that either you paste "preserving time differences", such that every 2nd lyric and chord symbol get attached to a new (invisible) segment starting at the correct 1/4 note positions, or you post "preserving relative ordinal note/rests", such that both the chord symbols and the lyrics are re-attached to each successive note. But I don't know how you'd describe that operation!

It seems that supporting hidden segments for spanners (lines etc.) isn't going to be straightforward. Even allowing lyrics to have a segment as a parent is causing some issues, as there are assumptions in the code that their parents are ChordRests.
Unfortunately that means there might need to be a fourth pasting rule, which is what's used now for spanners - find whichever existing chordrest the relative time-position is associated with (which might actually start before that time position), and paste there, meaning that multiple spanners can be pasted over the top of each other even if they were originally associated with different time positions (segments).
But at least that's no worse than what there is now.

Fixed in branch master, commit 0c4e33a6e1

[MU3] Fix #2861 Allow all types of Spanner to be copy/pasted

Automatically closed -- issue fixed for 2 weeks with no activity.