"Reset Beam Mode" feature- unexpected result
I'm in the process of changing the vocal lines in my scores from "old-school" beaming (vocal line notes not beamed unless on a melisma) to contemporary practice (vocal notes beamed the same as instruments).
MuseScore 2.02, Windows 10 PC
Process- In the attached score, be aware that I deliberately un-beamed the Harp notes at measure 32 for purposes of showing this issue.
1. Open the score, select Lauretta's first measure (on page 2), CTRL+SHIFT+END to select the entire part. The display shifts to the last page.
2. From the pulldown menu, Layout > Reset Beam Mode.
Expected result- only the vocal line (measure 31, for example) resets the beaming.
Actual result- the harp in measure 32 also resets the beaming.
If you experiment, you'll see that all measures with the same measure number(s) as those selected reset the beaming. For instance, select *only* measure 31 of the vocal line, reset beaming, and see that measure 32 of the harp is *not* affected. Or, select measure 32 of the C-bass part, reset beaming, and see that harp measure 32 *is* affected.
I have a lot of scores to change, and would hate for any instrumental parts that I may have un-beamed to also be changed. 99.999% of the instrument beams are already at the MuseScore default, but I can't be sure that a few weren't manually un-beamed (for instance, to reflect a temporary change in rhythm or a syncopation).
If the feature worked as expected (only the selected measures were reset), it would only be a few seconds per score to make the change.
Thanks,
Attachment | Size |
---|---|
Gianni Schicchi- O mio babbino caro.mscz | 52.58 KB |
Comments
Confirmed. Seems a bug to me.
Hmm, lokoking at aht ecode this seems to be by design?
...libmscore/cmd.cpp, line 1708 loops thru all staves and voices in the selected measures.
Changing that
for (int track = 0; track < nstaves() * VOICES; ++track) {
to
for (int track = selection().staffStart() * VOICES; track < selection().staffEnd() * VOICES; ++track) {
might fix this, it certainly does for me.
See #100481: "Reset Beam Mode" work on all staves of the selected measures, not just the selected ones
In reply to Confirmed. Seems a bug to by Jojo-Schmitz
I can't imagine any reason why the current behavior would be desirable, so I'd certainly support this change.
BTW, looking at the code, it's also pretty inefficient to loop through all segments starting at the beginning and "continue" until we get to the right tick. We should be able to just start at selection().startSegment() I would think. Not that the extra time matters much - it's not like we are doing this on each layout.
In reply to I can't imagine any reason by Marc Sabatella
Hmm, changing that outer loop from
for (Segment* seg = firstMeasure()->first(st); seg; seg = seg->next1(st)) {
to
for (Segment* seg = selection().startSegment(); seg < selection().endSegment(); seg = seg->next1(st)) {
doesn't help, esp. when selecting partial measures. On the other hand
for (Segment* seg = selection().startSegment(); seg; seg = seg->next1(st)) {
seems to work
In reply to I can't imagine any reason by Marc Sabatella
What should happen if there is no selection? Work on the entire score I guess, right? Because currently it just does nothing then
In reply to What should happen if there by Jojo-Schmitz
That would be my guess. Isn't that the way the Transpose feature works- if no particular selection is made, it affects the entire score?
In reply to That would be my guess. by marty strasinger
Transpose asks whether to run against the entire score. 'Reset stretch' does not, it just does it.
In reply to Transpose asks whether to run by Jojo-Schmitz
I was thinking F2/Shift+F2, the standard shortcuts for Transpose...
In reply to I was thinking F2/Shift+F2, by marty strasinger
I ment the Notes→Transpose... Dialog, but you're right, F2 doesn't ask