Hairpins change position after Save
I posted about a similar problem a couple of months ago. Then, it was pedal lines that were moving out of position whenever I saved, closed, and re-opened my score. No one could reproduce the bug and since it affected only one score, I didn't make an issue of it.
Now, it's hairpins (specifically, hairpin continuations over the page) that are changing position when I save, only this time, I don't even have to save, close, and re-open the score. I've attached a small, zipped screen recording where I add a hairpin, adjust its vertical position (both the start and continuation), and save. There's a short pause after I save, then, as you watch, you'll see the hairpin (Vlns. I staff, second page) move out of position all by itself! (Vlns. II are also affected; the hairpins were positioned before I made the recording.)
If you watch closely, you'll also see that I have some trouble positioning the hairpins. A single click on the arrows controlling the vertical offset in the Inspector causes the offset to be incremented by 2 steps instead of 1. This problem seems to be related to the length and number of instruments in the score. I haven't seen it when working on piano scores, but it's a routine annoyance that starts about halfway through all my orchestral projects.
MuseScore 2.0.2
Kubuntu 14.04
KXStudios repo
64-bit architecture
| Attachment | Size |
|---|---|
| wandering-hairpin.mkv_.zip | 1.25 MB |
Comments
As always, posting actual score and steps to reproduce the problem would be a good idea. It's certainly possible that we still won't be able to reproduce the problem, but since you are seeing a new effect, maybe we will have better luck this time.
In reply to As always, posting actual by Marc Sabatella
Marc,
Can no do on sending the score. After I made the screen recording, I closed the file and quit MuseScore. When I fired up MuseScore again and opened the file, I got a "file corrputed" error. When I looked at the mscx, yep, indeed, at least half of the file was missing. I'm fanatical about saving my work and shutting things down properly, so that's not the cause. And, as I recall, when I had problems with save/re-open last time around, that file, too, wound up corrupted, but certainly not by me.
Luckily, I had an additional old backup that meant I only had to re-compose/re-orchestrate about sixteen bars. For the purposes of sending a file exhibiting the bug I showed in my little screen recording, though, the file is of no use. The wandering hairpins are staying firmly in place, for now.
This is a very serious bug, no matter how seldom or how randomly it shows up. I'm not a casaul computer user. I know what I'm doing after over thirty years, plus I'm a developer myself. A fundamental of computing is that a file save operation NEVER results in an alteration of the data being saved, nor of the contents of the screen at the moment file is saved. It's twice now MuseScore has exhibited this problem.
I'm running 2.0.2 on 32-bit Linux Mint 17.2, and I'm seeing what sounds like the same thing on hairpins and dynamic markings that I've positioned either manually or using the inspector. When I save and reopen the file, I find some of the elements have moved from where I positioned them; in one case some hairpins on adjacent staves were moved horizontally by (IIRC) three measures. I have also seen ties and slurs thrown askew.
Unfortunately this would seem to be a very difficult thing to reproduce, since it occurs at random. The only thing that comes to my mind is some sort of numerical corruption, truncation or rounding error, etc. when the file is serialized for saving, or in the compression or decompression. How likely is this?
In reply to I'm running 2.0.2 on 32-bit by dhfx
I don't think it has to do with compression/decompression. I work with .mscx files.
In reply to I don't think it has to do by Peter Schaffter
OK, then could it be in the serialization, or however the score in memory is translated into a file format - or in the reverse process?
In reply to OK, then could it be in the by dhfx
As has been said earlier: we'd need to see the actual score to find out what happens there. It is possible that you just entered and extended these hairpins wrongly
In reply to As has been said earlier: by Jojo-Schmitz
It's not just hairpins. It also happens with slurs and with dynamic markings, although the shift there is usally small, not more than a few "sp" according to the inspector. As for how I'm entering the hairpins, I drag from the pallette, anchor the left-hand end to the start note, then double-click on the hairpin and use Shift-RightArrow to move the right-hand end to the ending note. Same with slurs - select the start note, enter "s", double-click on the hairpin and use Shift-RightArrow to extend the right-hand end to the ending note.
In reply to It's not just hairpins. It by dhfx
OK, that seems to be the right method. So even more we'd need to have a look at the real score...
In reply to OK, then could it be in the by dhfx
The offsets in memory are stored as floating point values and these are then written to the MSCX file as plain text using pretty standard Qt / C++ functions. If there is going to be errors there, it would be on the order of things like, the value 2/3 being written as "0.6666" versus "0.6667" versus the true value 0.6666666666666666666666666666666...., and you'd never in a million years notice the imperceptible shift that resulted.
When positions are written, some elements record the offset itself - exactly what you see listed in the Inspector - but others record their position relative to their parents. I think that is so that any manual adjustments will remain the same visually even if the default position of the element is ever changed. Something like that anyhow.
I am guessing that the problem will stem from something going wrong in the calculation of the position relative to the parent. Like, maybe in certain cases, the parent's position has not been fully determined at the point where we are trying to calculate the position of the element itself. This could indeed have something to do with the order that things are written into the file. But it wouldn't really explain why the problem isn't reproducible. So there is probably more to it than this.
Anyhow, in order to have any chance of fixing this, we'd still really need to see a sample score and precise steps to reproduce the problem.
In reply to The offsets in memory are by Marc Sabatella
Would that we could provide sample scores exhibiting the problem, but as both dhfx and I have noticed, the problem isn't consistent and crops up apparently at random. Last time I sent a sample score exhibiting the problem and precise steps, the damn thing worked fine at your end. It's why I sent a screen recording showing the problem in action rather than a file this time. Very frustrating at both ends, this one.
I'd like to add that I've noticed a similar problem when switching from Page View to Continuous View and back again. While I recognize this is a much more complex operation than simply saving a file, I suspect there must be a connection between the two.
In reply to The offsets in memory are by Marc Sabatella
I think I've also seen it happen when a passage (several measures) is cut-and-pasted to a new location, or when a layout change occurs due to a change on an adjacent page causing measures to overflow the page. Don't know if this is any help. Is there anything structurally common in the code to all these situations?
In reply to The offsets in memory are by Marc Sabatella
Another thing I've observed lately: I recently created an album and merged 3 separate scores into a single score. I had customized most of the slurs for clarity, by shifting them vertically to avoid beams on adjacent staves. When I looked at the merged score, many of my slurs had changed back to the default height, with ends either just above/below the note heads (depending on stem direction) or at the opposite end of the stem.
Is it possible that something in the copy process is losing customized (x,y) postions and replacing them with defaults, or with noise data as would occur with e.g. a C++ pointer error? This would take a close inspection of the source code to track down. Or it might even be in some library module that is platform-dependent or OS version-dependent; in such a case there would seem to be no point in providing a sample score; when Peter (in the above posts) provided one, Mark apparently was unable to reproduce the bug on his system. My thinking is that with enough description of cases where this bug seems to occur, it may be possible to localize it in the code.
In reply to Another thing I've observed by dhfx
As it happens, I've been looking at the code dealing with layout of hairpins recently (and much of this code is shared with slurs, pedal, and other lines) and thinking about these issues, that I hear about from time to time but still cannot reproduce. I can definitely see from the code how it would be conceivably be possible for these adjustments to be misinterpreted on write / read, as they have to go through a couple of different types of conversions.
So I *do* already have a decent idea of where the problem is likely is likely to be in the code; it's just still the case that without reliable steps to reproduce, it's still going to be next to impossdible to figure out why it doesn't work in certain cases.
Regarding albums specifically, though, I think that much is a known bug that is easily reproduced and almsot certainly unrelated. See #81906: joined scores from album lose line alterations.
In reply to As it happens, I've been by Marc Sabatella
Just throwing in my two cents: I've had similar problems with hairpins & slurs, although I've never posted on the subject because I can't reproduce what causes it. It's not limited to a particular score, and doesn't seem related to the size or complexity of the score. Some scores seemed plagued by it, others have no issues at all. I hope my notes below provide some ammunition for trouble shooting.
Correcting the problem usually involves switching from Page View to Continuous View (the defective lines often can't be selected for deletion in Page View) &/or deletion of the measure content (or the actual measures) several measures on either side of the defective line(s).
The problems are frequently associated with:
*Scores originally created in MuseScore 1.x, but now being worked on in 2.02;
*Switching between Page & Continuous View;
*When lines go across page breaks or the ends of systems;
*Lines that cross page breaks, and an edit on the left page side of the line isn't reflected on the right page side;
*When the score bounces back & forth with every edit/keystroke (previously explained by Marc as probably a rounding/floating point error {technically way over my head});
*When opening or saving the score (when the problem was not present prior to the save);
*When changing the Visible checkbox status in the Instruments window;
*Lines that disappear from view (not invisible; just not there at all) and then re-appear when a measure or note near them is selected;
*Lines marked Not Visible but still showing in dim/grey even though Show Invisible is not checked in the View menu;
*Instrument names that are mis-aligned at the beginning of staves, but re-align when Staff Properties is selected & exited for any staff.
There is an outside chance I have bumped into something that might possibly relate to this. See #93316: Slurs loses connection to notes if keyboard used to change pitch of notes. If you have a line, then replace either the start or end note by entering a new one directly on top of it, the line is still trying to lay out to the original note. This causes slurs to lay out incorrectly - wrong vertical position - although hairpins would still get the right answer since they don't depend on the pitch of the note they are attached to. For slurs, the layout definitely would then fix itself after a reload, and if you had made manual adjustments to fix the shape of the slur, those would adjustments would now be unnecessary and hence wrong. I can definitely reproduce this now. So far, I haven't found a combination of operations that would cause a hairpin to shift in the same way, but if those of you who have seen this issue want to try, feel free to and report back if you can come up with steps.
The key, again, would be to add the hairpin, then click the first note and type a new now directly on top of it. Eg:
1) enter notes
2) enter hairpin
3) click start note
4) type a different pitch (thus replacing the note)
5) do some manual adjustments
6) save
7) reload
It is *possible* some variation on this might produce a shift. As I said, it definitely does for slurs.
In reply to There is an outside chance I by Marc Sabatella
I came across a reproducible variation of this problem while reviewing & cleaning up the attached score.
There are a number of several-measure-long hairpins around measures 63-69 and measure 95 that are marked as not visible. Portions of them occasionally display as "grayed out" even though Show Invisible is not selected.
If they are not displaying this behavior when you first open the score (in page view mode), do this:
At measure 70, make a minor tweak (such as selecting the quarter rest in the timpani staff and hitting up or down arrow). For me, this causes the issue to toggle on & off (i.e., the invisible hairpin becomes visible/gray). Also, the display on the screen jumps several measures to the left or right with each toggle, associated with the automatic page breaks changing position.
The problem does not present in continuous view mode, only page view.
I corrected the problem in another version of the score by either shortening the length of the hairpins or deleting them.
I hope this provides more info for trouble shooting.
In reply to I came across a reproducible by marty strasinger
Update: I had the same problem when cleaning up the attached. This score has the same issue as my previous post, in that making any edit (such as moving a text line up, down, or sideways) causes the score (in Page View mode) to jump left & right across the monitor. This is accompanied with the automatic page breaks changing with every left/right jump.
My guess is that, when the page breaks change, the hairpins lose their place to an extent: the anchor point doesn't change, it's as is I had grabbed the hairpin by it's center handle & dragged it left or right (as opposed to using shift+L/R arrow to change the anchor point).
If I switch to Continuous View and select a hairpin, the dotted line that shows the hairpins' anchor point shows that it has shifted 2 or more measures to the left or right. (The anchor point is where is should be, it's just that displayed position is off.) It is then easy to drag it back to the proper position, and switch back to Page View mode, problem solved.
However, any more edits cause the jumping/page break changing to take place again, and the hairpins are once more out of position by several measures.
In reply to Update: I had the same by marty strasinger
Since I believe nobody has mentioned this I add an observation here: On the occasion that this hairpin move has happened to me (never with any consistency that I could observe and justify a post on this forum with) I noticed that the anchoring of the shifted hairpins remained unchanged. If you click on the end or beginning of the hairpin you can see a tilted anchor line (if this is the correct word) connecting to a note or position one or two measures before, namely the place where the hairpin was originally entered. Maybe this observation helps figuring this out.
I will add that I have shortcuts for hairpins, alt D or alt C, so I select the first note for the hairpin, then shift select the last note, then hit the short cut.
In reply to Since I believe nobody has by azumbrunn
I have had many problems with "wandering" hairpins, but cannot entirely reproduce the steps to cause the problem.
- probably all the scores which show this fault were created in MS 1.3 but were later edited in MS 2.0.2
- probably all the faulty scores were toggled between Page View and Continuous View
- probably all the faulty scores were also switched from portrait format (for printing) to landscape format (for on-screen display)
The attached screenshot shows a hairpin end anchor which has shifted well outside its intended stop point.
![Hairpin_anchor_moved.png]( "Hairpin_anchor_moved.png")
In reply to I came across a reproducible by marty strasinger
Bingo! Turns out the measure-jumping behavior is indeed the key. When you save the file, the position of the hairpins relative the system they are on is what is saved to the file. If for some reason those measures are in a different place within their respective systems, then the hairpins will now be wrong - they will show up in the right place relative to their *old* position within the system.
Unfortunately, this wasn't reproducible for us with your score, so we were unable to solve the problem even given this important clue. Now, however, we have a score where we can reproduce the problem.
To me, the real solution is to solve the issue of the jumping layout, which is going to be problematic in other ways as well. That would solve the jumping hairpin problem in itself. However, on the assumption that some corner case will still remain where the layout jumps betwene save & load, we probably still need some sort of sanity check on the position of the hairpins.
Update—somebody finally nailed down a way to reproduce this issue: https://musescore.org/en/node/108516#comment-490156
Has there been any update on this matter? I'm on musescore 2.1.0, rev 871c8ce, and this problem is just driving me insane.
In addition to haripins, my rehearsel marks are on the run as well. Things get messed up after upload to musescore website as well (although I don't care that much about that atm)
In reply to Has there been any update on… by Roland Bouman
Yes, actually, we fixed at least four separate issues that were causing this type of behavior prior to the release of 2.1. So far no one has posted any more cases where there are problems, so as far as we knew, this had been solved. If you are still seeing cases where this happens in 2.1, we would need you to attach the score you are having trouble with and give precise steps to reproduce the problem.
For the record, here are the four separate bugs that were fixed for 2.1:
#109021: Hairpin and other symbols are shifting when relayout occurs
#187151: Hairpins shifting out of position on systems containing ties from stem
#188061: Values in sp unit don't remain unchanged after changing spatium
#180991: Layout jump due to bad cautionaryWidth() calculation
Rehearsal marks would probably be unrelated. There is a known issue with rehearsal marks at the beginning of a system if you added them by palette double click and/or are modifying the alignment properties. See #195146: Rehearsal mark alignment changes to center after reload if added via palette double click. This one at least is easily worked around once you know what triggers it.
In reply to Yes, actually, we fixed at… by Marc Sabatella
Many problems persist if a score is created under 2.0.3 and then opened under 2.1. To help prevent these problems it is sometimes necessary to save the score as a 2.1 score. I'm not sure if it makes a difference with hairpins drifting or not, I haven't noticed problems with this since I've been using 2.1.
In reply to Yes, actually, we fixed at… by Marc Sabatella
Hi Marc,
Sorry, I'm having a problem with moving hairpins in 2.1. I've been a long time user of MuseScore, but the hairpins are jumping randomly in the horizontal offset.
I'm running the MuseScore-2.1-x86_64.AppImage on Ubuntu 14.04 with an AMD FX(tm)-6300 Six-Core Processor × 6.
I have a number files that have small staves and large verse fonts. These are for community (non-reading) choirs. I keep selecting the hairpins and setting the horizontal offset to zero. Then, I save the file and reopen it and they are back in funny places, sometimes with offsets as large as -70!
I have tried putting hard line breaks at the end of my staves after I've laid it out, but that doesn't stop them moving.
The images are from a file corrected, saved and re-opened over about 2 minutes. The same issue affects the tenor and baritone parts.
I read in detail the threads on this - but nothing mentioned has helped.
Kind regards,
Pete
In reply to Hi Marc,… by Pete_Alan
Hmm, I see what you mean. This appears to be yet another bug that happens to have the same effect. The problem has to do with the invisible piano staff below the staff you can see. The hairpins you have in your score are actually attached to that staff and not the staff they appear to be attached to. I don't yet understand why this is happening. I can see that if I delete the existing hairpins from this score and new ones, the same thing happens - even though they appear to be attached the visible staff, they are actually being saved as part of the invisible staff, and the same problem occurs if you then do a manual adjustment and save. However, if I create a new score from scratch and try the same experiment, I can't get it to fail. So I'm not sure why this problem is happening for you.
Anything you can think of regarding the extra invisible staff that might explain why it doesn't work in your score but does when I try it in a new one?
EDIT: actually, I think it has to do with multimeasure rests. If I turn them off, the problem goes away. So it's the combination of multimeasure rests and invisible staves that causes the problem. From here, I should be able to submit a bug report and then we can hopefully fix it. Thanks for posting your example!
In reply to Hmm, I see what you mean. … by Marc Sabatella
Delighted to be able to help the project. :-)
Just to provide you with a little more context, these single vocal parts start on a full score - Tenor, Baritone, Bass & Piano. These are all normal sized staves, lyrics, layout etc. When I'm happy with that, (for the people who need to read the music) I create a copy of that file (renamed a "Parts on a Page" [PoaP]).
With this PoaP copy, I hide the piano and reduce and simplify the three vocal line stave content, and increase the font sizes. With this modified file, I then delete two of the voices and save as another copy (and call this "PoaP/Tn", for example).
I then press control-Z to restore the deleted voices and then delete a different two voices. I do this one more time, and I have three individual voice PoaP files with small staves, large lyrics, single sheets (mainly), for the guys to sing from, and hear their parts against the piano accompaniment.
I don't expect any of this to have any impact on the nature of the bug - but thought it was useful to explain that the files are not created in the usual way you would create a score from scratch.
In reply to Yes, actually, we fixed at… by Marc Sabatella
Hi, yes, I'm also having problems with wandering hairpins. I admit that for the first page or two I wasn't entering them correctly: I was dragging them onto the first note then extending the right side to where I wanted it. But then I caught on to highlighting start & end notes and typing '<' or '>', then tweaking a little bit where necessary, as I do with slurs and 's'. My score was entered with a version before 2.1 (don't know which), and now I'm using 2.1.
Also I notice that my first system now has five measures instead of four like when I had printed to PDF and saved then closed it.
In reply to Hi, yes, I'm also having… by tharrop
MuseScore 2.1 on Win 7 Pro SP 1
Yes, I have posted on this topic before. Currently I have an MSCZ file which I think shows a reproducible problem of "wandering" hairpins. It occurs in the pickup bar of Movement 2, straight after bar 173 of Movement 1. For background, I generally typeset in Continuous View.
Image 1: diminuendos as saved in pickup bar
![Diminuendos_as_saved.png]( "Diminuendos_as_saved.png")
![Diminuendos_after_close_and_re-open_Continuous_View.png]( "Diminuendos_after_close_and_re-open_Continuous_View.png")
![Diminuendos_after_close_and_re-open_Page_View.png]( "Diminuendos_after_close_and_re-open_Page_View.png")
Image 2: close file and re-open - anchor points moved to the right (Continuous View)
Image 3: close file and re-open - anchor points moved to the right (Page View)
Every time I correct the anchor points, save and close. But when re-opening the file, the "dim." elements are shifted to the right (both anchor points).
In reply to Yes, I have posted on this… by DanielR
In general, you can't expect to make fine adjustments in continuous view and have them make sense in page view. The offsets are stored as absolute distance (in staff space units) but an offset that makes sense for a measure of one width won't make sense if the measure has a different width later, and that's what happens when you switch between page and continuous view - measures widths will change because the layout is different (no automatic stretch due to right-justifying of systems).
If you are able to reproduce a problem when doing your manual adjustments in page view, let me know (and give steps) and I'll investigate further.
In reply to In general, you can't expect… by Marc Sabatella
Marc, that's really helpful advice - thank you. Obviously my technique was entirely wrong, and having thought about it I do now realize that I was creating my own problems by changing the default hairpin placement while still in Continuous View. Lesson learned...
Dan
In reply to Marc, that's really helpful… by DanielR
Still, the clef that sometimes appears and sometimes does not - that shouldn't be happening. If we track down the cause of that, I think that will make manual adjustments a bit safer in continuous view. They still won't carry over well to page view, but they should stick in continuous view, and it's a bug that they don't in this case.
What seems to be the case on cursory examination is that when you first switch from page to continuous view, there are clefs after the section breaks (verified in new score created from scratch), but if you save and reload while still in continuous view, there are no clefs. Which kind of sort of makes sense - there are no systems to trigger the clef to be generated. If I toggle to page view and back to continuous, the clef reappears, but again disappears on save/reload. And if I make manual adjustments while in continuous view with clef, then save/reload and find the measure without clef, the adjustments indeed don't make sense.
Not sure what to do about that. Maybe not display the clef even when first switching to continuous view, since it was considered "generated". But I'm a bit worried somewhere else something depends on this, and the better fix is to be sure to display it even after save/reload. Not sure.
In reply to Hi, yes, I'm also having… by tharrop
For this one I'd need more information. As you say, a lot of hairpins appear to have been entered incorrectly - attached to one place and then dragged somewhere else. This isn't going to work if the layout changes for any reason, and the change from 5 to 4 measures on the first system (a result of a slight tweak to the layout algorithms) was enough to trigger that problem here. But if I delete these hairpins and enter them correctly, everything seems to work, as far as I can tell about how you intended these hairpins to go. In particular, the extra hairpin just before the first note of the piece in the bottom staff actually belongs to measure 5. If I delete it, then add it to measure 5 correctly and just make a slight adjustment to get it to line up with the dynamic, it stays put on save/restore. Ditto with the other incorrectly attached hairpins on the first system.
In reply to For this one I'd need more… by Marc Sabatella
@Marc
I know that your remark "a lot of hairpins appear to have been entered incorrectly - attached to one place and then dragged somewhere else" refers to the post before mine.
But for further background I can assure you that I never drag hairpins. I always move their anchor points with:
* Shift+LeftArrow / RightArrow for large jumps
* Ctrl+LeftArrow / RightArrow for small adjustments
In my example of the pickup bar, it's MuseScore that's dragging the hairpins...
HTH
In reply to @Marc… by DanielR
Indeed, I was referring to the previous one. Unfortunately the posts crossed and the indenting doesn't make it clear.
With yours, the problem appears to have to do with differences between continuous and page view. As I just mentiond in a previous response, it is not a good idea to make manual adjustments in continuous view. It's pretty much a given that the results won't look right in page view - not due to any bug, but just the nature of doing adjustments that make sense in one layout not making sense in another.
However, that said, if you only live in continuous view and never attempt to look at page view again, it should work to make an adjustment and have it stick as long as you remain in continuous view. And I can see that's not the case here. The problem seems to have to do with the clef at the beginning of the movement that is either present or not present in continuous view, depending on, hmm, maybe the wind direction? :-). So you are making an adjustment that makes sense when the clef is present, but on reload, the clef may not be present, and the same adjustment doesn't make sense - or vice versa. Not sure why the clef is flickering like that. Presumably it has to do with the section break, which changes how clefs, key signatures, and time signatures are handled across the line break that accompanies the section break when in page view.
In reply to For this one I'd need more… by Marc Sabatella
Thank you, Marc, for the quick reply! I will comb through it now and redo the early hairpins properly. If the problem persists I'll be more specific.