Regroup Rhythms deletes various elements, even more lost on undo
2.1 release, 871c8ce
1. Select any range that includes glissandos.
2. Run Layout / Regroup Rhythms.
Result: glissandos are deleted.
Naturally, I discovered this numerous edits after I had applied Regroup Rhythms to my entire score. :P
Comments
Not sure yet of the scope of this, but glissandos are definitely not the only element affected. Additional steps to reproduce another issue:
1. Tie notes across a barline, with an articulation/ornmanent on the second note.
2. Run Regroup Rhythms.
Result 1: the articulation is lost.
3. Undo.
Result 2: the articulation is back, but the tie is lost.
Furthermore, however far back into the undo stack you go, it's as if the tie never existed. Marking issue as major for this reason.
Separate issue with Regroup Rhythms: #196801: Regroup Rhythms changes spelling of notes that should not be affected
More things that disappear: tremolos, grace notes
Came up again in https://musescore.org/en/node/196981
Came up again https://musescore.org/en/node/197726
Came up again in https://musescore.org/en/node/206751, seems lyrics are deleted too
Don't assign to yourself unless you want to work on providing the fix
Sorry, first time using these forums. I wish I did have the skills to help solve the problem but I don't unfortunately. On another note, the fact that the regroup rhythms tool removes lyrics can be annoying, but there are also some times when I want to remove all the lyrics of a part quickly (eg copying a vocal riff to a brass part) so maybe the part of the tool which removes the lyrics could be incorporated elsewhere to make lyric removal a much less tedious process.
No tool for lyrics removal needed, just select range, right click a lyrics word, select, all similar in selection, delete.
Or, just exclude the lyrics from the selection in the first place when doign the copy, using the Selection Filter.
Just ran into this. Can't regroup rhythms without destroying lyrics. Deselecting lyrics in the selection filter dosen't change the behaviour.
I think by now it's pretty clear that 'regroup rhythms' removes almost everything. The only thing left after the dust has settled is the notes (sometimes rewritten, accidentalwise) and ties (but only if no 'extras' on the not-first note of the tie). It does make a nice job of what it's supposed to do though :)
Demonstration score attached. Apply regroup rhythms. UNDO. The ties across barlines are lost.
Came up again https://musescore.org/en/node/268030
This is a priority to fix for 2.2, right?
It is in https://musescore.org/en/handbook/musescore-22-hit-list#Must-fix-before…
I believe I put it there. ;-) I just wanted to make sure that I wasn't the only one who thought so.
In reply to I believe I put it there. ;-… by Isaac Weiss
From a quick overview, I found that:
- regroup is done to all the elements in the selection (or in the whole score if nothing selected), regardless the fact that they need it or not (i.e. regardless if their duration is shorter than the "cumulative" duration)
- chords and rest are overwritten by regroup with a new "clean" one by "setNoteRest" function. I think it should instead behave similarly to paste function and keep the first chord/rest in the segment, changing its duration only (if needed) and inserting the remaining chords/rests and related ties if splitting is needed.
Realistically, it's unlikely such a command could ever do a "perfect" job, and one would still be advised to use this command earlier rather than later. But a few things seem like no brainers.
Will this be fixed in 2.2? It seems a release candidate is imminent.
Not if it's waiting on me to fix it. Sorry, I have too many other things going on at the moment. It might be best to take the option out the menu for the time being, or bury it in Edit > Tools.
If not for the translation freeze, I'd suggest adding "(Experimental)" to the end of the string.
In reply to If not for the translation… by Isaac Weiss
I'm in favor of removing it from 2.2 until it's fixed. In the last 48 hours someone described the results of using this button. I forgot about this button doing that, so I didn't ask if they used it. I don't even remember what language the post was on.
In reply to I'm in favor of removing it… by mike320
I tried to work on this in my spare time in the last few days.
The problem is that at the moment this function rewrites all notes and rests in the score, even if they would not change. Another problem is that it is overwriting the notes (and rests) with a newly generated note (or rest), while instead it should clone the note (for the rest this would not be necessary, but for the case with a fermata over the rest), similarly to what the paste function does.
I looked at the note entry and paste functions, but I think a specific function should be written for this operation: it should be a note entry based on cloning (but only for the first part of the note, while stripping articulations etc. for the remaining part of the note).
I tried implementing it (for master branch, actually), but I still have a couple of problems with ties for the newly generated notes.
Since the release of 2.2 RC is imminent, we could at least limit the action of this function only when needed, i.e. when restTicks and noteTicks are really strictly greater than the ticks of the rest or note, so that articulations, note spelling, lyrics etc. would be lost only for the rewritten notes/rests and not for the entire score.
We can hide it behind the -e flag for 2.2 final.
In reply to I tried to work on this in… by ABL
I looked into this briefly when this was first reported, and also got the sense that making it do everything one could possibly want would be hard, but that at least cloning lyrics and articulations would be straightforward. But the problems with ties etc were deeper, so I didn't bother with such a "quick fix". Now I wonder if that plus limiting the effect to the selection wouldn't be still worthwhile.
The function only operates on everything if there is no selection; if the user has made a range selection (i.e. there is a blue selection box) then only notes and rests in the range are recalculated.
I agree that existing attributes and articulations should be copied over (at least for the leading note in a tied series) and/or nothing should happen to rhythms that are already "spelled" correctly.
A reliable implementation of this function will probably have to wait for the transition from using ticks for durations to using fractions, planned for MuseScore 3.
I think I managed to solve the residual problem I was seeing with ties in my branch. Here is a proposed PR:
https://github.com/musescore/MuseScore/pull/3552
I wrote a revised version of setNoteRest merged with pasteChordRest for the regroupRhythm function.
I have doubts on how slur should be handled: at the moment I am simply using the part of code of setNoteRest, but I don't think it will work correctly.
Moreover, tests should be performed to see how this PR affects real-time note entry (I cannot test it).
Here is Appveyor binary:
https://ci.appveyor.com/api/buildjobs/1fpm2nmkm4rd7lrt/artifacts/MuseSc…
In reply to I'm in favor of removing it… by mike320
No, please don't remove it! If used early it is very helpful.
Fixed in branch master, commit 5c165ec4c1
fix #196771 : Regroup Rhythms deletes various elements
Fixed in branch master, commit 2803c7d827
Merge pull request #3552 from AntonioBL/regrouprhythms
fix #196771 : Regroup Rhythms deletes various elements
In reply to Git webhook message by Git Message
Is this going to enter v2.2 as well? I understood the hit list that it will, but here it just says "fixed in master".
See https://github.com/musescore/MuseScore/issues/3570
Fixed in branch 2.2, commit aeaa2ee193
fix #196771 : Regroup Rhythms deletes various elements
Fixed in branch 2.2, commit 3e4b643308
Merge pull request #3570 from shoogle/regrouprhythms-2.2
backport to 2.2: fix #196771 : Regroup Rhythms deletes various elements
Automatically closed -- issue fixed for 2 weeks with no activity.