Regroup Rhythms
Due to the extreme unrecoverable consequences of using Regroup Rhythms I would suggest an emergency release 2.1.1 that will remove this menu option and update the handbook to have a warning for anyone using 2.1 to not use this unless they are aware of the consequences.
While we know it is good practice to save you work often and autosave does that every so often according to user preference, the reality is that people will loose work if they use this function ignorantly not knowing that EVERY articulation, ornament, grace note and tremolo they have entered might be deleted. In a large score this is a lot of work. They may not even realize this happened until it's too late to recover from it. As you know, most people who use this program are not professional composers and rely on MuseScore to assist them in making good notation and this has the potential, if it worked right, to be a valuable tool to that end, but is currently a time bomb waiting to explode on the unlearned user.
I will never loose anything from using this menu item, because I never used it for anything but limited testing, so it will not truly affect me. My concern is the users who will no doubt post here that their score is ruined, and us other users and programmers attempt to help them recover their losses.
Comments
I also found this "bug" when using Regroup Rhythm on this kind of notation:
It doesnt do anything to it of course, but if you now take UNDO, it removes the tie. Like this:
In reply to I also found this "bug" when by SkyLind
That too is part or the issue, see #196771: Regroup Rhythms deletes various elements, even more lost on undo
In reply to That too is part or the by Jojo-Schmitz
Oh looks like it had been posted already :D
In reply to Oh looks like it had been by SkyLind
And also #196801: Regroup Rhythms changes spelling of notes that should not be affected
Better would be to get these issues fixed
In reply to Better would be to get these by Jojo-Schmitz
Fixing is preferable to removing, but this feature is not so vital to 2.1 that it would ruin it. If it were quickly fixed and the update released that would be great.
My sense is that "regroup rhythms" was implemented for the real-time MIDI input, and probably it reinterprets notes as if they were coming via MIDI, which explains why enharmonic spelling is not preserved nor are markings preserved. If so, then this might not be easy to fix without significant rewrite.
In reply to My sense is that "regroup by Marc Sabatella
Does that mean thar taking away this feature would also remove real-time MIDI Input?
In reply to Does that mean thar taking by Jojo-Schmitz
Perhaps one could remove the command/menuentry for it, leaving the code to do whatever magic it needs during semi-real-time input?
In reply to Perhaps one could remove the by jeetee
Yeah, I had that idea too directly after having pressed the Save button ;-)
Maybe even hide it behind the -e (experimental) option
In reply to Does that mean thar taking by Jojo-Schmitz
Yes, I certainly didn't mean to suggest removing the real-time note input feature. Not even sure I would recommend *removing* the regroup rhythms featgure if it isn't easy to fix, maybe just making it more clear (perhaps via a warning dialog) that the operation maybe isn't exactly what one might expect in some respects.
I took a brief look at the code. The way it currently does the job does seem to have a built-in assumption we are basically entering notes from scratch. Which in the general case, we really are -
one chord might easily change in two tied ones or vice versa.
However, I don't think fixing some of the limitations would be difficult. Looks like we can preserve enharmonic spellngs with a one-line change, just setting up the tpc's for the nval for each note better in regroupNotesAndRests(). The undo issue with ties should also be fixable with a little more work. Copying lyrics and other markings is trickier because it isn't immediately obvious what the right answer is when converting between a single note and tied notes, but it should be mostly doable once we agree on the right approach. Copying most manual adjustments or property changes made in the Inspector likely won't make any sense at all but we could again at least try to make intelligent guesses (hmm, if a single note gets turned into two tied notes, should both be made orange if the original note was orange? If a full size note was tied to a small one, what should the result be if this command ends up combining them? And so on.
Due to the nature of what we are doing - basically deleting one set of notes and creating a potentially different number of brand new ones - there will likely be cases where the way we decide to handle some particular element in some particular case isn't what happens to be desired in some particular situation. To me it's not a deal-breaker, but it probably should be made clear that one is better off only using this command early on in the process, not after you've already invested a lot of effort in tweaking things.