"Bar object assigned to all voices will be encoded on voice 1"

[th-we]

This message is not very useful because it is printed too often and it's hard to work through all the occurrences based on the list. Instead, the user could be given the option (via dialog) to color all the problematic objects red so it's easier to fix things manually.

@rettinghaus and me discussed this briefly during the technical team workshop in Berlin. Any objections to creating a pull request that implements this, @ahankinson?

(This is independent of whether the message is actually sensible or not, like for tempo text where it does not make sense to attach it just to layer 1.)

[ahankinson]

So far the sibelius exporter has avoided actually changing anything in the source score. I would like to keep it that way, so that it doesn't actually change anything in anyone's scores. Many people who use the plugin assign some specific meaning to color in order to aid later processing -- like the DuChemin project, that used colours for different readings. If we start messing with colours in the plugin, we might overwrite some of this work.

That said, I'm not opposed to a separate tool to help people fix their scores. Would you be willing to write this into a separate plug-in that we distribute with sibmei?

[th-we]

This warning is still an issue. Currently, we also don't correctly read out the layer association because an object can be associated with multiple layers, which can either be read out using Voices (instead of VoiceNumber) or GetIsInVoice(). My suggestion is:

• If an object is associated with 1-3 voices, we write those layer numbers as @layer.
• If an object is associated with all voices, we don't write @layer because that means it applies "globally".

Unfortunately, Sibelius has some weird defaults for voice association. Dynamics (hairpins, text) are by default only associated with one voice, but in real life, they apply to all voices most of the time. Sibelius associates symbols with all voices by default, also for symbols like ornamentation, but in real life, they only apply to one note.

It is unrealistic to expect from users to change the layer association of tremendous numbers of objects. (We don't even do that in our test files.) To make the plugin usable and maintainable, we should accept how Sibelius works and how Sibelius is typically used. The encoding can not be better than what is in the Sibelius file, but if the encoding based on Sibelius' defaults is good enough for a user (or they can iron it out with postprocessing), that's O.K. We should however document the behavior and give instructions how to be more specific about associating objects to layers if the default layer associations are not good enough.

[ahankinson]

If an object is associated with all voices, we don't write @layer because that means it applies "globally".

Why not write all layers in @layer?

The encoding can not be better than what is in the Sibelius file, but if the encoding based on Sibelius' defaults is good enough for a user (or they can iron it out with postprocessing), that's O.K.

I agree that the encoding cannot be better than what is in the Sibelius file -- that's the point of the warning. It's to let people know that the plugin needs to change the "meaning" of the encoding by encoding something in one voice that belongs to many.

If you can find a way to fix this in the encoding, then the warning can be removed. But i wouldn't want to not alert users that we're knowingly changing the meaning of their encoding silently.

[th-we]

If an object is associated with all voices, we don't write @layer because that means it applies "globally".

Why not write all layers in @layer?

Because that does not make sense most of the time. We rarely have more than one or two layers. Leaving out @layer if something applies to no specific layer is also how MuseScore's export behaves, as far as I understand.

If you can find a way to fix this in the encoding, then the warning can be removed. But i wouldn't want to not alert users that we're knowingly changing the meaning of their encoding silently.

But it suffices to show this message once and point to the documentation. Then users can make an informed decision how to proceed and how they might want to change their workflow, which might mean painstakingly editing the layer associations, or improve @layer during postprocessing based on some global assumptions that fit their project.

Throwing out piles of warnings only has the effect that all of them will be ignored because nobody will go through all of them.

[rettinghaus]

I'm with @th-we on this.
Unfortunately currently we don't have a proper documentation for any feature. Maybe we could setup a wiki page to list some features and limitations of the plugin?