Shouldn't dotted state turn itself off after one use?

• Feb 12, 2021 - 01:56

When entering notation, I find it puzzling that when I activate the dotted state it remains active until explicitly turned off. The most typical use of a dotted note is in combination with an undotted note: a dotted quarter is typically followed by an undotted eighth. Wouldn't it be easier on the user if, after a dotted note had been entered, the dotted state would be automatically cancelled? Currently, when I enter notation in rhythm mode, a dotted quarter followed by an undotted eighth requires the following keystrokes: DOT 5 DOT 4. With the automatic cancellation that I suggest, the keystrokes would simply be DOT 5 4.


As much as I may agree, it isn't puzzling in the sense that augmentation is probably considered "rhythm information" in addition to its being untoggled when switching duration while in "regular" note-entry.

My question then would be, why the inconsistency between regular note entry and "Rhythm" note entry? FWIW, it'd be a curiousity to see someone explain that.

Observation: it looks as if the code deliberately keeps the dotting for rhythm mode when a rhythm toggle is changed (there's an area specifically dealing with this for rhythm as maintaining the augmentation toggle) so it seems as if it isn't an oversight. Let's see if anyone explains the use case.

If it would be generally acceptable, it wouldn't be a problem for me to change that behavior. If many rely on the current behavior, then it'll be hard pressed to get the code changes implemented.

In reply to by worldwideweary

I hadn't realized that you were a member of the musescore team, so I'm glad I have the chance to address you directly. I truly can't see any point in having the dotted state persist in rhythm mode (and as an enthusiastic user of that mode I can tell you that it's really annoying). I'd be interested in learning what you are able to discover about the justification for this inconsistency. If this reason turns out to be no longer valid, or an error in judgment, I wouldn't think it would cause much harm to correct it, as such a change would not break anybody's existing scores and would only require a slight change of habit from users. Can I leave this with you, or would it be any help for me to present it again as a bug report?

In reply to by David Mayerovitch

I merely contribute, so I also am at the mercy of user-input as to understanding why something is a certain way when I think otherwise (hence forums for verification, etc.)

I don't see why it would cause any harm to change rhythm-entry into being in accord with regular step-entry as relates to augmentation toggling when switching duration, but let's see if anyone attests to some specific use cases here. Some people may find it useful to be retained while inputting rhythm. I don't personally use [rhythm + repitch modes] for entry, so I don't have an opinion formed from experience.

An issue-tracker report is welcomed to be formed by you, at least as under "Suggestion" until some further input by others - that way there'd already be an issue-# prepared to facilitate a change in the code later. If you do so, please provide a link to it into this post so I can get quick access to it later. Problem is version 3 is wrapping up to be switched to version 4, and who knows if the change would actually get into another sub version (3.6.3 for instance) before 4.0 is released...

i think I'd only need dotted state to remain active in the context of a a compound-meter time signature where a dotted value is the metrical unit (i.e: dotted quarter in 6/8, 9/8 or 12/8) . But still in that context this behaviour shouldn't always be preferable: in practice, I think there are many instances in a 12/8 piece where I'd need to write dotted quarter followed by quarter and eighth -so even in compound time, I'm not sure it is more practical to keep dotted state active after entering the dotted note.

Compound time signatures aside, I'd say in my experience, in music notation the number of instances where a dotted value is followed by a non-dotted value far outweight those instances where actually one dotted value follows another. Especially in the commonest time signatures 4/4, 3/4, 2/4 it is very unusual to find successive dotted notes, and very very usual to find alternations of dotted, non-dotted...

In reply to by hellin95

So, in sum, I strongly agree It would be more efficient for the typist if the dotted state were deactivated after a dotted note is entered.

Perhaps it could work like the SHIFT key in a text processor, whose effect only remains active for as long as the user holds the key down? This would give the user the greatest choice to optimise keyboard input depending on the musical passage to be typed....

In reply to by hellin95

For what it's worth, what I was mainly concerned about in relation to the OP's post is not the retaining of the augmentation state after entry of a pitch, but rather its retainment after a duration change. It toggles-off during normal note entry, but it retains during rhythm entry when changing duration

They seem to be two separate situations:
1) losing augmentation after entry (like how accidentals operate) as per hellin95 mentioned

2) making rhythm entry equivalent to normal entry (losing augmentation after duration change).

I'm interested in seeing the reasons for #2 not to be the case, and itt would be a very simple procedure for 2) to be implemented

In reply to by worldwideweary

I think #2 makes perfect sense, both for efficiency of typing, and consistency across entry modes.

I see #1 might be debatable, since in compound time signatures, you could easily find yourself writing dotted notes of the same value in succession (dotted notes of different values remains unlikely and shouldn't be default, as per #2).

That's why, perhaps having a hold-down key function (and/or a checkbox, as suggested by others) would allow for the greatest user customizaiton as fits their workflow.

There is a tendency in MuseScore dev to discuss a lot what must "the" good behaviour, implement it, and leave 50% of the users unhappy.
Your question is related to the tuplet rhythm that must be reentered on each beat instead of sticking like other rhythm.
It is high time to recognize that there is no universal solution and introduce a "sticky" check box so that each user is free to select his preferred behaviour.

In reply to by frfancha

As a user, I agree with frfancha that a check box option is a solution that will satisfy everyone. The label could be something like "Retain dotted state after use". The default (unchecked) state should be automatic cancellation of the dotting. Even more explicit would be a pair of radio buttons: "Cancel dotted state after use" and "Retain it".

Making the behaviour a user option would be consistent with MuseScore's philosophy of being so richly customizable. A user might want the auto-cancel option most of the time but switch to sticky when working in compound meters.

Frfancha mentions tuplets: These, I think, should remain sticky at all times.

In reply to by David Mayerovitch

About tuplets I'd prefer to apply the same principle: let the user to choose whether tuplets should remain active or be deactivated after one input, since I think both situation are quite commonplace. For example: there are many passages when you might easily find yourself writing long series of triplets (Haydn / Mozart sonatas), but it's also frequent to have triplets alternating with full values (Beethoven's quartets come to mind...).

In this regard, what I do so far is to copy and paste several tuplets, then just re-pitch.

In reply to by David Mayerovitch

So, here's the other side of that coin. The dotted state remaining active must be a keyboard note entry problem. As a mouse user, I've never seen it. As soon as I select an 8th note after entering a dotted quarter, the dot is de-activated.
While I agree that a check box might be the answer, it would just be another thing I'd have to think about that I don't have to now.

I agree a better system of entered pairs like dotted quarter / eighth would be nice. But I would note that what you are describing is true only in the special "rhythm" input mode. In standard note input mode, the dot already turns itself off as soon as you press 4.

In rhythm mode, as I recall, it kind of went back and forth during development and based on feedback from users, the sticky dot won out for reasons I don't recall.

In reply to by Marc Sabatella

I think it is worthwhile to revisit this decision. As it stands, when entering notes in rhythm mode, by far the most common situation is a dotted note followed by an undotted note, so it is logical to have auto-cancellation of the dotted mode. It saves a keystroke each time. If anyone can propose a good practical reason to make the dot sticky, let's get it out there so we can assess it. Aside from the practical advantage of saving a keystroke, auto-cancellation would also minimize user confusion because the behaviour would become consistent across the different modes of note entry.

In reply to by David Mayerovitch

" by far the most common situation is a dotted note followed by an undotted note,". Well, not by far if you write mostly in 6/8, as has been pointed out. It seems to me that MuseScore is doing exactly what you are telling it to do. You've selected a note duration and it keeps that duration until you change it. The program has no idea what you want next. Even in 4/4 there are times where several dotted quarters in a row happen.

But then, I find rhythm, re pitch, and keyboard input way too many things to remember.

In reply to by bobjp

Overall, I'd agree it makes sense to keep rhythm mode entry consistent with step-time mode - i.e: dot is deactivated after selecting a different rhythmic value. As it currently stands, I think this subtle difference of behaviour across entry modes may be confusing for the newcomer.

Besides, I do think it is very infrequent to find instances when you might want to write dotted quarters followed by dotted eighths, whether we are dealing with simple (4/4, 3/4) or compound (6/8, 12/8) time signatures. It is way more frequent to alternate between dotted and undotted values of different durations (i.e.: quarters and eighths), whether it be in 4/4/, 3/4/, 6/8, 12/8 etc.... So still, it'd make sense for the solution that required fewer keystrokes for the majority of instances to prevail, fo the sake of typing efficiency.

I think this is one of those instances where practicality should prevail over strict logical consistency - i.e.: "user requested dot, therefore dot remains active until deactivated". And besides, this would maintain consistency across rhythm-entry and step-time modes.

In reply to by worldwideweary

There were many different aspects to this discussion, but I’m not aware of any specific GitHub issue ever being filed based on any consensus here about any proposed change. To me the actual behavior is as expected. Can you be more specific about the potential alteration you were wondering about?

In reply to by Marc Sabatella

Hey Marc. Greetings again.

Sure! The potential alteration is in relation to the Original Poster's comment back in early 2021:"Wouldn't it be easier on the user if, after a dotted note had been entered, the dotted state would be automatically cancelled?" in reference specifically to Rhythm Mode.

Apparently at the time I agreed that it would be easier, thought of making a change related to the post, but then was concerned someone else might rely on the "current" behavior of retaining the augmentation (and in the meantime of waiting for some further conversation, 3.x got finalized with no allowance for further updates, and I lost interest since master branch at the time seemed in a weird state of flux).

It seems, since there wasn't much else to say, that an advanced preference or something like it for retaining (or not) the augmentation toggle while in Rhythm Entry Mode was the way to go - give the user a way to choose one or the other (so as not to perturb someone who has acquiesced and enjoyed the "current behavior" for whatever reason). The guy said he found it "really annoying" and I kind of agreed and still do with him to have to de-toggle afterwards in Rhythm entry, which is supposed to be "speedy" (depending on circumstance).

I have this in my personal build as one of those boolean advanced preferences, but haven't checked specifically about this in version 4, and instead of doing too much research figured I'd post here to see. What triggered my interest is forgetting about this and realizing the annoyance while doing some notation entry myself. And now with all these words, I maybe would've been better off just checking github, haha, but what the heck. Never hurts to bring up an old post for fun from time to time I suppose.

In reply to by worldwideweary

I’m not aware of anyone having submitted a GitHub issue about this, so, no surprise if no change has been made.

FWIW, I would not favor a preference to alter the behavior. Better to just have two separate commands rather than one command that does different things depending on some obscure hidden setting. When I’m in compound meter, I’ll want sticky dots; in simple meter not so much.

In reply to by Marc Sabatella

When you say "two separate commands", what kind of commands do you speak of? For me, I'm thinking of the "toggle duration" behaviors which are keyboard commands and the padbuttons that can be clicked.
Update: Do you mean "enable/disable sticky dots" as a toggle/command? Something that manifests on the UI like the duration pads themselves? I think that makes sense .

Rhythm mode:
1) Invoke a duration toggle change
Result: toggles said duration, places a duration-based note, and leaves untouched augmentation toggle.

Regular step mode:
1) Invoke a duration toggle change
Result: In 3.6 at the time, this prepares for entry and removes the augmentation toggle if there is one.

Apparently in version 4 it has been decided to keep the toggle also like in rhythm mode now, (just checked in 4.1.1). So now it's a little different as there's no discrepancy: they both retain the toggle when changing duration. Something I don't like personally, but I didn't have anything to do with that change, and probably just because I'm used to it for years the previous activity.

My question though is what kind of command for these "two commands" would be possible to change the behavior of when toggling the durations via keyboard or clicking the duration toggles to un-toggle the augmentation dot like desired in this request besides a Notation Input option in preferences.

In reply to by worldwideweary

I hadn’t thought it through specific to this case, but was speaking in general - preferences to alter behavior of a command are a last resort desperation move at best. If you need to support two behaviors, having separate ways of achieving them is virtually always better.

In this case, it might mean having separate sticky-dot and temporary-dot commands. Or it could be a convention that entering the same duration again keeps the dot, but changing it clears the dot. Or it could switch automatically based on compound vs simple meter. That’s just three ideas off the top of my head. I’m sure with more thought one could come up with others that don’t require the complexity and limitations of preferences to flip behavior unilaterally. The point being, a single user might well sometimes want one behavior and sometimes the other, and there should be a way to get the behavior they want in the moment they want it.

In reply to by Marc Sabatella

Yeah, it could be a number of ways.

I just realized I was wrong: MU4 does lose the augmentation dot when changing duration in step-entry, just like in MS3. (Not even sure what I was referring to earlier now >_<) They both retain during rhythm-entry. For me personally it's no issue since my local setup works how I want, but again that "speediness" in rhythm-entry and having to be explicit/literal as to what is being entered was seemingly what was desired by what was said in this forum discussion, and don't like it retaining it in rhythm-mode. Hopefully someone can come up with a nice, acceptable design for the public with some options

Do you still have an unanswered question? Please log in first to post your question.