@layer on octave lines

[th-we]

This is a very common warning, but for many objects it's more sensible to attach them to voice 0/all layers. I'm currently facing this problem for ottava lines. Instead of writing layer bound @startid, @endid and @layer, it's more sensible to write a comprehensive @plist. That also makes it easier to find out, which notes are transposed.

If writing @plist instead of @startid, @endid and @layer is something we can agree on, should we distinguish classes of objects that can sensibly be on voice 0 and ones that make no sense there? Then we only should displaying warnings for the latter.

[ahankinson]

Can you give me an example of an object that doesn't belong to any voice? Ottava lines seem like they should be attached to a specific voice.

There is some expectation that the user will put some effort into 'semantically' encoding the contents of their Sibelius file. That warning is there to gently prompt people to fix their Sibelius encodings, since it will make for better MEI output. In every case where that warning appears (I think) the user can go back and make it better. I could be convinced otherwise, though, if you have a compelling use case.

@plist encoding would have to be checked against Verovio's functionality too. We're not completely bound together, but I do try to keep them as close as possible.

[pe-ro]

When both hands of a piano piece are written on staff 1 it's not entirely clear whether only the top layer/voice is affected. I think I remember that Gould has something to say about this, but since I don't have the book in front me at the moment, I can't say where / what. It seems to me that attaching an ottava line to a staff is a better default than assuming it only affects a particular layer/voice. Of course, you guys understand the inner workings of Sibelius much better than I, so you get to decide. 😀

[th-we]

Here's an example from Debussy's Petite Suite for piano/four hands, 4th movement:

The ottava line (almost always?) applies to the entire staff. Interestingly, in Sibelius it doesn't matter to what voice an ottava is attached to, all voices get transposed. You can hear that in the attached MIDI export from the following example where the three ottavas are attached to different voices, but all three have the same effect on all voices:

ottava-different-voices.zip

So, I'd either always assume ottavas are attached to all voices, even though Sibelius by default attaches them to a specific voice, or turn the current warning on its head and warn the user if the ottava is attached to a voice. In the exceptions (that I'm sure do exist) where an ottava only applies to a specific voice, the user will have to live with the warning.

In contrast to ottavas, Sibelius by default does not attach hairpins to a voice. But here the situation is less predictable. In piano music, hairpins (and dynamics in general) may apply to an entire staff or both staffs (impossible to encode in Sibelius, possible to encode in MEI with multi-value @staff). I'm sure in polyphonic piano music, it can also apply to single voices, but I didn't look hard enough to find an example. In scores with shared instrumental or choral staffs, dynamics may apply to all or single instruments - like in the Symphonie Fantastique:

Separate hairpins (rehearsal mark 2):

Obviously shared hairpins (13 measures after rehearsal mark 8):

So, in the case of hairpins, I guess we'd have to trust the user, though we know Sibelius is a visual tool where users often don't care where things are attached. When playing back dynamics, Sibelius seems to differentiate between different voice attachments.

[ahankinson]

My feeling is that if we're encoding semantics we should try and be as unambiguous as possible. If an ottava line applies to both voices, I would like to see it encoded on both voices, and leave it up to the renderer to decide whether to display it as such or not. I think this is important because not all "rendering" is visual, and doing things like playback or statistical analysis on ambiguous data gives you ambiguous results.

The current warning is there because I felt like the Sibelius default of not attaching a symbol to a voice is, from a semantic encoding point of view, a bad thing. A user concerned with trying to get the best semantic encoding out of Sibelius should be warned that they could do better. I don't think my opinion of this has changed.

That said, I think there is a case where we can make an assumption that specific symbols, if they are not attached to a specific voice, can be written as belonging to the staff and not the layer. I would want to do this on a case-by-case basis, and I would probably still want to keep a warning but perhaps re-word it:

"Ottava line assigned to voice 0 has been attached to the staff. If it should apply to a specific voice, please adjust your score."

(Or something like that -- I'm not entirely sold on the wording).

So, hairpins OK; ottava lines OK. But I think lines like trills should still be attached to a specific layer.

(I'm (unfortunately) still without a laptop with Sibelius on it, so I can't write or test anything at the moment.)

[th-we]

My feeling is that if we're encoding semantics we should try and be as unambiguous as possible. If an ottava line applies to both voices, I would like to see it encoded on both voices, and leave it up to the renderer to decide whether to display it as such or not. I think this is important because not all "rendering" is visual, and doing things like playback or statistical analysis on ambiguous data gives you ambiguous results.

Totally agree. To make things as unambiguous as possible for ottavas, I'd:

• use multi-value @layer where VoiceNumber is 0
• use @plist instead of @startid/@endid (which might suggest that the ottava only applies to the layer the start/end elements are on)
• warn if VoiceNumber != 0, as this is an atypical case.

Concerning warnings: With the current situation I don't think we're guiding the user towards a better semantic encoding. There are too many messages, they are too unspecific/repetitive/hard to parse by a human and not all of them are actually justified (like with ottavas). So we should bring the number of messages down, make them more specific and possibly consider a different approach of notifying the user. If there were warnings, we might want to give the user the following options:

• Print them on the console like we do now
• Add comments at the respective places (with Bar.AddComment()) so the user can step through them
• Ignore them entirely(?)

When using comments, we probably should also provide a simple script to wipe them out again.

I guess we should start classifying objects into categories:

• should be voice attached
• should be staff attached
• can be both (any way of creating plausibility checks?)

I suggest starting compilation of this classification on the Wiki. Might be a good idea anyway to document this.