A fork of Gregorio to implement the Old Roman and Beneventan chant in square notation

[bbolognese87]

We started about a year and a half ago to implement the Beneventan notation, especially those glyphs that are used in the Old Roman repertory. Beside designing new glyphs which can co-exist with current fonts, and have them integrated in the current system, we would like to join the network of people studying ways to adapt the Gregorio package to the needs of the community of scholars, as we are carrying on our work and creating new graphic possibilities for the transcription of chants.

We currently have a fork of Gregorio, which works fairly well although the modifications that we have made to the main branch might be a little unpolished, and this is where we felt that we really needed advice from the main developers. Until this stage, we worked on a private repository, and before attempting to place a pull request we would like to try and streamline our integration, so that it fits more harmoniously with the rest of the code. For a number of reasons, we have kept the repository private, but would be glad to add any of the Gregorio developers as collaborators.

Our project has its own webpage, and the new glyphs are available at this repository, where you can find an example of a transcription produced with our fork.

We hope you might find our initiative worth of being considered in the main development branch of Gregorio.

[rpspringuel]

Where do you see these sitting in the font eco-system for Gregorio? Is this to be a supplemental font which necessarily requires the use of one of the existing fonts, or a font variant (like our Dominican font variants) which provides all the necessary glyphs?

Further (and related), what does your gabc notation look like for these new glyphs?

[aureliocarlucci]

Many thanks for your prompt response, @rpspringuel . My collaborator will reply concerning your main question, and in the meantime I would be happy to invite you as a collaborator to our repository, so you can have a look at our code. We tried to find a convenient gabc notation, but are happy to take up your expert advice about possibly more appropriate conventions.

[bbolognese87]

Hi!

1) My collaborator, who is the admin for the repository, just answered to the first part. In terms of font eco-system, we have a new font file, i.e. graeciliae_oldroman. sfd which contains our new glyphs together with the old ones and which was created by completely bypassing squarize.py.

2) As for the gabc file, here is how it looks like. We have assigned simple command letters that were unassigned before to our new glyphs. This corresponds to Example 1 in here:

(c3) Cir(fR3)cu(fST!gSH/hg/egf/e)i(gST!hSH)é(jiitHG)runt(htGF) sanc(g/itHGhf)ti(f) in(fh/ig!h@f) me(hg!hi)ló(i/hST!iSH!IHF!es)tis(ijiif) et(i/jtIHigF!es) pél(jo~)li(i)bus(hT!GF) ca(ef)prí(fhF!es/ij/iig/iV!hig)nis(ge) an(e)gu(htGF)sti(hg!hi/ih)á(g!hi/jo/i/ihi)ti(hg) af(itHG)flí(hji/itHG)cti(fST!gSH/hvGFE) qui(e)bus(h) di(i!j>)gnus(ih) non(itHG/hi/ih) e(hi)rat(ghf) mun(feg>)dus.(f) (::)

[rpspringuel]

Can you create a constructed example (both gabc and output) that shows just your new glyphs? Something like one of the tests in https://github.com/gregorio-project/gregorio-test/tree/master/tests/gabc-dump/glyphs? This makes it much easier to exam both the new gabc and the new glyphs by picking them out of the noise of the existing stuff which you're changes don't effect.

[aureliocarlucci]

Adding to the comment above by @bbolognese87 , the first step is where we would like to streamline our build process, before creating an official pull request. While we were aware of these instructions, during the initial development phase we elected to focus on the gabc parser and interfacing with the TeX compiler.

Given our scope, and the fact that the wider userbase might not require any Beneventan notation, we are unsure whether to propose these new glyphs as an addition to the existing font, or as a separate one.

[bbolognese87]

Here is the code, the pdf linked! Is this what you wanted to see?

(c3) (fT) (gT) (:) (hv!gT!FE) (::Z) (ft2) (gt2) (::Z) (ft3) (gt3) (::Z) (ft4) (gt4) (::Z) (fR2) (gR2) (::Z) (fR3) (gR3) (::Z) (fR4) (gR4) (::Z) (fU2) (gU2) (::Z) (fU3) (gU3) (::Z) (fU4) (gU4) (::Z) (fU5) (gU5) (::Z) (fST) (fSH) (gST) (gSH) (:) (fST!gSH) (gST!hSH) (::Z) (fQ) (gQ) (::Z) (fQ1) (gQ1) (fQ2) (gQ2) (:) (gQ1FE) (::Z) (fS2) (gS2) (fS3) (gS3) (:) (gvF!eS2) (gvF!eS3) (::Z)

[rpspringuel]

Close. Just make the lyrics for each syllable be the gabc code being produced. E.g. your first line would be (c3) fT(fT) gT(gT) (:) hv!gT!FE(hv!gT!FE) (::Z)

[bbolognese87]

Here! Hope it is better. As you see, we have just chosen random letters to assign to the new glyphs (not very elegant, I am afraid :D ) oh, and the first glyph that I have added of course exists by itself in the standard font file, but it has a command assigned now because we were not able to have it appear by itself or, e.g., at the beginning of a climacus (as it is very common in the Beneventan notation).

(c3) ft(ft) gt(gt) fT(fT) gT(gT) (:) hvgT!FE(hvgT!FE) (::Z) ft2(ft2) gt2(gt2) (::Z) ft3(ft3) gt3(gt3) (::Z) ft4(ft4) gt4(gt4) (::Z) fR2(fR2) gR2(gR2) (::Z) fR3(fR3) gR3(gR3) (::Z) fR4(fR4) gR4(gR4) (::Z) fU2(fU2) gU2(gU2) (::Z) fU3(fU3) gU3(gU3) (::Z) fU4(fU4) gU4(gU4) (::Z) fU5(fU5) gU5(gU5) (::Z) fST(fST) fSH(fSH) gST(gST) gSH(gSH) (:) fST!gSH(fST!gSH) gST!hSH(gST!hSH) (::Z) fQ(fQ) gQ(gQ) (::Z) fQ1(fQ1) gQ1(gQ1) fQ2(fQ2) gQ2(gQ2) (:) gQ1FE(gQ1FE) (::Z) fS2(fS2) gS2(gS2) fS3(fS3) gS3(gS3) (:) gvF!eS2(gvF!eS2) gvF!eS3(gvF!eS3) (::Z)

Glifi.pdf

[rpspringuel]

That makes it much easier to see what's going on and as a result I have some immediate comments:

1. fT: Is this an inclinatum version of the oriscus? If so it would make more sense for the gabc code to be related to the fo that generates the normal oriscus. Something like Fo or FO.
2. ft2 to ft4: to my eye these look like versions of go~ with extended tails. If that's the case I would favor notation like fo~2 to fo~4 with fo~1 and fo~ being equivalent (or maybe reduce all those numbers by 1 so fo~ and fo~0 are equivalent).
3. fR2 to fR4: same as previous except the base form is g>
4. fU2 to fU5: is this two notes? If so, the notation should reflect that by having two pitches in it (as opposed to a number). Further this looks related to gf~ or -fg (depending on note order).
5. fSH: again, is this two notes? Further, H is already used as a punctum inclinatum at the h position and should not feature here.
6. fQ2 looks like a horizontal mirror on f> and fQ1 is the same neume with a vigra attached. I think the gabc notation should reflect that.
7. fS2: how is this different from gs<?

As you can probably tell, my reactions are based almost purely on visuals. That's because I'm not familiar with how these variant glyphs would "sound" when sung. If they sound very different from existing notation that looks similar, then I have less problem coming up with completely new notation for them. Otherwise I think similar stuff should be notated similarly.

[bbolognese87]

That makes it much easier to see what's going on and as a result I have some immediate comments:

1. fT: Is this an inclinatum version of the oriscus? If so it would make more sense for the gabc code to be related to the fo that generates the normal oriscus. Something like Fo or FO.

It is, and what you say makes perfect sense. We are going to change it in this fashion.

2. ft2 to ft4: to my eye these look like versions of go~ with extended tails. If that's the case I would favor notation like fo~2 to fo~4 with fo~1 and fo~ being equivalent (or maybe reduce all those numbers by 1 so fo~ and fo~0 are equivalent).

It is true, it also makes perfect sense and we are going to change the notation according to this.

3. fR2 to fR4: same as previous except the base form is g>

Same as above.

4. fU2 to fU5: is this two notes? If so, the notation should reflect that by having two pitches in it (as opposed to a number). Further this looks related to gf~ or -fg (depending on note order).

This is two notes, and it very much related to gf~ (or ge~, whatever the pitch of the second note is) but it is without the vertical vitga sign on the left: there were graphic reasons, related to the notation, about the reason that was removed. But -fg is the symmetric version of it, so it is not related (also conceptually, one is a liquescent monosonic neume with added sound, the other is an initio debilis).

5. fSH: again, is this two notes? Further, H is already used as a punctum inclinatum at the h position and should not feature here.

eh, this is difficult. Let us say that fSH and gST (random pitches) together make up scandicus quilismaticus Beneventan style, so the union of the two is three sounds. Indeed, SH stands for "scandicus head" and "ST" for "scandicus tail". I know it was extremely inelegant to write it in this way, but we wanted to include the possibility that my head went up a third (and I think we might have that graphics somewhere as well but have not inserted it in Gregorio yet) and this seemed the fastest way, although probably the most inelegant. Plus, the first two sounds always appear to be consecutive in the manuscript I think, so there is no need of specifying the second sound as well. If you have a better suggestion on how to implement such a thing, please let us know.

6. fQ2 looks like a horizontal mirror on f> and fQ1 is the same neume with a vigra attached. I think the gabc notation should reflect that.

It is not precisely that, indeed that is one of those we have designed pretty much from scratch and not made by adapting a pre-existing glyph. But the second is the first with a virga attached, as you say.

7. fS2: how is this different from gs<?

It is slightly longer and thinner. If you believe the difference is not visible, we can also eliminate it.

As you can probably tell, my reactions are based almost purely on visuals. That's because I'm not familiar with how these variant glyphs would "sound" when sung. If they sound very different from existing notation that looks similar, then I have less problem coming up with completely new notation for them. Otherwise I think similar stuff should be notated similarly.

We have no idea in the world of how these sounded. The only thing one could reasonably do when trying to transcribe one of these chants in square notation is to be as close as possible to the actual neume, while leaving interpretation to semiology, when semiology is actually able to say something about it. So unfortunately we cannot name these glyphs based on that!

[rpspringuel]

More comments regarding the numbered variants: Are there rules that can be extracted for when one would use say fR2, fR3, or fR4? Something like: if the next pitch is down by x use fR2, if it's down by x+1 then use fR3, etc. If there are basic rules, then I would propose that the base version (g>) would be have an implementation of these rules and then the numbered versions would be overrides to force a particular shape (for the inevitable exceptions). We already do this sort of thing for positioning episema or selecting the inclinatum tilt, for instance. We can also fairly easily implement commands on the TeX side that effectively turn the rules off and always use a particular shape for scores not wanting this notation.

On multi-pitch neumes, I always favor having the involved pitches represented in the notation as clearly as possible. Even if a particular neume always involves consecutive pitches, I would like both of these pitches to be specified as that will make it easier for people who are less familiar with the notation to understand what is going on (and perhaps convert it to something they are more familiar with, even if that involves some interpretation of how to sing the neume that we aren't completely sure about).

Given the lack of sound information, I definitely favor using a principle of similar visuals means similar syntax. That'll make it much easier for users to be able to remember and predict what the notation they want is. If semiologists eventually come to a conclusion that things that look similar really were very different, then we can modify our notation at that point to reflect the new understanding.

[bbolognese87]

More comments regarding the numbered variants: Are there rules that can be extracted for when one would use say fR2, fR3, or fR4? Something like: if the next pitch is down by x use fR2, if it's down by x+1 then use fR3, etc. If there are basic rules, then I would propose that the base version (g>) would be have an implementation of these rules and then the numbered versions would be overrides to force a particular shape (for the inevitable exceptions). We already do this sort of thing for positioning episema or selecting the inclinatum tilt, for instance. We can also fairly easily implement commands on the TeX side that effectively turn the rules off and always use a particular shape for scores not wanting this notation.

Yes: if you go down a second it's 2, if you go down a third, it's 3 etc. As far as the R's go, it is an excellent question to understand whether it's one sound that slides down several pitches (at the moment, by looking at similar formulas of which one involves this type of liquescent and the other is not liquescent, this seems to be the case) or not. So I'd propose we do g>2, g>3 etc, so one does not specify the second pitch but rather "how much it slides down", if I am making myself clear.

On multi-pitch neumes, I always favor having the involved pitches represented in the notation as clearly as possible. Even if a particular neume always involves consecutive pitches, I would like both of these pitches to be specified as that will make it easier for people who are less familiar with the notation to understand what is going on (and perhaps convert it to something they are more familiar with, even if that involves some interpretation of how to sing the neume that we aren't completely sure about).

We'll try to implement that.

Given the lack of sound information, I definitely favor using a principle of similar visuals means similar syntax. That'll make it much easier for users to be able to remember and predict what the notation they want is. If semiologists eventually come to a conclusion that things that look similar really were very different, then we can modify our notation at that point to reflect the new understanding.

Sounds good.

Also, a question: we are actually working towards a pull request, as we said above. Should we have the documentation and everything else ready when we do the actual pull request?

Thanks!

[rpspringuel]

Your pull request need not be complete when you start it. Just make sure to mark it as a work in progress and indicate what still needs to be done.

[aureliocarlucci]

Great, many thanks. Given the official recommendations, which workflow do you suggest? Options that come to mind:

• submit a pull request for our current code into a new feature branch of the main repository, and keep working on that branch until ready for integration;
• polish and change our code a bit, eg implementing your suggested change of gabc syntax, and then do the above.

Many thanks again.

[rpspringuel]

I'll reiterate my previous comment:

Your pull request need not be complete when you start it. Just make sure to mark it as a work in progress and indicate what still needs to be done.

One advantage to an early PR, is that you can get more direct feedback on the actual code, and not just the results you've shared thus far.