In the first update to Sibelius 8 back in January of 2016 — more than a year ago — Sibelius 8.1 added support for automatically handling rests in multiple voices, and Sibelius 8.2 improved the position of interpolated bar rests.
This helpful feature introduced a problem with files created in earlier versions, however. If you created a file in an earlier version, such as Sibelius 7.5, in which rests were manually moved to avoid notes, you may notice that the position of those rests has shifted in the parts for your file, with no warning.
Compare the position of the rests in this portion of this drum part, in a file created and opened in Sibelius 7.5.1:
With the position of the rests in the same file opened in Sibelius 8.5.1:
Here is another example with cues in a flute part, from a file created and opened in Sibelius 7.5.1:
And the same file opened in Sibelius 8.5.1:
Curiously, in each case, the position of the rests in the score is identical in both Sibelius 7.5.1 and 8.5.1; it’s only the parts which seem to be affected by this problem.
The setting Rests avoid notes in other voices in Appearance > Engraving Rules > Rests is automatically switched on in files created in earlier versions. Unchecking this box makes no difference to the position of the rests in the part examples described above, but strangely it will change the position of the rests in the score.
Here is the portion of the score for the earlier-mentioned drum part, opened in Sibelius 8.5.1, with Rests avoid notes in other voices switched on — the default setting. Remember that this score was created in Sibelius 7.5.1 so the rests were manually moved:
Unchecking Rests avoid notes in other voices will produce this result:
This is quite a mess, and it’s compounded by Sibelius 8.5.1 switching on the Rests avoid notes in other voices setting without warning for scores created in an earlier version.
For comparison, upon opening a file created in a version earlier than Sibelius 6, you will be presented with a dialog offering a number of options, with an explicit warning that “the appearance of your score will change as objects will be moved to avoid collisions.”
Further, if More Options… is clicked, a long list of options is presented. Options are disabled if the feature was already implemented in the file being opened.
This thoughtful approach put the user in control of how much he or she wished to immediately apply any new features in an existing file. The goal was to not change the appearance of existing scores where careful work was already done, and the default was always to keep things exactly as the were, leaving it to the user to make a considered decision.
This dialog still appears in Sibelius 8.5.1, but selecting the rest avoidance feature is not available as an option, and if your file was created in Sibelius 6 or later, you won’t see the dialog at all — meaning that the appearance of your file could very well change without you being aware of it.
No doubt it’s a challenge to maintain compatibility with earlier versions while introducing new features, and surely the task of maintaining a large base of legacy code is no small one.
But users should have the option of choosing whether or not a feature as disruptive as the automatic rests feature is switched on in scores created in earlier scores. It should be included in a warning dialog and/or and the default setting for these scores should be that the feature is switched off so that when the user opens the file it continues to behave as it did in an earlier version.
Until or unless this flaw is corrected, pay extra careful attention if you routinely work in Sibelius 8.5.1 with files created in earlier Sibelius versions.
Bernie Cossentino
Tough bug. Hope it gets addressed soon.
The programmers may want take note: I have a feeling this bug may be partly related to the buffer copying bug that resets positions of previously moved rests (and other items) after pasting via shift+alt+click?
Derek Williams
Thanks for this warning Philip! I’ll pay careful attention.
Bob Zawalich
re Bernie’s comment, FWIW, when Sibelius does a paste it does not actually copy rest objects (technically NoteRest objects with no notes). It leaves a hole there and fills the hole automatically with an appropriate rest. So any pasted rests will have the default settings for a rest. This is why, for example, if you have a passage with multiple voices and have bar rests in empty voices, they will disappear after the paste. This is pretty much intrinsic to how Sibelius works, and it by design. Daniel would say this is not a bug if he were still here.
In general other objects, such as notes/chords (which are Noterest objects containing one or more notes), text, and lines, retain their positioning data when pasted, either with alt-click of ctrl-c/ctrl-v.
Philip Rothman
Hi Bob, realizing we are off on a tangent here, but if you copy a passage with a bar rest in voice 1 and music in voice 2, the bar rest is pasted. I’m curious what’s different about the way Sibelius thinks about that as opposed to when the voices are reversed?
Bernie Cossentino
@Bob Z.
“In general other objects, such as notes/chords (which are Noterest objects containing one or more notes), text, and lines, retain their positioning data when pasted, either with alt-click of ctrl-c/ctrl-v.”
I’m sorry Bob, but this does not appear to be the case. A shift alt click will not retain object positions if their positions are not default. Hence my questioning whether this behavior may be contributing, in part, with Philip’s blog post.
Bernie Cossentino
My apologies…alt-click works fine. Shift alt click does not. Philip, please feel free to delete the above posts.
Bob Zawalich
Sorry for adding to the tangent.
There is something is Sibelius that abhors an empty voice 1.You can create a bar that has nothing in it but voice 2 (or 3 or 4 or any combination that excludes voice 1), deleting all signs of voice 1, and as soon as you copy and paste it, a voice 1 bar rest will appear. The happens even if you fully delete the voice 1 bar rest in the target bar.
This is not true of any other voice. I could guess reasons for it but only the developers really know. Pasting will restore deleted rests, as anyone who has set things up with deleted rather than hidden rests will encounter, and perhaps Sib is treating an empty voice 1 as a deleted rest. But I am just guessing.
Pasting is really pretty elaborate and subtle in how it figures out where, for example, multi-selected objects will be placed with respect to each other. I am often impressed by how well it usually works.
Bob Zawalich
And again, I just want to point out that in Philip’s example, as well as in the case of deleted rests, the bar rest is not pasted. instead, a hole is left and Sib’s default behavior is to fill a hole with a rest, (as it does when you add a small note to an empty bar), and that is what is happening in the paste.
Bob Zawalich
And for a final off-topic comment, I note that if you make a selection and type “R”, it *will* copy over rests and their offsets. I have no idea why, but it must be a different mechanism than copy and paste.
Bob Zawalich
And I need to correct myself: if there are multiple voices in a selection the rests and their offsets appear to survive a paste, but if you have a solitary whole rest in a voice other than voice 1 in will not be pasted. It’s all tricky when you get to the details.