Schenker-enable: Visualize relations with ties/slurs/bars, different note-heads, etc.

[pettter]

Visualizing (selected?) relations using slurs should not be too hard. The basic procedure is the following:

• Find the first and last (primary) note of the (monophonic, single-staff) relation
• Add a element to the measure containing the first note, indicating the correct staff and the end note

I am not sure how slurs interact, though.

[yrammos]

@pettter

I tested the recent schenker_visualisations branch. You were right — slurs in Verovio seem prone to collisions that, presumably, would necessitate manual tweaking of the MEI slur attributes. That's unfortunate, but slur collision detection is a notorious algorithmic pain in the neck (as evidenced also in the LilyPond suite of unit tests).

Might any of the following approaches be reasonable? Am labeling them for convenience.

1. "Manual": A rudimentary UI for manually shaping/moving slurs. Hovering over a slur, for instance, could reveal a semi-transparent popup control with position and curvature buttons wired to the <slur> attributes. (Whether such visual parameters properly belong in the MEI file is another question...)

2. "Compromise": Typeset slurs in grey ink, use black only for the hovered-on layer (plus/minus one layer for context?).

3. "Detect": For each new slur, apply collision detection (checkIntersection(), getIntersectionList() and the like); then nudge the slur up/down as many pixels as necessary until it does not collide. This is unlikely to produce production-quality typesetting, but might (should?) be more legible from a utilitarian point of view.

4. "Notational": Minimize the number of slurs by replacing as many of them as possible with a less collision-prone notation, such as variable-length stems or horizontal brackets, according to some heuristic TBD. We could draw inspiration from graphic styles such as those of:

   1. Steve Larson ("Strict Use of Analytic Notation," Journal of Music Theory Pedagogy 10, 1996). Larson uses a combination of judicious stemming and slurring. The semantic underpinnings of his graphing style might be too heavy for our purposes, though. I'd need to think about this.

   2. Felix Salzer (Structural Hearing, 1962). Salzer uses variable-length stems in most cases, horizontal curly brackets for Stufen, and the occasional horizontal beam or slur. (Beams are probably out the question, though; they form ambiguous rectangles when crossing, like electrical short-circuits, and would probably prove even more problematic than slurs.)

   3. Earlier Schenker: Around 1920 he would use motivic brackets for "Urlinien" and the occasional linear progression. William Renwick's article, "Brackets and Beams in Schenker's Notation" (Theoria 3, 1998), documents all these notational nuances.

[pettter]

I'm currently leaning toward the second Compromise option, at least for now.

In particular, the "Detect" option is likely to require an unreasonable number of rerenderings through Verovio, each potentially taking quite long time, depending on the size of the score, at least if they idea is to get a Good Rendering of the slur representation through standard means (e.g. Verovio, Musescore). Just nudging the SVG is an option, though.

The Manual redrawing may be more attractive once the interface for adding implied notes/tones is available.

Using non-slur Notational changes could also be useful (bracketspan looks like a useful tag, for example), though I worry that the note-level precision and flexibility may suffer. Perhaps highlighting can be helpful here as well.

[pettter]

Adding on to the Detect option: There are provisions in the slur tag to define both x/y coordinates and bezier points, but I'm not clear on how those actually relate to actual rendering. I'd need to do a deep-dive there.

[yrammos]

@pettter Nice catch — Adjusting the bezier parameters prior to rendering in Verovio would probably be the cleanest solution. Rendering of some MEI attributes is supposed to be implementation-dependent (e.g. the line @form attribute), but I doubt bezier params are among them (this would defeat their purpose, I suppose).

<bracketSpan> might be good to keep under the radar anyway, e.g. for motivic parallelisms.

I'm thinking, might the "Notational/Salzer" option (4.ii) be even simpler to implement—and visually more conventional—than "Compromise"? Please don't take my word for it. But MEI does offer a nice @stem.len attribute, which could be made into a function of distance from the background, roughly speaking:

@stem.len = some_constant / (distance_from_background) + some_base_length

although this would surely need to be refined in all sorts of edge cases… ( unit tests to the rescue :) )

(For full disclosure, there's a small open issue upstream with @stem.len : https://github.com/rism-ch/verovio/issues/932)

[yrammos]

Adding one more option to those outlined above:

5. "Non-Verovio": Building on the existing capsules-based visualization, seamlessly attach an elliptical segment above (top staff) or bottom (bottom staff) of the capsule. The height of the segment could be quasi-proportional to its length, so that nested relations would produce nested elliptical segments.

(N.B.: This is only a thought experiment — a prototype might debunk it.)