Wrong rest placement in double-stemmed writing

• Feb 10, 2015 - 07:35
Type
Functional
Severity
S5 - Suggestion
Status
active
Project
MuseScore

The attached score (produced in 1.3) represents a transcription of the images in pages 36-7 of 'Behind Bars', which focus on the vertical placement of rests in multi-voice context - please see book for full details.

See attached images for result in 2.0 nightly build b264afb - Mac 10.7.5.

Attachment Size
Wrong rest placement in double-stemmed writing.mscz 2.96 KB
Wrong rest placement in double-stemmed writing - Actual result (1:2).png 103.16 KB
Wrong rest placement in double-stemmed writing - Actual result (2:2).png 153.21 KB

Comments

• Feb 10, 2015 - 14:26
Status (old) active ⇒ needs info

I don't see obvious problems. Could you please be more specific? Sure, we have different defaults regarding how high any particular rest is placed, but that's not a bug - that's a simple editorial decision you are free to manually override.

Reply

• Feb 10, 2015 - 14:29

I also don't understand the comment about "hindering" #29871: No way to create full measure rest in voice > 1. That's a bug and should be fixed at some point; fixing it would in no way hurt anything. You wouldn't be compelled to use full measure rests in voices >1.

As for 34511, I already implemented the ability to center rests by hiding one of them. If we ever chose to make it fully automatic, it would have to be an option, for the reasons stated in that thread. There are some cases where this is proper beavior, others - like the example at the bottom of page 36 - where it is not.

Reply

• Feb 10, 2015 - 18:09

Well, I suppose I want improved defaults - I'm not a developer, but I suspect current ones could be better. You could get away with manual, but for time-saving purposes (and as a nice offering to the user), would it be difficult to implement automatic updating of rest position? Maybe it would be post-2.0 (re-doing the layout engine to make elements aware of others?)?

Regarding the first bug, you're probably right.

About the second, I was thinking about more than three voices, or incase there was remaining ambiguity. If there's no problems, that's fine. :)

Reply

• Feb 10, 2015 - 19:12
Status (old) needs info ⇒ postponed

Regarding the second thing - that's why it would have to be an option, because indeed, it just isn't always or even msot of the time what you want. Really,. just in the special case of choral writing when putting two similar parts on the same staff, or certain types of homophonic piano music. It would be up to the person using the option to decide if this option is *really* appropriate or if he would be better off doing it via the current method because there would be too many exceptions.

As for default rest palcement, I could still use *specifics*. Right now, rests are always offset by the same amount. I might guess you are looking for some sort of automatic collision avoidance algorithm that looks at the contents of the other voices and tries to derive an appropriate offset for each rest. Sure, some day if/when we implement collision avoidance, this would be part of it. Could even perhaps be done separately from the rest of the collision avoidance, which would necessarily be based on different algorithms.

But anyhow, automatic collision avoidance is not in the cards for 2.0. I've not marking this duplicate of other collision avoidance feature requests because as I said the implementation will probably differ, but it seems appropriate to mark it "postponed".

If I'm mistaken and you are actually talking about something other than automatic collision avoidance, feel free to re-open, but again, please post a *specific* example of where you think there is an actual bug.

Reply