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.
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.
I didn't say anything like "Get rid of autoplace!" or even "I'd like to disable autoplace!" I said make it not be default for certain elements. I thought I was pretty clear.
Why don't you allow us to disable auto placement like we change other options on elements added to a custom palette, then we can make any lines we want.
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.
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.
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?
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.
Comments
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 There is a element called … by [DELETED] 1831606
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.
In reply to Sounds like most of the uses… by Marc Sabatella
I didn't say anything like "Get rid of autoplace!" or even "I'd like to disable autoplace!" I said make it not be default for certain elements. I thought I was pretty clear.
In reply to I didn't say anything like … by [DELETED] 1831606
Why don't you allow us to disable auto placement like we change other options on elements added to a custom palette, then we can make any lines we want.
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.
OK! Documenting this properly may be challenging
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.
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
4) have autoplace set to off for that line in the palette?
In reply to 4) have autoplace set to off… by Jojo-Schmitz
Shhh! Marc doesn't want to hear that! : )
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.
Maybe we're not talking about the same element. Which is the "note-anchored line" you are describing?
Not from the palette. but from the Add menu
In reply to Not from the palette. but… by Jojo-Schmitz
Can you include an image so I can find it?
Menu-> Add -> Lines... -> Note-achored line (in attempt to translate the German terms back)
Actually Marc said that in his 2nd reply, further up.
In reply to Menu-> Add -> Lines... ->… 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
In reply to you select 2 note heads and… by Jojo-Schmitz
Then autoplace being enabled it simply a bug; it suppresses the expected automatic placement!
indeed. Now reported in #280360: note-achored line should have autoplace disabled
Where are you getting this need to disable automatic placement? Maybe in an older build? I fixed that days ago :-)
In reply to Where are you getting this… by Marc Sabatella
I only run official betas. Gettin' about that time?
I think tested the with the latest beta, not with anything more recent
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.
Apparently not. I guess there probably isn't code to handle this line type in the palette.