Files being corrupted between Save/Close and re-opening them
Sometimes--often, in fact--when I re-open a file, it's not the same as when I saved it. Articulations, text markings, lines, and pedal marks will have shifted out of place. I can't imagine how a file can be perfect when I save it and wind up different when I re-open it. It strikes me as a very serious bug. I had the same problem with v1.x, but didn't report it because 2.0 was on the way.
I'm attaching an example .mscz along with a screenshot showing the corruption and a .pdf of the way the page looked when I saved the file.
| Attachment | Size |
|---|---|
| Ch'ien.mscz | 117.54 KB |
| chien-page-2-good.pdf | 41.59 KB |
| chien-page-2-corrupted.png | 216.5 KB |
Comments
There were unfortunately several issues of this nature discovered affecting 2.0. Those that were discovered in time were fixed for 2.0.1. Can you reproduce the issue with the latest version of MuseScore? If you can, this may be a new bug, and should be entered into the Issue tracker .
In reply to There were unfortunately by Isaac Weiss
I will test this out when I build 2.0.1, which I'll do in the next few days.
It's not really obvious on a quick examination what has changed. Cna you point to what specifically you are concerned about?
In reply to It's not really obvious on a by Marc Sabatella
The pedal markings I guess?
Which version of MuseScore are you using?
In reply to The pedal markings I by [DELETED] 5
Yes, of course, now I see. Not sure how I missed that.
It looks like the pedal markings have been extenden incorrectly - attached to one note then dragged to appear as if they are attached to another. At least that's how it looks. If I reset the pedal markings, then extend them correctly, then save and reload, all is well.
Of course, even incorrectly attached pedal markings shoyuldn't move so much on reload, but then you are more susceptible to other layout changes. If the number of measures on a line changes for whatever reason, incorrectly attached pedal lines will be off in exactly the sort of ways we see here. So I'm kind of guessing that is what happened - something happened to change the layout. Either that, or the score was originally created in a different version (perhaps an experimental prerelease build) and the way pedal lines are stored changed.
In reply to Yes, of course, now I see. by Marc Sabatella
I went to the trouble of removing the original pedal markings and putting them in again, but the problem persists. I made sure there were no pedal marks dragged so that they merely "appear" to be connected to notes to which they are not, in fact, connected. At most, some endpoints are extended to line up with the barline. Comparison of a screenshot of a "good" (unsaved) version of the score with a "bad" (saved/re-opened) version shows no change in the layout wrt barllnes.
So, nothing is changing in the layout except the pedal marks that are getting knocked out of alignment. It's not just pedal marks, either. There are a couple of staccatissimi that move out of position, too. And hairpins.
The score was created with 2.0 and is being opened with 2.0.
I'm wondering if the problem is related to the fact that while the score has a nominal time signature of 6/8, virtually every bar (all but about 3) uses a different "actual" value for the time signature, some of them very odd (17/32 for example). Also, owing to the 4-staff piano layout, pedal marks are attached to different staves at different places in the score and have to be vertically repositioned to underneath the bottom staff. I would not be surprised if my extreme time signature demands turned out to be the source of the problem. It's asking a lot of MuseScore, though I do admit that other than this issue, MuseScore's handling of irregular measures is amazingly good.
While I'm on the subject of nominal vs. actual time signatures, one thing that caused me a lot of grief was the management of rests. I'll post a separate bug report on this.
The key thing about the pedal marks and whatnot moving out of place is that, for the first time in my computing life, I was scared to save a file because it meant I'd lose some of my work--the exact opposite of the rational for saving! Unthinkable, under any circumstances. If a score renders perfectly when I create it, there's something very wrong if re-opening it causes it to be reformatted in any detail whatsoever. It would be like saving "To be or not to be" and having it, upon re-opening", come out as "To bed or not to bed."
In reply to I went to the trouble of by Peter Schaffter
Agreed, if things don't save and load correctly, that is considered a "major" issue, and we definitely need to fix it. But as I stated, I could not reproduce any such problem with your file. When I reset the positions of those lines, then textended them correctly, and used the Inspector to lower them again, they were preserved perfectly. So either you are seeing a bug already fixed - are you using the original 2.0 release, not the 2.0.1 update, which fixed a handful of bugs like this? - or you have encountered a new issue that is extremely specific not just to your score - since I used your some same score, same page - but the exact sequence of steps you are following.
Can you try a nightly build, or building yourself from the source (I seem to recall you might be on Linux?) to see if the problem persists? If so, then we would need precise step by step instructions to reproduvce it. Like, post a score without pedal markings, then describe *exactly* how you are going about adding them, so we can try doing the same.
In reply to Agreed, if things don't save by Marc Sabatella
I've succesfully built and installed 2.0.1 with the correct Qt dependencies on a Ubuntu 14.04 KDE desktop.
The wandering pedals and hairpins problem persists. I'm attaching the score again along with 4 .png screenshots, pages 2 and 3 (x2) . The .png's labelled "good" were taken after I once again fixed the wandering pedals and hairpins. The ones labelled "bad" were taken after saving, closing, and re-opening the file. As is obvious, the "bad" ones don't have the pedal marks in the correct position.
In the "good" version, I took extra-special care to check that the beginning and end points of the pedals corresponded to the note-spans to which the pedal is supposed to apply. Playback confirms that they're correctly positioned.
As for reproducing the bug, the most reliable way I have is what I've written: get everything right, save the file, close it, then re-open. 100% reliable at this end. The way I went about adding the pedals marks is a) drag the Ped. line from the palette to the note or rest where the pedal is to begin, b) extend or reduce the end-point anchor to the note where the pedal is to end, c) adjust the hook position to line up with the bar line or next Ped. mark, d) align vertically under the system.
In reply to I've succesfully built and by Peter Schaffter
Can you please post *precise* step by step instructions? Like, post a score with no pedal marks, then tell us *exactly* which note to drag the pedal line to, *exactly* how to extend it, and *exactly* any other steps you are taking? Again, I was unable to reproduce any problemn in your score just given generic instructiosn to add ledal markings. There must be something specific about the exact series of steps you are taking that is leading to the problem - unless it is a problem that somehow fixed itself after 2.0.1 and that is why I cannot reproduce using as current build.
In reply to Can you please post *precise* by Marc Sabatella
If you had any idea how much time I've lost to this...
Here is absolutely everything you need, including an insanely detailed description of every step taken to add pedal marks. The description reproduces exactly the procedure I described in my last post, so you'll forgive me if my patience is wearing thin. No doubt yours is, too, but I've done this about fifty times now, every time I open the score and find it corrupted again.
The files:
* ch'ien-no-pedal.mscz
- the first three pages of my original score, ch'ien.mscz; the pedal marks on page one have been left intact, the pedal marks on pages 2 and 3, where the problem first shows up, have been removed
* ch'ien-with-pedal.mscz
- the same as ch'ien-no-pedal.mscz but with pedal marks added *precisely* as described in my detailed description; despite this, the pedal marks are out of alignment, as the file itself should show but if not, can been seen in the "post-save-and-reopen" screenshots
* chien-with-pedal-pre-save-and-reopen-screenshot-page-2.png
* chien-with-pedal-pre-save-and-reopen-screenshot-page-3.png
- screenshots of pages 2 and 3 of ch'ien-with-pedal.mscz immediately after I added all the pedal marks according to the detailed description; everything looks fine
* chien-with-pedal-post-save-and-reopen-screenshot-page-2.png
* chien-with-pedal-post-save-and-reopen-screenshot-page-2.png
- screenshots of pages 2 and 3 of ch'ien-with-pedal.mscz immediately after saving and re-opening the file; the pedal marks are in the same wrong positions I've been correctting and correcting and correcting
Here's the precise description of how to add pedal marks to ch'ien-no-pedal.mscz:
Make sure invisibles are visible. Page 2, bar 14, first 16th-note: - drag Ped.___ line from palette to 16th-note octave B1/B2 in the bottom staff at the start of the bar - edit Line Properties to change hook to 45-degrees - double-click line - using Shift+ArrowLeft, move right anchor to the fourth 16th-note of the bar (octave E-flat2/E-flat3) - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 2.5sp - drag hook to position it directly underneath the E-flat octave Page 2, bar 14, fourth 16th-note: - drag \___/ line from palette to 16th-note octave E-flat2/E-flat3 in the bottom staff (fourth 16th-note) - double-click line - using Shift+ArrowLeft, move right anchor to the seventh 16th-note of the bar (octave B-flat2/B-flat3) - in Inspector, adjust Vertical offset to 2.5sp - drag hook to position it directly underneath the B-flat octave Page 2, bar 14, seventh 16th-note: - drag \___| line from palette to 16th-note octave B-flat2/B-flat3 in the bottom staff (seventh 16th-note) - double-click line - using Shift+ArrowRight, move right anchor to the quarter rest at the start of bar 16 - in Inspector, adjust Vertical offset to 2.5sp Page 2, bar 16, after fermata: - drag Ped.___ line from palette to 16th-note octave B1/B2 in the bottom staff immediately after the 8th rest - edit Line Properties to change hook to 45-degrees - double-click line - using Shift+ArrowRight, move right anchor to 16-note octave D-sharp3/D-sharp4 in the bottom staff of bar 17 - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 2.5sp - drag hook to position it immediately underneath the D-sharp octave Page 2, bar 17, 16th-note D-sharp octave, bottom staff: - drag \__| line from palette to 16th-note octave D-sharp2/D-sharp3 in the bottom staff of bar 17 - double-click line - Shift+ArrowRight once - in Inspector, adjust Horizontal offset to -.5sp and Vertical offset to 2.5sp - drag hook to position it to the left of the C-sharp octave Page 2, bar 18, 16th-note C-sharp octave, bottom staff: - drag Ped.__| line from palette to 16th-note octave C-sharp2/C-sharp3 in the bottom staff of bar 18 - edit Line Properties to change hook to 45-degrees - double-click line - using Shift+ArrowRight, move right anchor to 16-note octave E-sharp3/E-sharp4 in the bottom staff of bar 19 - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 2.5sp Page 2, bar 19, 16th-note E-sharp octave, bottom staff: - drag \__| line from palette to 16th-note octave E-sharp3/E-sharp4 in the bottom staff of bar 19 - double-click line - Shift+ArrowRight once - in Inspector, adjust Horizontal offset to -.5sp and Vertical offset to 2.5sp Page 2, bar 20, 16th-note D-sharp octave, bottom staff: - drag Ped.__| line from palette to 16th-note octave D-sharp2/D-sharp3 in the bottom staff of bar 20 - edit Line Properties to change hook to 45-degrees - double-click line - using Shift+ArrowRight, move right anchor to 16-note octave G3/G4 in the bottom staff of bar 21 - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 2.5sp Page 2, bar 21, 16th-note G octave, bottom staff: - drag \__| line from palette to 16th-note octave G3/G4 in the bottom staff of bar 21 - double-click line - using Shift+ArrowRight, move right anchor to end of bar 24 (first bar, second system) - deselect the start of the pedal mark and its continuation in the first bar of the second system (bar 24) - select the start of the pedal mark - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 2.5sp - select continuation of pedal mark at bar 24 - in Inspector, make sure Vertical offset is 0 - drag hook to line up with bar line Page 2, bars 26 - 29 - drag Ped.__| line from palette to the invisible dotted-eighth rest in the second-to-last staff at the start of each bar (voice 1) ***Note: the pedal line refuses to attach itself to the sounding 16th-note in voice 2 of the staff*** - double-click line - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 13sp - deselect line - double-click line and drag hook to line up with bar line Page 2, bar 30 - drag Ped.__| line from palette to the invisible dotted-eighth rest in the second-to-last staff at the start of the bar (voice 1) ***Note: the pedal line refuses to attach itself to the sounding 16th-note in voice 2 of the staff*** - double-click line - in Inspector, adjust Horizontal offset to -.5sp and Vertical offset to 13sp - deselect line - double-click line and drag hook to line up with bar line Page 2, bar 31, first half - drag Ped.__| line from palette to the invisible sixteenth rest in the second-to-last staff at the start of the bar (voice 1) ***Note: the pedal line refuses to attach itself to the sounding 16th-note in voice 2 of the staff*** - double-click line - using Shift+ArrowLeft, attach right anchor to the first 32nd rest in the bottom staff ***Note: anchor will seem to attach itself to a non-existent point in the second-to-last staff - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 13sp - deselect line - double-click line and drag hook to line up with bar line Page 2, bar 31, second half - drag Ped.__| line from palette to the second invisible 32nd rest in the second-to-last staff in the middle of the bar ***Note: the pedal line refuses to attach itself to the sounding 16th-note in voice 2 of the staff*** - using Shift+ArrowRight, move right anchor to the end of bar 32 - drag hook to line up with the bar line Page 3, bar 33, first half - drag Ped.__| line from palette to the invisible dotted-eighth rest in the second-to-last staff at the start of the bar (voice 1) ***Note: the pedal line refuses to attach itself to the sounding 16th-note in voice 2 of the staff*** - double-click line - do Shift+ArrowLeft three times ***Note: anchor will seem to attach itself to a non-existent point in the second-to-last staff just after the double-dotted 16th-note chord*** - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 12sp Page 3, bar 33, second half - drag Ped.__| line from palette to the second invisible 16th rest after the invisible quarter rest in the bottom staff ***Note: the pedal line refuses to attach itself to the sounding 16th-note in voice 2 of the second-to-last staff*** - double-click the line - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to -.5sp - drag hook to line up with bar line Page 3, bar 34 - drag Ped.__| line from palette to dotted-quarter chord at the start of the bar - double-click line - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to -.5 - drag hook to line up with bar line Page 3, bar 35 - drag Ped.__| line from palette to the invisible dotted-eighth rest in the second-to-last staff at the start of the bar (voice 1) - double-click line - using Shift+Arrow right, move right anchor to end of bar 36 - in Inspector, adjust Horizontal offset to -1sp and Vertical offset to 12sp - de-select line - double-click line and drag hook to line up with double bar lineSystem & etc. info:
Ubuntu 14.04
KDE desktop
MuseScore 2.0.1, built from the provided tarball (i.e. not from the git repo)
Qt libraries 5.4
In reply to If you had any idea how much by Peter Schaffter
I'm sorry you are finding this so frustrating. Realize this really *does* work for me and apparently for everyone else, so understanding exactly how to reproduce the problem is crucial.
I guess it's a bit late now, but I was assuming since you say this happens *every time*, that meant you could post a very short list of steps involving just one or two markings. I assumed you had tried that since you said this happens every time. I certainly didn't mean you had to describe how to add every single pedal marking on the page!
So, are you saying the problem does not happen if you add only one or two markings, but only happens if you add exactly that sequence of pedal markings using exactly those steps? I tried following your steps for the first two lines, following your steps precisely. It did not change one bit on save/reload. Can you try redoing just those first two lines to see if you see the same? That is, do have to do all those lines exactly in that order in order to see a problem? If so, I'll keep trying.
BTW, I see in several places you mention dragging. That is one of the things that makes your layout so fragile. Is there a reason you keep overriding the natural horizontal positions of these lines? That's not to say that this shouldn't have worked, but it seems you are making this *way* unnecessarily difficult on yourself, and probably contributing to the problem.
In reply to I'm sorry you are finding by Marc Sabatella
So, are you saying the problem does not happen if you add only one or two markings, but only happens if you add exactly that sequence of pedal markings using exactly those steps? I tried following your steps for the first two lines, following your steps precisely. It did not change one bit on save/reload. Can you try redoing just those first two lines to see if you see the same?
Re-did the two systems on page two, omitting all pedal marks from page three. Still the same problem.
BTW, I see in several places you mention dragging. That is one of the things that makes your layout so fragile. Is there a reason you keep overriding the natural horizontal positions of these lines? That's not to say that this shouldn't have worked, but it seems you are making this *way* unnecessarily difficult on yourself, and probably contributing to the problem.
I override the natural position of the lines because they're not falling where I need them to. On account of all the accidentals, the optical centering of the left anchor is frequently off (no fault of MuseScore's, BTW), so I move the line to the left, which also moves the hook. Is there another way to restore the hook to its proper location other than dragging? Would it make my layout less fragile?
I agree the problem lies in the complexity of what MuseScore is being asked to do. I'm convinced it has to do with the non-standard-length measures. FWIW, I chose to engrave this piece to test MuseScore 2.0's ability to deal with precisely this requirement. Oddly, though I'm thoroughly bummed out about this bug, I'm insanely pleased with how *well* MuseScore handles all the stuff I threw at it. Other than the offending two pages, the score is 95% exactly the way I want it to look (and I can live with the other 5%).
However, the fact remains: under no circumstances should any digital file, having been saved, differ in any manner whatsoever when it's re-opened. You use the word "fragile", but how can something carved in stone (i.e. a saved file) be fragile? How can MuseScore render an open file perfectly, then render it differently after it's been saved? Is some sort of different algorithm being applied to files when they're being opened than when they're being created? That doesn't make any sense.
In reply to So, are you saying the by Peter Schaffter
Instead of moving the whole line horizontally using the Inspector, then readjusting the right end point, you could simply adjust the left end point of the line to center the Ped text. This seems safer to me.
Without fully understanding the bug, I can at guess at what is probably happening. Somehow, the information abut the manual adjustments you have applied is being written incorrectly into the file. Or, they may have been written correctly but read incorrectly. Either would explain why the line looks fine at first, but after saving and reopening, it looks different - something is lost in the write / read process.
There were a few bugs in 2.0, most fixed in 2.0.1, where this sort of thing happened in other situations - but none of these bugs to my knowledge affected horizontal adjustments to pedal lines. I maintain a "hit list" of bugs I consider most important to make sure get addressed. This category of bugs I call "Loss of Work", and they are right up there with crashes and score corruptions at the top of the priority list. So I definitely agree with your assessment that it is very important we sort this out! I will try to reproduce this on another computer where I can more easily get an older build up.
In reply to If you had any idea how much by Peter Schaffter
Hmm, I did discover one very interesting and probably important thing:
Look at your screenshots for page 2. In the "pre" version, the first system on page 2 ends with measure 23. That is also how it looks on my system. However, in your *post* screenshot, you can see that same system only makes it to measure 22. This is the sort of layout shift that has to do with why I keep saying manual adjustments are a bad idea, and in this case at least, I think this is contributing to why you are having problems with this page. Your manual adjustments were made relative to one layout, but when the layout changed, those same manual adjustments no longer made sense.
That said, even if I force that system to end after measure 22, it looks OK. If you reduce the stretch of those measure to put measure 23 back on the top system, does that improve things any?
The fact that I am using a current development build could have something to do with why I see something else in this particular case - a change to the font rendering made post-2.0.1 does affect layout.
In reply to Hmm, I did discover one very by Marc Sabatella
I agree the root of the problem will be found in what's causing measure 23 to get shifted when re-opening the file. But what do you mean by "Your manual adjustments were made relative to one laybout, but when the layout changed, those same manual adjustments no longer made sense"? Does MuseScore create one layout for files while they're being created or edited, and a different one when the saved versions are opened? I hope the question is rhetorical, since the answer, surely, is "no".
I have played around with forcing a break at the measure 22/23 spot, but the problem persists.
Something else to notice in the "post" screenshot for page 3 is that the hairpins in the last measure of the first system have also shifted out of position. The problem doesn't affect pedal lines only.
I'm as thoroughly mystified as you. About the only thing left for me to try is using the latest development version. I'll give it a whirl tomorrow.
In reply to I agree the root of the by Peter Schaffter
Well, I would give it a whirl if the nightly build worked. :(
Followed the instructions to the letter. Made sure I had gcc-4.9. Made /usr/bin/gcc a symlink to gcc-4.9 (was linked to 4.8, per Debian/Ubuntu default for my system). Qt 5.4 is in $HOME/Qt; $PATH has location of Qt at the beginning.
The tarball of the latest nightly build was corrupted ("Unexpected EOF in archive"). The tarball of the previous nightly build extracted fine, but running 'lancemscore' resulted in
Up-to-date, accurate, complete instructions, please, or link thereto if there's a forum post on the subject (my eyes are fried from hunting through MuseScore forums the past couple of days).
In reply to I agree the root of the by Peter Schaffter
No, there aren't multiple layouts. What I mean is this:
Imagine a measure containing four quarter notes. Add a marking - a fermata, say - to the first note, then drag it to the right a small distance so it now appears directly over the second note, even though it is actually attached to the first note. The information about your manual adjustment is visible in the Inspector - you dragged it maybe 3sp to the right. And this is what gets written to the file if you save it.
Now, add line breaks so that this same measure is now the *only* measure on a system, meaning it extends the entire width of the page. MuseScore will dutifully move the fermata 2-3sp to the right of the first note, but now, this isn't even *close* to lining up with the second note, because the notes are much farther apart than they were. Your fermata is now hanging out there in space, 3sp to the right of the first note but way short of the second note.
This is the danger of manual adjustments. Sometimes they can be useful, sure, but they should never be relied upon to get things to line up precisely, because they *won't* line up precisely if the layout changes. This was of course an extreme example.
In reply to No, there aren't multiple by Marc Sabatella
This is possibly a discussion for another forum, but it seems to me MuseScore's greatest asset is precisely the control it gives over the placement of score objects. As a long-time developer in the field of typesetting and document layout, I've learned that nothing should be so automated that it can't be adjusted manually. In my work, there is no such thing as one size fits all. MuseScore has earned my respect because of its granularity. If I do need to move a fermata, I can, and MuseScore happily obliges. Funny you should mention moving the fermata because I did, in fact, have to do that in the problem score. I needed fermate over barlines, but I also needed the playback to respect them. Attaching them to a note or invisible rest at the end of the bar and scooting them over the barlines was a perfect, elegant solution. I appreciate being able to use MuseScore "creatively" this way. If I encounter a challenge, MuseScore almost always provides a way to surmount it.
In reply to This is possibly a discussion by Peter Schaffter
Well, I'm not saying that manual adjustment is always bad. Just that using it to align objects that are inherently attached different is inherentlly problematic. This is not some arbitrary limitation of MsueScore; it's an unsolvable problem period. Consider in my example - how is MuseScore supposed to know that by dragging the fermata 5sp to the right, your intent was to make it align with the second note? Maybe you were just moving it to the right for visual effect. Maybe it was to avoid a collision with some other element that was also attached to the first note. You cannot have your cake and eat it too.
So again, I'm not saying, don't ever do any manual adjustments ever. Just think through what you are doing and try to do it in a way that won't be "fragile". Attaching an element to one note then dragging it to align with another is *always* going to be problematic, ass the amoutn of the drag depend on the exact distance between those two notes, and that distance will change as the layout changes - different numbers of measure per system, different content in those measures, etc.
In reply to Well, I'm not saying that by Marc Sabatella
Marc --
Thanks for your replies. For whatever it's worth, I know that manual adjustments to the positioning of objects relies on a score remaining "stable". It is, to my mind, self-evident. Thus, my workflow is to
At this point, the layout of the score is "fixed". Opening it again should reproduce the unadorned score in exactly the same state it was in when saved. Next, I
Now, unless I misunderstand how MuseScore works, it seems to me that none of the procedures outlined immediately above should in any way change the "fixed" layout I started with. I approach scores the way I do precisely to *avoid* introducing changes to the fixed layout. The articulations, slurs, dynamics, lines, textual instructions and pedal lines are all attached to notes whose position doesn't (shouldn't?) change just because something's attached to them. Thus, my impression is that I am not asking anything unusual of MuseScore, and am creating my scores by following the documentation to the letter, even if the number of tweaks is more than perhaps the developers expected.
All of which is to assure you that I do everything I can to avoid the "changing layout" scenario you describe, and do, in fact, think things through carefully before even starting a project.
Clearly, the bug affecting pages 2 and 3 of my Ch'ien score is rare. Since you are unable to reproduce it with the development version you're running, logic would dictate that the bug has vanished in that version. I'd test this myself, but as I wrote earlier, nightly builds fail on my system.
Given that by *not* saving/re-opening the score, I have been able to generate a correct pdf, and screen capture the score for a YouTube video, perhaps it would be best to set the issue aside and wait to see whether it crops up again with the next score I'm creating, which will be identical with respect to layout requirements (piano, four staves per system, lots of cross-staff beaming, and actual time signatures usually not the same as the nominal value).
In reply to Marc -- Thanks for your by Peter Schaffter
Yes, it seems you are doing things as carefully as possible. One thing to consider is that if the default positioning of elements ever changes in the future, your manual adjustments may turn out to be counterproductive. So I personally would not be spending time making manual adjustments where there are not actual problems - it's time I don't need to spend, and may regret later. But if you don't mind the risk, and have the time to spend, then by all means, go for it!
Anyhow, before you start another complex score, can you at least verfiy the problem you are seeing does not happen even in simple scores? That is, create a basic piano score from scratch using all default settings, and some quarter notes, add a handful (3-4, says) of pedal markings, do the same sort of manual adjustments, and see if these survive save/reload.
In reply to Yes, it seems you are doing by Marc Sabatella
Marc --
I tested a simple score with adjusted pedal marks, and am unable to reproduce the bug. I'm going to attack the next nightmare score. Will let you know if the issue crops up.
Weirdness aside, MuseScore 2.0 is a dream come true. Best music notation software I've ever worked with (and this from a longtime lilypond user). Congratulations to everyone involved. You've made my life better. :)
In reply to Marc -- I tested a simple by Peter Schaffter
Follow-up...
I completed another score with the same requirements as the one that exhibited the bug. No problems this time, although the first one steadfastly refuses to behave itself whenever I open it.
In reply to Follow-up... I completed by Peter Schaffter
So strange. I wonder, if you delete all measures but a few, does the problem still happen? Might be easier for me to analyze the problem - even if I still can't reproduce it - with a smaller test case.
I frequently run into problems similar to what Peter Schaffter describes (mostly with dynamic markings and staff text), though I have learned from this thread things I can do or avoid doing (write all the notes and only the notes first, avoid excessive dragging) to prevent them in the future.
My immediate problem is this: one file I'm working on is so corrupted that when I click on a misplaced marking to delete it and rewrite it in the correct place, instead of capturing the marking it grabs the whole score as if I were trying to scroll--i.e., it refuses to acknowledge that the marking is there at all. In some cases the stray marking was misplaced way into the margins, which I was able to solve by introducing temporary format changes. But for the ones I'm trying to correct now that isn't working.
I even tried outright deleting and rewriting the measure to which the stray (in this case) ff markings were _supposed_ to be attached, to no avail. I closed the file and reopened it and they're still there, yet inaccessible. at least they don't show up when I save the file as a .pdf. Suggestions? Thanks in advance.
PS I think I originally created this score in 1.3, FWIW...
In reply to I frequently run into by pwpisano
In order to help, we'd need you to attach the score you are having problems with and precise steps to reproduce the problem. Best to do that in a separate theread dedicated to your problem, which sounds a bit different.
Most likely, the problem is that at some point you manually adjusted a marking by moving it very long distance from where it actually is attached, and then at some point lter the score formatting changed and the place you moved it to (say, 6 inches to the right) is now completely off the page. That will make the marking appear as a "ghost" on another page. The solution would be Ctrl+A to select all then Ctrl+R to reset the manual positionings of everything through the score. Then you can find the measure where the errant marking is *actually* attached, then undo the operation and repeat it after this time selecting just the problem measure (so you don't lose any other manual adjustments).
Update—somebody finally nailed down a way to reproduce this issue: https://musescore.org/en/node/108516#comment-490156
In reply to Update—somebody finally by Isaac Weiss
The case identified in that other thread resulted from the layout shifting in the middle of the manual adjustment. This shouldn't ever happen - making an adjustment to the position or shape of a line should never really affect layout but can occasionally happen due to a bug where *any* change causes the layout to shift. Typically, when this type of bug happens, we see the symptom as ebing that even a simple Ctrl+A to select all will cause layout to change. If a score gets into that state - which again shoudln't ever happen, but occasionally does especially if there is a clef, key, or time signature change right at a line break and we have trouble deciding if we can fit that measure or not because of the courtesy symbol - then I think the problem with hairpins shifting is a side effect of that.
So what I am wondering, for those of you who have seen this line-shifting issue - do you also remember your score getting into that state where layout shifted in the middle of a manual adjustment? If so, I'd say we have finally figured out what is happening. But if you weren't seeing the layout shift in the middle of the adjustment, I'm afraid it is still mysterious.
I believe at least response somewhere in this or another related thread did mention this relayout in the middle of the operation, but I seem to recall no one else was able to reproduce that. One good thing about 2.0.3 as opposed to 2.0.2 and especially 2.0.1 or 2.0 is that layout is more consistent between systems now, so if one persona can reproduce something like this reliably, chances are much better it will also be reproducible on another system.
In reply to The case identified in that by Marc Sabatella
Actually, further experimentation reveals the layout shift doesn't have to happen *during* the manual adjustment for the bug to be hit. The actual key is that a layout shift happens between the save and the subsequent load. That is, the measures are one place on the page at the point when the score was saved, but they shift around to different positions (because some measure moves from one system to the previous/next) on reload.
Which is to the say, it turns out https://musescore.org/en/node/62456#comment-288056 really was the key here.