rism-digital / pae-code-spec

Issue tracker and website for the Plaine and Easie specification
https://plaine-and-easie.info/
0 stars 0 forks source link

Rework tuplet section #123

Open ahankinson opened 1 month ago

ahankinson commented 1 month ago

It's not entirely clear yet what the given numbers are, since there can be:

8(6ABC;3)

Of which:

Or something along those lines?

lpugin commented 1 month ago

I would say:

I guess the unclarity comes essentially form the fact that PAE cares essentially about how it looks like. This means that indicating the total value of the group has been widely ignored.

lpugin commented 1 month ago

PS one thing we could introduce is a ratio option with :. That is, allow to encode 8(6ABC;3:2)

ahankinson commented 1 month ago

8 indicates the total value of the group

What does "total value" of the group mean? That the tuplet takes 3 16th notes in the space of 2 (i.e., one 8)?

But this isn't really necessary, and depends on the time signature, no? 8(6ABC;3) makes sense, but can you also have 4(6ABC;3)?

Is there a situation where the first value is necessary to the correct interpretation of the tuplet? Or can it be considered "fully specified" with (6ABC;3), since you can determine that this is three sixteenths in the space of two?

lpugin commented 1 month ago

Yes, this is a general problem. People have most of the time ignored the total duration since in most simple cases, it is not necessary. In fact, for visual rendering it is not necessary at all.

Considering this example:

image

The first one should be coded 4({8CCCCC};5) and the second 2({8CCCCC};5). So necessary for the duration interpretation, but not for the rendering. (The first one is a 5:2, and the second a 5:4)

lpugin commented 1 month ago

Maybe we need to think about which cases a total duration MUST be givein. In the example, the second one is the "standard" one because it goes one level down, which is typically what you expect in binary meter. E.g 3 = 3:2, 5 = 5:4, 7 = 7:4, 13 = 13:8. So 5:2 is one case where the 4 before the tuplet must be given because as standard quintuplet would replace 4 8th notes and note 2. In ternary, it goes more often the other way around (2:3)

lpugin commented 1 month ago

Looking at this, it seems that we can consider a standard and clear practice to have the tuplets in binary meter:

This means that:

image

is by default the duration of a quarter note and meaning a:

image

As in the examples above, this can be considered a non standard practice:

image

Similarly, this

image

is by default the duration of a quarter note too, meaning a 7:4 (and not a 7:8)

I would suggest adding a reference to Chapter 7 of Behind Bars.

Since we are missing the total duration of the groups in probably the majority of our incipits, there is not point keeping this mandatory. I would instead suggest adding an option to code the ratio with an additional optional :[0-9]+ after the ; numerator, which will be a much simpler and much clearer way to code non-standard cases or in case of doublt. That is, allowing (6{CCCCC};5:2)

The specs can be:

ahankinson commented 1 month ago

The total duration or the ratio MAY be given when tuplets follow the standard practice

Do we need to define what "standard practice" is here?

The total duration MUST not be given if the ratio is given (I think it is better to make the exclusive in order to avoid conflicting values)

In this case the total duration and the ratio should go in the same place so that they are actually mutually exclusive.

If we're thinking only visually, we don't actually need ratios, nor duration calculations. I get that it makes alignment with multiple voices work, but since we don't have multiple voices in PAE, it's not really necessary here.

Given that there may or may not be a prevailing time signature which would dictate how the first value works, and that there may not be barlines in the right place to actually enforce that, perhaps we should drop the first value and opt for a simpler form:

(Annn;B)

Where A is the first duration of the first note within the group (it must be restated); subsequent notes in the group may also have differing durations as necessary, and B is the (optional) number given in brackets to be shown above the group.

B will render 3 if not specified. A ratio like 5:4 can also be specified.

If you really want to play it back, the playback duration would anyway need to be computed from the time signature and the number of beats in the measure anyway, since it wouldn't necessarily be reliable to use the initial duration.

We could keep the initial duration for backwards compatibility, but just ignore it.

lpugin commented 1 month ago

The total duration or the ratio MAY be given when tuplets follow the standard practice

Do we need to define what "standard practice" is here?

We can give a reference to Gould. It has a good definition.

The total duration MUST not be given if the ratio is given (I think it is better to make the exclusive in order to avoid conflicting values)

In this case the total duration and the ratio should go in the same place so that they are actually mutually exclusive.

Do you mean in the specs, or in the encoding?

If we're thinking only visually, we don't actually need ratios, nor duration calculations. I get that it makes alignment with multiple voices work, but since we don't have multiple voices in PAE, it's not really necessary here.

Ratios can also be given as such in the source, so thinking only visually can include ratios. I agree on the total duration, which we do not need in my opinion.

Given that there may or may not be a prevailing time signature which would dictate how the first value works, and that there may not be barlines in the right place to actually enforce that, perhaps we should drop the first value and opt for a simpler form:

(Annn;B)

Where A is the first duration of the first note within the group (it must be restated); subsequent notes in the group may also have differing durations as necessary, and B is the (optional) number given in brackets to be shown above the group.

I am not fully convinced we need A. 8CC(DDD)CC seems fine to me.

B will render 3 if not specified. A ratio like 5:4 can also be specified.

Yes, I think this would be good.

If you really want to play it back, the playback duration would anyway need to be computed from the time signature and the number of beats in the measure anyway, since it wouldn't necessarily be reliable to use the initial duration.

We could keep the initial duration for backwards compatibility, but just ignore it.

Yes, I would not drop it in the data we have. That is, make it optional.

lpugin commented 1 month ago

One rule I can see regarding the total duration and the first duration is to say that "When the total duration is given before the tuplet (, then the first duration MUST be given within the (.

(Otherwise it is impossible to know if the value before the group is the total duration of the group and not just a duration)

ahankinson commented 1 month ago

One rule I can see regarding the total duration and the first duration is to say that "When the total duration is given before the tuplet (, then the first duration MUST be given within the (.

That seems to be a bit complicated.

I'm trying to figure out if the current Verovio behaviour is correct, even according to Version 1.

I read 4(8DDD) as (unless I'm mistaken) "3 half-beat subdivisions in the space of two." That's a pretty standard triplet.

So is this:

image

Actually correct? I thought the 8 here is saying "three whole-beat subdivisions in the space of one" (which is nonsense, but that's the point) not "these notes should be rendered as an 8th". (Which seems to be the current interpretation in Verovio?)

Even clearer:

image

I would think that this wouldn't be possible, since (if we assume the "default" value of "4" applies to the group duration AND to the note duration) then that's three whole-beat quarter notes in the space of one?

If that's the case, then if anyone is using the "group duration" A( value to set the value of the notes IN the tuplets, then it's wrong, isn't it? It's not really a visual duration indicator, it's just there to provide some sort of "musical" duration that we don't use anyway. (e.g.., we don't insert barlines automatically according to the time signature, or restrict having too many beats in a measure. There are no other places in PAEC where we actually pay any attention to the "beat").

If that's the case, then we would need to correct the tuplets that are incorrectly using it that way, instead of formalizing that interpretation into the new rules, right? I understand that the Version 1 tuplet definitions are pretty thin on details, but I think that's the original meaning.

The next question is how do we deal with the group value in existing encodings.

A crazy thought is to move any value in that position to a new optional field:

4(8DDD;3) -> (8DDD;3,4)

The advantages are that the ,4 MAY be specified for the total duration of the tuplet, but it's not in a position in the stream of characters to privilege (or mistake) that value as a "duration" value any more. It also "reads" a bit better too, since this is "3 subdivisions in a quarter". Likewise:

(6GGGGG;5:4,4) == (6GGGGG;5:4) == (6GGGGG;5,4)

While redundant, I think they all say "5 subdivisions in a quarter"?

This value can get moved and saved in any automated upgrades from V1 to V2 and not lose any information, but its presence can be effectively ignored when interpreting the notation.

This also removes the need to do "if this then that else this" in parsing the code, since there will be no way to mix up the group duration with the initial note's duration.

In this system,

Tuplets always send my head for a spin, so let me know if I got my calculations incorrect...

lpugin commented 1 month ago

Long story short: the first version of Verovio - or maybe even the parser I wrote before - used to implement V1 à la lettre. However, that appeared to be a big problem because most of the incipits we have code tuplets in a non compliant way. So when Verovio renders (8DDD) as a three 8th-note tuplet, this is clearly wrong, but what is actually wrong in the first place is the coding of the tuplet.

I realized that users would code what they would see, and I had to go back to MS-DOS Score to understand what it was meant - if you want to loose time we still have in in the office. I ended up implementing in Verovio what Score used to do, which means to accept not fully coded tuplets.

If we can migrate our incipits and move the total duration at the end, then I think your idea is quite good. This will be a big task where we need a complete no change before / after evaluation.

I would allow: (6GGGGG;5), (6GGGGG;5:4) or (6GGGGG;5,4), where :4 is a new option to indicate the fraction (e.g., total value) to be shown, and ,4 the total value, which we can migrate from the old incipits if we have it and that could still be used when desirable. I would not allow (6GGGGG;5:4,4).

lpugin commented 1 month ago

One comment on this

One rule I can see regarding the total duration and the first duration is to say that "When the total duration is given before the tuplet (, then the first duration MUST be given within the (.

That seems to be a bit complicated.

Yes it is, but otherwise there is no way to tell if a duration before the tuplet is the total duration of the tuplet, or simply a standard visual duration change. So the current ambiguity we have in the data makes it impossible to give a total duration without giving an initial duration in the tuplet.

ahankinson commented 1 month ago

Yes it is, but otherwise there is no way to tell if a duration before the tuplet is the total duration of the tuplet, or simply a standard visual duration change.

A good place to start would be if there is a number just after the ( -- I can imagine that the transcriber wouldn't set one duration and then immediately after set another.

If there is a number before the ( but no number after (without an intervening note), then that is a candidate for correction, or at least further investigation.

his is clearly wrong, but what is actually wrong in the first place is the coding of the tuplet. ... I ended up implementing in Verovio what Score used to do, which means to accept not fully coded tuplets.

I can imagine that this solution seemed to be the most correct one in the times before we had a process in place for correcting things in the tuplets. But now we have a situation where the incorrect coding of the tuplets is leading to ambiguities in what is actually meant. The way I see it is we have two choices:

  1. Continue allowing the ambiguity because it's now "standard" practice, even though it will cause problems in the future; or
  2. Correct the ambiguity now, even though it's going to be a not-insignificant amount of time to fix the problems.

I think we're generally leaning towards option 2? Nobody really benefits from option 1 in the long run, except those who would have to learn a slightly different way of coding things....

I would not allow (6GGGGG;5:4,4)

I dunno. I see it as:

([NOTES];[LABEL],[DURATION])

Are you suggesting that 5:4 would show that ratio exactly in the bracket, but 5,4 would only show the 5 in the bracket? Is there a standard case where a ratio in the bracket would say something different than the duration of the group?

I was suggesting that the label and duration are completely separate because then there is no need to "understand" what's in the label. If it's a number, and optionally a colon and another number, then that's just what it is. The duration then can be understood on its own as well, and we don't need to infer things back and forth between the two. They are standalone properties.

My expectation is that most people, if they get the display correct, will not supply the duration anyway.

lpugin commented 1 month ago

What would you expect with conflicting values between the label and the duration? Something like (6GGGGG;5:2,4) ? Or in other words, what would be the corresponding MEI representation?

ahankinson commented 1 month ago

I would expect the 5:2 to be rendered in the bracket. I'm not so concerned about the 4 -- I would think it could simply be ignored?

MEI doesn't actually use that value, as far as I know.

lpugin commented 1 month ago

It sounds weird to have the MEI version of the PAE losing information.

ahankinson commented 1 month ago

It's not losing information if it doesn't actually need it in the first place... The only reason it's there is so that we don't lose information between V1 and V2, but either way neither is needed in MEI, I think?

lpugin commented 1 month ago

Just putting the 2 in numbase would not yield a proper sounding rendering.

What (6GGGGG;5:2,4) says for me is actually "Show a 5:2 but play a 5:4". Am I wrong? I don't think this is a feature we need in PAEC.

ahankinson commented 1 month ago

It's the "play" bit that I'm talking about. I think that if we ever get to the point of building playback, the actual durations would need to be calculated at runtime anyway, rather than relying on the 4 (or any other value).

I don't want to get into cases where the composer has done something crazy, like write "gallop" in the bracket or something, but you could also imagine a case where they've written 5:2, with no barlines and no time signature. In that case, what is the effect of the 2 other than a simple label in a bracket?

lpugin commented 1 month ago

I don't understand. Why do you want to allow (6GGGGG;5:2,4) then?

ahankinson commented 1 month ago

So that if we have 4(6GGGGG;5:2) in an incipit in V1, there is an upgrade path to V2 that keeps the same meaning.

lpugin commented 1 month ago

We cannot have this in V1 because you cannot give a fraction in V1.

ahankinson commented 1 month ago

Ah, you're right. I see now that's something you want to introduce.

lpugin commented 1 month ago

I would not allow it, so it would be invalid PAEC. Only would be allowed:

Both the first and the third showing a 5 and the second 5:4