Should leading (and trailing) space be reset in imported scores?
Subsequent to this thread: #280911: Grace note at start of score leads to bad layout.
If you import MS 2.3 scores (say) into MS3, the leading (and trailing?) spaces on notes are retained. IMV, it might be better to automatically reset these spaces to zero and leave the correct spacing to be determined by autoplacement.
Comments
Agreed. I think all manual adjustments, related to location, should be reset when you tell version 3 reset changes made in version 2. The one exception is when an item is moved below the staff, the the position should be changed and offset reset to 0.
In reply to Agreed. I think all manual… by mike320
What about shape-related adjustments? We're currently inconsistent about this.
In reply to What about shape-related… by Marc Sabatella
That is why I explicitly stated "related to location" except moving above or below. I was thinking specifically about x & diamond note heads, which should remain x & diamond note heads and so forth. This is because version 3 does nothing with them that version 2 did not. They don't affect automatic layout in a different way than normal notes. Other factors not related to location include small notes and invisible notes. I'm probably missing something, probably even important, but if it affects the location it should be returned to default, otherwise it should be left as it was in version 2. If this turns the score into a total disaster, this is a perfect example of a score that's better off being left in version 2. Of course the user could answer no and the user location changes should be kept. That's not usually a good option from what I've seen, though it should still remain an option.
In reply to That is why I explicitly… by mike320
Definitely noteheads etc. shouldn't be. The question mark is more about things like shape of slurs, manual adjustments to length of hairpins and other lines (we all know at least some of these are flat out wrong and should have been an anchir change instead) and so forth.
In reply to Definitely noteheads etc… by Marc Sabatella
In honesty, manual adjustments to lines should be handled better in general. People do not want hairpins and slurs extended to look like they cover the next 3 measures but in reality they only cover the next 16th note. Until this is fixed, it is best to leave these changes as the user put them and let them see the error of their way and hopefully ask what's happening so one of us can teach them.
I do understand the reason for the different effects of the various methods of adjusting items from the lines palette, but it should be smarter. When the user drags the end of the hairpin past the next note, the anchor should move to that note in a manner similar to dynamics changing their note anchors when they get dragged. I also realize this is no minor change. I didn't have to have our conversation about the shift key and palettes or even build MuseScore myself to understand this is not likely to be a one line fix.
In reply to In honesty, manual… by mike320
You know, since the code already exists for dynamics, and for slurs, it's probably not actually all that hard to adapt it to work for other lines (and frankly I'd love to remove it from dynamics). A little copy & paste, a little renaming of things here and there, etc. We'd probably want to make it so holding Shift or whatever disabled the anchor change and allowed the fine-tuning.
In reply to You know, since the code… by Marc Sabatella
I think the current results of ctrl & shift are fine for those of us who know how to use them. What needs to be fixed is what happens when the endpoint is dragged as is the instinctive action for users. Their expectation is that the dragged line will work as expected and not leave the anchor point several measures away. In the case of voltas, I would make it automatically extend the volta to visibly cover complete measures only and perhaps have ctrl+drag allow for fine tuning of the end points so the hook or number doesn't force the line to move up to avoid text or other things. I vote for ctrl to disable anchors since that's the way to fine tune lines with the arrows.
I have no major problem with the current results you get from dragging dynamics around, though you do have to be careful not to change its anchor point to the adjacent staff. I take advantage of the change in anchor points to move dynamics from voice 2 to voice 1 on occasion, too bad it doesn't work the other way around.
In reply to I think the current results… by mike320
Right, that's what I mean, change it so plain drag works the same for other lines as it currently does for slurs and dynamics: changes the anchor. But then there would be no mouse-based way to do fine adjustments, which is why I suggest having either Shift+drag or Ctrl+drag do what plain drag currently does. Right now Shift+drag does nothing whatsoever - you can't drag while Shift is pressed - and Ctrl+drag is no different from plain drag.
And I'm not suggesting changing anything whatsoever about behaviro of cursor keys - Right/Left and Shift+Right/Left would be unchanged. The only thing that I'm suggesting changing is drag. And as I said, since the code is there already for slurs - the changeAnchord() function called within SlurSegment::edit() - it's probably not much work to do the same for other element types.
But - since Louis Cloete is also working on changes involving line anchors, probably the work should be coordinated.