Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Old-style multimeasure rests #286

Open
adrianholovaty opened this issue Aug 17, 2022 · 1 comment
Open

Old-style multimeasure rests #286

adrianholovaty opened this issue Aug 17, 2022 · 1 comment

Comments

@adrianholovaty
Copy link
Contributor

We should add support for encoding the "old-style" of multimeasure rests, as pointed out in this comment by @clnoel.

184913344-b1b7c8a0-6d2a-40f8-adfa-f00e4da6c091

More precisely, this is the presentational decision that multimeasure rests should use a combination of whole and double-whole rests instead of the contemporary "I-beam".

It would also be good to encode the threshold at which a rendering engine should use an I-beam instead of individual rests. For example, see the "To display symbols for multimeasure rests" section in this Finale help page.

An obvious place for this information would be in the <score>'s <multimeasure-rests> element — i.e., scorewide as opposed to defined in each individual <multimeasure-rest>. Perhaps we encourage the use of a scorewide encoding but allow overriding for any individual <multimeasure-rest> element?

@rettinghaus
Copy link

In printed orchestral parts these old-style rests usually were used for up to 10 measures, more were indicated with the H-bar rest. So for the scorewide encoding it should be a threshold indicating the switch between the two styles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants