Octave of neumes on every staff with a C clef must be corrected

[dchiller]

Related to #6.

This issue should include applying these fixes to Einsiedeln and Salzinnes MEI files.

[JoyfulGen]

Some updates about this!

The octave of a clef isn't actually indicated in the MEI file, as you can see in this clef encoding:
<clef xml:id="c1xkohyv" facs="#zjmbewe" shape="F" line="3"/>

It is, however, reflected in the octaves of the pitches that follow it; each neume component (nc) has an oct attribute:

<neume xml:id="m-3611e181-adb2-44f5-a468-dfcf7f2d107b">
  <nc xml:id="m-c6177dcb-2a88-48d5-87d2-4edd8d3b2322" facs="#m-a25470ca-0170-45ba-96a6-bfa620695043" oct="3" pname="f" tilt="n"/>
  <nc xml:id="m-05c4eeba-fb03-4d8a-9ea4-2d9574a74c90" facs="#m-cae35e52-a265-4cd0-a218-795c57aa2b7d" oct="3" pname="d"/>
</neume>

Both MEI_encoding and Neon have now been updated to make the default octave of C clefs C4 instead of C3. So new files, including MS73, are all good in the clef department.

We still have a problem with Salzinnes and Einsie though, because their pitches were encoded when the default clef was C3. So even though you can't see anything wrong with the actual clef, all of the pitches are an octave too low. This is super apparent in Neon; because C clefs have been updated to C4, pitches appear an octave lower than where they should be, like so:

So I believe that the correction we need is for the octave of all pitched elements following a C clef to be made one higher. This needs to be done on all files with C clefs in the following repos:
https://github.com/DDMAL/e2e-omr-resources/tree/main/resulting_mei_files/Einsiedeln/Reviewed_once
https://github.com/DDMAL/e2e-omr-resources/tree/main/resulting_mei_files/Salzinnes/reviewed

If the correction can be done automatically, that would be ideal! It's possible to make the correction manually in Neon by dragging up all of the neumes, but that will take a loooong time.

@yinanazhou, can you confirm that all this is correct?

[yinanazhou]

Yes! Looks good!

[dchiller]

@kyrieb-ekat You maybe already have a way to easily solve this??

[kyrieb-ekat]

Yes! I put a thing together for changing all of the clef lines in MS73 (a little too early, alas), but it won't be hard at all to switch it around to change octaves. To be clear: do we want all octaves to get bumped up by one, c-clef octaves be bumped up by one, or only octaves currently 3 be moved up by one?Possibly stupid question, but just want to be certain. 😁

[dchiller]

I believe (and @JoyfulGen and @yinanazhou can confirm) that previously a c-clef was universally assumed to mark C4, when instead a c-clef (without any mark of transposition, which I have never seen in this repertoire) universally marks C3. So, any note whose pitch was determined in reference to a c-clef (any note after a c-clef and before another clef) needs to be moved up one octave. All clefs and any notes between a non-c-clef and another clef are fine as is.

Has your "thing" been committed anywhere yet?

[kyrieb-ekat]

Nope, I pulled the trigger on it before the MS73 files were processed (it lives here though); I just opened a PR with what I have right now, and with the test files I did (there should be a CH-E_611_094r.mei, a CH-E_611_094r.mei.updated1, and a CH-E_611_094r.mei.updated; .updated1 is because the location tracking was returning the wrong locations; both .updated and .updated1 are otherwise identical in content). Probably for the final commit removing the location tracking might be the move, as I really just used that so I could go double check stuff.

[JoyfulGen]

I believe (and @JoyfulGen and @yinanazhou can confirm) that previously a c-clef was universally assumed to mark C4, when instead a c-clef (without any mark of transposition, which I have never seen in this repertoire) universally marks C3. So, any note whose pitch was determined in reference to a c-clef (any note after a c-clef and before another clef) needs to be moved up one octave. All clefs and any notes between a non-c-clef and another clef are fine as is.

This is correct!

[JoyfulGen]

Woops, heads up, past me accidentally put some files with manually corrected C clefs into the https://github.com/DDMAL/e2e-omr-resources/tree/main/resulting_mei_files/Einsiedeln/Reviewed_once repo... so we have some unwanted dis="8" dis.place="above" tags floating around. Ick! The easiest solution I think would be to simply remove them. @yinanazhou, is this correct?

[dchiller]

Hmm.... so does that mean there are some files where we don't need to change the octave anymore?

Because #15 changes all components up an octave without checking whether or not it has already been corrected....so does that safeguard need to be added?

[dchiller]

The other thing complication is that in the folder https://github.com/DDMAL/e2e-omr-resources/tree/main/resulting_mei_files/Einsiedeln/Reviewed_once/updated_octave I think that @CThierrin had previously done 2 things with the Einsie files:

1. updated this octave of the c clefs (we don't want this)
2. updated the octaves of custodes (I think we still want this, right?)

And there are a bunch of Einsiedeln files that have a commit message "Clef octave not fixed".

So I guess I feel confused about which set of files in Einsiedeln should have the correction in #15 run on them? And do we need to make adjustments to #15 to also update the octaves of custodes?

The situation with Salzinnes is easier, I think, because previous corrections have not been done on them (We want to take all the files that are in Reviewed, make these octave corrections to both neume components and custodes, and then we're good)

[kyrieb-ekat]

Hmm.... so does that mean there are some files where we don't need to change the octave anymore?

So, the octaves in the files are still incorrect, they just have the dis="8" dis.place="above" added to the end (ex. <clef xml:id="clef-0000001615436604" facs="#zone-0000000770092529" shape="C" line="4" dis="8" dis.place="above" />). The ensuing items still have the old octaves: <nc xml:id="n1acfimi" facs="#z1ogi71" oct="4" pname="c" tilt="s" />.

I don't think it should be too hard to go through and just remove every instance of dis="8" dis.place="above", which should fix that issue. Can add this to #15.

updated this octave of the c clefs (we don't want this)

We might be able to go back through and only target the clef octave, without touching the elements inside the group?

updated the octaves of custodes (I think we still want this, right?)

If we do still want this, would the move then just to leave them be for now, and maybe circle back to snag them if we change our minds?

[dchiller]

I don't think it should be too hard to go through and just remove every instance of dis="8" dis.place="above", which should fix that issue. Can add this to #15.

I guess what I'm saying instead is do we just get rid of those files in updated_octave ... and start from scratch?