Regroup Rhythms deletes various elements, even more lost on undo

• May 5, 2017 - 18:37
bug report

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


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.

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.

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 :)

In reply to 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.

  • undo needs to work, especially with respect to ties
  • when breaking up a note into two tied notes, elements attached to original need to be reproduced on first note of tie
  • when combining tied notes, markings on first note should be retained, all else should be lost
  • in theory, lyrics won't need additional special handling - if they are preserved at all, their properties including tick counts will be as well

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.

In reply to 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.

In reply to 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.

Status active patch (code needs review)

I think I managed to solve the residual problem I was seeing with ties in my branch. Here is a proposed PR:
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:…