Changing length of notes is too difficult

• Oct 9, 2021 - 20:28

When shortening a note, e.g. quarter to eight, MuseScore inserts a rest directly afterward.When lengthening a note, e.g. eight to quarter, MuseScore deletes the following notes (eight count or more.) If I want a triplet to begin a little earlier it's even harder.

When I'm trying to get the timing of a song to sound a certain way, it is very labor intensive to essentially "copy" the entire remainder of the score, do my editing of a single note, then "paste" the remainder of the score immediately after my edit.

I realize MuseScore is trying to maintain the measures and timing of the score, but I would like to control that.

I believe the easiest would be to automatically move ALL notes left when I make a note shorter, then place measure markers appropriately. When lengthening a note, move ALL notes to the right, then recalculate measures. This could be an "Edit Notes" mode rather than Enter Notes mode.

The result would be a much faster and more reliable way of editing notes, giving us the ability to fit a passage into a measure or withing certain beats and get the timing right. I write and understand software, and I don't believe this would be a difficult mode of editing. (Think of Microsoft Word) when in Overwrite mode or in insert mode. In insert mode, everything following the cursor moves right as you type while in Overwrite mode, if you type in a smaller character (e.g. W - i), everything moves left.

Changing Midi start and stop times and events would be fast and easy.

Will you consider this as a feature request?



That's just not the way MuseScore works.
There is the insert mode though (but that is inserting into a single measure, not pushong notes into the next), ans also the option to delete the selected range

I would say you are thinking about this backwards, and that's why it's hard to wrap your brain around what is actually happening.

When you shorten note, don't think of MuseScore as inserting a rest. Think of it as simply doing what is necessary to prevent other notes from inadvertently moving earlier. And similarly for when you lengthen a note. In other words, it's not just about preserving the duration of the measure - it's also about making sure that asking MuseScore to do one thing (change duration of a note) doesn't accidentally do something entirely different (change start time of some unspecified number of subsequent notes).

if for whatever reason in the particular case where you are changing duration you also - as kind of a separate matter - happen to want to move some unspecified number of subsequent notes (only you can possibly know how many) earlier or later, simply do that directly - via cut and paste. It's fast, easy, and best of all, give es you absolutely complete control over when to move those notes and when note to, and how many notes to move.

So, the key is to realize these are simply two separate operations that are done via separate commands. Changing duration changes during, it doesn't move notes. Moving notes moves notes, it doesn't change duration. Sometimes you want to do one but not the other, which is why it's great that MuseScore doesn't force these to always be connected.

Of course, it would indeed be possible to implement an optional command that would attempt to do both at once - change duration and also try to guess how many subsequent notes to move. Probably even a plugin could be created for that today. My guess is, the guess about how many subsequent notes to move would be wrong often enough that it wouldn't be as useful as people imagine (certainly that was my experience using a similar feature with other programs) but it wouldn't hurt to have the option.

In reply to by Marc Sabatella

" I would say you are thinking about this backwards "

I would say he is simply requesting insert mode exactly like what exists in Dorico and numerous other users are requesting.
The honest answer is that the concept of measure has been deeply embedded in the datastructure used in the MuseScore code. Meaning any feature implying a change of measure is a nightmare if not just impossible to implement. That's also why copy/"paste in place" time signatures will never exist ("paste by inseting whole measures" could be done though)

In reply to by Marc Sabatella

"...try to guess how many subsequent notes to move."

Computers do not guess. If the user lengthen's a note by a quarter beat the program knows exactly how many subsequent notes to move, and by how much.

As has been said Dorico does this. Full insert mode is sadly lacking in MS. I can count the number of times I've written exactly the right number of bars in a piece and never needed to insert an extra section, bar, theme, idea, etc on one finger.....

It may not be how Musescore "works" - but it seems a lot of users wish it was.

In reply to by [DELETED] 37205164

The computer still had to guess whether to move only within a measure, or a stem it the entire score. And what to do with note that now span accross a barline (tie them most probably) or beat now (combine or tie?) do no longer span a barline or beat (combine or tie?). Lots of guesses to make and wrong at least 50% of the time

In reply to by Jojo-Schmitz

A umpteenth thread concerning the same request. I finally understood that the MuseScore code had not been designed from the beginning to work this way, hence the systematic reference to cut and paste, perfect and unsurpassable for large sections of measures, but really too cumbersome, and clumsy for small corrections within a measure.
In fact, everything depends on the use you make of the software. If you are copying an already established score, with known, visible note values, I would say that this behavior would be rather irrelevant, since in case of a blunder, of a mistake, it is trivial to erase the "bad" note/rhythm and enter the good one.
On the other hand, for someone who wants to copy a score by ear, or a composer, or any other novice who wants to try his hand at composing a melody and who has no real preconceived idea, cutting and pasting is a real pain, and this is where there is room for improvement.
The idea of a scratch pad mode was mentioned several times (eg :, and it seemed to get a lot of votes, for lack of anything better. Unless I missed something, nobody is working on this.

In reply to by Jojo-Schmitz

Look I get it that MS is free for us, and that it's design is driven by extremely devoted un-paid programmers. BUT, can we please stop using the term "guess"? The computer does what the program tells it to do. That is it, on repeat, always (until it doesn't!) the same result from the same actions.

I just checked my Dorico to be sure and yes, inserting a 1/8th note resulted in everything moving exactly one eighth note to the right, and Dorico correctly calculated (funny how computers do this..) to split a 1/4 note at the end of a bar into an 1/8th - tied to an 1/8th at the beginning of the next bar. So it is not rocket science but good programming.

Of course it's rare to want to insert a beat or less into a piece and have the entire lot shift. But it is extremely common for me as a composer, to want to insert a number of bars, empty or otherwise, into an existing section in the piece.

The ability to shift everything from the insert point a certain number of bars to the right would be an absolute godsend in MS. Cut 'n paste in this scenario is very clumsy. And I'd have thought, no matter how MS was developed and for whom it was developed, insert paste should be very high on the list of required features. As a composer I cannot do without it - which is why I'm finding myself hopping between Dorico Elements for certain compositional tasks, exporting XML and Musescore for final layouts and tweaking.

I'm sure there's no one "perfect" scoring app that will suit everyone's needs, but MS could come pretty close I think if some of the often requested features were added, and not dismissed as "that's not how Musescore works..." Once upon a time you couldn't add a photo to a Word doc - as the user base increases so will the flexibility requirements. I'd have thought Educational use was high on the MS list, and composition is taught in schools, as well as any number of exercises that might require inserting bars into a piece.

Not a rant, just a serious request to consider this feature - and also to stop using the word "guess" with regard to computer programming - unless you're working on an organic parallel symbiotic non-linear random phrase generating compositional computer.....then I guess it's anyone's game.

In reply to by [DELETED] 37205164

It is of course not the Computer nor the Program that is guessing, theyx can't and that's the whole point. But the Programmer who wrote the code for it would need to make those guesses. And without being sure about what the various users really intended.

And the example you descibed is the easiest one, all the other scenarios I described are far more involved and far more likely for the programmer to make the wrong guess.
But ever there: what happens with the qurater noted in the first beat that now ends up on the 1-and beat, should it get split into 2 tied 8th notes? (possible solution: respell as per beam properties or some other coded-in musical riles) What if that inserted 8th (or another gets removed again, should the now split quarter note get reunited? How to distiguis that case from 2 toed 8th notes the user entered manually?
(possible solution: have a 'generated' property for ties).
Nit easy, nor rocker science, but that all needs to get considered, though through and impelementd.

to insert a number of bars
This is the very easy part and possible already, just select a measure and press Ins and, voila, there you have an extra (and empty) measure.

The ability to shift everything from the insert point a certain number of bars to the right
Define certain. That's a prime example where guesswork comes in.
Cut'n'paste though is a very precise thing here, you, and only you, know exactly what section you want moved and by how much.

In reply to by Jojo-Schmitz

When the user enters full insert mode there is absolutely nothing to guess.
The score must shifted until the end that's all.
Yes other insert mode, more powerful, allowing the user to set the "up to" point to which score must be shifted could be useful as well, but that's no reason to not do at least as well as Dorico does.

In reply to by [DELETED] 37205164

Before any insert mode gets implemented, it needs to be crystal clear what modes there should be and how exacle they should behave in all possible scenarios.
If you don't want to help in defining this, fine, but such a definition is not pointelss at all, it is a vital part, needed before any coding can start.

And with a name of "[DELETED] 37205164" you left this site already anyway...
I have no idea why it is possible for you to still post here. To me that is a bug, and a serious one.

In reply to by frfancha

"score must shifted until the end that's all" - except that probably the majority of people requesting this want no such disaster to befall their score - they want only the notes to the end of the measure moved.

That's why it is guessing as to which behavior to implement - the one you want, or the other others want. neither is likely to be correct but a small fraction of the time.

In reply to by Jojo-Schmitz

"As a composer I cannot do without it - which is why I'm finding myself hopping between Dorico Elements for certain compositional tasks, exporting XML and Musescore for final layouts and tweaking"

A question: why you don't toogle definitely to Dorico if it's behavior is more suitable for you?

In reply to by [DELETED] 37205164

So, as I understand it, the time you save on typing with Dorico (depending on your workflow and preference), you then lose it again on "final layouts and tweaking" (and here, MuseScore would have better qualities than Dorico?)
So we come back to the sentence you were expressing above, I quote: "I'm sure there's no one "perfect" scoring app that will suit everyone's needs"

But don't get me wrong, I am not 'trying to pick a fight'. At all. I have defended this idea (and I do defend it) in several threads (you can find them easily), at least the idea of a scratch pad mode.

Not for me. I'm comfortable enough with the program (and I don't compose) that I don't need it, and grind or cut and paste if necessary. I defend it simply because it is a recurring request (like others, e.g. copy-paste all elements) and this recurrence does not occur by chance among users. It corresponds to a need, not a passing whim.
And that we should take it into account, or at least try to. I fought so long, and for years, for example, to obtain the easy fingering mode, and the Paste Half Duration and Double Duration features implemented (among other advances) to speak with knowledge.

In this case, it seems that the program is facing a major difficulty (by its very design from the start), at least from what I understand from the various interventions of the programmers. Maybe this obstacle will be overcome one day? I don't know, let's hope so.

In reply to by [DELETED] 37205164

How on earth would you expect a computer to know how many subsequent notes you want moved/ i certainly don't know. It's likely to be different every time.

Computers guess all the time. Sometimes the guess is right, sometimes it is wrong. There is almost no time every that I'd want to literally all notes to the end of the score to be moved - that would be a complete disaster. in almost every single real world case I can think of. Every once in a while it might happen to be just the notes to the end of the measure, which is what Finale assumes. In the cases where that is the right guess, it saves me two keystrokes, so great. In the cases where it is wrong - if not the majority, at least a very sizable minority - it costs me more than two keystrokes to repair the damage. So, as I said, I was never a fan.

But indeed, as long we were not forced to deal with this - the vast majority of the time if I change a note's duration, I do not want other notes to move - I'm fine with someone implementing such an optional command.

WOW! I didn't think this was such a hotly debated request! Let me see if I can explain a little better.

When I enter a series of notes, as each note is entered, MS will DETERMINE (not guess) how to place and represent the note, and all it's properties. It does this using an algorithm using a set of rules. I hope we can agree on that.
Now let's say, after entering 16 bars, I realize that I forgot to enter two pickup notes because a certain target note should be on the 1 beat of the 3rd measure, rather than the '4 and' beat of the 2nd measure (I was transcribing and didn't pay attention to the beat or timing at that moment. That happens often during an 80 measure song.)
So I want to add two 16th notes at the end of the second measure "4 and" beat. If this was my only mistake, sure, the control-X cut, insert two new notes, then paste is easily accomplished. But when I pasted those last 13+ measures, how did MS know where to put the ties? The beams? How did MS know where to put measure marks? How did MS know anything about the new note placement? ANSWER: It used the same algorithms and rules!

So, in insert mode (say I select the last note in measure 2 and hit the 'insert key' and a little identifier shows up e.g.. graphic button is shown depressed, color change, status box, etc.) I enter two 16th notes and each time I enter a note, the computer does an automatic cut and paste of everything to the right. Conversely, If I deleted a note the automatic cut and paste to the right will shorten the entire composition.

I've written a lot of software and I don't understand why some use the word 'guessing' - it's simply the program doing it's list of operations. Of course, the laws of unintended consequences will rear it's head now and then, but Control-Z or Esc can work wonders. And if there were several instrument parts, it would be acceptable to limit it to a single instrument and have to manually do the same to all other parts if needed,

If MS was MIDI based, each note that starts to the right would simply get the start and end time added to - or reduced - by the new note length inserted or deleted. I have not seen the database that MS uses so now I am guessing about MIDI. Guessing is the result of thought and reasoning. Computers that are not AI based, don't do that, and even AI based need to be trained to determine a result.

I hope this is a little clearer about what I think would be a big improvement to MS and reduce the debate heat. No one who does not need this feature would be affected so I wonder why the great defense of current operation is so loud.

Cheers mates.

In reply to by nmeet

The guess - and it is absolutely positively a guess, there is no AI algorithm in the world that possibly know the answer - is not about the note you changed, but about how many subsequent notes to move. Of course it's a guess - there is no possible AI algorithm that could ever be redesigned that could ever know how many subsequent notes you want to move.

Which isn't to say it's not worth making a guess and implementing an algorithm around it. but let's be realistic about this - a guess is still a guess, and it's going to be wrong a lot. The two guesses most often proposed here - "move everything until tend of score" or "move only to end of measure" - are between them likely to be right probably 50% of the time at best.

In reply to by Marc Sabatella

Apparently I wasn't clear. ALL NOTES TO THE RIGHT (END OF COMPOSITION) are affected. There is no guessing on that. All those notes are already defined. No guessing on something defined, in context with the entire file. If someone wants to change something in the middle of the of the melody without affecting the entire staff, then the current way will do the trick.

AI does not KNOW answers - it learns the best (current) one but should continually be refining it's answer as more data/examples are given. This is not a debate over AI - it's unfortunate that I used it as an example. Please forget about AI as it is pointless in this discussion.

Actually, I think this whole thread is pointless because the developers are focusing on 4.0 now. If they have ignored previous requests, they'll probably ignore it in 4.0 too. (sigh)

In reply to by nmeet

And exactly this "move all" is what not everybody really wants. Some want it in the measure only (and that is implemented), some in the system, some in a certain section (see above), some in the entire score.
And again, on top: what happes to notes at the end, should they fall off the edge or the measure, system, section, score made longer, here also no common agreement is a given.
Way too many loose ends for any software designer or programmer to be able to even start working on this.
A musical score simply is not the same thing as a text document, where you can insert and delete charahters, words, sentences at entirly arbitrary locations.

In reply to by Jojo-Schmitz

"...And exactly this "move all" is what not everybody really wants..."

Ummm - don't use it?

Also - if you made the song longer you would need more measures. (Less for shorter.) Try pasting a few copied measures at the last rest in a song. It gets longer and it knows where to put measures, ties, beams using it's current subroutines.

In reply to by nmeet

> "Ummm - don't use it?"

Then how do you decide whether to use your proposed behavior (till end of score) or the behavior someone else asked for (till end of section) or yet another (till end of measure) or even yet another (only on the current staff, or on all staves)...

How do you decide or design a UX around all of these equally valid use cases.

In reply to by nmeet

If you are saying the user wants all notes to end of composition to be affected that's a guess. It's a guess by definition, because it's what some people want some of the time, and not what others want at other times. I don't understand why it seems so difficult for people to see this or why pointing it out makes them so upset that they seem unwilling to discuss the matter further. But intelligent discussion about that is the first step that would be required in order to actually see design begin towards such a feature. So I encourage you to put aside the preconceived notion that the guess about wanting all notes to the end of the composition moved it the right guess for all people all the time, and instead start thinking about what the different real world use cases actually are, and which use cases are best served by which guess, and which guess is less damaging to the use cases it is not correct for, and then maybe there can start to develop some consensus as to which guess actually is best to make in designing such a feature. And then, once that consensus exists, someone could start designing it.

See for existence proof that it's possible for other guesses to be useful in other situations, and that's it's possible to actually make progress - it is only pointless if people give up on discussing the matter.

In reply to by Marc Sabatella

Another possibility would be to try and identify a small number of completely-defined algorithms for doing tasks of this general nature and then try and determine which ones warranted inclusion as features in the future.

It doesn't seem that such algorithms would involve "guessing" by the program.


In reply to by Doug Kerr

Completely defined is not incompatible with it being a guess as to what the user actually wants. Both "move only the notes until end of measure" and "move all notes until end of score" are completely defined as algorithms. But both are guesses as to what the user actually might want. And that's inevitable, because there is no way to know which of these two would actually fit what the user wants (and in fact in many cases, neither does - it would be something in between these two). People seem hung up on the word "guess" as if they think I mean, "do something different every time". I don't. I mean, "do the same thing every time, even though sometimes that thing is desirable, other times not". If you know a better word for it, I'm happy to switch wording, but the point is, no matter what MuseScore does here, it's not what the user wants all or even most of the time.

In reply to by Marc Sabatella


I understand.

I guess to someone who says, "I changed a quarter note to an eighth note, and MuseScore added an eighth rest after the note, and that's not what I wanted", I would say, "What would you rather MuseScore had done?"

If there is a practical answer, it might suggest a mode that MuseScore should offer, if possible. If there is not a practical answer, well, there ya go.


In reply to by Doug Kerr

There is a practical answer - or more precisely, there are two very radically different practical answers. Half the people (roughly) requesting such a feature want the change to only affect the current measure. The other half want the change to affect the entire score. Once those two camps start talking to each other and showing real world use cases and analysis of which approach might be better for which situation, it would start to become possible to consider designing and implementing a solution.

But from a development standpoint, I can say that the everything-to-end-of-score would be infinitely harder to implement and would likely cause enormous problems both for developers and for users. Yes, it works that in Dorico, because its underlying representation for the score is radically different from ours. Doing this using our current score data structures would completely destroy much about your score every time you performed such an operation and found notes straddling barlines. Whereas rewriting all the data structures and algorithms to support this in a more native way would take years and introduce all sorts of new complications and bugs since the program wasn't designed for this.

So, the only truly practical answer is one in which such changes affect the current measure only.

In reply to by Doug Kerr

So, here is a simple use case that models a common need I have. I have four quarter notes in a measure, and want to change the 2nd and 3rd into an eighth note and a dotted quarter note. What's the best way to do that?

By way of reference, in Overture "I just do it". I select the 2nd note and press the key for "make the time value of this note an eighth note." I select the third note and press the key for "make this a dotted note." In the middle of the process the measure is "underfull", but when I am done it is properly filled.



In reply to by Doug Kerr

Out of interest, what is the "just do it" way in overture to end up with a deliberate rest instead.

As in, I've written a singing tune, but the 2nd beat should now be halved and followed by a rest of that "original half" duration because I want my singers to get more breathing time?

In reply to by jeetee


  1. Change the (I assume) quarter note on the 2nd beat to an eighth note. (Select the note and use the keyboard shortcut for "make time value eighth note".)

  2. Insert an eighth note just after that new eighth note. (Select eighth note from the notes palette and click on the score where it needs to go.)

[Minor typos patched.]


In reply to by Doug Kerr

Hi Doug,
Thanks for clarifying. Does this mean you can't insert a rest right away or was it just a slip of the typo?

I think lvr's plugin is catering to this use case quite well and can serve as a good scratchpad-within-measure example of a mode MuseScore could offer in the future natively.

In reply to by jeetee

Hi, jeetee,

You say: "Does this mean you can't insert a rest right away . . ."

In this case I had no wish nor need to insert a rest ever - I was just wanting to change two quarter notes to an eighth note and a dotted quarter. And Overture did not insert any rests for me in the course of the maneuver. But Overture would have let me insert any rest I chose any place in the measure (or to change all the quarter notes to half notes)!

Maybe I haven't understood your question.

There were a couple of typos that I know of, "Inset" where "Insert" was meant, and an occasional "eight" instead of "eighth". I just patched those in my original post.


In reply to by Doug Kerr

My question was posing a different scenario in which the current MuseScore behavior happens to also be the desired end result:

> "Out of interest, what is the "just do it" way in overture to end up with a deliberate rest instead."
> "As in, I've written a singing tune, but the 2nd beat should now be halved and followed by a rest of that "original half" duration because I want my singers to get more breathing time?"

So how do you change a quarter note on beat 2 to become a 1/8th note followed by a 1/8th rest?

In reply to by jeetee

Hi, jeetee,

You asked, "So how do you change a quarter note on beat 2 to become a 1/8th note followed by a 1/8th rest?"

In Overture:

  1. Select the note and press the key assigned to "make eighth note". (That would be "8" on a "stock" Overture.)

  2. On the Notes palette, select the eighth rest and use the mouse to plant it between the (now) eighth note and the following quarter note (best 3).

That is, you just make what you want.


In reply to by Doug Kerr

So, two separate steps to shorten a note, rather than just one in MuseScore. that's the price, I guess, of not having the "shorten note and also move some number of subsequent notes" be a separate command from the normal "shorten note" command. Again, I'm hoping we can do better. Otherwise, we're simply treading off which of the two operations is harder than necessary, rather than actually improving anything.

In reply to by Marc Sabatella

Well, to be precise:

One step to shorten one note (unless you count selecting the note and changing its time value as two steps). One step to lengthen another note.

I'm still hoping to hear how to do the same thing in MuseScore. To be clear what that is:

Start with four quarter notes in a 4/4 measure. End up with quarter note, eighth note, dotted quarter note, quarter note.



In reply to by Doug Kerr

I don't at all want to give the impression that I am promoting the idea that, to perform one or several well-defined tasks, the approach offered by Overture is "easier", or faster, that the approach offered by MuseScore. It is just an approach with which I am familiar, and I thought it would be worthwhile to have it in sight as this matter is discussed.


In reply to by Doug Kerr


A colleague reminded me that the reason that in Overture the play times did not change when I changed the time value of a note or two was that I had inadvertently turned on a feature that made it work that way. (A "senior moment", I guess.)

Now (with that turned off!), if I take the second of the four quarter notes and change its time value to an eighth note, Overture makes its play period start at beat 2 and its play duration whatever fraction of notational duration I had set for the "default" play duration (more on that below). The following quarter note is advanced in start time by half a beat, but keeps its play duration. And there is roughly half a beat of dead air at the end of the measure.

Then, if I change the third note to a dotted quarter, the corresponding shifts take place, and the measure is "full".

If I had instead plugged in an eighth rest, everything would have shifted to accommodate that. And the measure would again be "full".

If I didn't do either of those things, the measure would have been anomalous.

As I mentioned, we can set the initial (often called "default") play duration for deposited notes to be any desired percentage of the notational duration ("face value").


In reply to by Doug Kerr

That's an excellent example of the type of case for which the one-measure-at-a-time approach is the more natural fit - it ensures that the rest of your score is unaffected. It is up to you to make this measure correct, but nothing you do along the way interferes with any other part of your score.

I'm curious, though, if the measure is temporarily underfull, what happens on other staves? Do they lose half a beat, and is it always restored correctly? I rather prefer the idea of keeping the measure full length but padding it with rests at the end, on this staff only, to prevent risk of damage to other staves.

In reply to by Marc Sabatella

Hi, Marc,

On the other parts (staves), the notation does not change when I change the time value of a note on the target staff from quarter note to eighth note, so there is nothing to be "restored"

It is a little hard to know what the play situation would be owing to a flaw in Overture in which the play timing underdata (as we see it on the piano roll view) does not follow changes of this kind in the notation! When I am done with the full maneuver I described, the piano roll view still shows, for the target staff, a length of four beats and contents of four toots the length of a quarter note.

(That measure length is reasonable. I note that of course if I just delete one of the four quarter notes, the measure length does not shrink to three beats.)

On the other hand , if I start with four quarter notes and change one to a half note, now the measure length is shown as five beats. (Has to be, to accommodate the contents.) But the piano roll view still shows four toots the length of a quarter note (and one beat's worth of "dead air" at the end.

So of course, this makes the Ghost of Overture Present not a good vehicle to demonstrate variations in how this sort of thing can work.


In reply to by Doug Kerr

Hmm, so you're saying that when you change the quarter to an eighth, different staves now have different numbers of beats in them? To me that's a complete disaster, and that much more so if it breaks the ability to play the score back correctly. I am definitely hoping we can come up with something far better! But these are the sort of difficult questions to resolve in designing and implementing this type of feature.

So, putting aside the question of how not to do it, a worthwhile question is, how should this sort of thing be handled? As I said, to me, a reasonable approach is to pad the end of the current measure on the current staff upon any shortening of note values. Lengthening, though, remains trickier. if we literally add beats, that would require rests in other staves in order for the result not to be corrupt, but that might break existing ties across the barlines. A more logical approach might be to actually lengthen any simultaneous notes or rests on other staves, and also shorten them when reducing length if the measure is currently overfull. But this too could become tricky - how to lengthen a half note by the duration of an eighth - add a tied note?

The devil really is in the details when it comes to this, and that's why nothing has come of it after all these years - no has has seemingly wanted this enough to make a really concrete detailed proposal that deals with all of these questions. At this point, it's probably moot - any such concert design would probably come from Martin (@tantacrul) rather than the community. But it doesn't mean discussing ideas here isn't worthwhile.

In reply to by Marc Sabatella


One part of a straightforward approach would be that you just can't do anything that would overfill the measure, and if you have made it underfull, MuseScore would put padding rests at the end (to "conserve parity" - not to outguess the scorist). Then, any shortenings or deletions would have to be done before any lengthening or additions. (Plumbers, cabinetmakers, and warehouse managers have to work that way.)

If what the scorist has in mind is that the last of four quarter notes would now be tied to a quarter note in the next measure, then she should just do that (dealing with that second measure in whatever way she visualizes - what that is - she must have some plan, but none of us can guess what that is ).

It is very tempting to make an application so clever that the user is always saying, "No, I didn't want you to do that for me." MuseScore is Salieri - not Mozart.


In reply to by Doug Kerr

Yeah, the idea of disallowing the increase in duration occurred to me too. In theory, it wouldn't limit you - it would just enforce a particular order of operations (first shorter then length, not the other way around).
But I have a feeling this would not sit too well with most people requesting the feature.via cut and paste, and it would be a lot of work to implement and still generate complaints, I fear. I'd like to think there are better solutions.

In reply to by Marc Sabatella


Let me elaborate on the matter of multiple staves and the Overture approach to changing note time values.

Suppose we have a score with two staves, and we consider a 4/4 measure which, as the scenario begins, has four quarter notes in each staff.

Our objective is to change this so that on the first staff, we have quarter note, eighth note, dotted quarter note, quarter note. We do not want to change what we have on the second staff.

We select the second quarter note on the first staff and press the key that changes its time value to eighth note. We are only half done with the operation, but suppose for some reason we stop here and play the score.

The first staff plays as if it has an eighth rest at the end. The second staff plays as it would have originally.

Now for another matter, regarding inter-measure ties, about which there seems to be much anxiety.

Let's take a case in which we have a single staff on which we consider two consecutive measures, each initially with four quarter notes. with the last note of the first of those measures tied to the first note of the second measure. We want to do the same thing to the first measure as in the first example.

We select the second quarter note in the first measure and press the key that changes its time value to eighth note. We are half done with the operation.

The notation now shows, in the first measure, a quarter note, an eighth note, a quarter note, and a quarter note tied to the first quarter note of the second measure. How can this be in a 4/4 measure? Just follow along. Remember, the "operation" is not finished; the chemical equation does not have to be balanced.

If we play the score, we hear the first quarter note, then the eighth note, then a quarter note, and then a note that lasts through the play duration of the first note of the second measure (a total play duration of about 1-1/2 beats). The fourth note (a quarter note) is stretched in play duration to continue to join up with the first quarter note of the second measure. (Remember, in even an ordinary tie situation, if the notes have play durations that are not 100% of the notational durations, they have to be stretched in play duration to "join up", and this is no different from that.)

But now I finish the operation, selecting the third note in the first measure (a quarter note) and pressing the key that means "dot this note".

The notation now shows, in the first measure, a quarter note, an eighth note, a dotted quarter note, and a quarter note tied to the first quarter note of the second measure. If we now play the score, it plays just as we would expect - just as we want now that our operation is finished. The tie has not somehow been ruptured or scrambled by this operation. That's because that program, as it often has to do in a regular tie situation, stretches the play duration of first note of a tied pair to continue to join up with the second note. And when that stretch is no longer needed, it is unstretched.


In reply to by Doug Kerr

"The first staff plays as if it has an eighth rest at the end."

I often check for errors by playing the score, and to me having a system that doesn't play what I've written would break this functionality.

Then again, if it wrote the rest to the end of the bar (like it plays) it wouldn't really make much sense: then its essentially the system musescore currently has, only that the rests are added to the end of the bar, not where the change happens.

The only option for that would be for the software to have different staffs' barlines be out of sync which im pretty sure nobody wants 99% of the time.

For multi-staff scores I cant see this working without a serious hit to the playback. I understand that someone might prefer this functionality over playback, but also strongly believe it's not a good direction to take.

In reply to by fransfelix

Hi, f,

Indeed, there has been from time to time among Overturians a call for measures that are (hopefully temporarily) underfull or overfull to be clearly marked as such.

At present, the program offers a function to search for such anomalous measures (perhaps while "auditing" a mostly-completed score), but it is so clumsy as to be laughable and of no real help to this matter.

A complication with such a "warning flag" is that in Overture, as we first deposit notes onto a virginal staff, the first note deposited causes the "measure rest" which was the original occupant of a measure to flee (and no new string of rests appears), leaving the measure "underfull" (and thus subject to having the "Unclean! Unclean!" flag posted over its head.

Overall, I think the MuseScore approach, in which every measure is always full is the most foolproof.

In reply to by Doug Kerr

The issue with ties isn't present in Overture because Overture does what I believe to be the more sensible thing - it doesn't change anything after the current measure. it's programs that use the other approach that people are strongly advocating for - where every single note until the end of the score is shifted - where the results can be disastrous if the program's data structures were not designed from the beginning to consider tied pairs of notes a single note internally. The issue in that case is not so much how to handle pre-existing ties, but how to handle all the ties that necessarily get created when shifting a note so that it now straddles a barline. And a worse problem for tuplets.

I think this is not as complicated as people make it seem.
The question is mostly about how much this "non-overwrite mode" moves stuff.
Options are, roughly

· Affects only the measure being edited
A) the measure keeps the time signature (adds/removes rests or deletes notes at the end if necessary), OR
B) the measure gets gets smaller or larger accordingly, OR
C) the measure keeps the time signature and adds rests or inserts more bars if necessary

· Affects the whole score
A) the last bar of the score keeps the time signature and adds rest or deletes notes if necessary, OR
B) the last bar of the score gets smaller or larger accordingly, OR
C) the last bar of the score keeps the time signature and adds rest or more bars if necessary

If you want to have it affect a different area, same options for that.

Now for my opinions

For me personally, non-overwrite mode that affects the whole score makes no sense. But I can see that for some people's workflows this is preferrable. My suggestion would be that there could be a "doodle mode" which wouldn't have bars and and where changing notes' length would not eat anything or add pauses. This stuff could then be copypasted into a regular musescore file once it's done.

Non-overwrite mode that affects only one measure could make sense, even though I havent felt the need for one. If I could choose, it would be implemented like this: Everything else works as is, but when you have a note selected and want to change the lenth in "non-overwrite mode", you just press shift+[number]. Option A would be most intuitive for me.

One of the biggest hurdles in trying to implement this might be triplets. A̶s̶ ̶f̶a̶r̶ ̶a̶s̶ ̶I̶ ̶k̶n̶o̶w̶ ̶y̶o̶u̶ ̶c̶a̶n̶ ̶n̶o̶t̶ ̶s̶t̶a̶r̶t̶ ̶a̶ ̶t̶r̶i̶p̶l̶e̶t̶ ̶o̶n̶ ̶o̶f̶f̶b̶e̶a̶t̶ ̶i̶n̶ ̶m̶u̶s̶e̶s̶c̶o̶r̶e̶,̶ ̶a̶n̶d̶ ̶y̶o̶u̶ ̶h̶a̶v̶e̶ ̶t̶o̶ ̶b̶e̶ ̶a̶b̶l̶e̶ ̶t̶o̶ ̶d̶o̶ ̶t̶h̶a̶t̶ ̶t̶o̶ ̶m̶a̶k̶e̶ ̶t̶h̶i̶s̶ ̶w̶o̶r̶k̶.̶ [Edit: I have been corrected, triplets just need to fit within a bar.]

In reply to by fransfelix

I think an attractive and practical behavior when the time value of a note is reduced would be:

• The lost musical time would be compensated for by a rest placed at the end of the measure, except:

• If the last note in the measure is tied to a note in the next measure, the "compensating rest" would, as at present, be placed adjacent to the shortened note.


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