Request auto-placement of generic "lines" be optimized for different purposes

• Dec 19, 2018 - 01:11
Reported version
3.0
Priority
P2 - Medium
Type
Graphical (UI)
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

Title says it all ---


Comments

Title Auto-placement of generic "lines" is less than useless Request auto-placement of generic "lines" be optimized for different purposes
Status active needs info

Sorry, you'll have to be a lot more specific. What are you personally using these "generic" lines for, and in the specific context of that usage, what placement would be preferable? As it is, the placement is designed to sit beyond the closest elements such as articulations, tuplets, slurs, and dynamics, but be closer than most other text and symbols. This seems perfect for, say, string indications and similar purposes, also seems reasonable for the kind of annotations one might do for music theory / analysis. but no doubt there are other purposes for which sitting either closer to or further from the staff would be preferable.

Realistically, there is no way one single placement is going to work for everything, but since these are meant to be generic, I could imagine using "stacking order" (or a new field specific to autoplace) to give some options.

There is an element called "Line" in the "Lines" palette. As far as I know, it has no musical meaning at all. It is there to do whatever you want with; I have used it in MS2 extensively to show voices or hands switching staves, or parallels of one kind or another, or connecting a text block to what it is talking about (extensively in analyses). There is absolutely no notion of the 'usual', 'probable', or 'standard' use of such a generic element. As soon as one tries to position it, of course, AP slaps your hand. It just doesn't understand what "generic" means. See, for example, https://musescore.com/user/1831606/scores/3484071 for countless uses in color.

Let me reduce it to a campaign slogan: automatic placement of generic elements is categorically inappropriate in all cases.

In reply to by BSG

Sounds like most of the uses you describe are better accomplished with the Add / Lines / Note Anchored Line.

Anyhow, again, more specifics would still be useful. Connecting a text block to a specific element does indeed seem one case for which it is a natural choice and for which disabling autoplace would be useful. Now, I would say you're welcome to add a customized version of the line (with autoplace disabled) to your own palette, but this doesn't actually work - the setting doesn't stick. That much would seem a nice enhancement.

Anyhow, as I mentioned, for many uses like string indications and musical analysis, the current default is very good. If you have a different use, you are welcome to disable autoplace, but I see no reason to penalize those who happen to use for one of the purposes for which is does work well. In other words, just because it doesn't work well for your particular use case doesn't mean it has no value for anyone else.

You were clear. I thought I was equally clear about why I thought making autoplace not be the default for everyone just because it is sometimes inconvenient for you is not a good idea. It's easier for one person to disable it when needed than it is for everyone else to have to enable it.

Also, I thought I was clear that I support making sure the autoplace setting is preserved on custom palettes.

Could you please tell me of the case where the default placement of a GENERIC LINE, not a fermata, trill, or tenuto mark, above the staff at approximately one staff space, extending from this note to the next, is exactly correct? I don't think we are communicating.

I would agree maybe 2-3sp would be a better default offset, but you'd still absolutely need autoplace enabled so that the line avoids notes above the staff, articulations, etc.. And I already mentioned the cases I had in mind - string indications, score annotations.

Indeed, you're welcome to participate :-) Here's the link to the Handbook for MuseScore 3, which we are collectively in the process of updating: https://musescore.org/en/handbook-3. Realistically, though, I don't know that anyone has necessarily figured out a strategy for documenting autoplace specifically. Worth discussing in forum.

Yes, it is an extremely powerful, and in MS3, central mechanism, which, if it works properly, you might not even realize is there. But when you try to place some text, or line, or what have you, and an invisible hand comes out of the box and says "No!" in a little high cartoon voice and places it back, some explanation, and way of arriving at it, will be required.

Funny you should mention that :-). I just last night submitted a PR for a new "tour" that will pop up the first time you try dragging something, explaining a bit about autoplace (including how to disable it). I've got a whole list of similar "tours" I would eventually think about adding (to be prompted by a user doing something where we can kind of guess ahead of time maybe he will be surprised), but this seemed one of the more important things to explain right away.

Status needs info active
Priority P2 - Medium

Concrete suggestions:

1) we change the default for the line to be 2.5sp or thereabouts
2) we provide some sort of control in Inspector over the "autoplace order" - maybe just for these generic lines at firs,t but with eye towards maybe eventually allowing customization of more elements
3) we provide a simple way to disable autoplace at the moment you are dragging something

I don't favor that for the reasons I've explained (it's very useful in many cases), but I would add "preserve autoplace setting when adding lines to custom palette" so you can create your own "no autoplace line" if you want. I still think the vast majority of places where people think they want this, they really want a note anchored line, and the more important problem is figuring out how to expose that feature better, since it is essentially unknown to most people.

Most of the lines I draw are indeed note-anchored, but to the head of the note; the other end is always to some text, some note on another staff, etc. I have never ever wanted, or seen, a line from the place where an articulation or ornament would be. How could the app ever guess what you intend to use the line for!?!

I would like a line anchored to two other objects, including note heads, text boxes, etc. It has a need to be "closer" to the note or note head than an ornament or other categorically note-anchored object.

Understood. The note anchored line I keep mentioned does exactly that - it tracks the notehead as you change pitch, works cross-staff, etc. It actually touches the notehead, I'd prefer to see a little breathing room maybe, but I generally add that a manual adjustment. Anyhow it is very clearly exactly what you should be using in many cases, which is why I keep mentioning it, and it's not clear if you've tried it yet.

But the note anchored line designed to connect two notes specifically, not a note and something else, so it doesn't handle your case of wanting a line from a text element to a note. In principle, we could introduce a new element type, a one-side note anchored line that would be simialrly attached to one note but be freely adjustable on the other end. Or, a new "annotation" element that could be attached to a specific note and would include an optional "line" property (the annotation developed but not merged for GSoC a few years and neither of those features - it was just staff text you could toggle the visibility of en masse). Either of these (line or annotation types) would be nice suggestion, probably best suited for separate issue reports.

In reply to by Jojo-Schmitz

I hadn't noticed this. I selected a note and tried it; did nothing. Selected a region of a couple of notes. It put a line above the staff, having nothing to do with the notes three staves down I had selected, and I can't move it. Is this working as designed? So I turned OFF "Automatic placement", and it THEN AUTOMATICALLY PLACED IT CORRECTLY (i.e., spanning the two notes). WTF ("Well-tempered Flügelhorn")? It did this repeatedly, i.e., three pairs of notes I tried. What is the contract here?

As Marc mentioned, a little known feature...

You select 2 note heads, which don't need to be adjacent (like they'd need to be for a glissando) and then add that line, And, with autoplace disabled (which it better should do by default), it connects those two note heads

Can a note-anchored line be added to a custom palette? I have tried adding a custom dashed line to my Lines palette, but when I highlight two notes and try double-clicking the new object on the palette, nothing happens. I may have added it incorrectly, but I'd like to know if this is possible.