beam@num.place meaning

[craigsapp]

beam@num.place (and beam@bracket.place) can have the value above or below. What exactly does this mean? The documentation says that it is in relation to the noteheads:

@place in other cases are related to a fixed vertical orientation, such as above or below the staff. But in this case the meaning is a relative position dependent on the orientation of the notes on the staff (i.e., the stem direction). It seems that above really means stem/tail and below really means head/notehead.

Here is a diagram:

If you use the standard definition of above and below, these positions remain constant whether the stem is above or below the notehead.

Related to this, what is the meaning of beam@num.place for stemless notes? If relative position is dependent on the stem direction, then should a stem direction be assigned to the stemless notes (I find this reasonable to do).

[pe-ro]

If you use the standard definition of above and below, these positions remain constant 
whether the stem is above or below the notehead.

Exactly. The position of the number is independent of the stem direction.

Am I correct in assuming that what you're looking for is a way to create a dependency between the stems and the tuplet numbers? That is, if the stems are flipped, then so is the position of the numbers?

We might be able to accommodate both by allowing @num.place to use 2 sets of values: "above" and "below" for absolute placement and "head" and "tail" for relative placement.

I think you meant tuplet/@numplace, but in any case, for stemless notes or in the case where stem directions aren't specified, stem direction has to be assigned.

[craigsapp]

Am I correct in assuming that what you're looking for is a way to create a dependency between the stems and the tuplet numbers? That is, if the stems are flipped, then so is the position of the numbers?

Yes

We might be able to accommodate both by allowing @num.place to use 2 sets of values: "above" and "below" for absolute placement and "head" and "tail" for relative placement.

Here are the possible cases:

A, C, F, G: "below"
B, D, E, H: "above"
A, E: "tail"
B, F: "head"

tail/head assignments are confusing for C, D, G, and H. Perhaps they can be defined by the direction of the first note in the beam group.

Typically music style uses head/tail system. Modern editions like using "tail", but 19th century editions prefer "head". When dealing with music that have lyrics, a possible preference would be for "above" so that the tuplet is not getting in the way of the words.

[pe-ro]

Makes sense. But, how should Verovio / other processor deal with mixed stem direction AND relative number placement? For instance, a value of "head" or "tail" for case G? Should "head" and "tail" be disallowed by Schematron when stem directions are mixed?

[craigsapp]

For "head"/"tail" mapping to "above"/"below" in the case of a mixed-direction beam:

Perhaps they can be defined by the direction of the first note in the beam group.

So:

C, H: "tail"
D, G: "head"

[pe-ro]

Sorry, missed that sentence. The exact mapping strategy doesn't matter as long as Verovio is consistent.

Is this something that should be in 4.0 or can it wait 'til the next revision?

[craigsapp]

There is no hurry, so it can wait until the next version.

[craigsapp]

This also applies to tuplet@num.place. See issue rism-digital/verovio#987

[craigsapp]

@ahankinson transferred this issue from music-encoding/music-encoding on Apr 12

Should discussions about new features (or changes in features) be placed here (music-encoding/guidelines) or in (music-encoding/music-encoding)? I am going to submit a new issue for <key>, which I will start in this repository...

[bwbohl]

@ahankinson transferred this issue from music-encoding/music-encoding on Apr 12

Should discussions about new features (or changes in features) be placed here (music-encoding/guidelines) or in (music-encoding/music-encoding)? I am going to submit a new issue for <key>, which I will start in this repository...

new features please to the music-encoding repo, not the guidelines