Fixed chords

[ahankinson]

This is a first attempt at reaching some agreement on the encoding of chords.

Chords are enclosed in ^ and >. The duration of the chord is given prior to the opening ^ (similar to tuplets). No duration values are allowed within the chord. (i.e., chords with notes with differing durations are not allowed.)

~Similar to repeat groups and repeat measures, tied chords are repeated with the v character.~ This has evolved, see #60 This means that you don't have to spell out the notes of the chords, and only identical tied chords are supported, varying only by their duration.

A p may be used to indicate a fermata over the chord.

Fixes https://github.com/rism-digital/pae-code-spec/issues/65 Fixes https://github.com/rism-digital/pae-code-spec/issues/60 Fixes https://github.com/rism-digital/pae-code-spec/issues/2

Examples:

2^CEG>

{8^CEG>^DxFA>}

[github-actions[bot]]

PR Preview Action v1.4.7 :---: Preview removed because the pull request was closed. 2024-07-16 07:08 UTC

[lpugin]

There is one more thing that needs clarification - I think - which is if an octave change within a chord remains as current after it. I would expect it, but I don't think this is explicitly stated. Is it? Or do we want to change the this? We would need to think about the implications if we do.

I noticed this to be particularly "nasty" with the use of repetition. For example, if you do:

2'G4!G^B^''D!f/ you probably expect the last chord to be repeated like that:

However, this is what Verovio produces - keeping the last octave as current:

[ahankinson]

It's not explicitly stated. Could you please make an issue?

[BaMikusi]

Apologies to @ahankinson for mixing the topics, but I have really lost the overview, and would not like to potentially duplicate tickets. In any case, @lpugin's example reminds me of a more general problem with repetition shortcuts.

Both with repeated measures (i) and repeat groups (!...!f) the intention seems to be to indicate a repeat of the music, but in fact only the code will get repeated, which might result in non-identical renderings, depending on the context (surrounding indications of octaves and durations). I guess in the V2 specs we should make clear once and for all what gets repeated in such a case.

(Would actually be nice if that could be the actual music, but I guess that should prove a considerably bigger challenge for the rendering.)

[ahankinson]

Could you clarify how you're differentiating the "code" and the "music"?

[BaMikusi]

I have a source before me. I am encoding it, and at some point I realize that what comes (say, an entire bar) is exactly what I have just transcribed. PAE spec then encourages me to simply put an i in the next bar, but what Verovio then renders may still not be the same music/notation as what I had in that previous bar. Because the i in fact implied the repetition of the code, which is likely not quite what the cataloger meant to be repeated, when seeing a musical repetition in the source itself.

[BaMikusi]

So, the specs should actually say: you could try to repeat the previous bar by entering an i, and if the circumstances are umproblematic, that will indeed work out for you.

[BaMikusi]

Sorry, when writing my last comment I was just rushing out of the office to catch my train, and had no time come up with an example -- but now here's one:

Say, this is the music I actually see in the source: 'EF/GB''2C/'4GB''2C/

However, while transcribing this, I realize that the 2nd full bar is actually identical to the first one, so I decide to follow the specs and use an i shortcut like this: 'EF/GB''2C/i/ But while this i indeed appears effectively to copy over the code from one bar to the next, since at the beginning of the 1st full bar we were in the ' octave and had quarter durations 'inherited' from the precedents, while at the start of the 2nd full bar we are in the '' octave and have had a half value before, the music displayed will be so different that no one would guess this was meant to be a note for note repetition of the previous bar:

[ahankinson]

@lpugin I think this is ready to be merged, but could you please double-check?