Using visibility for different notation in score and part
The attached minimal example illustrates my issue, which is using different notation variants for repeated notes in score and part, respectively.
I have tried to keep the viola part compact and readable by using tremolo notation, whereas in the score, I prefer the expanded version using 16th notes. This kind of works. However in the part, bars are too wide because of the invisible notes.
Can I do something to make the layout engine ignore the invisible notes?
Attachment | Size |
---|---|
Example.mscz | 14.03 KB |
Comments
Possibly workaround, but not workable in some situations. Notate the score in voice 1, the part in voice 2. When creating the part, only link the 2nd voice to it.
Disadvantages:
* You must notate everything twice and make voice 2 hidden in the main score.
* The part-from-a-voice feature is still quite new, issues with dynamics and other markings belonging by default only to voice 1 are likely.
Better workaround: Use a 2nd instrument
After notation and part creation, you can then mark the instrument invisible in the main score.
Disadvantages:
* Both viola's show up in the mixer
* Don't forget about it when writing your music
Advantages
* Easy copy-pasting between the two after re-enabling the visibility for the instrument.
In reply to Possibly workaround, but not… by jeetee
Wow, thanks a lot. These are two feasible workarounds. I actually went with the second voice for my score, and it seems to work.
Since I'm preparing a score for upload to musescore.com, I'm wondering will both approaches work online?
In reply to Wow, thanks a lot. These are… by kontrafuss
As far as I'm aware, both approaches will work as intended on .com as well.
In reply to Wow, thanks a lot. These are… by kontrafuss
Musescore.com doesn't show the parts separatly as far as I know
In reply to Possibly workaround, but not… by jeetee
By the way, discovered a bug in voice extraction.
In reply to Also note there's a bug in… by kontrafuss
Or #306594: Part voice extraction broken, and see my remark there
Invisible elements should usually not require any space, most of the time they do this would be a bug.
Here though it might be on purpose, to not break scores that rely on the spacing this creates