3.6.2 for Mac: combining rests affects notes by deleting them and splits up longer rests in the next bar
When I combine shorter rest signs to longer ones, subsequent ones in the next bar are split up and notes that are "in the way" are deleted. See attached screen video.
Musescore German version
OS: OS X El Capitan (10.11), Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548020600, revision: 3224f34
| Attachment | Size |
|---|---|
| Musescore6.3mac_Rest_bug.gif | 280.04 KB |
Comments
Use "Regroup Rhythms" feature in menu "Tools" (for a few measures, or all score)
In reply to Use "Regroup Rythms" feature… by cadiz1
See:
In reply to See: [inline:Video_2021-10… by cadiz1
What you are observing is that.
By selecting the two rests (with click, and Shift + click), a note is eaten.
I don't know how this can be qualified (bug or not, I don't remember), at the least, it's unexpected, I agree.
But everything happens as expected if you select only one rest before changing rest/note value.
And even more, as said previously, using the "Regroup rhythms" function provided for this purpose and much faster.
In reply to Use "Regroup Rythms" feature… by cadiz1
Thanks for bringing this to my attention, it works seamlessly. On the other hand, applying the command directly to individual rests shouldn't cause such damage to the score. If the function is not intended this way, nothing should happen except an error message.
In reply to Thanks for bringing this to… by mschwehla
See my third comment (with 2th GIF)
In reply to Thanks for bringing this to… by mschwehla
It's generally easier to understand and assist if you attach an actual score and give precise steps to reproduce the problem. But from what I can tell, everything seems to be working as it should be. When you increase the duration of note or test, it is supposed to "eat" the next note or rest to create room. If you select multiple notes or rests, it tries to increase the duration of each in turn, but of course in most cases that means each eats part of the next, then spilling over to the next note or rests after the selection. I suppose this operation could be disallowed, but chances are someone somewhere has a use for it.
In reply to It's generally easier to… by Marc Sabatella
I saw no use in providing a static score when it is the process that is significant; nothing can show that like a video. The duration of rests is not increased when you combine, e.g., two eighth rests to a quarter rest, but the software does exactly that: adding an eighth rest, for example. And, once a bar is "cleaned" by that method, the next bar is crowded with short rests without a reason. I'm greatful for cadiz1's reference to the menu command, but honestly can't imagine what use that special response which I referred to in the video clip would be for anyone.
In reply to I saw no use in providing a… by mschwehla
For future reference - as a developer who spends much time trying to reproduce and fix problems, I can assure you, video is seldom as helpful as a score and a simple list of steps. Video takes far longer to process, and we can't normally see what you are pressing (or not pressing) along the way. Sometimes, though, it is true, the sample score isn't relevant if you can give precise steps to reproduce the problem from scratch. So that is what I am doing here
Duration of rests is increased if you click a longer duration. This is demonstrated simply:
1) in a new score, enter a series of rests via N 4 0 0 C D E F G A, then Esc
2) click the first eight rest
3) press 6 to change to half rest
Result: exactly that happens, and the next beat and a half (the other eighth rest and the C-D) is eaten to make room
If you try selecting multiple rests, then just as I said, the duration of each is changed one at a time. So, if instead of the original steps 2-3, you do this:
2) click the first eighth rest, shift+click the second to create a range selection
3) press 6 to change to half rest
what happens is, the first rest is changed to a half rest, which eats the next beat and a half, then the second rest (which technically was already eaten during, but it works anyhow) also gets changed to half rest, which eats the next beat and a half starting from that point. Result: two and a half beats of rest, the notes remain.
Seems a strange thing for a user to choose to do, but if he asks for it, we do it. It's much more obviously a sensible thing to do when shortening notes or rests - eg, pressing 3 instead of 6. Now the two rests are shortened instead of lengthened, so nothing is eaten.
And of course, the exact same process applies to notes. Here, though, it's more apparent that what you probably "really" wanted was to increase both eighths to uarters and move the second one to avoid being eaten by the first. That's what other Edit / Paste Double Duration command is for.
In reply to For future reference - as a… by Marc Sabatella
Marc, my question is (see attached file) : test.mscz
1st measure: click the first 8th rest and Shift + click the second 8th (to get a selection frame)
I know I wouldn't do this, but now if I type 5, I get the result of measure 2.
Is this the normal/expected result?
In reply to Marc, my question is (see… by cadiz1
Yes, as per my explanation, and see especially my followup explaining the order the notes and rests are processed in.
Selecting multiple rests then trying to lengthen then all is a very strange thing to want to do which is why the result seems strange in this case, but in more "real world" cases - involving, for example, notes instead of rests - it's pretty sensible.
In reply to For future reference - as a… by Marc Sabatella
Slight correction: actually, the reason the lengthening of the second rest within the selection works even though technically it was already eaten is, everything is apparently processed in reverse order. You can see this most clearly if those are two notes - say, A-B - instead of two rests. If the A were processed first then the B, the B would end up a half note still starting on "and" of 1. But that's not what happens; you get the A as a half note and the B as an eighth note on 2. Which is consistent with the idea of notes and rests being processed right to left, which in hindsight makes perfects sense as the only reasonable approach.
In reply to For future reference - as a… by Marc Sabatella
Thanks for the detailed explanation. So any transformation command only addresses one element at a time and keeps or increases the overall count, but doesn't substitute e.g. two for one because it does not trust the user actually choosing the correct substitute value for the values clicked together. This could be checked and refused in real time, however. But apparently I didn't see it that way.
As to the video question, you're right that a step-by-step description is easier to read than a video, but a video is a kind of evidence at the same time and might reveal details that the user doesn't consider. When I developed database interfaces, I was glad for a video given the often strange error messages from users. Anyway, thanks again for your reply.
In reply to Thanks for the detailed… by mschwehla
Well, not necessarily "any transformation command", but yes, the special commands (only added within the last year or so I think) that allow you to take a selection and change all of the durations at once work that way. The main intended use case was turning a series of half notes into quarter notes followed by quarter rests - keeping the rhythm the same, but changing the durations.
What you are trying to do is completely unrelated, which is why using this command - meant for a completely different purpose - produces results other than what you wanted. You didn't want to individually change two eighth rests into two quarter rests. You simply wanted to clean up your rests. For that, a simple "Delete" does the job (it replaces rests with a "standardized" rests that make sense in the time signature). Or, to rewrite the rhythms for the notes as well as the rests, use "Regroup Rhythms".
In other words, you used a hammer when you actually wanted a screwdriver, so, no surprise the result was that the threads got stripped :-)