Selecting elements should not switch input duration

• Aug 15, 2012 - 12:14
Type
Graphical (UI)
Severity
S5 - Suggestion
Status
by design
Regression
No
Workaround
No
Project

Whenever I select an element in the score, the duration setting in the toolbar switches back to quarter notes or to whatever gets selected. This leads to me constantly entering notes with a wrong duration, thus totally disrupting my workflow. I would expect the duration setting in the toolbar to be a reliable, user-determined thing.

Of course, it is also desirable that the duration of a note doesn't change when I only want to replace its pitch, so I'm guessing that's the reason for the current magic. But I wonder what's the more common use-case that should be supported by default: entering notes (i.e. replacing rests with notes, usually shorter than the rest) or changing the pitch of an existing note?


Comments

Can you be more specific about the exact sequence of steps you are referring to? And are you talking about the current code trunk or how things are in 1.X?

I can't think of cases where you'd be trying to selecting notes while in note entry mode, but then, you can't enter notes otherwise. So I'm not seeing the disconnect you refer to. If you aren't in note entry mode, you clearly are not trying to enter notes, so It makes sense that the behavior is that which supports the main thing you *can* do while note in note entry mode - change pitch.

"If you aren't in note entry mode, you clearly are not trying to enter notes, so It makes sense that the behavior is that which supports the main thing you *can* do while note in note entry mode - change pitch."

I AM trying to enter notes, because MuseScore automatically switches to note-entry once I hit a letter (which is good). Then I hit 'N' so I can select stuff again. I select a rest, maybe in the next measure, want to continue entering 16ths - which I specifically chose before - but what comes out is a quarter.

When I click on a rest, I usually want to create a note there, or change the duration of the rest. If I want to create a note, it is not safe to assume that the note will have the same duration as the rest, or that the note will be a quarter. But that's what the current code does (2.0 trunk). It changes the duration setting for me, and I am surprised. In most cases I want to create notes with the same duration that I chose last. If something else happens, I am surprised.

Maybe a cheap fix could be not changing the duration when the user clicks on rests.

Also, remembering the user's original choice might be a good thing. So if he wants to change an existing note's pitch, it's okay to use the duration of that note, but as soon as something new is entered, the duration setting could be restored to the one set by the user.

By the way, I think the current 2.0 behavior is similar to the 1.2 one. I checked on both versions, and they both destroy my setting.

I can't see why you'd want to make a special case for rests. I'm just as likely to want to alter a rest into a note of the same duration as I am to start note entry there. And if I want to start entering notes, I don't normally begin by click a rest (or a note) - I begin by clicking an empty, which currently always resets to quarter note. So that's what I thought you were actually asking about. I'd probably support a propsoal to change the behavior when entering note entry in an empty measure to not alter the current duration.

But I don't think I'd want any change to the current behavior in terms of what happens when you click on a note or rest while outside note entry mode. That behavior is too useful to change just because some particular use case might happen to want a different default. That's my opinion, anyhow. I think no matter what the behavior is, it's going to be what you want sometimes and not what you want other times, but I see no particular reason to believe the current behavior isn't what I'd want more often than not.

Well, rests are a special case by definition. They are something else than notes. The only thing they share with notes is duration.

I disagree that the use cases are equally likely when selecting rests. When I click a rest and then hit a note, I want to generate a note of my intended duration, not of what happened to be there before. Anyway my experience with the current behavior is that I'm constantly undoing and redoing my actions because the program constantly trashes my duration setting. Had the same problem with Sibelius, by the way.

Since we're only exchanging opinions here, maybe it would be worth a try to change the behavior just for evaluation. And I'm offering to do it myself. I'm just not sure if anyone would even consider to take a look in the end.

But on a much more general note - and that's a whole different discussion - I would challenge the whole concept of a "note entry mode", because modes are generally bad and force you to keep them in mind all the time. This great project has the opportunity to make things better than Sibelius, rather than doing it "the way it has always been".

All I can say is we seem to have different working methods. As I said, if my goal is to just start entering new notes, I don't begin by clicking a rest - what the point of that be? I just click the measure. Why are you clicking individual rests if all you want to do is start entering some notes? That's the part I don't get.

The only reason I can see for clicking a specific rest before note entry would be if you specifically want to change that rest - eg, to turn it into a note. So yes, it does seem to me that having the value selected is the right thing the majority of times - probably over 90% of the time, actually. So I personally can't imagine why the change you suggest would be an improvement.

But again, that's just me. Maybe most people click rests instead of measures as a prelude to note entry. Perhaps someone who is sufficiently motivated could do a study, monitoring user input, counting clicks, etc.

Anyhow, since this is open source, if you feel strongly enough about this, why not try implementing it yourself and seeing if you still like it, and then maybe pass it along to other to see if they agree?

I still think it would be much easier to simply stop clicking rests if you don't want to replace them, though.

As for note entry mode, sure, it would be possible design an entirely different program that operated under different principles, and it might be better in some ways. Likely worse in others. It's not just Sibelius but every notation program I have ever encountered that has some notion of input modes - also virtually ever graphics program I have ever used. And for good reason, I suspect. It's probably tougher than you might think to design a notation (or graphics) program with no modes. But feel free to give it a shot!

Since you're asking:

"I don't begin by clicking a rest - what the point of that be? I just click the measure."

I could ask you the same question back. Why would I click the measure? Then it gets a blue frame and it looks like I'm limited to editing just that measure. Or like it might be deleted completely if I press the wrong key. It doesn't give me the feeling that I have aimed at a specific point to insert something, but that I've selected a region - why would I do that now? When I insert text somewhere in a text editor, I place a cursor at the specific point and start typing - I don't select the whole paragraph first.

"I still think it would be much easier to simply stop clicking rests if you don't want to replace them, though."

I think computer programs should adapt to people and not the other way round. And as I said, I DO want to replace them, but usually with notes that have a different duration than the rest. How could I accomplish that, say, starting on beat 3+, by selecting the whole measure?

The reason I don't click the note is that clicking a note is not how you normally enter Note Entry mode. It's how you edit a specific note. Simple as that. Have you *tried* clicking a measure then hitting N? You'll find the cursor is placed right after the last note - which is say, right on the rest. So it works just fine.

As for the analogy to word processing, first, that is dangerous because MuseScore is not a word processor, and a lot of things are necessarily different. But consider - in a word processor, click a letter in a paragraph written in one font, now click a space in a paragraph in another font, and start typing. Do you get the font the first paragraph? No, you get the font of the paragraph where you actually clicked. Clicking a space changes the font just as surely as clicking a letter. So actually, MuseScore *is* behavior more like a word processor here. Clicking something in MuseScore changes the duration toolbar to match, just as clicking something in a word processor changes the font toolbar to match.

Anyhow, yes, it would be *possible* to rewrite the interface the way you describe, but then I'd lose the funcitonality I rely on. Why make me give up something I find very useful? It doesn't have to be either-or. We can both have the behaviors we want - but it will require you to click the measure rather than the note. That hardly seems so much to ask.

Of course, as I said, MuseScore doesn't preserve the duration when start by selecting the measure either - it resets to quarter note. But that's something that could be changed without angering a lot of people by removing an extremely useful feature.

I just tried. When there's a quarter on beat 1, click the measure, hit N, it
places the cursor on beat 3. Not very useful, also not what I would
expect. User interfaces should be all about meeting natural expectations of users
- or creating the right expectations in the first place - instead of making users
read manuals and learn the behavior of the program, so that's why see much
room for improvement there. For you it might be different, because you already
learned the behavior. I'm also used to driving a stick, and I wouldn't want to
give that up, because I put effort into learning it a long time ago. Still automatic
is probably easier.

Then again, I wouldn't want to take something you find useful away just for the
sake of it. So could you tell me again, which part of the behavior we discussed
is extremely useful for you?

I agree, angering a lot of people would be wrong. But we're speculating about
numbers here. I actually don't know any other MuseScore users, so I can't
really judge. I wish more people would engage in a discussion like that.

So, if the cursor is in some case on the wrong beat, fix that. Again, no need to get rid of useful and very intuitive (considering the font analogy) behavior.

Again, what is useful to me is that any time I click on something, the duration toolbar is changed to that value. So I can then replace that thing with a different pitch (or a rest). To me, that's the only reason for clicking something - to change it. Now, 2.0 provides a new "repitch mode" that partially reduces the need for this behavior. But still, the behavior of the interface is quite consistent and intuive to me - click something, toolbar is changed to reflect it. Just like a word processor. So I really think a change like you are suggesting - while no doubt occasionally useful for certain usages - would be very counterintuitve to me. It would actually seem like the toolbar were broken. Wouldn't think the same if you clicked on some text in a word processor and the toolbar weren't changed to reflect the font?

So as for natural expectation, again, we have no numbers. But clearly, different users will have different expectations, so you can't really make the notion of "meeting natural expectations of users" the main deciding factor - that would give you at least two or three different answers to almost every question. There is no getting around the fact that no matter what implementation choice one makes on a given matter, some users will find it meets their expectations but other will not. Which doesn't mean it isn't worth the effort to at least think about that, but in this case, it's pretty clear there are two very different and incompatible sets of expectations involved.

I tend to agree with Marc on that one. The UI is very toolbar oriented and when you select something, you expect the toolbar to be updated. If we want to change this, we should work towards a "rythmic palette" somehow. Something you don't expect to follow your selection.
I agree with stateless UI... but that's a huge endavior for a score writer...

Status active by design
Regression No
Workaround No

Toolbar reflecting selected duration is by design.