Hard to select notes
I find that clicking on a note to select it is much harder than it has any reason to be. As often as not, I'll end up accidentally selecting the note stem instead. I'm not sure why I would ever want to select the stem separately from the rest of the note. It certainly isn't something I've ever wanted to do. But it interferes with regular note selection, which I do constantly.
Do stems really need to be independently selectable objects, distinct from the notes they're attached to? The only common reason to select a stem is to change its length, and that could be done just as easily if it were treated as part of the note. The inspector for a stem has only four items. One of those (Visible) is redundant, since the note's inspector already has a "stemless" option. The other three (Color, Horizontal offset, Vertical offset) hardly even make sense. I mean, why would you want to offset the stem away from the note it's part of, or display the note head and note stem in different colors? But if those really are important, they could easily be added to the note's inspector.
Comments
What you call note actually is the note head. A chord can have one stem (if half or shorter) or none (full or longer), but can have multiple node heads.
And single note head with (or without) a stem is just the smallest chord.
In reply to What you call note actually by Jojo-Schmitz
Then let me be clear about the problem I'm trying to solve. Here are some common reasons for selecting a note:
- To delete it.
- To modify its length.
- To modify its pitch.
- To copy/paste it.
- To select a range of notes (click on one end of the range, shift click on the other end).
- To set the starting point for playback.
*All* of the above only work if you select the note head, not the note stem. And the note head is a very small target to click on. If you're off by just a pixel or two, it ends up selecting the note stem instead, which actually has a much larger clickable area.
Perhaps I should have said "chord" instead of "note"? You can see the distinction in the inspector when you click on a note head. It has a section of chord properties, many of which actually affect the stem: small, stemless, stem direction. So the data model seems to be that there's one chord, which contains multiple note heads, but selecting any one of those note heads means the chord is selected. And then there's the stem, which doesn't quite fit in. Its appearance is partly determined from the note/chord inspector, and partly from its own inspector, and selecting one doesn't select the other.
In reply to Then let me be clear about by peastman
I got it. and yes, notheads are sometime hard to select, but it gets easier when zooming in a bit.
In reply to Then let me be clear about by peastman
If you are viewing the music to small for clicking to be convenient, definitely considering zooming in. But also keep in mind, clicking isn't the only, or best, way of selecting things. The standard keyboard shortcuts work (eg, left/right arrows to move the selection "cursor" forward or backwards, or with Ctrl to move by measure, or with Shift to extend the selection while moving the cursor, etc). Also Shift+drag allows you to select a rectangular region. Also, note if for some reaosn you click a stem instead of the notehead, hitting the Right arrow key will move the selection to the note.
In reply to If you are viewing the music by Marc Sabatella
Yes there are workarounds, but that's not really my point. This is an awkward part of the UI. It's the sort of small irritation that doesn't prevent you from using the program, but does make it less pleasant to use. And it could easily be fixed with only minor changes to the UI.
In reply to Yes there are workarounds, by peastman
What is your proposal for a change that doesn't interfere with the ability to select stems?
In reply to What is your proposal for a by Marc Sabatella
That was precisely my question: why do stems need to be selectable in the first place? Why are they treated as independently selectable objects? See my original post.
In reply to That was precisely my by peastman
You can do a number of tmshings with ste - hide them, move them, lengthen then, etc. And they *are* separate elements - one stem can have several notes attached. We can't very well remove these capabilities.
In reply to You can do a number of by Marc Sabatella
Yes, I'm aware of those things. I discussed exactly those issues in some detail above! For example, you could change the length of the stem just as easily if it were treated as part of the chord. There's no need to have it separately selectable just to allow that. And there's already two different ways to hide the stems: with the "visible" option in the stem inspector, or with the "stemless" option in the note/chord inspector. In fact, that's itself an argument for this change. Several of the options for modifying the stem are already in the note/chord inspector rather than in the stem inspector. I suggested moving the remaining ones there as well (or just eliminating the ones that really don't make sense). The result would be a UI that's both easier to use and more logically consistent.
In reply to Yes, I'm aware of those by peastman
The Inspector for stem is only visible if a stem is selected. And a stem being set to invisible is a different thing from a chord being stemlessstemless, even if in the printout it looks the same
In reply to Yes, I'm aware of those by peastman
Edit mode can do one thing at a time. Either it allows you to move the notehead or it allows you to edit the stem. I don't see how you can expect it to do both at once.
In reply to Edit mode can do one thing at by Marc Sabatella
Very easily! Selecting a stem doesn't allow you to do much of anything useful with it. If you want to change its length, you have to double-click it: that's a different mode. And if that stem were treated as an integral part of the chord, that mode could still be activated just as easily by double clicking. It's not a hard UI problem to solve.
I honestly don't understand where you're coming from. It's a frustrating part of the UI. The current behavior is clearly problematic. If you were suggesting alternate ways to improve it, then we could have a useful discussion. But as far as I can tell, all you're saying is, "It's an insoluble problem," without even being willing to consider ways to improve it. Why are you so opposed to any possible change to the current behavior?
In reply to Very easily! Selecting a by peastman
Let me offer a very explicit proposal for how it could behave:
1. When you click any note in a chord, the stem gets highlighted as well. It's part of the selection.
2. When you click the stem, that selects the entire chord.
3. If you double-click anywhere on the chord (including the stem), that puts it into the edit mode where you can change the stem length.
4. Any of the stem's inspector properties which are judged to actually be important should be moved into the node/chord inspector. (I don't see a value to any of them, but other people might see them differently.)
If you see any problems with this design, or have suggestions for a better one, by all means say so.
In reply to Let me offer a very explicit by peastman
As I explained before, Edit mode for a note already has an important meaning - it allows you to move the notehead. There is no way to have Edit mode both move the notehead *and* change stem length. This is the part you don't seem to be understanding.
Why would you want clicking one note in a chord to also select the stem? This doesn't make sense, and with two different element types selected, it would make it impossible to operate on the selection as a note - no up/down to change pitch, etc.
I'm not opposed to finding improvements. But I also don't really see the problem as being significant - it's not particularly hard to click a note if you are zoomed in to a reasonable degree (and why would you try to work on a score at this level without zooming in sufficiently?).
I'm certainly open to suggestions, but so far, I don't see anything workable.
In reply to Let me offer a very explicit by peastman
Peastman do not discuss with them about usability, they are very boneheaded in this topic. It is a waste of time. I had yesterday the funny find, that Lilypond via Frescobaldi offers to me a better workflow than MuseScore. They do not see the obvious right down under their nose.
In reply to Peastman do not discuss with by hasenfuss
I think we can have a discussion without any ill will from hasenfuss. So let's take point number three in the description of a new scheme:
What's missing is now the ability to move the notehead, right?
In reply to I think we can have a by Isaac Weiss
Try doing this simple experiment. First click on a stem. Notice there's nothing you can do with it. You can't change the stem length. You can't move the note head. The only function of the mode you're in now is to use the four items in the inspector, all of which are either redundant or mostly useless.
Now double click on a stem. Notice that it just put you into a different mode than the one you were in before. In this mode, you have a new ability: you can drag the end of the stem to change its length.
Finally, click on a note head. You're now in yet a different mode, one in which you can move the note head.
So we currently have three different modes, two that are useful and one that is mostly useless. My proposal doesn't affect either of the two useful ones. It only eliminates the useless one. If any of the inspector properties from that mode are judged to actually be important, they can be merged into the third mode.
Based on various comments you've made, I'm pretty sure you don't work with orchestral scores a lot? Try creating a new score with the "concert orchestra" template, and you'll immediately see why zooming isn't a very satisfactory workaround. If you zoom in far enough to eliminate this issue, less than half the instruments will be visible on the screen, so you'll constantly be zooming in and out.
In reply to Try doing this simple by peastman
You are, by default, in Normal mode. Clicking any element selects it, but you are still in Normal mode. Double clicking any elements puts it in Edit mode. Those are the only two modes - not sure what third mode you mean. In any case, I think it would be bad for usabiltiy to have clicking a note do something other than what clicking any other element does, and the same for double clicking.
I do work with orchestral scores a lot. I don't understand what you mean about zooming not being satisfactor - it's practically *essential*. When editing notes, I am generally zoomed in enough to work with them well. I don't need all instruments on screen at once while editing, any more than I need all measures on screen at once. Just enough to work with, and then it's trivial to scroll around with the mouse wheel or page keys to see more. I only zoom out to do overall page layout sorts of things.
In reply to You are, by default, in by Marc Sabatella
> Those are the only two modes - not sure what third mode you mean.
I'm starting to find this conversation very frustrating. I don't see how I could possibly describe my proposal more clearly than I already have, yet you keep not understanding it. The "third mode", as I very clearly described, is the mode where the stem is selected (but not the note or chords it's attached to). This is a useless mode. Its existence adds no capabilities to the UI, and interferes with using essential features. What aspect of that have I not already stated multiple times?
> there is simply no way MuseScore (or any program) can be very usable if you don't make your document big enough to work with comfortably.
It's a simple application of Fitt's Law: The larger the target area you're trying to click on, the less time it takes to click on it. And the less likely you are to miss it.
> you are similarly going to have trouble selecting individual notes in a chord
Let's go through all the possible situations and see how my proposal affects each one of them:
1. You want to select a single note (not part of a chord). In this case, the effect of this change is that you now have a larger area to click on. That is unambiguously an improvement.
2. The thing you want to click on is a chord. Above I listed six common reasons for doing that. For three of them (changing its duration, setting the start or end of a selection range, setting the start point for playback), it doesn't matter which note in the chord you select. So again, it's an unambiguous improvement. You have a larger target area to click on.
3. You really want to click on a single note within the chord. In this case, the change doesn't help you, but it doesn't hurt either. You still have exactly the same target to click on.
4. You want to double-click so you can edit the length of the stem. Once again, you now have a larger target to double-click on. That's an unambiguous improvement.
So in most cases this change is an improvement, and it is never worse than the current behavior. So what are you objecting to?
> We can't remove functionality that people depend on just because others don't use it much.
Wow. That was both gratuitously insulting, and a complete misrepresentation of what I said. I've said at least three times already that we will not remove any features that are judged to be useful. I'm starting to think that hasenfuss was right and you're just being a troll. If that's not the case, you can prove him wrong by not continuously misrepresenting my suggestions and making me repeat myself again and again.
In reply to > Those are the only two by peastman
I'm sorry you find it frustrating. I just think that perhaps you aren't understanding the full ramifications of what you are suggesting, perhaps because you are not as familiar with the program. I don't know how to explain things better without frustrating you further, but I guess all I can do is try.
The case of a chord is not some unusual special case. It is extremely common. If you are not zoomed in far enough to accurate select individual notes of a chord, you aren't zoomed far in enough. You will similarly have trouble selecitng articulations, accidentals, etc. There is no getting around the need to zoom in further. Which is to say, your proposal would have limited benefit.
But my concern is the cost. Right now things are consistent - clicking something selects it and only it, double clicking puts in into Edit mode. You are proposing changing that to work very differently for notes, and inconstency is not generally a good thing. But more specifically, you still seem to be missing the point that if you double click a note, it allows to to edit the note and if you double click the stem, it allows to edit the stem, and these are two separate capabilities and your proposal requires sacrificing one or the other. This is the functionality that it seems to be would be lost. Pointing this out is not meant to be insulting - just helping you see something that you seem to have missed. I'm sorry if this somehow bothers you, but I don't know how to make that point more clearly. Right now you can double click a note to edit the mote, or double click the stem to edit the stem. Two different features. If double clicking either produces the same result, one of those two features is lost.
So to summarize - as far as I can tell, your proposal still won't elimintate the need to be zoomed in far enough (to select notes within a chord, or elements other than notes), and it comes with a cost in terms of introducing inconsistency and loss of a feature. To me, it isn't worth it, but I'm just one person expressing my personal opinion. I'm trying to help you refine your idea and perhaps improve it to address these concerns, so we can find a solution that actually works better. So I look forward to seeing you can come up with!
In reply to I'm sorry you find it by Marc Sabatella
having the inspector for stem to link back to its chord, just like the note/chord inspector does have a link to the stem, might help?
In reply to having the inspector for stem by Jojo-Schmitz
It might indeed - if you mean, it would give you a reliable way of getting to the chord in a single additional if you accidentally click the stem instead. But I am not giving up on the idea of finding a way to make it easier to click on individual notes, if one can be found that doesn't come with a cost in terms of loss of consistency or features.
In reply to I'm sorry you find it by Marc Sabatella
To clarify, @peastman, right now you can double-click a notehead to move it left or right, and double-click a stem to make it shorter or longer. Do you see a way of keeping both of these options available?
In reply to To clarify, @peastman, right by Isaac Weiss
FWIW, here's a simple proposal that might actually be workable and requires only small changes: make the active zone for a stem only towards the *end* of the stem. That is, treat a click or double click anywhere near a notehead as applying to the note, but a click within say 1sp of the end of the stem as applying to the stem. It makes it somewhat harder to access the stem, but only somewhat, and no loss of consistency, no special hacks required to make the Inspector act as though having a note and stem selected together is really only a note, no new fields or buttons in the Inspector, etc.
In reply to FWIW, here's a simple by Marc Sabatella
Most probably won't work if flags are involved, there it is already difficult to select the stem.
In reply to Most probably won't work if by Jojo-Schmitz
Of course, if the stem were treated as an integral part of the chord, then the whole problem of stems being hard to select would go away. So my proposal would solve that problem too. Just saying... :)
In reply to Of course, if the stem were by peastman
The stem is an integral part of a chord, but not of a note head.
In reply to Of course, if the stem were by peastman
As I mentioned, there are technical issues with what I think you are proposing that are kind of hard to explain, but I guess I should at least try.
A stem is not part of a *note*, it is part of a *chord*. This should be obvious since several notes can share the same stem. If clicking a single note also selects the stem, it means we are selecting the stem, but *not* the rest of the chord (obviously, it would not be acceptable to have a click on a single note select all notes of that chord). So the stem would *not* be so "integral" after all. It would instead be a series of special cases where selecitng a note also selected *part* of the chord, but not the whole thing. And in any case, now that the note and stem are selected together, there would be no easy way to set the properties for them separately (eg, color, position, visibility) except by introducing yet *more* special cases, where the stem color et al would be a a special property of the chord set rather thatn properties of the stem itself. this complicates the code as well as the UI for the Inspector. Again, it's not completely unworkable, but I think you underestimate the extent to which this really changes things both internally and in the UI.
Which is why I think a more straightforward approach is better - one that doesn't involve re-architecting the code or intreopduce lots of special cases and new UI controls just to handle the complications that result from such a change.
In reply to As I mentioned, there are by Marc Sabatella
The distinction between note and chord is not nearly as clear cut as you imply. Consider how it works now. Click on a note in a chord and look at the inspector. You'll see that it's divided into four sections: Element, Segment, Chord Automatic, and Note. And here's the critical point. Two of those sections (Element and Note) contain options that relate to the individual note, while the other two (Segment and Chord Automatic) contain options that relate to the chord. See for yourself: edit an entry in one of those sections, then click on a different note in the same chord, and you'll see the entry you just changed continues to have the changed value. And even more significantly: several of those chord properties (which come up when you click on a single note head) already describe properties of the stem (such as Stemless and Stem Direction).
Once again, that is how it already works right now. It is already the case that when you select an individual note head, you are considered to have selected the chord, and you can edit properties affecting the appearance of the stem. My proposal builds on the existing behavior and makes it more consistent. Instead of having some stem properties in one inspector, and others in a different one, it moves all of them into a single inspector.
In summary: the things you say my proposal would change are not actually changes at all. They are precisely how it already works. I would just make it more consistent, so all stem properties work the same way, instead of some working one way and others in a different way.
In reply to The distinction between note by peastman
Yes, I know that when a note is selected, you have access to chord properties. But still, the change you are suggesting is more significant than that. If you are a programmer, I can point you to the code so you can understand the significant differences internally better. If not, I hope you can trust that it really is different internally. But for the user interface, it's easy to show how things would be different. Right now, clicking a stem means the stem alone is selected. The Inspector shows properties that apply to the stem - visiblity, color, and position. If the stem were not treated as independently selectable, then the only way to set these properties would be to invent *new* properties to add to the "Chord" section of the Inspector: "Stem color", "Stem horizontal offset", etc. We would be replacing *standard* properties that are set in *standard* way - the same as for every other element - with "special" properties that you have to set *differently* for the stem than for any other element.
I don't know what you mean about some stem stem properties being set in one inspector and others in another - this isn't true at all. The stem properties are set in one place and place place only - in the inspector for the *stem* itself. There are separate *chord* properties than are set from the *note* inspector (and nowhere else), but these are not the same as *stem* properties. Again, there aren't two different eways of setting stem properties - there is only *one* way, and it works *exactly* the same as every other element. To set basic properties like color, visibility, and position, you simply click the element and use the insector, and to edit other properties you can double click to enter edit mode. The is precisely the same as for every other element. Your proposal change this so that even to change these basic properties for the stem, you can have to do it *indirectly*, by changing a new "special* property that appears in the inspector when the stem is selected, and it changes edit mode to now do two separate things (edit the note or edit the stem) depending on which handle you click.
Again, it's not impossible to change things to work the way you propose of course, but it *is* a more significant change than you seem to realize, and it's a change that makes both the interface *and* the code more complicated and less consistent. This is in part why I am not comfortable with such a change when I think a much smaller change would be equally if not more effective.
In reply to Yes, I know that when a note by Marc Sabatella
> If you are a programmer, I can point you to the code so you can understand the significant differences internally better.
Please do. (I'm a professional software engineer.) But also remember that designing the UI based on the current code design is almost always the wrong approach. First decide how the UI should work, then adapt the code to make it work that way. Code can be changed, just as user interfaces can be changed.
> But for the user interface, it's easy to show how things would be different. Right now, clicking a stem means the stem alone is selected.
Indeed, that would be changed! The whole point of this discussion is that I believe it should be changed.
> There are separate *chord* properties than are set from the *note* inspector (and nowhere else), but these are not the same as *stem* properties.
That's purely a matter of semantics. Perhaps it's also a distinction in how it's currently implemented, but again, that can be changed. As far as the user is concerned, there's no fundamental difference between stem color and stem direction such that one is a "stem property" and the other is a "chord property". One is just as much a property of the stem as the other. The fact that they are currently separated into different inspectors is yet one more problem with the current design. To the user, the color of the stem and the direction of the stem are both properties of the stem. Having them in different inspectors is just confusing.
> it's a change that makes both the interface *and* the code more complicated and less consistent.
Quite the opposite: it makes the UI both less complicated and more consistent. There are fewer selectable objects, fewer inspectors, and all the properties you expect to be in the same place are in the same place. I can't comment on the code without having looked at it, but seriously: if it's written in a way that makes as simple a change as this impossible, that's a good sign that's it's time for a refactoring!
In reply to > If you are a programmer, I by peastman
I agree that design UI based on code is the wrong approahc. That is why I primarily have been trying to focus on explaining the inconsistency in the design you are proposing and why I haven't been focused on the implementation details.
I don't know how to explain the inconsistency any more clearly than I already have, but I guess I can try again.
Right now, to make element X red, you click that element and then click the "Color" control in the Inspectore. To make element X invisible, you click that element then untick the "Visible" checkbox in the Inspector (or press the shortcut "V"). To change the horizontal offset of element X, you click that element and change the "Horizontal offset" in the Inspector. This holds for any element X.
Your proposal changes this so that it fails for X = stem. In order to change color, visibility, or position for a stem, you'd need to follow a *different* procedure. That is the inconsistency I meant. Suddenly stems behave differently from every other element. You can argue that this loss of consistency is made up for by some gain elsewhere, but you can't say this *isn't* an inconsitency, because it very obviously is.
As for the implementation, have you built from source yet? Most of the relevant code will be found in the libmscore folder, in stem.cpp, note.cpp, and chord.cpp. The is also code in the mscore/inspector folder to handle the setting of properties.
What you'll find is that there are very good reasons things are structured as they are, and it's *far* from a simple change. But feel free to try your hand at it so you can see for yourself.
Still, though, I think the change I propsoed is *far* simpler both from an implementation and from a UI standpoint (no need for additional handles - which require additional clicking - or for new proprties to be added to the Inspector), as well as being more consistent and also being more effective (it solves a broader class of problems instead of just the case of selecting a single note from a one-note chord while not zoomed in far enough). These seem like *huge* advantages to me. Is there some advantage of your proposal over this that I am missing?
In reply to I agree that design UI based by Marc Sabatella
You're focusing exclusively on things that almost no one ever wants to do. Or even worse, that are already redundant features. For example, can you name a single realistic reason for anyone to edit the "horizontal offset" property of a stem? If you want to offset the note as a whole (stem plus note head), you do that from the note/chord inspector. (It's the "horizontal offset" property under "chord automatic".) If for some really bizarre reason you want to separate the note and stem from each other, you can do that too from the note/chord inspector. (It's the "horizontal offset" property under "element".) Then for absolutely no good reason at all, there's also a "horizontal offset" property in the stem inspector. Not only is this for something hardly anyone ever does (displace the stem away from its note), but you already have a way of doing that.
Can you honestly say that property exists there for a good reason, because someone thought it out and decided it was useful to have it there?
Suppose it weren't there, and I had posted a feature request asking for it. What would your response have been? You would have said quite emphatically that it was a useless feature, that it would clutter the UI, and that adding it was a bad idea. And you would have been right!
Making the stem invisible is likewise redundant. There is already a "stemless" property in the note/chord inspector. Is there truly a good reason for having two different properties in two different places to create a note without a stem?
As for color, that's another one I have trouble imagining anyone actually uses. Do you really want to make a note one color and the stem attached to it a different color? But if there really is demand for that property, what is inconsistent about having a "stem color" property right underneath "stem direction"? Those are both properties of the stem. Putting them in different inspectors makes no sense. That's inconsistent.
Instead of talking about rarely or never used corner cases, let's talk about things that people do constantly. Selecting notes is something I do several times a minute, as do most users. Selecting stems (such as to resize them) is less constant, but still a normal thing to do. Both of these things are frustratingly difficult. This change would make them much easier. The change you suggested would not. Tweaking the target regions by a few pixels is at best a band-aid, and most likely will make negligible difference. Why do that when we can truly fix both problems?
You said you could point me to the relevant code to show why this is hard to implement. Please do so!
In reply to You're focusing exclusively by peastman
If you want to color notes as per their pitches, like the color notes plugin, you indeed want foreheads and stems to have different colors, esp. for chords with more than one note.
Stemless and invisible stem are different things even if the result in print is the same.
Stem direction is a property of the chord, as is stemless, not of the stem, a stem is just to simple an element for this.
But indeed it seems a good idea to have the stem inspector not being separated from the element/note/chord inspector. Actually we'd need to add a stem inspector, as currently no such thing exists, what you currently see is the element inspector.
The code is out there on GitHub, see e.g. libmscore/stem.cpp and mscore/inspector/
In reply to If you want to color notes as by Jojo-Schmitz
> Actually we'd need to add a stem inspector, as currently no such thing exists, what you currently see is the element inspector.
That's a statement about the code, not the UI. As far as users are concerned, the inspector displayed when you select a stem is, by definition, the stem inspector. Or rather, you're confirming something that was instantly obvious: the current UI was never designed. No one thought about, "What properties should a user see when they click on the stem of a note?" Instead, they just wrote a generic inspector with the most generic properties possible, and it gets used for stems and various other things. That works as a quick and dirty implementation, but it's not the way you create a good UI. Instead, someone should go through every inspector and consciously design each one. That would be a moderate amount of work, but it would do a lot to improve the simplicity, user friendliness, and overall polish of the program.
In reply to > Actually we'd need to add a by peastman
If it were the stem inspector, it would say so in the heading. There is no stem inspector currently, period. No reason not to have one in the future, but currently we just don't.
If you select a note, you see the inspectors for element, note and chord, and have buttons to go to the inspector for dot, double dot, etc, at the bottom.
Stems have very little properties beyond those of any element, which they are derived from, element has visibility, color, offset, stem on top has length, but that is about it. Stem direction and stemless is a property of the chord a stem may be part of (a chord has a stem direction even if stemless, either via the stemless property or like for whole notes or longer).
In reply to If it were the stem by Jojo-Schmitz
'Stem direction is a property of the chord'
It is implemented like this, but is there any music/logic reason why it could not also be implemented as 'stem' property?
(This is a pure question, I do not suggest or desire to have it as stem property)
In reply to 'Stem direction is a property by frfancha
AFAIK stem direction influences the layout even for notes/chords that don't have a stem, like whole notes or longer, so having stem direction as a property of stem wouldn't work there.
In reply to 'Stem direction is a property by frfancha
To me, if I want to flip the stem of a note or chord, the most natural thing is to do by selecting the note or chord. Also, it's great that I can do it for many notes or chords at once by doing a range selection. So it's definitely a great thing from a usability perspective that stem direction is a chord property. Which isn't to say we couldn't also make it so selecting a stem displayed and activated the chord properties. That's fine, really.
In reply to If it were the stem by Jojo-Schmitz
I think you missed my point... and in doing so illustrated it perfectly! :) You're looking at it entirely from the perspective of a programmer, not a user. The UI was designed to match the data model. And that's not the way you create a good UI. Instead, it should be designed by understanding how your users think, then figuring out what will be most intuitive and convenient for them.
You gave the example of clicking on a note. The Inspector window then lists properties divided into four categories: Element, Segment, Chord Automatic, and Note. To you as a programmer, that probably makes perfect sense. It lines up with the class hierarchy and the variables defined in each class.
But think how a typical user (that is to say, a musician) sees it. What does "element" mean? Or "segment"? Of course they can understand the idea of a score being composed of many elements, but in this case, the note is the element. So why are there two different sections called "note" and "element", when they are both the same thing? The idea of a "segment" means nothing at all to them. It's just a meaningless title. And although I'm a programmer, even I have no idea why the third section is called "Chord Automatic" instead of just "Chord"! I'm sure that title makes no more sense to most other users than it does to me.
The categories aren't even ordered in a consistent way. You'd at least hope that all the categories relating to individual notes would be grouped together, and likewise the categories relating to the whole chord be grouped together. But no: the first and fourth categories relate to the individual note, and the second and third categories to the whole chord.
So I would reorganize all the properties into categories that make sense to a musician: Note, Stem, and Chord. There shouldn't be separate "note" and "element" categories, because those are exactly the same thing (to a user). Likewise for "segment" and "chord". But stems are a distinct concept in music notation, so it makes sense to put the stem-related properties into their own category. And as I discussed elsewhere, I would put all stem related properties together. They shouldn't be split between two different inspectors.
In reply to I think you missed my by peastman
IMV, Peastman's argument is sound. A reorganisation of the Inspector should be considered.
In reply to IMV, Peastman's argument is by geetar
Adding a real inspector for stem (ratger than just the one for element) and showing that when a note is selected, additionally to the element, note and chord inspector. Or have a button at the bottom to get to it, similar as for the dots or triplets.
Oh, that Stem button is already there. So we'd really only need a Stem inspector. The only own property it has is _userlen and _len, and the setters setUserlen(), setLen() and the getters userLen() and len() and line and it's getter line(). len is not something the user should be able to influence, same for line (which doesn't even have a setter) so it really is just _userlen.
It may additionally refer to it's chord's stem direction.
It should have a button to refer to it's chord (the corresponding inspector)
Shouldn't be a big deal to add this.
None of this solves the OP's issue of finding it difficult to select a note though, except maybe for that button that from stem least to note.
In reply to You're focusing exclusively by peastman
Well, like I said, you can argue the loss in consistency is offset by gains elsewhere, so that's fine. I still would prefer a solution that didn't involve a loss of consistency or require additional UI complexity (new properties added to an already cluttered Inspector for notes, new handles when editing a note) and would also prefer a solution that is easier to implement / maintain. But if you're volunteering to try implementing your solution, that's fine by me - if the powers that be end up agreeing the loss of consistency and increase in UI complexity is worth it, they will merge it.
I already listed the source files that would be involved in making the type of change you are suggesting. You would need to change what happens in InspectorNote, also Note::startEdit() et al, Stem::startEdit() et al. Some of these are inherited functions - eg, I think there is no unique Note::startEdit() but rather the generic Element::startEdit() is used. You would probably need to override this. You'd want to look at the simialr code in the various Spanner classes to see how the handles are implemented.
BTW, making a chord stemless is *not* the same as making the stem invisible - different effects on layout. For instance, consider what happes to flags or beams. And yes, coloring stems different from heads *is* q reqwuired piece of functionality for some use case. And as I said, whether or not you personally use a feature doesn't make it OK to remove it or make it harder to find / access.
I'm all for making it easier to click a note, but I would much rather it *not* come at a such a high cost, which is why I proposed what I believe to be a far superior solution. I'm not sure why you call my proposal a "bandaid" or why you think it would be extremely effective - I can only guess you don't fully understand the proposal or how things are implemented. I'm quite confident it would work extremely well, with only minimal code changes required and no additional UI controls required. What makes you believe otherwise?
In reply to Well, like I said, you can by Marc Sabatella
> Well, like I said, you can argue the loss in consistency is offset by gains elsewhere, so that's fine.
From my perspective, there's no loss in consistency at all. Rather, there's a gain in consistency, which is a bonus (but also only a minor point). For example, I don't understand why you think "stem color" and "stem direction" are such different properties that they belong in different inspectors. I see them both as "properties of the stem", and I'd expect them both to be in the same inspector. I'm pretty sure most other people would too. Yet right now, they're split between different inspectors. That's inconsistent.
Then there's the "offset" properties which are even worse, because they're actually redundant. There are two different sets of properties in two different inspectors that can both be used to create exactly the same effect. "Consistent" is not a word I would use to describe that. :)
Even if I try as hard as I can to see things from your perspective, the strongest statement I can make is that it's an arguable point. Neither design is intrinsically more consistent than the other. It just depends which of two aspects of the UI you think it's more important to have consistent. But since the properties involved are rarely used ones, I don't think either aspect is really all that important. Overall I think consistency would be improved (especially in the sense of "consistent with users' expectations"), but only in some obscure corners of the UI that aren't too important compared to the other effects of this change.
So when you talk about this feature having "such a high cost", I honestly have no idea what you're talking about.
> I proposed what I believe to be a far superior solution.
By all means, try it out and see how it works. I'm very doubtful that it will do much at all to solve the problems, but the proof is in the pudding, so try it out and see. Since your solution will still give a smaller click target for the note than my proposal, a smaller click target for the stem than my proposal, and won't fix the inconsistencies described above, I'm not clear what you think is "far superior" about it.
> But if you're volunteering to try implementing your solution, that's fine by me
No, I'm not offering to implement it. That's why I posted it as a feature request. :) If I implement anything, it's going to be https://musescore.org/en/node/104296, since that's a feature I care about far more than this one. This is merely an annoyance, whereas that one completely prevents me from doing the things I want to do.
On the other hand, I'm definitely willing to make suggestions about the implementation. You've repeatedly said this was a hard feature to implement, but I haven't seen anything in the code that makes me think that. If you explain why you think this would be hard to implement, I'd be glad to look over the code and see if I can suggest a cleaner, easier way of doing it.
In reply to > Well, like I said, you can by peastman
as explained already, stem color is something the stem inherits from element (every element has a color and stem is derived of element) while stem direction is a property of the chord. Not sure why you don't want to understand that, you've been pointed at the source code an, so please see yourself. About the only property that a stem has on top of what it inherits, is stem length.
In reply to > Well, like I said, you can by peastman
Well I guess we're at an impasse then. I've tried to explain as clearly as I can what the issues are with your proposal in terms of consistency and complexity; I'm sorry if I still have not succeeded. Let's put that aside though and talk abotu functionality.
My proposal offers the same *horizontal* expansion of the click target as your proposal, it just doesn't also expand the click target *vertically*. This is actually a crucially important difference, as it means my solution is able to also help select individual notes within a chord, whereas you proposal is not. That's actually it's main advantage, aside from simplicity.
To be more precise (magnify to 800% or whatever is necessary to see what is happening more clearly):
Currently, clicking anywhere along the stem - *including a number of pixels to the left or right (as determined by Edit / Preferences / Proximity for selecting elements)* - selects the stem. This is true even for the area where the stem and notehead intersect, even though logic would dictate the note should get priority when clicking there. The proximity effect means that the stem "steals" not only its own width from the notehead (and this width may be artifically inflated for screen display at small magnifications so the stem doesn't become too thin to see), but it also steals *additional* pixels overlapping the notehead, and the smaller the notehead, the more that proximity effect steals. So as magnification decreases, you not only have a smaller notehead, you have a smaller *percentage* of the notehead that you can actually select.
This, I believe, is the entire source of the problem you are experiencing when dealing with small magnifications. The notehead itself is small, but no more so than other symbols in your score that somehow you are still able to select. The problem is that the stem "stealing" some of the note's real estate.
My proposal solves this - the stem no longer steals any of the note's real estate, and indeed, the *note* now gets the benefit of the proximity effect, meaning you can click a few extra pixels to the left or right and still hit the target.
Your proposal accomplishes the same thing in the single note case - the active zone for selecting the note will be exactly the same in the horizontal dimension, but there is one main difference that I believe is a very significant disadvantage from a usability standpoint:
If you click within the zone where the stem + proximity intersects the notehead, currently this selects the stem, which we both agree is not ideal. Your proposal changes this so selecting that zone actually selects the entire chord - all notes of the chord and the stem as well. So an attempt to click *one* note actually selects *all* notes. It's better than currently where attempting to select one notes selects *no* notes, but definitely not ideal if you *are* in fact trying to select just *one* note. It means you still cannot easily access one note from within a chord, thus it fails to solve an important part of the problem.
In my proposal, clicking that intersection zone selects just the desired note, making it easier to select individual notes within a chord. And not just within the intersection zone - also the proximity zone to the *right* of the stem. It actually greatly imprves the ease of selecting individual notes. Whereas your proposal converts many valid attempts at selecting individual notes into selections of the entire chord. You can already select entire chords easily enough via Shift+click is that is your desired.
Anyhow, I hoep that more clearly explains why I think my proposal solves the problem more completely and effectively than yours. The fact that it is also much simpler to implement and requires no new UI elements (no new Inspector properties or handles) is just a bonus, really. It's mostly about the functionality - making it easier to select individual notes, not giving up and selecting and selecting the entre chord instead.
In reply to Well I guess we're at an by Marc Sabatella
> This is actually a crucially important difference, as it means my solution is able to also help select individual notes within a chord, whereas you proposal is not.
On the contrary! I absolutely agree that where a note and a stem intersect, selecting the note should take precedence over selecting the stem. So on that we are totally in agreement. But here's the difference: in your proposal, this would actually decrease the clickable target to select a stem. Selecting a stem, already somewhat difficult, would become even harder. Whereas in my proposal it would become much easier, because clicking anywhere on the note would lead to the stem becoming selected.
> The notehead itself is small, but no more so than other symbols in your score that somehow you are still able to select.
It's not a question of being "still able to select" elements. I am certainly able to select notes. It's just more frustrating than it ought to be. Other small elements are also frustrating to select, but they're less important. I select notes far more often than all other elements put together.
So to repeat what I said before: my proposal gives both a larger target for selecting notes, and also a larger target for selecting stems, than yours.
> Your proposal changes this so selecting that zone actually selects the entire chord - all notes of the chord and the stem as well.
Again, that's not at all what I intended. Selecting the note should always take precedence over selecting the stem. The only reason I even added the bit about selecting all notes is that it has to do something when you click on the stem.
In reply to > This is actually a by peastman
Yes, your proposal means that the stem gets selected when you click that overlap area, but in your proposal as it stands, so would the rest of the chord. And that's the problem. The only way to prevent clicking the overlap area from also selecting other notes is to implement what I suggested. I think perahsp you aren't realizing that this would be the effect of your proposal because you weren't aware of that whole issue with the overlap area "belonging" to the stem. But that is indeed the issue - the entire issue, actually. Solve that and you don't need to change anything else at all.
In reply to Yes, your proposal means that by Marc Sabatella
> Yes, your proposal means that the stem gets selected when you click that overlap area, but in your proposal as it stands, so would the rest of the chord. And that's the problem.
No, that's just a misunderstanding of what I'm proposing. :) Was I not sufficiently clear about that in my last post? Let me say it again: if you click on the overlap area between the stem and a note, it should only select that one note, not the entire chord.
Remember that if any note in a chord is selected, that means the stem is selected and you can do all the things you normally do with stems. "The stem is selected" does not imply "all notes in the chord are selected".
In reply to > Yes, your proposal means by peastman
Well, I was I'm going by your statement in an earlier response "2. When you click the stem, that selects the entire chord". Remember, the overlap area belongs to the stem, so clicking the overlap area selects the stem - indeed, that's the entire problem right there. And *because* clicking the overlap area selects the stem, in your proposal this would instead select the entire chord, as per your statement I quoted above.
Meanin that *unless* you modify your proposal to 8change* what happens in the overlap area - which is what I have been saying all along - your proposal won't make it easier to select individual notes in a chord at all. The cases that currently succeed in selecting a single note will continue to do so, but the cases that currently fail and select the stem will now fail and select the entire chord. I'd rather not just change one failure into a different failure; I'd rather not fail at all.
I'm glad you are now agreeing this would be a good thing, so let's accept it and move on.
The next step is to realize that once you fix the overlap zone problem - which is the *entire* problem - there is no need to introduce unnecessary handles or additional Inspector controls or anything of the sort. Fixing the overlap zone is the complete fix right there.
However, I should point out I misspoke on one point: the overlap area does *not* include the proximity zone for the stem, only the width of the stem itserlf. but that width might be artifically enlarged to avoid a stem so thin it can't be seen. So it's still the case that proportionally, the stem takes more space away the notehead at smaller magnifications.
In reply to Well, I was I'm going by your by Marc Sabatella
Glad to know the confusion on that point is cleared up!
But why do you say the overlap zone is the entire problem? Note heads are slightly wider than they are tall, so extending the click target vertically is at least as valuable as extending it horizontally. And as I pointed out, your proposal would make it even harder to select a stem than it already is, whereas mine would make it much easier.
And furthermore, I still haven't heard any real answer to the question I asked in my very first post: is there actually a good reason for having stems as independent objects, that can be selected separately from the notes they're attached to? At this point, I think it's clear to both of us that no features actually require that. There's nothing users need to do that would be impossible if they were merged. So for a moment, forget about how it's implemented right now and suppose we were just designing it from scratch. Is there actually a compelling argument for choosing that design? The arguments for unifying notes and stems are clear, as I've discussed at length: larger click target for notes, larger click target for stems, all stem related properties get put in the same inspector. I also suspect most users intuitively think of "a note" (consisting of note head and stem) as a single object, and therefore would find this more natural. That's certainly how I think of them, though of course we'd have to conduct usability tests to really find out whether I'm typical or not.
In reply to Glad to know the confusion on by peastman
"I still haven't heard any real answer to the question I asked in my very first post: is there actually a good reason for having stems as independent objects, that can be selected separately from the notes they're attached to? At this point, I think it's clear to both of us that no features actually require that."
Maybe you want to believe that but it still seems like your proposal does away with the ability to, through a double-click, move noteheads or adjust the stem height *separately*. And don't say "use the inspector" because right now I don't need to. Your proposal reduces my ability to make manual adjustments through the normal wysiwyg GUI process. I think Marc's proposal wins.
In reply to "I still haven't heard any by schepers
> it still seems like your proposal does away with the ability to, through a double-click, move noteheads or adjust the stem height *separately*.
Not at all. Double click the note, then drag the handle at the end of the stem, exactly as you do now. Nothing in my proposal changes that.
In reply to > it still seems like your by peastman
Peastman,
You ask two things:
[A] Consider the chord as a single musical object with sub-objects (A1) and reorganize the inspector with musical terms (instead of 'element', ...) around this (A2)
[B] Solve the hard to select note problem
And you say doing [A] would automatically solve [B] (which is true).
Marc disagrees with [A] (at least with A1, on A2, except the reaction of Geetar (Peastman's argument is sound. A reorganisation of the Inspector should be considered) I don't remember.
Marc and you have valid arguments and the discussion can go forever...
On the other hand, even if it is not [A], the proposal of Marc would perfectly solve the [B] point.
So wouldn't it be wise to already adopt Marc's solution, which would solve the hard to select note problem, and keep the conceptual discussion for another thread?
In reply to Glad to know the confusion on by peastman
There is no need to extend the zone vertically, because there is no area stolen from the notehead in that direction. That is, it will never be the case that you successfully click within a notehead but it doesn't get selected due to some problem other than you simply not clicking accurately. Quite the contrary - the proximity zone *already* means you can miss slightly above or below, or even horizontally on the side *opposite* the stem. It's only the horizontal direction *on the stem side* where there is a problem, and it's entirely due to the stem, and this can should be easily fixable. The stem steals not only the overlap zone, but also the proximity zone on the side opposite the notehead, but it should do neither.
So, aside from the issue of the stem stealing real estate, selecting a notehead is *exactly* like selecting any other object. So aside from that, any issue you have due to being zoomed out too far is going to exist for all other elements as well, and you can address it by simply increasing the proximity zone setting in Edit / Preferences / Canvas. No need to special case notes here - if you like working with very small sizes, then you'll probably benefit from a larger proximity setting across the board.
As for the other question - why are stems independent - I'd say mostly to make it easier to have independent control of them. Yes, you can add multiple handles to compund objects to allow them to have more independence, but it's a more complex UI, so that's the tradeoff. I prefer simplicity, and apparently so did the folks who originally implemented this.
BTW, we could also make a new "select entire chord" command - say, Alt+click - that worked to select all elements of the chord at once. Right now we do have Shift+click, which (if nothing is currently selected) will create a range selection encompassing the chord, but that might include notes in other voices, so it's not ideal. A new "select entire chord" command would be another way to address the issue without introducing unnecessary complexity or inconstency.
In fact, I'd propose we do both of these things - fix the issue where the stem steal real estate from the note, and also implement a "select entire chord" command.
We *could* even consider making clicking a stem the equivalent of "select entire chord" rather than just select the stem, and require the Alt+click (or use of the Inspector) to select the stem only. This too is a slight loss in consistency, but at least it's still relatively simple from both a UI and implementation standpoint.
In reply to There is no need to extend by Marc Sabatella
> There is no need to extend the zone vertically, because there is no area stolen from the notehead in that direction.
The need is simply that notes are hard to select, and having a larger click target would make them easier to select. It's as simple as that. Yes, other objects can also be hard to select, but notes are by far the most common objects to click on. I select notes far more often than all other objects put together. It would be nice if, say, dots over notes were easier to select. (Those can be really hard, unless you're zoomed way in.) But I do that so rarely, I don't care about it very much.
Turning the entire note head plus stem into a single object gives you a larger object to click on. Hence, selecting it becomes easier. And that would be a clear improvement.
In reply to > There is no need to extend by peastman
Here, I can only again appeal to consistency. If you want things to be easier to select, make them bigger. Either zoom in, or increase the proximity setting in preferences. I don't see any reaosn to make some unusual special case for notes to make them work differently from other elements.
Again, you seem to be thinking only about single-note chords. Selecting a *note* absolutely positively has to be about clicking its head, because there might be multiple notes on a single chord. That's the only way to imprve the ability to select *ntoes* as ooopsed to *chords*. Like I said, as a completely separate thing, we could consider making it so click a stem also selected the entire chord. This also would be easy to do without introducing complex new UI controls or redesigning the internal data structures. So that is preciely what I proposed.
In reply to FWIW, here's a simple by Marc Sabatella
The only issue that exists right now with this idea is when a flag covers part of the stem. If flags were drawn behind the stem, would that make the stem easier to select?
In reply to The only issue that exists by schepers
yes, it would. But this would require changes to the glyphs. And I don't think that is going to happen.
In reply to yes, it would. But this would by Jojo-Schmitz
I would have thought the same hierarchy would work wrt flag/stem/note head and drawn them in that order to make heads have precedence. Right now note heads are drawn over stems, but stems are selectable *through* the head. That shouldn't be if indeed things that are drawn first (lowest) are covered by elements drawn later (higher).
In reply to The only issue that exists by schepers
In theory it shouldn't matter if stems of flags are drawn first, but in practice, it very well might. Not sure. Anyhow, it's certainly *possible* to select a stem even with a flag present, but indeed, a little awkward.
As I mentioned elsewhere on this thread, I'd love to see us implement a "select element below" feature, where successive Ctrl+clicks in the same location would select the element *behind* the currently-selected element. This idea was discussed somewhere on the fourms a few months ago, and I kind of walked through how I thought it might work. I even took a very brief look at implementing it, but got sidetracked and never followed through.
Such a feature would of course have *lots* of benefits - there are quite a few situations where elements can overlap making it difficult to select the element underneath (often requiring workarounds like temporarily moving the top element out of the way, etc). And if this became the best way to select stems in the presence of flags (there would also be the "Stem" button in the Inspector), I don't think I'd lose sleep.
In reply to I'm sorry you find it by Marc Sabatella
> The case of a chord is not some unusual special case. It is extremely common.
Since I never suggested it was, I don't know what this is referring to. On the contrary, I went through the list of common cases and showed that the only difference between a chord and a single note is this: for a single note, this change is always an improvement, but for a chord, it is only sometimes an improvement (but never worse than the current behavior). That sounds like a clear win to me.
> If you are not zoomed in far enough to accurate select individual notes of a chord, you aren't zoomed far in enough.
You say that as if it were a binary choice: either you're zoomed in far enough, or you aren't, and that's that. But that isn't how it works. The smaller the target you're trying to click on, the longer it takes you to position the mouse, and the more likely you are to accidentally click the wrong thing. There isn't a sudden change from "everything is perfect" to "the program is unusable". There's just a steady increase in frustration and inefficiency. The effect of this change is that, at any given level of zoom, users will work more efficiently and experience less frustration.
> Right now things are consistent - clicking something selects it and only it, double clicking puts in into Edit mode. You are proposing changing that to work very differently for notes
No, I haven't proposed anything of the kind. What I actually proposed is that the stem of a chord should be treated as an integral part of it. Single clicking will select it, exactly as now. Double clicking will put it into edit mode, exactly as now. At present, a stem has only one handle in edit mode. Likewise, a note has only one handle in edit mode. But lots of other objects have multiple handles (crescendos, slurs, etc.). If the note and stem are combined into a single object, it will therefore also have multiple handles. That's entirely consistent with the rest of the UI.
In reply to > The case of a chord is not by peastman
OK, this is the first time you've expressed the idea in terms of multiple handles on a single object, so this does represent a significant refinement over your previous versions of this proposal.
There are still technical issues with trying to present it this way, but I fear it may be hard to explain them adequately. What I will say at this point is, it might be possible to develop an implementation that works this way, but it would be a pretty big change under the hood in terms of the implementation and as such would take a lot of effort and carry some risk. I still wonder if something like my earlier suggestion of simply tweaking the click zones wouldn't solve the problem just as effectively and with *much* less effort and risk.
It was observed that stems can be hard to select in the presence of flags, but I don't see this as an insurmountable obstacle to my idea. If nothing else, one can use the Inspector to get at the stem of a chord once. Another possibility is the idea of allowing one to select objects that lie underneath other objects - to me, a *much* bigger issue than the one you've raised, since it happens at normal zoom levels as well. If there were a gesture that could select objects underneath other objects, then one could get at the stem by first clicking the note or flag, then using the new gesture to get at the stem underneath.
In reply to Try doing this simple by peastman
Adding to my previous response:
If you are zoomed out so far you are finding yourself accidentally clicking the stem when you mean to click a note, you are similarly going to have trouble selecting individual notes in a chord - you'll just as often miss one note and hit another. Eliminating the possibility of selecting a stem doesn't solve the problem if you have a chord of several notes - you'll still struggle to click the note you intedned to click if you aren't zoomed in far enough. So that's not a solution. The only solution is to zoom in enough to make accurate clicking possible.
To me, this just seems like common sense - there is simply no way MuseScore (or any program) can be very usable if you don't make your document big enough to work with comfortably. You'd have the same problem trying to click in a text document if it isn't zoomed in enough (or you are using too small a font), etc.
As for what happens when you click a stem: it selects the stem. Therre are a number of things you can do with the stem (or any other elements) selected, and just because you personally do any of them often doesn't make them useless. We can't remove functionality that people depend on just because others don't use it much. Changing the offset, visiblity, and color of stems *is* important, even if not all that common.
In reply to Adding to my previous by Marc Sabatella
As to that, I understood the suggestion was just to make those properties into another section in the Inspector. You can already independently adjust the offset of either the chord or the notehead by just selecting the notehead, so we would just add another category for the stem.
In reply to Changing the offset, by Isaac Weiss
You can select the stem from inspector when a note is selected: scroll down, hit the 'stem' button.
There's another reason why stems need to be selectable: to tie chords. (select stem, hit `+`). Actually I'm having problems selecting stems more often than having problems selecting notes, esp. in that case, and esp. if flags are involved too (so a chord of unbeamed 8th notes, that I want to tie to the next chord in the next measure).
In reply to Peastman do not discuss with by hasenfuss
Not to get booted from the forum, but I have to agree with you on certain aspects of your post. Several months ago, my comments on "tuplets" were deleted, and the sad thing is that at least certain asects of the posts offered some insight into how do deal with them. My remarks would have been valuable to anyone dealing with the problem. If a friendly environment is expected to be maintained, posts that deal directly with the subject of note entry into Musescore should not be deleted just because the developers or operator of the forum decide to abuse their power. In theory Musescore is a community effort. Sometimes certain members of the community, "users," really only have one option: All they can do is express their opinion. I'm not saying the developers need to accept the opinion, but they should respect it to the point that they do not delete it from the forum. After all taking the time to enter into the discussion is work too.
In reply to Not to get booted from the by gBouchard
Do you mean comments in https://musescore.org/en/node/55391? I'm not familiar with that thread, but I've never seen posts or threads deleted before and I've been here a number of years. Be careful with the accusations.
In reply to Not to get booted from the by gBouchard
@gBouchard as the developer of the musescore.org and the only one with the ability to delete posts or comments, I can tell you that your comments were not deleted, but unpublished due to a overactive anti-spam algorithm. It's a very unfortunate coincidence and it has nothing to do with you or your writing. Please continue the conversation.
In reply to @gBouchard as the developer by Thomas
The announcement of Dorico remembers me this topic because Dorico's doc contains:
"Notice also that you can click on a stem to select all of the noteheads in the chord, which is very convenient."
In reply to The announcement of Dorico by frfancha
Hmm, if you select a note, at the bottom of the inspector you can select its stem, but not vice versa, that might be a good improvement, maybe?
In reply to The announcement of Dorico by frfancha
Unless I'm mistaken, Dorico does this only in its Write mode, not in the Engrave mode, which is the one where you have access to adjusting the size and position of elements.
In reply to Unless I'm mistaken, Dorico by Isaac Weiss
Exactly. Perhaps we need a write mode?
This is still an issue for me 2019
In reply to This is still an issue for… by ZachWood
In 2019, if clicking something gets you something else, press ctrl while you click the same thing and something else will be selected.
In reply to In 2019, if clicking… by mike320
ok thanks, I didn't use that workaround yet! Still couldn't there be an option to not select note stems?
In reply to ok thanks, I didn't use that… by ZachWood
I don't think this makes sense, as mentioned, it's sometimes necessary anyhow, and it really seems weird to have a special option just for this. We could add a checkbox to the Inspector to exclude them, but that wouldn't really change anything from the perspective of clicking notes - it just means that instead o the stem being selected when you miss the notehead, nothing would be. But elsewhere, we discussed the change made at 3.1 to make noteheads "win" more often, and I'm glad to see that this seems to have been successful.
In reply to I don't think this makes… by Marc Sabatella
Selecting the stems should just not stand in the way of editing the note(head)s, which is between 90% (when fine tuning the look of a score) and 100% the thing you want to do when you click in the proximity of a note, is this really so weird?
Just so you understand the point: Yes, I wanted nothing to be selected instead. Really desperately. I expected the option in the selection filter.
The common way to deal with a misclick is to click again, till you hit the thing. I would argue it is more intuitive for the user, and it would improve more than just my user experience to just have an option to not accidentally get into modes one never wants to use.
You fixed a lot of my missclicks and improved user experience with a carefully engineering hitbox change, which I am thankful for. But... Adding the stem to the selection filter would have solved the missclick issue and would have improved another part of the user experience.
I'd still argue to include the stem in the selection filter for people who frequently missclick. It may seem weird to you to have the special option, but it doesn't clutter and really doesn't influence anything else than improve the software for a (debatable) amount of people.
Hardware problems are certainly not the only issue, think accessibility, imagine people with bad eyesight or twitchy fingers.
Also, when drawing a selection box, the note stems also get selected and that seems to prevent some editing to be done (opposed to individually selecting the noteheads with ctrl, you can fe not change note length).
Either way: Thank you very much for your prompt answers and the work the team put in this incredibly software and even small concerns of users!
In reply to Selecting the stems should… by ZachWood
As I tried to explain, the selection filter wouldn't help. Disabling something in the filter doesn't force something else to be selected instead, all it does is prevent the selection of the disabled element. That is why we didn't choose that approach - it would not have worked. Instead I picked one that does work.
Not sure what you mean a out the box. This - a tangle selection - selects everything in the range. Notes, stems, dynamics, slurs, etc. It is true that there no meaningful behavior for duration change of a range selection - not really clear what result you would want, but there are specific commands for this - but the inclusion of stems in the range has nothing to do with that.
In reply to As I tried to explain, the… by Marc Sabatella
I totally agree with ZachWood on this. The simple fact is that I select notes constantly, and I want to select stems exactly never. Any time I click, and the click leads to selecting a stem, it is 100% guaranteed that was a mistake. There simply is no situation in which I ever want to select a stem separately from the note it is attached to.
In reply to I totally agree with… by peastman
I quite often need that, to tie a chord and often find it quite difficult to really hit the stem, even more so if it has flags too.
I totatlly disagree that notes are hard to select, I never had a problem with that. Stems are hard to select at times and I have to zoom in quite a bit to finally hit the right spot
In reply to I more often need that, to… by Jojo-Schmitz
I agree with the sentiment that the hitbox for stems is too small, a bigger hitbox and the ability to turn of selection of stems would be the most helpful solution for everyone I believe.
Also, notes in generally are not too hard to be selected, but selecting and editing multiple notes could be a lot quicker and less error prone, if there is the option that other elements can not be selected.
In reply to I totally agree with… by peastman
It's also needed to extend the stem. But, have you tried the current version? I implemented the change discussed earlier, so now the stem no longer "wins" over the notehead. The only time you ever select the stem now are cases where you absolutely totally completely missed the notehead.
In reply to I totally agree with… by peastman
EDIT: I removed my distasteful joke
In reply to As I tried to explain, the… by Marc Sabatella
I don't expect something else to be selected, I want nothing to be selected till I click the thing I want to select. As does everyone else. But it's not about predicting what any user wants to select, being able to select note stems can sure stay the default. The option to never select note stems (or rests by the way) would be more useful for me and most likely not only me than most other options in the selection filter. It certainly would be the only things I would regularly use in there.
To reiterate the tangle selection thing:
The tangle selection selects everything in range except for the in the selection filter deselected stuff. Thus, if you deselect dynamics and lines, these are not going to be selected. It is not possible to deselect everything except noteheads. Only having noteheads selected would lead to a meaningful output for several operations for the selection including changing note duration for all of them. I am not aware of specific commands for this!
I wanted to lengthen every note in several bars, but not the rests in between, how could I have avoided having to click on every note individually?.
I am used to clicking on every note I want to change individually, because shifting with arrow-, ctrl- and shift- keys leads to unexpexted results, and selecting multiple notes in multiple lines at the same time is even impossible otherwise.
There seems to be the broader issue, the anti-feature of not being able to add elements to a selection except by individually clicking on every element of the whole selection. Maybe this is where the user experience can be improved most.
I put it again, in simple terms: Being able to deselect note stems and rests in the selection filter would be an amazing feature for me!
The reflections on this lead me to realize the selection of multiple elements in musescore needs improvement in general, maybe I should open a separate topic for this?
In reply to I don't expect something… by ZachWood
I'm confused then. If you didn't want accidentally clicking a stem to result in selecting the note instead, what benefit do you see in the result being nothing selected? I'm struggling to see it. Either way, if you want to select the note, you have to try again.
Again, the issue with changing durations for multiple notes has absolutely nothing to do with stems. It's simply that the operation is defined to work on list selections, not range selections. It's not impossible that someday it would include range selection, but right now, it's one click (the Notes button in the Inspector) to convert a range selection into a list selection. that's actually easier than having to deselect and then reselect stems in the Selection Filter. So yes, you can select notes individually, but in your case, far simpelr is to go ahead and do the range selection then press "Notes".
On the other hand, the operations that do work on range selections, like Paste Half/Double Duration, already work with no need to or benefit from excluding stems or anything else from the selection.
Said as clearly as I can: even if you could exclude stems from a range selection in the Selection Filter, it would still be a range selection, and operations that don't work on range selections would not magically start working. Nothing about stems has any bearing whatsoever on this.
In reply to I'm confused then. If you… by Marc Sabatella
The benefit of nothing being selected is, that I can click as many times at the proximity of the thing I want to select as needed with my current accuracy (depending on hardware and ability/disability), without accidentally entering editing mode of another element which I would have to quit or even moving another element which I would have to undo. It was a big issue when the hitbox was really unintuitive, it is now only a minor inconvenience that is not fixed the way I did think it would, because the selection filter is not made to improve the selection speed, but to copy or delete certain elements, as I now know.
To press "Notes" in the Inspector to change to list selection really speeds up some work I do, thank you for the information, I now can select a range and add/remove single notes from the selection. And the stem is not an issue at all in list selections, thanks for clearing that up, I understand now how you could not understand what I thought was obvious.
I am still looking forward to an update to the selection features. Is there something in the way of letting ctrl+shift add another list selection to the existing selection or just generally allowing to add list selections to current list selections?
If I can just roughly draw a box around the note and it is selected or added to my selection, I can be way more imprecise/quicker with my mouse and thus my issue disappears.
In reply to The benefit of nothing… by ZachWood
Glad we're getting somewhere!
Cltr+click does add to a list selection. There are also options in the right-click / Select / More dialog to add to or subtract from a selection. So I'm not sure what you're asking here. Could you attach a score and a very specific description of what you are trying to select?
In reply to Glad we're getting somewhere… by Marc Sabatella
I am getting somewhere by being made aware of workarounds to existing issues at least.
Ctrl+click adds one element at a time. My point is that this is painfully slow and error prone ( to briefly get back to the original topic: it used to be a lot more error prone).
My suggestion is to give the option to add to a selection by point+"draw selection box" that does not change the mode or (de-)select random stuff. Ctrl+shift+"draw selection box" would be the shortcut other programs use for this, as it is the synthesis of adding to a selection and drawing a selection box.
I am opening a new topic, as this has not been an issue of hard to select notes compared to stems, but an issue of how selection works in general.
In the perfect program I would have liked only one sort of selection and the possibility to add/remove to this selection freely, multiple elements at a time with a filter or by selection box. Doing operations on the selection would only apply to the elements to which they can apply instead of failing and selections would stay selected when ctrl is pressed.
To make an example, I have the issue just now, it's recurring multiple times an hour:
![selecting.png]( "selecting.png")
15 instruments in 10 different measures play a 8th note glissing up to another note like in the picture. I want to select all the 8th notes and lengthen them to 4th, as the 8th note proved to short. I have to point and click on all the notes individually, if I accidentally select a glissando it is very difficult to deselect it (possibly a bug). Either I run the risk of deselecting all or I have to press 5 every time I click on a note, sometimes missing and having to undo stuff.
It is a lot less frustrating now that the notehead hitbox is bigger though, so thank you and this topic is closed for me, see you in the other thread!
In reply to I am getting somewhere by… by ZachWood
There is also a "same duration" checkbox in that same Select / More dialog, so that would be a very simply way to select all eighths in a range.
If you come across something else you are having trouble figuring out how to do in MsueScore feel free to start a new thread, attach a score (often a picture is not really good enough to understand fully, although I think it was here unless). Chances are we can show you can easily get it done. And if not, then feel free to make proposals for new features that you think would help. Right now I don't understand the "selection box" you mention or how it would help here, but indeed, this isn't the right thread for that discussion.
In reply to There is also a "same… by Marc Sabatella
I know about that, there are unfortunately lots of other 8th notes in the proximity, that would be selected as well.
By selection box I mean moving the pointer with the "mouse left" and "shift" pressed over an area to select elements within the box shaped area created.
If you take a look at the new thread I opened, it's not about specific issues with my score but general and easily reproducible software behaviour that in my opinion could be improved upon.
In reply to I don't expect something… by ZachWood
The other thing I think you mare misunderstand is that the main purpose of the Selection Filter is not to make something unclickable, it is to control which elements within a range selection get copied/pasted/delete etc. So the actual main effect of deselecting stems in the Selection Filter would be to break copy and paste, leaving you with stemless notes in the copy. Similarly, it would break Delete, leaving the stems behind since they were excluded from the selection. Not that MuseScore supports this, which is the main reason they aren't an option in the filter - only elements capable of being copied / delete can work this way.