Need option to completely disable Auto Placement

+1. Currently 3.0-dev only offers the user the option of resetting or NOT resetting all element positions (for 2.x scores). However, this is surely a redundant choice, given that most, if not all, users are going to want to preserve the existing layout of scores.

Surely, the pop-up dialog box should, instead, offer the option of "Automatic placement" ON or OFF.

Not redundant at all, I for one want that reset (actually a "reset everything to defaults") to then go from there

Why would a user want to reset a score that is already correctly laid out? it's just duplicating effort to arrive at the same result. For example, in the attached score, virtually every text-based element is in a user-customised position. Resetting it would serve no purpose.

Because it isn't. All(most all) of those manual corrections are not (or should not be) needed in 3.0, removing them all manualy is painful.
If you don't wnat positions reset, just don't press OK on that dialog.

JJS wrote: "Al(most all) of those manual corrections are not (or should not be) needed in 3.0"

Guitar fingering symbols are one exception to the rule. IME, most require manual adjustment.

Guitar fingering symbols are one exception I don't use tablature stave so this may be true there, but on a music staff this is now much improved.

No, the request is reasonable.

Regarding this statement: "In particular the collision resolver is a clever idea, but it does this by spacing the staves out vertically, so that my bottom staff sometimes would fall off the page."

Not to be an armchair quarterback :) , but can't you guys make the autoplacement resize the staves when necessary so that the bottom staves don't fall off the page? Someone probably thought of this already, and I know it can be done manually, but why should we have to as long as you're automating layout features?

@WilsonE7: see #278700: Add command to choose scaling based on current layout

We can easily add the command to the tools menu. If users want to avoid using the most important feature of the release, why not?

FWIW, the spacing of staves and systems, while related to autoplacement of elements, is a bit different, and probably if we add a control to disable this, there should be two independent controls. I could easily imagine wanting autoplacement of elements but keep consistent staff spacing and letting me take care of any issues that result myself.

Regarding my comment about wanting independent controls for element placing vs staff spacing - I suspect that too is easy. I would bet a large negative value for minVerticalDistance probably accomplish the fixed staff spacing already.

I could do with this option, for sure. Say you want to perform / rehearse a piece from the sheets and page turning would be awkward. I think that often it is the case "as long as I can read it I don't care much about aesthetics, collision avoidance or whatnot." That's what I love about Musescore 2: the ability to squeeze a lot onto one page. With automatic placement scores bloat a little bit.

See also, #279105: Allow user a greater choice of RESET options.

BTW, we currently have a command for "Autoplace slurs" that seems to literally be just for that. I wouldn't complain if it were repurposed. Although, string freeze...

To me, a shortcut to toggle autoplace for the selected elements is still the more valuable use case to support, compared to trying to disable it completely.

A proposal:

1) we rename existing but undocumented "Autoplace slurs" command to "Toggle autoplace", and implement it by altering the definition of Element::autoplace() to check the corresponding flag MScore::autoplaceSlurs (which we could rename as well of course). Thus, autoplace would be effectively disabled because each individual element would report that autoplace was off when we check it. And yet we'd still be maintaining the actual element flags, so toggling autoplace back and forth would preserve each element's own autoplace status.

2) We have Shift and Ctrl modifiers while dragging that (sort of work) work to constrain dragging vertically/horizontally. How about we add Alt modifier that disable autoplace (only once at the start of the drag, please - no cluttering the undo stack with dozens of change properties!)

Is it critical we provide this for initial release? Probably not, but doing it this way would be pretty easy.

Maybe, Continuous view is the answer to the requests related to the ability to keep score readable but garbaged concerning notation.
I ultimately realized, and I'm sure MuseScore is a notation software first of all. It has a lack of functionality as software for performers. This defines the priority for us and possible improvements in the future. The focus now is better notation.

The scenarios mentioned in this issue are all about performing, not engraving.

Came up again in: https://musescore.org/fr/node/281045

+1 for this potential feature. I use musescore for professional engraving, and this possibilitie would be very useful, i.e. contemporary music publishing where we need special layout and stacking.
For all features, all elements can be place freely if needed (text, symbols...) with v2. It was a good spirit of musescore dev to let the final user free to use the program without limitation. Auto-placement can't become a limitation now. IMHO.

I still like my suggestion above to implement a very simple "disable autoplace" command by changing Element::autoplace() to check the preference flag in Mscore.

Would/should this be a per-score setting? Or a general one?

Per-score (style setting) seems more useful to me, good point. The existing slur autoplace setting is global (preference). Having both wouldn't hurt of course, and the implementation could be the same in terms of just checking both in Element::autoplace(). It's not impossible to check that at each and every place we do autoplacement of course, but a much higher risk of missing something and creating problems that way.

Hi Anatoly,
Not sure I fully understand your distinction between engraving and performing goals.
Engraving correctly is done with one goal: to perform based on the engraving result.
Or not??

I would like this to be a style option.

I have a lead sheet project that is currently on MuseScore 2.3 with a lot of manual adjustments to make sure all the music fits on exactly one or two pages. When I open the scores with MS 3.0, there are a lot of things the automatic placement does that ruins the positioning of chord elements / segnos that result in a visual unpleasantness, and at times making the sheet half a page longer than it is when it opens in MuseScore 2.3.

If I could run the CLI batch job to open MS 2.3 scores, apply a style that disables autopositioning, and then save them as 3.0 scores, we might be able to migrate to MS 3.0 and take advantage of its features.

Attached are PDFs of the same score, opened by both MS2.3 and 3.0.

I'm afraid you don't realize that disabling auto-placement wouldn't really help you keep your V2 layout in V3.
Because all default positioning have changed and V3 doesn't contain the V2 default placement algorithm.
So even with auto-placement turned off, V2 scores containing manual adjustments read in V3 = V3 default placement + V2 manual adjustment = strange result.
The two valid options for V2 scores already correctly done in V2 are:
-Keep a V2 version of the software running next to your V3 (that's not a prob) specifically for these scores
-Try reset and make the effort to redo some manual adjustments hoping that smart layout of V3 limits greatly the amount of work to do (possibly waiting for 3.1 or 3.2 version to have a more "definitive version first if you prefer)
Edit: and to be clear that's doesn't mean that disabling auto-placement option(s) (by element type and/or by score) would not be useful !

HSFlik - if you attach your actual score instead of just a picture, we could better understand what the actual issues are. On the surface, it doesn't really seem like any manual adjustments should have been needed in 2.x, nor should it look different in 3.0 because everything would already be at the default. It does seem you probably neglected to add a line break to the first system in the original; doing that would have helped. But disabling automatic placement there would just result in a lot of collisions - it wouldn't reproduce the 2.x layout, because as mentioned, the algorithms have changed in ways that have nothing to do with autoplace.

Based just on your picture, I'm guessing if you answered "yes" to the question about resetting to remove the no-longer-needed manual adjustments, then added the missing line break to the first system, things would be close to perfect.

+1

+1

I have "scores" (actually "book-like presentations coerced into scores") that would be completely destroyed by auto-placement. Not likely to delete MS2 for this reason. Almost anything in my "Tutorials" set meets this description. A global "no" is required to create new scores in this form in MS3. For everything else though, auto-placement of everything by default is great.

Just curious - you've tested this theory? That is, given that the default layout even before autoplace has changed so that adjustments performed in 2.x often won't make sense and therefore your scores will continue to look different with Autoplace disabled, you've verified they look less different when you manually disable it?

If people are thinking disabling autoplace is the. magic bullet for getting 2.x scores to look the same on import, I am afraid they will.be disappointed, as that really isn't much about Autoplace.

Another good reason: https://musescore.org/en/node/278999#comment-883370
"Auto-placement can't become a limitation now"

"Libro III" of my "Contrappunto Barocco" ( https://musescore.com/user/1831606/scores/5159121 ) is damaged perhaps repairably by opening in MS3 with "don't reposition"; If I then say "reset style", or open it with reposition, it is damaged much worse. The first thing that you see is the vertical spacing of my paragraph text blocks is lost -- blank lines are apparently trimmed. I know, I should find some other engine and venue for such publications .... Is there any real reason why such effort ought be rendered near-impossible?

To be clear: I completely support this option. I can see it quite useful for creating non-standard scores like experimental notation.

I just fear many of the people adding their "+1" are under the mistaken impression that disabling it will lead to their imported scores looking just as they did in 2.x. That just won't be so, because many if not most of the differences are due to other layout improvements. Realistically, with autoplace disabled globally, the vast majority 2.x scores would take far longer to get looking good than with it enabled.

To use the specific example from BSG above, things spacing between text blocks has nothing to do with autoplace, it's a change in the basic algorithms. There may be ways to correct this on import, but they have absolutely nothing to do with disabling autoplace - it's just an impot issue that needs fixing. It also seems there is a bug with autoplace not accounting for figured bass at all, so disabling it won't help - the bug in autoplace needs to be fixed so it can actually do its job there.

Overall, it just feels like people are making unwarranted assumptions about what the advantages of disabling autoplace would actually be. Again, I agree that in particular circumstances it could be useful, but I suspect the majority of people asking for it will be disappointed when they realize it does not in fact solve their problems, and that they actually need to just learn how the new layout algorithms work so they can work with them better, and submit bug reports for the particular things that don't work as they should.

Did you look through the whole score? Vertical spacing between text blocks was the least of it. Elements were strewn all over the place; the red lines striking out certain examples are the most visible. I agree that people will overvalue the ability to disable auto-place, but in my case, IN THOSE SCORES, auto-place is a cure for the wrong problem. If MuseScore had better facilities for building such presentations, it might be a different story, but I would agree that I am stretching it almost beyond its limits, but it should still be possible.

I did look at the whole score. The vast majority of the problems are not fixed by disabling autoplace. On the contrary, they are places where autoplace is not functioning correctly, and places where some settings or other aspects of the default layout have changed so that your manual adjustments are now counterproductive.

Eg, the default position & alignment of staff text has changed, so manual adjustments made to repositon text don't look the same, which is why the text above the bottom staff on the first system is too high, a bug in autoplace causes it to ignore the figured bass and thus create a collision. Disabling autoplace doesn't help with either of those cases. The space between the paragraphs on the first page was due to a blank line that has been deleted on import for whatever reasosn, disabling autoplace doesn't help with that.

The diagonal lines drawn across the staves do need autoplace disabled in order to be allowed to collide with things like that, so simply right-clicking one such line, Select / All Similar Elements, and disabling autoplace on those alone fixes that issue. Note that some lines may have autoplace disabled automatically on import - this happens if the start point was within the staff. Ideally, we'd be able to do it for all lines that cross the staff at all, so that's a valid suggestion to make. Then there are a number of lines where the largish manual adjustments you applied simply don't work as expected anymore because, again, the default layout has changed, and re-doing those manual adjustments will be necessary either way - again, disabling autoplace doesn't avoid that need.

Then there are the staff spacers - you used spacers up in places where spacers down would have been more appropriate (to protect the tall stacks of figured bass below the staves), and the meaning of these has changed so that they will now need to be readjusted - or deleted and and the correct down spacers applied instead - or the bug with autoplace not respecting figured bass fixed.

The point being, sure, there are things that need adjusting in order to import this score successfully - but disabling autoplace globally is not going to help much if at all. Whatever it buys you in saving those 5 seconds it takes to disable it for all lines, you lose in needing to fix the collisions that would otherwise result because the default positions of things are different and your manual adjustments are now counterproductive.

In fact, I'm pleasantly surprised to see this score do as well as it does - it doesn't take that much effort to have it looking as good as or better than 2.x, despite all the complex tricks being played here!

OK, I'm convinced.

You're right, it was 5 minute's work : https://musescore.com/user/1831606/scores/5159121 . Note, however, that the through-slashes, which are correctly red in my MS3, now are grey, not the end of the world, but a bug. Un-autoplacing some text boxes was key. Also, leading whitespace lines now work, if trailing ones no longer do.

I reproduced those problems and others when I reloaded the score, and fixed them readily. But the redness of the lines refuses to "take". I can probably narrow the bug down and report it.

Great!

The failure of the line color to stick on saving is a bug indeed.

So is the spacing of the text frames. If you check the "gap" setting (hard because it's hard to select them at all once they are full of text), you'll see they come in with the gaps set to 0 but end up being saved with gaps of 7sp. That's because the default changed between MuseScore 2 & 3 and we aren't handling it properly. But the correct workaround is, after saving, reloading, and finding the gaps have reverted to 7sp, set them back to 0sp and save again, this time it sticks.

Regarding the lines and autoplac, as I mentioned, we already disable it automaticlly on import if the manual adjustment places the start point within the staff. We just forgot to check the endpoint also, so diagonal lines that start above the staff but then cut through don't have autoplace disabled automatically. That should be easy enough to fix.

If you haven't already, I encourage you to file issues for each of these.

I already filed one for the redness of the lines; perhaps it had to do with rare red moon yesterday. I don't understand the failure scenarios for the other two well enough to file a report. All I know is it ignored by V2 spacing, but you convinced me it was within its rights to do so.

The autospacing of lines, is, I re-assert, an extremely curious concept at best.

The difficulty in selecting the text box when there is text in it is a bug. Alt-up/down (like coincident notes?)?

OK, I will file something about the issue with text gap info in imported files not being saved and lines crossing the staves not having autoplace disabled.

FWIW I just posted this tutorial about a small MS issue https://musescore.com/user/1831606/scores/5402682 , prepared with MS3, and I could feel the power of the autoplace under my fingers, working with me. The 7.0 margins (and the inability to select text frames without shifting the text to expose it) were my only problems.

By the way, I was getting 7.0 text box separation in a totally new MS3 file. That's 14.0 between two. That can't be right -- is that supposed to be the default? How about 1 or 2?

7sp is the default, because it makes sense when we are talking about distance to a staff, not distance to another text frame. It was kind of inconsistent that MuseScore 2 always placed a bunch of extra space (courtesy of vertical frame top/bottom margin) above or below a frame when preceded or followed by a staff but not when preceded or followed by another text frame. I can see it was useful for your use case, but in other contexts it might seem surprising and unwanted. The new behavior is more consistent but obviously not as useful in your case. I think part of the reason for the change is that now the gap setting in the Inspector is now more obviously and directly tied to the style setting (there is even a "set as style" button for the setting in the Inspector). I'm not convinced this all works out in practice as well as in theory, but anyhow, hopefully this helps provide soem context.

Anyhow, what you are doing - putting multiple text frames directly after one another is kind of unusual. I was going to say "and unnecessary" and suggest you simply put multiple paragraphs into a single text frame. But then I realize how clever your method is - it allows MuseScore to place text on a paragraph-by-paragraph basis, greatly facilitating pagination. Nice!

For now at least, I'd think of the rule as being, use the default above/below except when you want stacked frames with no space between them, and for those, explicitly set 0sp (or 1 or 2 as you see fit). Maybe eventually we should consider a separate style settings to control distance between frames, separate from the top/bottom gaps? Trying to think how to have the best of both worlds...

By the way, I'm giving a couple of presentations this week on MsueScore in education. Do you mind if I show your score as an example and talk about some of the techniques you are employing? Feel free to say you'd rather I didn't; I have plenty of my own too...

Please do use my scores (I hope you mean the counterpoint book, not the eighth-note thing) as examples. Try also this: https://musescore.com/user/1831606/scores/5003587
This sort of thing is very, very tricky, delicate, easily broken, and difficult. I wish it were easier. The deficiencies of text boxes (including lack of autofill and hyperlinks) are the largest problem.

Thanks, and yes, I meant the counterpoint. Will check out the other too.

FWIW, I create documents like this by adding the musical examples to LibreOffice if there is that much text - I only use the text-frame-within-MuseScore method for method simpler cases that end up being a lot less fragile. But being able to share directly on musescore.com and also to take advantage of the playback is quite nice.

Actually, come to think about, improving the text facility to make this sort of thing easier could make an interesting GSoC project...

I posted here on "improve text boxes to be more like other text editors", with a laundry list) some months ago: https://musescore.org/en/node/272408 [#272408] .

I filed issues, see:

#282507: Frame gap in imported score lost on save
#282508: On import, diagonal lines crossing staff should be set to no autoplace
#282509: Very difficult to select text frame with a full line of text

You should look at this, too.... https://musescore.com/user/1831606/scores/5008203

In my previous version, I was able to make manual adjustments as to positioning not only for individual elements, but also in the settings on a larger scale ... non of that is possible now ... no matter what I try, I cannot get any element or group of elements to move from their default positions ...

In order to us understand and assist better, please ask for help in the Support forum, and attach the score you are having trouble with and give us precise steps to reproduce the problem. In general, changing style settings should work the same as always, and in fact is much easier now because you can make many of these changes directly in the Inspector, and even changes in the Style dialog are "live" (taking effect immediately without needing you to press Apply).

Sorry, I have said all I am going to say ... please read my issue carefully that explains what was working but now isn't. I don't know how to show you and I am not going to even attempt to do so ... I am hoping to go back to a previous version if that is still possible ... If not, well maybe later, but not today ... thank you and have a great day ...

It's certainly possible to continue to use 2.3.2, in fact we encourage it for existing scores with many manual adjustments. Meanwhile, if you do decide you'd like help learning how to best take advantage of the incredible improvements in 3.0, I do hope you ask on the Support forum when you are ready, as we are always eager to assist!

I honestly wish I had not tried the new version ... If I use it to open existing files it changes the formats and I also can't do with it what was simple in the previous version ...
The previous version may not have been perfect or the best way, but I'm sorry this new version is making a mess of it all as well.
The fact that they aren't even compatible well that too is ridiculous in my mind as I now have to keep track of which program I did what in ...
I definitely plan to go back to the previous version ... at least I was able to do what I needed to do ...

I'm sorry, I am not in a very good frame of mind about this as it seem that "so-called" improvements to programs are intended to make everything more complicated and trying to make things easier for "who?' Certainly not the user ...

As mentioned above, the tremendous improvements in the default layout do mean that existing scores with many manual adjustments that were applied to work around deficiencies in the old versions will not necessarily work so well anymore. I can see why it might be disheartening to see this. That's why we recommend resetting those manual adjustments on import, or continuing to use 2.3.2 just for those scores.

But for new scores, you will quickly discover just how amazingly well automatic placement works, avoiding the need for most manual adjustments at all. I assume you, it really does make things much easier for the user - great-looking scores with no manual adjustments is fantastic! And you really can continue to make manual adjustments as well as update style defaults, and we're happy to help you understand why ypour initial attempts didn't work, if you reach out to us on the Support forum

As for keeping track of which version is used for which scores, just keep your 2.x scores in a different folder than the new 3.0 ones - exactly as we do by default - and there should be no confusion about which are which.

As an example of the power of automatic placement, the following required no manual adjustments whatsoever - try that with 2.3.2!

I'M SORRY, BUT I NEED TO BE ABLE TO MAKE MANUAL ADJUSTMENTS AND THE NEW PROGRAM WON'T LET ME ... SO, THESE ARE NOT "TREMENDOUS IMPROVEMENTS" BUT A WASTE OF MY TIME AND ENERGY ... AND I DO NOT WANT TO HAVE TO KEEP TRACK OF WHICH PROGRAM I USED FOR WHICH SCORE ... I'M TRYING TO PUT A SONG BOOKLET TOGETHER FOR SENIORS AND I'M SORRY THIS IS ONLY MAKING THINGS MORE DIFFICULT ...

I really don't think this is the right way to go about requesting help/features.

Thank you, that was real helpful ... have a great day !

As I said, if you are having trouble understanding how to use the program, we are happy to assist you. The program does let you make manual adjustments, and if you ask for help in the Support forum, we can show you exactly what you need to do.

I am NOT having problems figuring the program out ... it simply will not let me make the manual adjustments regardless ...
I can't state it any simpler than that ... however ...
I hope you are having a great day ... 'cause, I'm certainly not ...

@JanK54 You can do what you want, you're not listening. Start a new thread and ask for help.

No, you aren't listening ...
The new program does have some great features, but SOME THINGS ARE EITHER NOT AVAILABLE OR ARE SIMPLY NOT WORKING AND THIS IS ONE OF THEM ...
I don't have a problem figuring the program out, but this particular feature is not working the way it ought to ... or the way you claim it ought to ...
I need to be able to move things around, but whether I use the "inspector" or the "settings" or any other methods and options ... IT'S SIMPLY NOT WORKING ...
I do not appreciate having to redo things ... or having to switch between programs ... and I'll leave it at that ... Thank you and good day!

I do hear you, and I get that it is frustrating when things don't appear to work as expected. But I want to assure that while some details have indeed changed, manual adjustment really does continue to work. I use it all the time. But until you reach out to us on the Support forum and share more information about your problem, it is difficult for us to guess what is going wrong. So for now we will have to leave it at that.

Whenever you're having a better day and are ready for us to help you, we will still be here waiting to assist you in making whatever adjustments you need to get your scores looking better than ever, with less effort than you thought possible!

FWIW, here is a GIF showing me manually adjusting a single text element, then using the new "set as style" button in the Inspector to make that position be the new default for the rest of the test elements too:

Hopefully this does convince you it really does work, and that we are serious about helping you getting it working for your score too!

This is driving me crazy. I keep disabling the automatic placement of each element and it just keeps resetting itself and moving them all again and magically ticking automatic placement again. I hate it and just want to put my rehearsal marks where I want them! Which is to the left of chord symbols, directly above the treble clef. The ability to completely disable the automatic placement would be fantastic. I might just go back to musescore 2 until this is fixed.

Came up again in https://musescore.org/en/node/283209

I agree with the petition. Please, give us the option of complete disabling the "automatic placement" tool. I'ts a pain in the... it's annoying 9 times out of ten.

Thank you.

Thank you! I couldn't agree more ...
This new version has some good things but that is not one of them ... Especially when I am unable to move anything around (not even manually), in spite of following THEIR directions implicitly ... !

I find it is a blessing 9 times out of 10, but for that tenth time, I'd like it.

Importing a 2.x file into the new 3.x, with the new automatic placement, (whether accepted or denied during the import process), totally screws up the positions of the fingering numbers, (piano). I understand that the algorithm for item placement has changed and so this is to be expected. I don't mind going in and moving all these finger numbers back to the positions I want them, but I do mind having to turn autoplacement off before every single individual move I want to make. Please allow us to globally turn autoplacement off for an entire score so that we can go in and make manual placement changes everywhere we need, quickly, without having to turn it off for every single individual item. Once the changes we need have been made, and the score saved, then we should be able to turn autoplacement back on again, globally, without it changing the work we have just completed. In other words, turning autoplacement back on after items have been manually moved should only apply to new work on the existing score.

You shouldn't have to disable autoplace to adjust positions fo things - it is designed to work better if you don't, in fact. If you have a specific case where you believe there is an issue with fingerings, please start a new thread in th Support forum to discuss it, and attach the specific file and give more information on what you are trying to do.

Meanwhile, if you do for some reason need to disable autoplace for existing fingerings, you can already do that easily (right click a fingering, select / all similar elements, then disable autoplace) without affecting anything else. No need to disable it globally and then re-enable it.

There ought to be a way to affect all -future- similar elements, at least for this score, although it can get dangerous. I should like "all future ornaments 'Baroque', please". "Get them all 'afterwards' " is not useful for a work-in-progress.

I am not going to argue any longer about what this new program can or cannot do, or what it is or is not doing! I will work it out myself and find a way around it or not use it as the case may be ... Have a wonderful day! Thank You!

JanK54, we're not interested in arguing, we are interested in helping you use MuseScore. You mention some problem with moving things using the mouse. Since autoplace in no way prevents this, there must be something else preventing you from doing this, but until we see your score and understand what you are trying to do, we are unable to help. So we continue to encourage you to ask for help in the Support forum and attach your score. If you do that, we can probably have you sorted out in hours or even minutes; no need to spend weeks floundering about trying to figure things out on your own when we are standing by ready to help!

@Marc,
I wonder if the difficulties don't come, at least partially, from some ambiguity on what we mean by "disabling auto placement".
For a given item on the score:
[A on/off] MuseScore put at default position + [B on/off] MuseScore auto adjust position taking into account elements which play the game of auto-position + [C on/off] MuseScore applies any manual adjustments on top of that
And independently:
[D on/off] MuseScore takes the resulting position of item into account to work auto adjustment on other elements (the [B] phase of the other elements)

So:
- Is order [A][B][C] or [A][C][B]? I think it is [A][C][B] in fact
- Turning [A] or [C] off is impossible (and doesn't make sense), ok?
- We can turn [B] or [D] off, but have only one check box "automatic placement", does it turn both off or only [B] ? What about two independent check boxes?

I think you are asking good questions, although I confess I don't fully understand the specific example with the A B C D.

There is no doubt in my mind that a lot of the requests are really "I want my existing score to look exactly like it did in 2.3.2", and that's a completely unrelated issue. I think also people don't realize how pervasive autoplace is in the code at this point. For instance, with autoplace disabled, notes would no longer respace to avoid collisions between lyrics, and similar for other things that were previously handled on kind of an ad-hoc manner. So you'd get scores that not only don't look exactly like they did in 2.3.2, but look far worse and would require unbelievable amounts of manual adjustment just to get even close to useful.

Probably if we ever do implement a switch t disable autoplace, we should make at least some effort to still do some things like avoiding collisions of lyrics, reasonable placement of fingering, etc. Perhaps what it really might mean is, we no longer check things against the skyline. This, I think, gets to your example above. So we still do the things automatically that people expect, but what we don't do is move tempo texts above staff texts - we allow those to collide. Even if this doesn't produce the same results as 2.3.2, it would give a starting point that requires approximately the same amount of manual work to get approximately the same results on average.

What users feel is: Everything is out of my control now!
Users want to check and adjust something.
But while doing so, they hate to have to fight with auto-place.

Add a "Disable Auto-Placement and keep settings (positions)" command. *1
And allow the user to continue adjusting from this point.

*1with "Enable Auto-Placement" command.

The funny thing is that those 7.0 sp are not “distance to staff” because, when you add an Above dynamics and a Tempo, they both go into these 7 sp ☹

Autoplace makes it really hard to figure out from where which distances are measured, and what actual values are used. (But I agree it makes for legible scores by default, just less tight than one’s used to. Still +1 for a per-score global disablement option, and no, not because of 2.x scores…)

I think it looks bogus. The F7 chord symbol is much too close to its neighbours, and having staff text jump between the positions is often not okay (e.g. I tend to line up all my dynamics, hairpins, cresc./dim. in one given stave line so they all match up, and everything else comes above or below that, very unlike your moved sfz). The B♭ jumping likewise is absolutely inacceptable to me.

??? Which score are you talking about? If you mean the hugely contrived worst case scenario example I posted, sure, it could be improved upon with manual. But I guarantee it will be far less work do so if you don't make the counterproductive mistake of disabling autoplace first.

Yes, I am (you were most likely confused because my answer did not appear under your post, https://musescore.org/en/node/284342 is reported ☺), and yes, I agree that’s likely. But it would be good to have that option.

We're getting a bit off-topic, but not completely, so let me just go a bit further here before saying, "more discussion really belongs in the forum".

My feeling is the purpose of the algorithm is to produce very good results out of the box in common cases, and better-than-nothing results in less common cases. Secondarily, it is more important to gracefully handle changes in page size or staff size than to do the absolutely most optimal thing in any one case. Finally, to make it convenient to override the algorithm where needed without losing its benefits entirely.

Looking at the example again:

There is no way for the algorithm to know you want the two staff texts aligned. But if that's what you want, then simply select them both and "raise" the vertical offset until the one on the left reaches the one on the right, then they move together, and everything else adjusts accordingly. If you want the tempo text to drop down into the space below the staff text - not normally advised, since tempo markings are required by standard engraving rules to be above most other text - simply disable autoplace for that element only.

As for the Bb chord, you say you don't want it raised, but what other choices are there? You could flip the fermata underneath - and again do this without disabling autoplace, and the chord symbol falls into place automatically. If you want the F7 higher, and the Bb aligned with it select those two and use the Inspector as for the staff text.

As, with only a few clicks, you can have this:

Maybe that's not quite what you want, but you get the idea - autoplace is helping here, not hurting, an if it were disabled completely, you'd have to not only adjust these same elements to avoid collisions, but you'd also have to adjust everything else where autoplace is doing what you want.

Anyhow, for more discussion on the best ways of working autoplace, I do suggest discussing in the forum, including specific samples scores, etc.

+1 to this as well. I am developing band lead-sheets, and text commentary is added all over the page. previous to 3.x versions, this was working perfectly. I upgraded to be able to collaborate on someone else's score, and discovered that it is now forcing a location for my text annotations.

Autoplacement feels less like a feature and more like a removal of an existing feature.

I consider this a major problem, since it's at the heart of many charts I create.

This is by design. It's a suggestion to rethink the design decision.

You can already disable autoplace for the texts easily. Disabling it for everything would be counterproductive; it's far better to let it do its job everywhere else. Feel free to start a forum thread and attach a sample score so we can show you how to best take advantage of it. I promise you will be impressed.

As I said, in 90+% the autoplace does a good job, if needed with a bit of nudging.

This is about having the possibility to not use it in a score at all, though. Design freedom. And, you know, in most 2.x scores I did (vocal scores), with a bit of styling (setting default offsets for things like dynamics and hairpins), I got almost 0 collisions, so this is a totally valid request.

No one is doubting that there are some small number of cases where it might be advantageous. I am resppnding to those posting "+1" with no real evidence that thIs would actually help their specific situation. Some day the option will no doubt be provided, and my concern is that the vast majority of people requesting it will discover it does not solve their problem a d instead aittle education about autoplace works would solve it right now. So I will continue to offer my house and continue to caution people about unrealistic expectations.

I've been giving thought to how this could best be done.

It occurs to me you can already do this to a large extent by simply setting the various "autoplace min distance" settings in Format / Style to large negative numbers. This allows these elements to overlap others, effectively disabling autoplace for these elements. It's available for some types but not others - the others have hard coded distances. So, one starting point is to just implement more such options. I've got this prototyped and it's interesting to play with. I have style files (.mss) I can load into any score to set all of these to -99 at once and it's basically as if autoplace didn't exist - collisions galore, just as in 2.3.2. Still more that could be done, but also not clear how much should be done, since 2.3.2 actually did its own version of autoplace for at least some elements (lyrics both horizontally and vertically, chord symbols horizontally, fret diagram vertically, some interactions between articulations and slurs, etc, so turning autoplace off completely means scores look even worse than 2.3.2.

Anyhow, I intend to discuss autoplace in my weekly "MuseScore Cafe" series this Wednesday, so feel free to tune in and check it out - see https://youtu.be/QlLxcnzsCrM. If you have any scores you'd like me to feature as I show how autoplace works, how to make most effective use of it, and why, when, and how to disable it where needed, feel free to send them to me ahead of time - marc@musescore.com

Marc… sorry, this is not helping. The way this sounds is “my way or the highway”. I mean, it’s good of you to work on creating a really tight style, but that doesn’t change anything about the fact that an (extremely tiny) amount of scores will do only with autoplace completely disabled (without getting people insane), and a per-score global toggle is the best way to achieve that, and tuning autoplace parameters isn’t. (Not that tuning autoplace parameters is bad… it’s wonderful for some 99.99% of all scores, perhaps, but it will never be 100%, so the need for this knob will not go away, and if you insist on trying to discuss it away, it may not be received well by some.)

I'm confused. I haven't pushed my code yet, how have you managed to test it and determine it doesn't solve the problem? Setting the autoplace parameters to negative values does work, have you tried it? Setting all of them at once is the same as a global toggle, unless you have tested my code and found some corner case where something is missed?

And I can't emphasize enough the importance of people posting real world examples. I think maybe people have the misconception of autoplace as being one algorithm applied in one place in the code that does one thing, that can easily be turned on or off en masse with no effect on anything else. That's not how it works. It's a lot of different pieces of code spread out in a lot of different palces doing a lot of different things, including many things you probably take for granted because 2.3.2 did them automatically as well (like moving articulations up and down along with notes, or spacing lyrics out, or spacing out staves for multiple lyric verses, etc). That's why it is important I see some real world examples to test the effects of different combinations of settings and changes to different algorithms to make sure the options provided really do what people need.

But to hopefully convince you that yes, setting the various min distance parameters to large negative numbers really does work - not just giving a tighter spacing, but allowing overlaps just as badly as 2.3.2 - here in my example file with those settings:

Don’t be this stubborn, it doesn’t suit. You just want examples in order to argue against specific points that can also be done with autoplace, so no example is going to convince you anyway.

It’s a matter of workflow. As I said, I decided to just adopt to the wider spacing and all that, but — having now actually used 3.x for creating scores — while I don’t have an actual example at hand, I can now easily see the need for this.

As for “autoplace also moves articulations” and all that: it isn’t about this. It also isn’t about anything 2.x. This is about a different workflow, in which all positions are set manually, and absolutely instead of relative to the autoplace algorithm. (Also, autoplace changes offsets between versions. While not getting the 2.x results (which, I emphasise again, is not a problem for me, as I’m only considering new scores), I’d assume the autoplace-disabled results are more consistent.)

This is a simple “there’s already a way to disable autoplace, but you have to do it manually in the inspector in every element, so do add a per-score global toggle for that” request. It is already possible to do that, just too error-prone (forgot one element? which one?) and time/effort-intensive to be usable.

I expect this to be used by those who prepare sheet music professionally in an environment where the actual amount of pages counts and/or where there is a strict house style in place already anyway. For those, 3.x is a major regression.

Again, this is not about 2.3.2 but about new scores.

You don’t have to convince me, I believe you (and it’s good that it works). But this is not about whether it can be done with autoplace, but about workflow.

There’s a workflow where you use autoplace and then nudge things into position relative to it.

And then there’s a workflow in which you manually predefine all positions in absolute values, ensuring perfect consistency. This is currently not possible in a user-friendly way.

I am not being stubborn. I am asking for examples so I can best come up with a strategy to produce the results people want. I agree, it's about workflow, and I understand that some people don't want collision avoidance, they want predictable defaults according to style settings. What I am saying, but apparently not clearly enough, is that this is what happens if you set the min distances to large negative numbers (and do the few other tweaks I am working on).

I think if you take a hard and unbiased look at my example, you'll see what I mean. Every single element in that score is exactly where the style default says it should be - autoplace is performing no collision avoidance whatsoever, and every single element is precisely where its style setting puts it. And that's great, for this example. But again, I need to see other examples to understand what people want, so I can be sure to provide independent controls where there is any disagreement about what is desired.

So for instance, if one group iof believe that "disabling autoplace" should mean, "lyrics overlap each other and I want to manually add leading space to each and every note to resolve this", but others want to be able to disable autoplace but still have collision avoidance of lyrics, then that means we need independent control of that parameters, and we can also discuss which should be the default if we also provide a "disable all autoplace". Similarly, maybe some people want "disable autoplace" to mean, fermatas above high C overlap it, and others want disabling autoplace to continue to put the fermata above middle C, so I probably need that to be an independent control, and we also get to discuss which should be the default when disabling autoplace "globally". It's a complex picture and I need to see more real world examples from different people with different expectations in order to understand what is needed.

Please stop thinking of me as the enemy here. I am very honestly trying to help, and would appreciate cooperation in the effort.

For further comparison, here is the same score rendered in MuseScore 2:

I won't claim it's pixel-for-pixel identical - and I get that that's not the goal - but again, the poi t is, the image should prove conclusively that this approach does work to provide the desired workflow.

For the record, the only significant difference I actually see between the 2.3.2 rendering and the rendering with my code is the position of the tempo marking, and that's only because the style default is different between MuseScore 2 & 3.

My guess is that it's more convenient to have something like this:

• By default: First autoplace do its own task.
• Then the autoplace can be deactivated, but the positions set by the autoplace are preserved.
• And after this stage, users can make their own corrections.

Reason: Because, users do not want to fight with autoplace while making their corrections.

"Reason: Because, users do not want to fight with autoplace while making their corrections."
That's right. Exactly.
Very irritating.
So, +10

But isn't that precisely how it works? Autoplace choose a location for you, then you make your manual adjustments with other positions preserved.

Once again, if you have a specific score and a specific use case where things aren't working as expected, please, we need to see them in order to understand how to meet your needs better. Please help us help you by providing more specifics.

!?!?!!? If you try to move something that autoplace has placed, well, sure, it might let you shift it a few pixels if it really likes you, but try to move it an sp or 2 and it goes "NONONONO!!!!" like a little cartoon device and snaps it back to where it wants.

Again, please please please please provide sample scores. I have no trouble moving elements very long distances with autoplace enabled. The one thing you cannot do is move things downward to create collisIons. And I doubt creating collisions is the goal. So once again, please, let's talk in the context of specific scores so we can all better understand the very different use cases being discussed here and find the best set of options to satisfy the wildly different expectations being discussed in this thread. Please!

For example: I want to add a string number under the staff (which is almost always the case).
See what can happen - animation below.
And the answer must not be: disable autoplace! That's precisely what I don't want to have to do: going systematically to the Inspector (I have other things to do...), for each element, and each time, and so on. I must be able to go where I want, when I want, without the program defending it to me, or fighting me!

OK, I do understand your example, but can you see that this is completely different from what others are asking for? You still want autoplace to put other things in good places , you just want manually adjusting to be easier. Totally different from what mirabolis is talking about, which is changing the default placement of each and every element in the score to be at the style defaults, with no collision avoidance at all.

That's why it's important we talk in specifics here, so we can all understand each other and what options are actually needed to meet everyone's needs.

In your case, instead of globally disabling autoplace for all elements - thus making everything in your score collide - a better solution would be for the act of dragging to automatically disable autoplace for that element and that element only, leaving everything in its proper place. Would you agree?

There are complications with that too - what if you only want to drag an element a very small amount, and suddenly find other elements that were above that element now colliding with it because autoplace is disabled (eg, moving a staff text slightly to the right would cause the tempo text above it to drop down and collide, now that autoplace is disabled for the staff text). So to me, one solution would be to have a keyboard modifier to mean, "drag and also disable autoplace". A keyboard shortcut to disable autoplace would also help, then you could press that just before dragging. Another possibility would be a program preference "Always disable autoplace on drag", but I suspect that in real life usage, you'd quickly realize that for many of the drag operations you do, you don't want autoplace disabled (as in my example of the staff and tempo text). I suppose you could always re-enable it via the keyboard shortcut when needed. Still, I'm not sure that's the best model usability-wise.

Anyhow, the point again is, you are not really asking for autoplace to be completely disabled like mirabolis and some others are. So it continues to be important to realize that there are many different aspects to what is being discussed here, and that's why specific examples like yours are always appreciated, to make sure I actually have a chance to address everyone's specific concerns.

Meanwhile, I would also note that instead of dragging the fingerng down, wouldn't it be much easier to just press "X" to flip it, as you can with other markings? I have a PR pending to do that already.

BTW, in the example above, one good reason why flipping with "X" is far preferable to disabling autoplace even for just that fingering is that if you later change the pitch of the note, you'd want the fingering to adjust its position, right? Same really applies to many other cases where one might think at first in terms of disabling autoplace when maybe there are better alternatives. Like in my staff text example, what if there was instead an option to control whether staff text or tempo text goes on top, so you could easily switch them without the need to disable it? That's actually not easy to implement at all, so I'm not actually suggesting it, just encouraging some outside-the-box thinking here about solutions to the actual problems that people want to solve.

"a better solution would be for the act of dragging to automatically disable autoplace for that element and that element only, leaving everything in its proper place. Would you agree?"

For this kind of use cases, sounds very good, of course.

Oops, sorry, I hadn't see the rest:
"Meanwhile, I would also note that instead of dragging the fingerng down, wouldn't it be much easier to just press "X" to flip it, as you can with other markings?"

Yes, sounds good too. Maybe better?

OK, good. I want to have it all :-). That is:

1) help people understand how to use autoplace most effectively, as is
2) understand how we can improve things to allow people to customize autoplace behavior further without the need to disable it
3) understand how we can improve things to allow it to be disabled more easily and provide the expected behavior when doing so (tough, given different people have different expectations here)

So far, things like my PR's for #284347: Add Placement above/below property for fingering and #284235: Too much space between lyrics are intended to help with 2). The code I am currently developing is design to help with 2) as well as 3), which I absolutely acknowledge is still going to be needed no matter how much we do regarding 1) or 2).

Regarding my current work, so far I have done the following

• implemented a bunch more "autoplace min distance" parameters for different element types
• ensured that setting large negative numbers (eg, -99) works to effectively disable autoplace for all elements of the corresponding type
• verified you can load an MSS file containing such values to easily disable autoplace completely, or choose to customize which element types you still want it applied to - thus allowing different people with different opinions of what "disable autoplace completely" might mean in practice to each have a way of getting exactly what they want
• created a framework to allow a single style setting to disable autoplace more globally, above and beyond these inidividual min distance style settings, as per my proposal in https://musescore.org/en/node/278999#comment-879847. This would be pending a better understanding of the consensus on how this should work in practice, though. As I keep mentioning, now that autoplace is involved in the layout of lyrics and articulations, I really think people would find having it completely turned off for those elements would be unbearable. And probably other cases would exist as well. That is why I keep emphasizing the need to develop a consensus based on a collection of real-world examples from a variety of different people and good collective discussion of what a "disable autoplace" setting should actually mean for those scores.

What I currently think is also worth doing:

• a keyboard shortcut to toggle autoplace for selected elements
• a keyboard modifier or preference to cause drag to automatically disable autoplace

These ideas sound terrific.

I have code working on my branch to disable autoplace on Alt+drag, which is only keyboard modifier still available for drag. Question: is this actually available for all supported OS's? I seem to recall maybe Alt+drag moves the current window on Linux. I find I prefer this to messing with preferences, it makes it easy to get either behavior on command. Combined with the keyboard shortcut I have for toggling autoplace on selected elements, I think this should nicely address the "start with autoplace but make it easier to disable it when needed while performing manual adjustment" use case.

It depends on the window manager. Some drag the window when Alt is pressed, some with AltGr, some have other combinations, and most are configurable. (Same for shortcuts, the window manager I use on the desktop has them with Alt, the one on the laptop with Ctrl-Alt.)

In a Unix environment, Ctrl and Shift are the only generally available modifiers, and everything else will not work for some users.

OK< thanks, that's unfortunate. Well, the shortcut will still help.

Since Linux is so unpredictable, I have two possible suggestions. Use shift+alt+drag to avoid conflicts or use alt+drag and put a note in the handbook that some Linux users may not be able to use this feature. I don't think you can redefine mouse actions in the shortcuts.

Alt is caught independent of Shift ;)

There are also many Unix systems that don’t even have an Alt key.

I took mirabolis' comments as suggesting Alt was not reliable for some users on Linux, period, whether combined with Shift or not. But to be clear, the shortcut I meant was the one I am also adding to toggle autoplace for selected elements. Well, I added the command, no shortcut assigned to it yet.

Alt is caught independent of Shift

Does this mean you cannot press both at the same time if the Alt key exists on the keyboard? BTW, I decided not to suggest ctrl+alt due to problems that might be present on some non-English keyboards that could interpret the key combination as altgr.

No, I meant that Alt is captured by the window manager independent of whether Shift is also pressed.

And yes, Ctrl-Alt is the same as AltGr on Windows at the very least.

Just ignore Alt for anything Unix. As I said, that key does not officially exist there.

https://github.com/musescore/MuseScore/pull/4730

This PR adds commands (shortcut can be added in Edit / Preferences / Shortcuts) to toggle autoplace for selected elements and to disable it globally. It also makes Alt disable autoplace on drag, and adds a bunch of new "min distance" style settings to control the margin enforced around different types of elements. As mentioned previously, setting any of these to a large negative value effectively disable autoplace for that element type independently (already possible for staff text, rehearsal marks, tempo text, dynamics, and fermatas).

In a previous comment, you mentioned the X key (but not in this last comment, for a particular reason?)
Basically, in order to avoid the chore of disabling autoplacement via the Inspector for a yes or no, to avoid fighting the program every time, so, in your PR: is can all elements, whatever there are, now be, either ?

1) switched to the other side of the staff with X to disable its default behavior (e. g. string number, above vs. below)?
2) moved near the notes, inside the staff (e.g. with Alt + drag, or/and arrows keys?) and there are hundreds and more (I was thinking for example of symbols/special characters, like specific ornaments and so on, that are not in the palettes)?

Or there are still a few exceptions (which should not, for reasons of coherence), but whose reasons may escape me. For sum up, it is necessary to have an extremely visible, expected, and consistent behavior for each element.
And in the hope that this PR will not wait weeks (as some can unfortunately be) before being merged, so that it can be tested as fully as possible.

I'm not sure what you are referring to, but my PR doesn't change anything about the "X" command - is there some change being requested? BThere is a separate PR to implement above/bow for fingerings, but that has nothing to.do with autoplace.

It is already possible to move any symbol onto the staff - you just may need to disable autoplace for that particular about. Currently you need the insepctor for this. My PR here makes it possible to define a shortcut to make that easier, also makes Alt+drag do this automatically.

I was simply referring to the fact that, for example, the X command is inactive in 3.0.4 to move a string number below the staff, no more no less. And so, the question was whether this PR solves this issue, for this element as for others (whose default behavior would be only above or below right now). Or instead, let's wait until we can test it to get more concrete answers to the new behaviour.

This issue is about disabling autoplace, so the PR for this issue does that and nothing more. There is a separate issue requesting above/below setting and "X" command to flip between them (#284347: Add Placement above/below property for fingering), and hence a separate PR for that issue (https://github.com/musescore/MuseScore/pull/4702)

So, to be clear, the PR for this issue does the following things specifically:

1) adds new style settings for min distances for more element types (textlines, voltas, repeat text, "let ring" markings, etc)
2) adds new style setting and corresponding shortcut/command to globally disable autoplace
3) adds new shortcut/command to toggle autoplace for selected elements
4) allows Alt to disable autoplace for an element while performing manual drag adjustments
5) some improvements in how invisible elements are treated by autoplace

Of these, the most useful I think will be 3 & 4. These are what will allow you to continue to receive all the benefits of automatic placement while making it easier to disable it for some specific element you want to manually adjust. Really, there isn't anything much to test - neither 3) nor 4) does anything different than simply unchecking the "Automatic placement" box in the Inspector. They just provide easier ways of doing the exact same thing. Whatever unchecking the existing "Automatic placement" box does now, the new commands do the same thing. So, very little to test.

The thing that was originally being requested here, though, is 2). The command I added for this will need testing, sure, but it also doesn't really do anything except force all elements to be treated as though autoplace had been turned off for them. So it's like an easy way of turning off autoplace for all elements at once (except that elements each remember if they had been turned off individually). I still have reservations on the wisdom of this, but people are asking for it, and it wasn't hard to do, so I did it.

The first item on the list is more an advanced customization but could be useful for people who want to enjoy autoplace for most elements but who need to disable it just for some specific type of elements - like, if you want autoplace for everything except voltas. The last item is just something that was bugging me, that making an element invisible not only makes it not affect other elements, but it also changes the position of the element itself. I would say 1) and 5) are probably of less interest to most people than the others.

Ok, thanks. Good clarification for a promising PR :)

After going threw the issue and solutions mentioned above I think the one you @Marc mentioned is going to work because we cannot implement a function to completely place the elements free handedly because that would be very hectic to the user to check each element and its position and auto placement also has some issues like colliding ,downfall and it doesn't go according to the user, so the only thing I think is going to work is that we use a toggle button to switch auto placement on or off but and for specific element or
for all.
As, according to my experience the first time I used musescore the auto placement feature prevented me from placing the element where I wanted rather flickering either to left or right colliding with the neighbours. Then I went on researching a bit about scores and then I found that there is no convention as to spacing and all so I thought why is this not allowing me to place the element as where we wanted... But somehow I managed to produce a great track out of it 🙂

I really don't understand why there's such an over-discussion on a simple feature request... Is it REALLY that difficult to understand that there are users that would simple like to 'turn-off (un-check a box) automatic placement for any number of reasons they have... I appreciate the new feature and will absolutely use it when 'I want to/need to'... but it's a total pain in the backside when I am creating pages for students where I placing text and elements in various positions around the page... and for each and every item I have to go to the side bar to uncheck the box...

A simple default toggle checkbox... and done. It could be per score, or a start-up default choice...

That's it. Easy and simple.

Thank you, cmpan5 .

Actually, if you read the discussion, you'll see there are quite a number of very different things people are actually asking about, and in some case they were unaware that the capability they were asking for already exists. So it's good to have had the discussion - some people learned they can already do what they wanted, and for the rest, I managed to come up with a solution that should meet just about all of the varied needs discussed here.

The case of just wanting to freely move text is one of those that is already mostly possible, no new feature needed. Just go to Format / Style / Staff Text, and set the "Autoplace mn. distance" to a large negative value". But indeed, that option is not available for all element types, so my PR adds a bunch more as well as providing several other controls as discussed. Again, based on the extensive discussion here, it should meet all the needs expressed, so unless you have a different need not already discussed here, I think you will be satisfied.

>> Why would a user want to reset a score that is already correctly laid out?

Because the score is a work-in-progress (which I consider virtually every score in my personal library to be). I don't want to be fighting against version 3's defaults for the rest of my time working with that score.

Quit fighting them, learn to use them to your advantage.

Saying that manual corrections are not or should not be needed in 3.0 assumes a level of perfection in Musescore 3 that I'm just not witnessing at all. In fact, I'm doing far more manual corrections now than I have before, including but not limited to:

1. Changing the distance between clef and key (it's suddenly too wide now).
2. Changing min bottom margin of lyrics (the default seems to be 5.0, which is completely ridiculous and makes all kinds of white space that doesn't need to be there).
3. Re-setting many slur lines that float way too high above the notes being slurred.

This isn't just irritating, it's actually bad and sometimes straight-up unreadable. How exactly did any of this get programmed as standard into the third edition of the program? I expect improvements, not devolution.

Don't use manual adjustments to change distance form clef to key etc - use the settings in Format / Style / Measure. You're right that the default changed, though, not sure why - I don't have my copy of "Behind Bars" handy to compare. In any case, autoplace has no relevance to this - you don't need to disable it to add leading space or change horizontal offset of a key signature. but again, don't do that - just change the style setting.

Default lyrics bottom distance is not 5.0sp - maybe you have some particular scores where you set it that way yourself, to work around the lack of automatic staff spacing there? The default in MuseScore only 2.0sp, so just open Format / Style / Lyrics and reset it there for older scores. In 3.1, we will automatic correct this on import.

Regarding slurs, I encourage you start a new thread in the Support forum and attach the specific score with a problem. In general, slur positioning should be much better than before, but no doubt there exist some corner cases where things don't work as well, and we'd like to fix them.

Thanks I appreciate the reply. It's odd that the default would have changed without anybody's noticing...? But anyways...

I'm poking around now with using Styles. Makes sense - thank you.

As for slurs - I can save some examples of slurs gone wonky and post those.

Also, you're right about the Lyrics positioning - sort of. The default for a new score is indeed 2.0. However, all my Musescore 2.0 scores come with a Lyrics position of 5.0 or even 6...for some reason. I definitely never set them to that. :/

Cheers,
-Gidoza

Maybe you used a template that did this? Default in 2.3.2 is 4.0sp, which was chosen conservatively (as in, maybe bigger than necessary) to avoid notes above the staff below. Now that automatic placement handles these collisions for us, we no longer need this padding, and that's why 2.0sp is more appropriate.

To be clear, in 2.3.2, I am talking about "Lyrics bottom margin" in Style / Genera / Page. This is totally separate from position. In 2.x, position of all elements was measured form the top staff line, which wreaked havoc on staves with other than five lines. In 3.0, elements below the staff are measure from the bottom line as you would hope. So a smaller offset for position is definitely appropriate, and we doi already perform that adjustment automatically on import.

Yes, please, please, one click only to disable automatic placement of notes! Please, please, please!

'click'.... globally turn on Auto Placement. Now I have for all objects.

'click'.... globally turn off Auto Placement. Now I chooses which objects.

'click'... my 'startup' choice in preferences.

TADAAAAAAAAAAAA! As simple as A B C.... 1 2 3... Ah... life can be so simple at times...

This is the gist of what people are looking to do... so why not simply consider it and 'tell us' you are?

See above, there is already a PR pending to add more options.

But, autoplace has (almost) nothing to do with notes. Not sure what you were expecting disabling it to do with respect to notes specifically?

I wrote notes but I meant fingering! So please, please, one click only to disable automatic placement of fingering! Please, please, please!

Yes, I (ab)use "fingering" a lot to denote "illustration points in score" (e.g., http://musescore.com/bsg/continuo1 , also an excellent new example of "vertical frame" book publishing). Auto-placement got most of them right, but I had to disable it on many, and could use "disable auto-placement by item class" effectively.

What do you guys think about the following thoughts?

There are basically two different user scenarios: writing and engraving.

When one creates a melody for all instruments, he/she only cares about notes and their attributes (pitch, duration, articulations, spanners, accidentals, etc.) and measure attributes like text, lyrics, clefs, time/key sigs, etc. He/she should not care about page formatting, spacers, titles and other information. The only thing really needed is the UI which focus you on entering melody and more or less meaningful autoplacement.

When composer finishes creation of the melody, it is time to prepare the score whether to publishing online or printing. This is the next step, when users don't care about entering notes, rests, articulations, etc. The only thing which is absolutely necessary is manual placement of all elements and page layout. Automatic placement should be turned off for all elements, but the initial positions calculated during smart layout must be kept.

Sometimes people don't need engraving at all, because they want to use the score in digital format only and play/perform/share using musescore.com.

Separating workflows will allow us to simplify interface and avoid using the inspector in Writing mode and significantly simplify palettes and even avoid spending resources on playback in Engraving mode.

What do you guys think? Does it make sense? Does it resolve the infinite war with the automatic placement in this thread? :)

Too radical a change; I am not sure how well this would work "scores" like the one I just cited, which are more "books with musical examples", where the formatting is as important as the notes at every point.

@Anatoly-os
https://musescore.org/en/node/278999#comment-897859

And read the next answer (Marc Sabatella's).
quote "But isn't that precisely how it works? Autoplace choose a location for you, then you make your manual adjustments with other positions preserved."

I am not sure I understand what you are suggesting. While, in theory, I could see dividing my work cleanly into note input versus page layout stages the reality is most of us constantly move back and forth. I gather this distinction is something seen in Dorico? If I understand where you are going with this, maybe you are seeing a new mode where you don't enter notes but instead do manual adjustments, and upon switching to that mode, automatic placement adjustments get converted into fixed offsets you can then adjust from? I don't like that at all if it means I then lose the benefit of automatic placement forever in that score - unless you propose somehow pulling those adjustments back into "normal" mode when I'm temporarily done with page layout. Maybe there is a way to make that work, I don't know, it seems way overcomplicated.

My PR as it stands is quite simple and works well without requiring any fundamental shifts to anyone's workflow.

In the message in question: I tried to explain the same thing as in the message I quoted below:

Quoted from Anatoly-os:
When composer finishes creation of the melody, it is time to prepare the score whether to publishing online or printing. This is the next step, when users don't care about entering notes, rests, articulations, etc. The only thing which is absolutely necessary is manual placement of all elements and page layout. Automatic placement should be turned off for all elements, but the initial positions calculated during smart layout must be kept.

And if we don't like what we do at one stage, there's always a chance to reset the positions and start over again with automatic placement!

Mr. Sabatella;
I think the following point is important
(After a certain stage) When we disable the Autoplace, the position of the elements should not be changed. On the contrary, it must be protected (like the freeze command in Sib).
Without this, using or disabling autoplace won't help anyone.

I'm not against Autoplace. And I believe the Autoplace feature is good.
However, in the last step, the user must be able to disable the autoplace (and the element positions are must be frozen by the software).

Therefore disabling autoplace does not mean that you will not use it.
If you start using it first and disable it at some point, you should be able to continue from where it was left (keeping positions).

If you have disabled it from the beginning (because autoplace hasn't made any adjustments yet), MuseScore software acts exactly like 2.3.2.

Thank you in advance for your understanding.

Hello Ziya Mete Demircan,

“When we disable the Autoplace, the position of the elements should not be changed” is wrong. This feature request is about a global toggle, which is easy to implement. It’s about living with autoplace or not. (If you wish to have a freeze positions feature, please open a separate feature request for that. It has all kinds of problems, such as, what anchor relations are frozen / what is the position base. Please do _not_ mix these two feature requests; this thread is already overlong.)

If you wish to disable autoplace only for some elements, then do these manually.

Also, this is wrong: “If you have disabled it from the beginning (because autoplace hasn't made any adjustments yet), MuseScore software acts exactly like 2.3.2.”

MuseScore 3 cannot act exactly like 2.3.2 because it does not implement the layout algorithm of MuseScore 2.x at all and has differing built-in style defaults. Furthermore, the internal workings of some things changed completely.

What you all need to realise is that, even with autoplace enabled, moving elements around (at least by adjusting in the inspector, I don’t do it any other way because I wish to have nice, round spatium numbers in my offsets) is still possible.

The only hampering thing is what dhfx said: “seeming to have a mind of its own as to where things should be placed (much more than in 2.3.2), such as increasing the vertical spacing of staves so as to avoid collisions, causing the bottom staves to be pushed down off the page (in contrast, 2.3.2 is like working on preprinted manuscript paper”.

What everyone needs to understand is that disabling autoplace globally will overshoot into the other direction:

  MS3 with AP                                   MS2       MS3 w/o AP
  |<-------------------------------------------->|<--------->|

Sure, the distance will be less, but you will lose layout helper features that MS 2 had, because you insist on doing it manually.

What Marc Sabatella needs to understand is that the wish to do this manually is totally natural and ought to be honoured. “We give our users rope” is a common Unix principle: the power to do anything with it they want, even hang themselves.

Implementing a global disable autoplace toggle (as a score option) is no more than:

• add a new score option (with entry in the file format, the menus, perhaps also saved in MSS files)
• changing bool autoplace() in libmscore/element.h to take this new option also into account (and any other places where not this macro is called)
• if you want to do it nicely, grey out the autoplace flag in the inspector when this global option is enabled

So, why’s this not available in 3.1-alpha (git master)?

(Perhaps I could do a PR, but I’m a bit lacking in time to test this atm, plus I’m somewhat frustrated because I have several other PRs waiting for merging, some waiting for feedback, etc. for ages.)

@Ziya Mete Demircan you write "When we disable the Autoplace, the position of the elements should not be changed. On the contrary, it must be protected (like the freeze command in Sib).
Without this, using or disabling autoplace won't help anyone."

I'm sorry but this is just not the case. There have been many arguing for exactly the thing you say won't help. They don't want autoplace to first move things and then issue a command to cause it to leave the already moved things alone but not move anything else. Quite a number of people in this thread as well as forum discussions and feedback we have received elsewhere who don't want autoplace to even start moving things - they want their style settings for position to be honored without interference. So that's actually what the command I have implemented does.

it would no doubt be possible to also implement a "freeze" command - one that locks current elements into their positions. Such a command could be useful in conjunction with disabling autoplace, but it potentially be even more useful without disabling autoplace. There is also the question of whether such a command would only act on existing elements or would it be automatically applied to newly added ones.

There are lots of different use cases here, each with their own specific needs. That is why I have been practically begging people to provide specific examples of how they see this working. As it is, I implemented what I did because it seems clearly useful, not a major change in the usage model of the program, and not hard to implement. if you want to start a new thread describing specific use cases and expected behaviors for an additional proposed "freeze" command - which is different from completely disabling autoplace - I encourage you to do so. I'd recommend doing it in the forum where more people will see it and participate.

@mirabolis I do understand that what you are asking for is natural, that's why I implemented exactly that. Again, are you saying you've tested the PR and found some sort of issue with how it works with respect to some specific element on some specific score? If so, I encourage to comment on the PR thread, and attach the score in question. But in my testing, it works perfectly.

Oh, sorry, I completely missed the “PR created” status change. My mistake.

Fixed in branch master, commit 6b7f33ec64

fix #278999, fix #288474: autoplace customization

To address the "make it easier to disable autoplace while still keeping its advantages" aspect of this: there is now a (customizable) keyboard shortcut "=" that will toggle autoplace for the selected elements. You will also be able to disable or enable it for "mixed" selections using new buttons in the Inspector. Alt+Drag will also disable autoplace, but see below. There are also new "min distance" settings available to control minimum distance for element types that lacked them previously. No UI for them yet but you can edit a MSCX or MSS file for now.

To address the "I just want all elements to have the default position from their style settings, as if autoplace never existed" aspect, there is a new command "Toggle Automatic Placement globally" for which you can assign a shortcut to in Edit / Preferences / Shortcuts. This does what it says - the effect is the same as disabling elements for all current and future elements in the score.

To address the "I want autoplace to place things intelligently by default, but then I want to be able to freely move them", I am also working on an additional facility that will provide this. The gist of it is, when moving an element, you would leave autoplace enabled so other elements would avoid the one you are moving, but you would be able to move element itself more freely, including onto the staff. No guarantees on that, but it seems promising.

Thank you for your hard work on this.

Yes, thank you very much for this work and this new step towards making it easier to make the program more flexible.
I haven't had too much time right now to test it a lot. The shortcut "Toggle Automatic placement for selected elements" seems the most obvious to using, and should address most of the need to stop going to the Inspector for a yes or no in order to disable automatic placement. If only for that reason, it is a huge step forward.
I also saw the tabs in the Inspector (as for "Visible", "Invisible"). Good idea.
On the other hand, the deactivation of the automatic placement by Alt + drag is not usable as it stands, in any case, it is disconcerting. Simply because the dragged element jumps (after releasing the mouse) to a place that is difficult to predict. To summarize, it does not land where the mouse releases it. Maybe I misunderstood something (I tried with a string number)
And also, always with a string number, and to return to the first shortcut mentioned "Toggle automatic/selected elements": when you activate it, of course, you lose the benefit of the anti-collision feature. But in this case, I would rather expect - at first - that the shortcut would not move anything (or in a minor way?) As if it were first put on hold of the user's decision. Because here, the string number (at least the circle) comes hitting the note head. Possibly, then, it is necessary to untangle the "free" (!) element of the notehead. With the mouse, this can be an additional burden. But, with the direction arrows, it's fine, so, minor problem I guess.
Thanks again Marc. Really appreciated effort and work.

Thanks for the feedback!

I agree the Alt+drag behavior is a little odd. The problem is that disabling autoplace may changes the default position, so the offset you are applying might not make sense any more. But the second drag will then work normally. So for people who prefer using the mouse, it's still an option, if a little awkward. But if I succeed with the work I am doing to make it possible to drag elements onto the staff and keep autoplace enabled, I think you won't even want Alt+drag. I'm still struggling with compatibility issues on that. It's actually working quite well if you don't need to load scores from 3.0.5 (or 2.3.2), but I want to find the best way to make it work for existing scores too.

"But the second drag will then work normally"
Correct, I saw that too.
"But if I succeed with the work I am doing to make it possible to drag elements onto the staff and keep autoplace enabled, I think you won't even want Alt+drag"
Wow, better and better!

I want to follow up on the this. Anatoly and Ziya both make the point about wanting a user model where you first let autoplace do its thing, and then you can move things freely after that. Anatoly writes of this as being separate phases of work, but others (incuding me) expressed concern that we might prefer to do adjustments as we go. Ziya writes of a special command to freeze positions, at which point autoplace is off and you can adjust freely from there. That's certainly doable, and for a while I was thinking of implementing such a command, but this is problematic too. After all, if you then start moving notes etc, those frozen positions don't make sense. It's more of "relative" position you want to freeze, at least some of the time. And there are questions of whether one would want to freeze all elements or just selected, and how frozen elements would affect the position of other elements. So to me, such a command may solve one problem, but I still don't it completely addresses what many people really want - to have autoplace do its job but then let you adjust freely, any time you want, anywhere you want, no extra steps required.

So, what I have been working on is just that - a way to freely adjust the position of elements without disabling autoplace, switching modes, or issuing extra commands. It doesn't force any changes to how anyone works - it just allows you to move any elements freely. Basically, autoplace continues to place elements as it currently does, but at any time, you can then move them pretty much anywhere you want, without disabling autoplace, without issuing a separate freeze command, without switching to a new "engraving" mode.

It feels extremely natural in actual use, I think. Here is what it looks like in action:

I accomplish simply by adjusting the "autoplace min distance" setting on a per-element basis as you move things into places that autoplace wouldn't normally allow. It's like autoplace is now saying: "by default I wouldn't let you in here because min distance is X, but, because you specifically asked, I'll lower min distance for you just enough to allow it". The per-element min distance is exposed in the Inspector so you can also have more direct control of it, and the "set as style" buttons works too.

What's especially interesting about this is that autoplace remains enabled, so even though you've moved an element into the skyline area, other elements can continue to avoid it, and it continues to float up and down as the skyline changes. So it's really the best of both worlds, I think. Of course, if you don't want that, you remain welcome to use "=" or Alt+drag or the Inspector to disable autoplace for the element.

I have a PR for this: https://github.com/musescore/MuseScore/pull/4982. If you are on Windows and would like to test it without building it yourself, try https://ci.appveyor.com/api/buildjobs/rfcx1oxrueuxa352/artifacts/MuseSc…. There are some other improvements here, like enabling the "X" command for more element types, and automatically detecting attempts to move an element to the opposite side of the staff and fixing up the placement and offset for you. Plus it cleans up the glitch mentioned above where sometimes an element jumps after releasing when dragging.

Feedback welcome!

"So, what I have been working on is just that - a way to freely adjust the position of elements without disabling autoplace, switching modes, or issuing extra commands. It doesn't force any changes to how anyone works - it just allows you to move any elements freely"
"It feels extremely natural in actual use, I think."
"What's especially interesting about this is that autoplace remains enabled, so even though you've moved an element into the skyline area, other elements can continue to avoid it, and it continues to float up and down as the skyline changes. So it's really the best of both worlds"

Absolutely. I didn't try it for hours yet, but this PR is just perfect in my opinion. So many thanks to you for that. Applause :) It was really the last black spot that irritated me, euphemism, which broke the workflow (and that real plague to go in Inspector all the time to disable automatic placement - I was starting to hate this Inspector!)
And from now on, and for the first time, I can say that I LOVE version 3 ! (...well, except for known regressions, considered minor apparently, but which are annoying/unpleasant on a daily basis)

Don't just read it; Please try it !.
Download the software from the link provided by Mr.Sabatella and use it for a while.
You will see how it works in a natural flow.
And you will even forget that the autoplace is there.
Trust me!

Edit: And there is no need to "freeze" command anymore.

I'd be eager for a Mac build.

The PR is now merged (!), so it should be Mac nightlies.

Congrats. 👌

Will check out, thanks.

Wow, excellent work Marc!

Thanks! For the record, it's really just taking Werner's excellent foundation and going the next step in managing the "autoplace minimum distance" setting on a per-element basis.

I wish this version could find a score of Dylan's "I shall be released", if you know what I mean. I just had to rip out a harpsichord part from a score I posted because the .com engine still has the "hidden voices affect spacing on others" bug.

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