Introduce line handlers

[th-we]

Use the same mechanism for handling lines as we use for text and symbols.

• This makes export of custom line styles possible using extensions.
• More line styles are supported now
• All lines now get an @endid if at the end of the line there is a NoteRest in the same layer.

There is one thing I'm not entirely sure about. Should @endid always point to the note the line ends at? For example, in this case of a vibrato line:

The endpoint is attached to the second note (because it lasts until that very point), but the vibrato line does not apply to the second note.

Should @endid simply be omitted for some line types? They will still have @tstamp2.

[ahankinson]

Yes, @endid should be omitted if the line does not cover the ending.

[th-we]

O.K., I've changed the behavior to not include @endid for all line styles. However, I'm not 100% content yet. Specifically, @endid can currently only be added if the line end is perfectly attached to the end position of a NoteRest. However, Sibelius does not always create the lines like that and the user can not easily see it.

I could imagine these options to choose from different @endid behaviors for different line styles:

• No @endid at all (e.g. for brackets that are open to the right, so don't really have a defined endpoint)
• @endid only if perfectly attached (e.g. for pedal lines; pedal changes can be timed anywhere in between notes)
• @endid of closest preceding NoteRest (if existent, e.g. for octave lines; preceding note is that last one it applies to).
• @endid of closest following NoteRest (if existent, e.g. for glissando lines; glissando ends at following note)
• possibly @endid of closest NoteRest (e.g. for slurs, but those should always be precisely attached)

A suggestion for how this could be achieved: With the declarative line handling, we could introduce something like this, e.g. for:

'line.staff.vibrato', CreateSparseArray('Line', CreateDictionary(
  'form', 'wavy',
  'type', 'vibrato',
  'endid', ClosestPrecedingNoteRest
))

...where ClosestPrecedingNoteRest is an object that tells the line handler what to do. For extensions, it can be made accessible as api.ClosestPrecedingNoteRest.

Better naming ideas for ClosestPrecedingNoteRest/ClosestFollowingNoteRest are welcome as these names don't really transport that a NoteRest that precisely matches the endpoint of the line will be chosen as @endid.

As extending and maintaining the existing test files became really confusing, I tried something akin to Schematron rules in 6bdccbd7ab7f2215cc63bfdc8a3f74d044cd5769 which hopefully makes creating, understanding and maintaining tests much easier. Here is a screenshot, which should be pretty self explanatory: The test expression is defined in the Sibelius file and will be exported to a special annotation. The JavaScript test code is reduced to a boilerplate, which could eventually be removed as we could also iterate over all test files and evaluate all the exported XPath test annotations. Some things might still be more sensible to test with JavaScript.

If this approach seems sensible to you, I would probably write any new tests in this fashion. It makes it much clearer to see what object a test applies to, and it does not require to keep two test files (JavaScript and Sibelius) in sync. Also, in the output MEI, the test and the exported object are very close together for checking. In the case of the screenshot above:

<octave xml:id="m-74" dis="8" endid="#m-69" layer="1" place="above" staff="1" startid="#m-68" tstamp="1" tstamp2="0m+3" vo="10.5mm"/>
<anchoredText xml:id="m-75">line.staff.octava.plus8</anchoredText>
<annot xml:id="m-76" layer="1" staff="1" startid="#m-69" tstamp="1.2734" type="xpath-test" vo="1.75mm">octave[@endid][@tstamp=1][@tstamp2=&apos;0m+3&apos;]</annot>

[th-we]

O.K., from my side, this is ready to merge now. Could anyone run the tests on their setup?

[th-we]

I addressed the different @endid handling for different line styles using placeholder values that are resolved when then ending bar for the line is reached. The way it works is documented for the function HandleLineTemplate() over here.

[th-we]

I noted that many of the line-like objects you've converted are now set to PreciseMatch which is a pretty big change in behaviour, I think? If I recall, for example, slurs were set to Closest before

You're right! I guess it would be good if you (@ahankinson, @rettinghaus, @annplaksin) could have a look at my choices for PreciseMatch, Previous, Next and Closest here (without wanting to distract from the rest of the code).

Thanks for the quick reaction!

[ahankinson]

Honestly I would just change them all to Closest, and then only use PreciseMatch in places where you know that's what you want / need.

(I know that the "Closest" @endid resolver has led to some annoyed people in the past, but it's better than the alternative which is a line that never resolves....)

[th-we]

I don't think it's that dramatic if a line does not resolve to an @endid, it will still have @tstamp2. Just like for trill lines:

The end of the trill line precisely matches the following note, but as we agreed, that should not be the @endid as the trill line does not apply to this note any more. So currently, I do not set an @endid and only rely on @tstamp2.

For easier review, here's a list of search strategies and the styles I currently use them for:

• PreciseMatch
  • line.staff.arrow.black.vertical
  • line.staff.arrow.white.vertical
  • line.staff.bracket.vertical
  • line.staff.bracket.vertical.2
  • line.staff.dashed.vertical
  • line.staff.slur.down
  • line.staff.slur.down.bracketed
  • line.staff.slur.down.dashed
  • line.staff.slur.down.dotted
  • line.staff.slur.up
  • line.staff.slur.up.bracketed
  • line.staff.slur.up.dashed
  • line.staff.slur.up.dotted
  • line.staff.tie
  • line.staff.vertical
• Next
  • line.staff.arrow
  • line.staff.arrow.black.right
  • line.staff.arrow.black.right.dashed
  • line.staff.arrow.black.right.left
  • line.staff.arrow.white.right
  • line.staff.arrow.white.right.dashed
  • line.staff.arrow.white.right.left
  • line.staff.gliss.straight
  • line.staff.gliss.wavy
  • line.staff.port.straight
• Previous
  • line.staff.bracket.above
  • line.staff.bracket.above.end
  • line.staff.bracket.below
  • line.staff.bracket.below.end
  • line.staff.hauptstimme
  • line.staff.nebenstimme
  • line.staff.octava.minus15
  • line.staff.octava.minus8
  • line.staff.octava.plus15
  • line.staff.octava.plus8
• No endid
  • line.staff.bracket.above.start
  • line.staff.bracket.below.start
  • line.staff.dashed
  • line.staff.dotted
  • line.staff.hairpin.crescendo
  • line.staff.hairpin.crescendo.bracketed
  • line.staff.hairpin.crescendo.dashed
  • line.staff.hairpin.crescendo.dotted
  • line.staff.hairpin.crescendo.fromsilence
  • line.staff.hairpin.diminuendo
  • line.staff.hairpin.diminuendo.bracketed
  • line.staff.hairpin.diminuendo.dashed
  • line.staff.hairpin.diminuendo.dotted
  • line.staff.hairpin.diminuendo.tosilence
  • line.staff.plain
  • line.staff.vibrato
  • line.staff.vibrato.wide

I don't think that Closest would be the correct strategy for the ones that are listed as Previous because they are all bracket types. A bracket will not apply to a following event, even if it is closer to the bracket end than the previous event.

Concerning the ones where I used Next, I'd be O.K. with converting them to PreciseMatch(but not closest, as they all point to something "later" in time).

[rettinghaus]

I agree with @th-we that this is probably the best approach.

@th-we PR still in conflict with target, please resolve.

[rettinghaus]

@ahankinson may I proceed?

[ahankinson]

Sure! Thanks.

[th-we]

Did anyone run the tests?

[ahankinson]

Oh, wait! I just spotted something -- I left a review comment.

[ahankinson]

I didn't run the tests

[annplaksin]

I currently cannot run any tests because I have no running Sibelius available. Sorry!

[th-we]

O.K., I took the chance to further simplify how line templates can be registered, especially in extension plugins. From my side, this is ready to merge. At least for me, tests all pass.

[rettinghaus]

I made some more tests and everything looks good to me. Thank you!