System positioning uncontrollable
Brief acknowlegment first, of the good work that has been done in creating, maintaining and continuing to develop MuseScore, and providing it to people free of charge.
Version 1.3 revision 5702, no update available, Windows 7 Pro
Trying to set distance between systems:
4.3 to 4.4, 4.4 to 4.5, small increase in distance each time, fine.
4.5 to 4.6 causes a big jump, many mm.
Then to 4.7, small increase again, to 4.8, small increase again.
Then to 4.9, not an increase, but a big reduction, many mm less distance between systems than at 4.8.
Page fill and last system threshholds are both set to 100%.
I wondered whether some other automatic page layout function that I don’t know about was causing this behaviour.
But then going back from 4.9 to 4.8 made the distance between systems larger again, not smaller.
That nonrepeatability when returning to an immediately previous smaller value tells me that this behaviour is unlikely to be caused by any automatic page layout function.
I repeated the whole process, starting at about 4.1 and saving and reloading the file at each step. Exactly the same behaviour happened.
So it’s not just a fault with a display of the score, but something deeper.
Similar behaviour in trying to move the bottom edge of a vertical frame at the top of the page, above the systems.
For some of the movement distance the staves move the same amount as the frame edge, as they should, but, at one point, pulling the frame edge down just one pixel on screen makes the staves jump down by many mm.
And when I bring the frame edge back slightly the staves do not return to the position where they were immediately before.
Just the same stave position fault as for the system distance setting - jumping, hysteresis.
I have not tried other positioning settings, to check for similar faults with them.
I’m stuck, unable to complete preparation of an item for publication.
This needs an urgent fix.
I have not seen this behaviour before today. I hope it's just a minor fault resulting from a program upgrade, and easily fixed.
Thanks again for your good work on MuseScore. It is much appreciated.
Comments
...is probably one of the trickiest areas in MuseScore to master - not because it is overly complicated, but rather that there exist interrelated parameters. Changing one may affect others.
Posting your score would be a tremendous help, as much would have to be guessed otherwise.
For example:
Is the score written for multiple instruments? Is it a simple lead sheet? Does it have lyrics?
Perhaps just changing scaling under Layout / Page Settings could do the trick, but that's merely a guess.
Regards.
In reply to Score layout... by Jm6stringer
Thank you for your reply.
You are correct about score layout being "one of the trickiest areas in MuseScore to master".
Before posting my report I read again all the help files about positioning, and did some searches regarding systems jumping, system positioning problem and similar terms, but found nothing that mentioned behaviour like this.
Sample is attached.
Rather than put up a copyright work with all the music and text content in it but needing final layout, for all the world to see and download for free (there goes my early retirement ... ), I have replaced all the content with filler notes and text.
Stave content is different but the staves are structured and sized as in the original. Text frames have less text but the same number of lines, with everything in the same size as the original, including the frames.
This morning (11/3/2014, 7:30 Adelaide time) the program is still showing the same version with no updates available.
The system positioning behaviour in the original version of the file this morning is the same as the bizarre behaviour last night while I was writing the report.
The same things happen in the attached sample.
As before, 0.1 space increments in the system spacing setting mostly cause small increases in system spacing, but at some points it jumps unpredictably.
The height of the top frame influences the level at which the jumps happen, as would be expected for automatic layout functionality.
The big jumps in system positions do not all happen at points where a frame jumps to or from an other page. If that had been the case the solution would have been obvious.
For example, setting increments in the range 4.0 to 4.4 all make slight increases, as expected, but then the next increment to 4.5 makes a big jump, 4.6 makes a slight increase again, then 4.7 not an increase but a big decrease, with nothing jumping off or onto the page.
A one point as the spacing setting is reduced by 0.1, when the bottom frame jumps back from the second page to the first page the system spacing increases with a big jump, rather than decreasing, as would be expected to fit that frame into the same page.
With the top frame set as in the sample file, increasing the system spacing from 4.3 to 4.4 is an example of that. At 4.5 the bottom frame still remains on the same page.
Strange behaviour.
The copyright notice text box never seems to have any effect on positioning of any other element. Moving things over it never seems to cause any problem other than visual confusion.
Even if this behaviour is being caused by an automatic layout function that is still unknown to me and is not mentioned in help files or forums, clearly the program is not working properly and a fix is needed.
In reply to Even more uncontrollable this morning by Laurie Williams
...everything is displayed on a single page. Is that what you want?
I was trying to follow your 'incremental settings' approach. Are you talking about menu item: Style / Edit General Style / Page / System distance? If so, the only jumps that I get are when the bottom frame gets moved to a second page. (Windows XP)
Rather, why not describe what you wish to see:
For example - one page with more space between the lowest frame text and the copyright notice.
More space between systems with less staff distance.
See attachment and compare the Page settings to your score.
Regards.
In reply to When I open your score... by Jm6stringer
Thank you for your prompt reply and your version of the file.
Yes, that's the setting. I said it's the "system distance" setting.
The MuseScore program in your computer seems to be working properly. Very different from mine, at least since yesterday.
Are you using the same version?
The margins in my sample file were round numbers of mm but are now slightly different. Is that a result of you working on the file in inches, and me reopening in mm?
Re what I wish to see, yes, that's the general idea, which is why my sample file has all the content on one page.
Until yesterday I have had no great difficulty in positioning things in MuseScore, at least since the initial learning phase, which, due to good help files and forums, was not a long one.
I can fiddle things into position, but because of the unpredictable behaviour I don't feel that I can trust the program to lay out the bits as I need them and keep them as set.
That's why I said "I'm stuck".
Related to that, I expect to have the same problems in more complex scores that I intend to publish shortly.
Clearly, the program as I have it is not working properly.
I'm happy to use TeamViewer to demonstrate the problem to a MuseScore developer who understands the behaviour that I have described and would be able to fix the fault.
In the meantime, I'll resist the temptation to reinstall the program.
Thanks again
Laurie
In reply to Intermittent and nonduplicable faults are the worst by Laurie Williams
The main thing people usually don't get is that setting the setting system distance doesn't actually control the distance between systems directly - it asks MsueScore to place *at least* that much space between systems. But if your page is more than a certain percentage full (Page fill threshold in that same dialog), MuseScore automatically stretches the systems out to fill the page. So it will *appear* that further changes to system distance are having no effect. To see the actual effect of your system distance settings, set Page fill threshold to 100%, which says, only fill the page if it is already 100% full. Then you'll be able to see the effect of your system distance settings more accurately.
Now, you have this parameter set to 100% already. So I guess you've already experimented with this. Things do indeed work exactly as you have described, which is exactly as I would expect. With 100% Page fill threshold, you don't get page fill until you're basically full already, which ahppens at 4.5sp system distance. This is why you see a "jump" in system spacing at that point - it's the page fill kicking in. 4.6 doesn't make enough of a difference to actually force another page (I guess there is some rounding involved), but 4.7 does make the page too full to fit, so something moves the next page, creating more room on the first page to be filled, etc.
So unless I am missing something, there is nothing wrong - what you describe is exactly what I see and exactly what I expect to see, except I guess one could choose to be a bit disappointed that 100% is subject to some round off.
In reply to The main thing people usually by Marc Sabatella
Marc, thank you for your contribution.
Yes, as you already noted I have experimented with fill threshholds, both set to 100%.
I understand the point about "at least" (rather than "equal to" - same in Word for table column widths, for example) but, as you noted, those 100% threshhold settings should make it irrelevant.
I made those changes to 100% early in my experience with MuseScore.
Perhaps, as you say, some "rounding" applies at the 100% setting level - not in the setting, but in the numbers with which it is compared as things move.
Re "Things do indeed work exactly as you have described, which is exactly as I would expect." - no, that should not be so.
Same for "This is why you see a "jump" in system spacing at that point - it's the page fill kicking in." - again, no - it's disabled, or it should be by that 100% setting.
Some points that I stated explicitly but you seem to have missed:
going back over the same numbers did not always cause the same changes at the same points in the reverse direction - that's the hysteresis that I mentioned;
nothing jumped on or off the page when the jump happened, so no extra room for anything to fill into miraculously appeared or disappeared;
when the bottom frame jumped to the next page the spacing of the systems on the first page decreased rather than increased (and by a proportion much larger than would be expected for a page fill threshhold set at or near its limit);
the other respondent here tried the same incremental setting changes, on the same sample file, and found none of the bizarre behaviour that I encountered.
Did you experiment with my sample file?
I have just tried this again in the sample file that I sent this morning Adelaide time, starting at 4.0, in 0.1 increments, and over a longer range than before.
Remember that automatic fill functionality is effectively disabled by the 100% setting, or should be.
4.4 to 4.5 - the spacing jumps, a big increase, but nothing jumps off the page;
4.6 to 4.7 - bottom frame jumps off the page, big spacing jump;
6.2 to 6.3 - an other big jump in spacing, but nothing to move to the next page at that point, since the big frame still easily fits on the first page;
6.4 to 6.5 - the big frame jumps to the next page, and the systems jump up, more tightly spaced (not down for more open space as they would if a mild partial automatic fill function were active).
Some other thoughts that I just had.
I wondered whether the file has become corrupted in some way, which would have been done by the program, but the other correspondent here experimented with the same file and found none of this behaviour.
Also I wonder whether the program has some automatic fill functionality which is not mentioned anywhere in the help files, perhaps a remnant from some earlier experimentation in development that was not intended to persist.
The fact remains that the program that I have is not working properly.
I won't be demanding a refund though :)
As before, I'm happy to demonstrate the fault via TeamViewer to someone who is in a position to fix it.
Just had another thought - perhaps at the extreme of 100% the fill threshhold causes a problem because of a fault in the code, so I'll try 99%.
Only change that that made is that the first big jump, still with nothing jumping off the page, happened from 4.0 to 4.1, slightly earlier.
So the auto fill is still active, even at 100%.
Next thought - my guess is that the answer is that for some reason, perhaps avoidance of division by zero, the programmers have fiddled the real page fill parameter inside the program to be slightly less than the one entered in the box by the user, perhaps by scaling, eg to around 99% of it, or by subtraction, eg to 1% less than entered, to avoid 0% at the bottom end.
That would explain why it seems to be still switched on, when at 100% it should be entirely disabled.
No surprise - it will not let me enter 101%.
If my guess is correct, then the program needs a separate on/off setting to activate and deactivate the page fill functionality, while still leaving a previously entered page fill threshhold percentage showing.
If those numbers at the extremes are a problem for the program then it should limit the entered range, eg no less than 1% (which is a ridiculous number for a fill threshhold anyway) and no greater than 99%, with the tick box used to kill it completely.
Slightly more code but slightly faster processing too when that bit is completely disabled.
And I have just tried entering 0%, which surprisingly it permitted, but it would not let me enter any negative value.
At 0%, the bizarre behaviour entirely disappears, all smooth increments - until the big frame jumps to the next page, when the staves jump so far apart that they fill the page.
So perhaps, in the code, 0% (effectively) = 100%, until that point, which I'll never reach anyway since I need that frame to remain on the first page.
Laurie
In reply to Holmes to Watson ... by Laurie Williams
Just had a play with your score in both 1.3 and a self built version of the 2.0 development version.
I can report that the behaviour you're describing in 1.3 also happens on my system, the jumps you describe happening at a system spacing of 4.5 and 4.7.
I too suspect the reason is some rounding factor applied to the algorithm.
Spacing works a little differently in 2.0 in that you specify minimum and maximum spacings for the systems.
The first thing you notice is that when you load the score the lowest frame is already moved to the next page, and in fact I had to fiddle with page margin settings on the layout menu to get it to shift back so everything was on the same page.
I strongly recommend that you download a nightly build and do some testing for layout with that, as there will be no more bug fixes for 1.3, focus being entirely on the release of 2.0 which is expected later this year.
One of the issues is with layout problems with loading scores created in 1.3, so any help you could give with that would be appreciated.
In reply to Just had a play with your by ChurchOrganist
Thanks for your response.
Re "when you load the score the lowest frame is already moved to the next page"
I'm only slightly surprised at you saying that it does that. In mine it reopened as I left it, all on the same page.
So you see what I had in mind when I said that I was (effectively) "stuck" because I felt that I couldn't trust the program to keep positioning as I had left it.
Re "One of the issues is with layout problems with loading scores created in 1.3, so any help you could give with that would be appreciated."
Do you mean shortly after 2.0 is available? Or suggestions based on the present onscreen layout behaviour of 1.3?
eg the fact that frequent Reloads are frequently advisable, and essential after doing anything that may move the Copyright box.
In reply to Clarification by Laurie Williams
Do you mean shortly after 2.0 is available? Or suggestions based on the present onscreen layout behaviour of 1.3?
No I mean help by testing nightly build(s) by loading scores from 1.3 into them and reporting any issues in the issue tracker.
I loaded one of my 1.3 scores into the development version the other day, and it had shifted every slur one note to the left and then crashed when I tried to move them.
There are also issues with things like ornament positions not being retained, which is partly due to the positioning algorithm being tightened up.
Basically the faster these issues are idnetified so the programming team can deal with them, the quicker the stable version of 2.0 will be released.
In reply to Do you mean shortly after 2.0 by ChurchOrganist
That makes sense, but I'm wondering the same as I assume many people would be about those nightly builds - whether all of them are early development attempts at 2.0, rather than any of them being minor updates to 1.3 or anything earlier.
I assume all for 2.0 - correct?
In reply to That makes sense, but ... by Laurie Williams
Test, nightly builds are all steps to the upcoming 2.0, there is no development upon 1.3 anymore.
In reply to That makes sense, but ... by Laurie Williams
2.0 has been in development for over 2 years now, so it's not in early development.
As Jojo says, there is no further development on MuseScore 1.x, 1.3 being the last bugfix release.
We are finally getting near to having enough stability issues in 2.0 fixed to be able to think about a stable release soon, although it will be some time yet, as once the programmers have given the all clear, there will be new templates to make, soundfonts to finish off, final tweaks to instrument data, etc
Whilst there are a number of people engaged in continuous testing of the nightly builds, it would be very useful to have someone with the analytical skills you obviously have doing that.
In reply to Holmes to Watson ... by Laurie Williams
Yes, as I said, some sort of rounding seems to be going on. Presumably once your score reaches 99.6% full )or whatever) is consider "close enough" to 100% and the fill still kicks in. Once one takes that possibility into account - and the fact that floating point arithmetic can be slightly non-deterministic - we get to what I said before: nothing about the behavior seems particularly surprising to me. If there is still something that you think isn't explained by this, maybe include just one or two specific examples in another post so we can focus on those.
In particular, you seem surprised by the behavior with fill threshold at 0%. But this is working exactly as it should. A threshold of 0% means always fill the page, and indeed, it *is* always filling the page. That's why systems get so far apart if you page is not already close to full.
FWIW, in 2.0, the algorithm will be different. Page fill is not longer an all or nothing affair. The System distance setting is renamed to what it really is - "Minimum system distance". And instead of a threshold beyond which MuseScore fill the page completely, this is replaced by a "Maximum system distance". So filling the page doesn't have to mean "all the way". Setting maximum = minimum disables fill. It's actually a big improvement over 1.3, but still will take some time to understand how to use effectively.
In reply to Yes, as I said, some sort of by Marc Sabatella
Marc, thanks for your reply too.
Re "we get to what I said before: nothing about the behavior seems particularly surprising to me"
Only if you assume that when the program tells you "No" it really means "Yes" or "I'll still do it if I'm in the mood, and don't bother arguing about it.".
As before - the program does not permit auto page fill to be completely disabled and is therefore not working properly.
Re "you seem surprised by the behavior with fill threshold at 0%"
No, but I can see from my wording how you may have got that impression. It's just as would be expected, yes.
My point about 0% being equivalent to 100% was partly wrong - clearly the program does not interpret 0% as 100% as I said.
But my point about the behaviour (until the fill jumps in) being equivalent is correct in this important practical sense - at 0%, subject to the program fiddling the balances every time, I promptly finished the layout job because I could move everything around with no jumping, as I could at 100% if that setting had the effect that we're led to believe it does.
Re the settings in 2.0, interpreting the two numbers as minimum and maximum would be an improvement.
But the idea of needing to set two numbers to be the same to kill auto page fill (or any other auto function) is a bad one, poorly considered.
Fiddling one of the numbers to match the other would be time consuming and frustrating.
And even if two numbers appear to be set the same, after recent experience how can we be sure that in future no internal rounding or scaling error will happen that makes the program think that two numbers that appear to be the same are different?
Perhaps related to that, many times in the present program I have set text sizes in boxes to 11.00, and sometimes when I return to that text the size is shown as 11.02. How would that be in a box that shows only one decimal place?
I know what I would be doing to disable auto fill in the proposed version - cursor in each of the four character fields (two pre decimal, two post decimal), Ctrl A to select all of it, and enter all four sets of digits.
A nuisance, and even then I would not be entirely surprised if it continued to function.
As I said earlier, a separate switch is needed to do it properly and eliminate all chance of nasty surprises.
A tick box, in the window with the number setting boxes, to completely kill the auto function.
Just flick it on or off! Simple!
Then some numbers can be left in the boxes, to be instantly reactivated and deactivated again at any time to compare the results.
Otherwise, one or both of those setting numbers would be lost to make them match to disable the auto fill, and take both time and memory to restore.
Two boxes may appear simpler than three, but the reality is otherwise.
Simplicity is a good thing, but the appearance of simplicity is frequently a mask for annoying intrusive complexity.
Again, properly disabling that auto fill functionality means ensuring that the program ignores the associated code, and a program structure that makes it possible.
And the arrow increments for all those boxes should be 0.1, not either 0.5 or 1.0, and certainly not inconsistent among the various boxes in that window as in the present version.
In reply to Getting it right by Laurie Williams
You are right, 100% doesn't completely disable page fill, because MuseScore only allows integer values, and therefore rounding is involve. Presumably once you exceed 99%, it round up and fills anyhow. Now that we understand this, everything seems as expected, no? That's my point. Maybe not what you expected originally, but as expected now that we understand how things work.
You seem very fixated on the idea of disabling fill, but why is that so important to you? The whole point of the new scheme in 2.0 is that you should't *need * to disable it. Whereas in 1.3, fill can lead to bad results because it is all or nothing, in 2.0 it will work more smoothly. There won't be "nasty surprises": - just results that look good out of the box.
That said, a check box that basically locks the maximum to be the same as the minimum is a fine idea from a UI standpoint.
In reply to You are right, 100% doesn't by Marc Sabatella
Marc, thanks for this.
Re "Now that we understand this, everything seems as expected"
Again - only if your expectation is that the program will not work as it says it does. Time to leave discussion on that point at that, I think.
Re "You seem very fixated on the idea of disabling fill, but why is that so important to you?" and "The whole point of the new scheme in 2.0 is that you should't *need * to disable it."
If it can be trusted to work perfectly all the time, fine. You, I and other posters and readers here know perfectly well that that will not be the case.
Re "a check box that basically locks the maximum to be the same as the minimum is a fine idea from a UI standpoint"
Not so.
I suggest that you read my reasoning again. You have missed several points in it.
Laurie
In reply to Part way there by Laurie Williams
I think you misunderstood me. Either that or my sarcasm detector isn't working. I *thought* you were saying you thought a "tick box, in the window with the number setting boxes, to completely kill the auto function" was a great idea. Well, I just said the same thing, but in different words - I called it it a ""a check box that basically locks the maximum to be the same as the minimum". But that's the exact same thing.
And in any case, I'm afraid I still think you are being a bit illogical and unfair.
First, you say you expect the program to work "as it says it does", but where does it "say" there won't be rounding? I think we both simply misunderstood and *assumed* 100% would turn off fill, because neither of us took rounding into consideration. I've now realized I was in error in assuming this. Can't you do the same?
In any event, whether you consider it a bug (as you apparently do) or an ill-conceived feature (as I do), refusing to use any future version of a similar feature just because a past version of the feature didn't work the way you wanted- doesn't that strike you as illogical? The much more logical course of action would be to download a nightly, test the new version of the feature, and report any issues you see so they can fixed. Then you won't have to refuse to use an incredibly useful feature just because you are afraid it won't work the way you expect.