gregorio
gregorio copied to clipboard
gregorio-project
NABC+abovelinestext and NABC below lines
This patch (which depends on #1659) allows both above-lines text (alt) and NABC neumes to be displayed at the same time, and also allows a 2nd NABC voice to be printed below the lines.
New lengths for them are shown below:
Below-lines NABC is coded using existing support for multiple NABC voices. (g|pu|vi) is a g with a punctum above and a virga below. The font is set using \gresetnabcfont[2]{fontname}{fontsize}, and other styling by the style belowlinesnabc. (The style for above-lines NABC is still called nabc and not renamed to abovelinesnabc).
Questions
-
What should the defaults for the new lengths be?
-
In the existing setup, the above-lines things get two lengths, a "raise" and a "height", but the below-lines things get only one length, a "height". This patch continues the pattern. But if more control is needed, we could add lengths
belowlinesnabcdepth,textdepth, andtranslationdepth. -
The existing default for
additionaltopspacenabcthresholdis 4, which means that the above-lines NABC is almost never pushed up. So I did not bother implementing a corresponding threshold for below-lines NABC; the below-lines NABC is never pushed down. But if needed, we could addadditionalbottomspacenabcthreshold. -
Should the
nabcstyle be renamed toabovelinesnabc? Or let thenabcstyle apply to both voices, and add a new styleabovelinesnabcto apply just to the above-lines voice? -
Is there any desire for more NABC voices than this?
Closes #1559, closes #1645, maybe #1626.
What should the defaults for the new lengths be?
What are the values you used in the above sample image? They look reasonable to me, but I've never used the NABC features, so I'm probably not the best person to answer this question. @jakubjelinek and @lbssousa would probably be better equipped to know what is needed.
In the existing setup, the above-lines things get two lengths, a "raise" and a "height", but the below-lines things get only one length, a "height". This patch continues the pattern. But if more control is needed, we could add lengths belowlinesnabcdepth, textdepth, and translationdepth.
I don't think the depths are necessary. If someone asks for more control we can revisit that.
The existing default for additionaltopspacenabcthreshold is 4, which means that the above-lines NABC is almost never pushed up. So I did not bother implementing a corresponding threshold for below-lines NABC; the below-lines NABC is never pushed down. But if needed, we could add additionalbottomspacenabcthreshold.
The risk, I suppose, is that the below lines NABC and really low GABC neumes might end up overlapping and there would be no way to prevent that without additionalbottomspacenabcthreshold. How big a risk is that? Can anyone quantify it (or at least point to an example)?
Should the nabc style be renamed to abovelinesnabc? Or let the nabc style apply to both voices, and add a new style abovelinesnabc to apply just to the above-lines voice?
I like the idea of nabc applying to both and abovelinesnabc and belowslinesnabc applying to them separately.
Is there any desire for more NABC voices than this?
@jakubjelinek?
The defaults for the new lengths are
abovelinesnabcheight: 0.2.cm (lowered from the default abovelinestextheight of 0.3cm)
abovelinesnabcraise: 0.17351 cm (same as abovelinestextheight)
belowlinesnabcheight: 0.5cm (same as translationheight, seems maybe too much to me)
I like the idea of nabc applying to both and abovelinesnabc and belowslinesnabc applying to them separately.
Agreed, will do.
Here's @lbssousa's example from https://github.com/gregorio-project/gregorio/issues/1559#issuecomment-2727694195
Some of the near-collisions might be avoided by improving the horizontal alignment of the GABC and NABC.
Preamble:
\grechangedim{baselineskip}{90pt}{scalable}
\gresetnabcfont[1]{grelaon}{8}%
\gresetnabcfont[2]{gregall}{8}%
\grechangestyle{nabc}{\color{black}}
\grechangestyle{belowlinesnabc}{\color{red}}
The flipside of my question about the depths is, maybe above the lines we don't need both abovelinestextraise and abovelinesnabcraise. Maybe we only need abovelinestextraise above the lines, then (from bottom to top) abovelinesnabcheight, abovelinestextheight, spaceabovelines.
What should the defaults for the new lengths be?
What are the values you used in the above sample image? They look reasonable to me, but I've never used the NABC features, so I'm probably not the best person to answer this question. @jakubjelinek and @lbssousa would probably be better equipped to know what is needed.
I think it is important to keep the existing defaults (or something very close to them) for the single nabc line above score, there is already a lot of gabc out there with nabc around and any significant changes would mean people need to retweak a lot. For the above and below case, it would be nice if the defaults allowed something roughly in the Graduale Triplex style.
Is there any desire for more NABC voices than this?
@jakubjelinek?
I think it can be useful, but it is far less important than the one nabc above and one nabc above + one below cases. Multiple lines above could be useful for neume comparisons (e.g. in the http://gregorianik.uni-regensburg.de/an/#id/34 style).
The flipside of my question about the depths is, maybe above the lines we don't need both abovelinestextraise and abovelinesnabcraise. Maybe we only need abovelinestextraise above the lines, then (from bottom to top) abovelinesnabcheight, abovelinestextheight, spaceabovelines.
This makes a degree of sense, though we might then want to rename distances so that it's clear what the spaces are tied to (or not tied to). Stacking from the top down we might have:
abovelinesspace
abovelinestextheight
abovelinesnabcheight
abovelinesraise
abovelinesspace would be "always on" while the two heights would only be used if the element they correspond to is present and the raise would only be present if either of the heights was being used.
Something that just occurred to me, what about stacking order? #1626 shows a different stacking order than what is here. @jakubjelinek and @lbssousa is the relative order of NABC (both above and below) and above lines text, lyrics, and translations sufficient, or do you need to be able to control the stacking order?
the raise would only be present if either of the heights was being used.
That’s true, and I think that convinces me that both should have their own raise.
I added the abovelinesnabc style. But possibly, it should be nabc1 and nabc2 for consistency with the font and visibility options, and to leave the door open for more than two voices.
Something that just occurred to me, what about stacking order? #1626 shows a different stacking order than what is here. @jakubjelinek and @lbssousa is the relative order of NABC (both above and below) and above lines text, lyrics, and translations sufficient, or do you need to be able to control the stacking order?
Hmm... Good question. Since, until now, all the books published so far with triplex Gregorian notation mark the adiastematic neumes by hand, I believe we can now offer a new paradigm by placing the lower adiastematic neumes between the staff and the lyrics of the chant. In my view, it would be interesting to keep this stacking order configurable.
Don't the existing books put the adiastematic neumes between the staff and text? It would definitely be simpler if that was the fixed order.
Don't the existing books put the adiastematic neumes between the staff and text? It would definitely be simpler if that was the fixed order.
Nope. 1979's Graduale Triplex is just the exact 1974's Graduale Romanum (which is a photocopy of 1908's one) with adiastematic neumes drawn by hand. Recent book Graduale Novum also has adiastematic neumes drawn by hand in the same fashion of Graduale Triplex, but with a more comfortable spacing between staves. None of them brings adiastematic neumes between staff and text, mainly due to technical limitations.
I think, however, that future book which benefit from GregorioTeX could bring the adiastematic neumes between staff and text, now that it's technically possible.
BTW, could we propose a change in NABC syntax, introducing another delimiter to split NABC sections? It would make it easier to implement syntax highlighting in this case.
Example code (assuming & as such hypothetical delimiter):
Text(gabc|nabc1&nabc2|gabc|nabc11&nabc2|...)
Sorry, my fault. Both GT and GN do bring power adiastematic neumes between the staff and the lyrics. The approach proposed here is correct.
Enviado com Tuta; aproveite e-mails seguros e sem anúncios: https://tuta.com/free-email
4 de mai. de 2025, 23:02 por @.***:
davidweichiang> left a comment > (gregorio-project/gregorio#1662) https://github.com/gregorio-project/gregorio/pull/1662#issuecomment-2849736589
Don't the existing books put the adiastematic neumes between the staff and text? It would definitely be simpler if that was the fixed order.
— Reply to this email directly, > view it on GitHub https://github.com/gregorio-project/gregorio/pull/1662#issuecomment-2849736589> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/AAJX7XO5CTSP5WODXGOFCX3243BBTAVCNFSM6AAAAAB4IEJITGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBZG4ZTMNJYHE> . You are receiving this because you were mentioned.> Message ID: > <gregorio-project/gregorio/pull/1662/c2849736589> @> github> .> com>
Thanks @lbssousa -- do you also have a few minutes to edit your Tollite portas example (or another example)? It looks like some of the nabc neumes could be better horizontally aligned with the corresponding gabc neumes. That will be helpful for the documentation, the tests, and deciding what defaults are reasonable.
I added the
abovelinesnabcstyle. But possibly, it should benabc1andnabc2for consistency with the font and visibility options, and to leave the door open for more than two voices.
While I'm all for consistency, nabc1 and nabc2 are so much less descriptive than abovelinesnabc and belowlinesnabc that I think that the consistency should probably go in the other direction.
Actually, now that I think about it, maybe they should be aliases? above as an alias for 1 and below as an alias for 2. This way there is a natural way of thinking about it in the most common cases (only 1 or 2 nabc voices), but we leave the numbering system in tact should additional nabc voices ever be added.
The risk, I suppose, is that the below lines NABC and really low GABC neumes might end up overlapping and there would be no way to prevent that without additionalbottomspacenabcthreshold. How big a risk is that? Can anyone quantify it (or at least point to an example)?
The additionaltopspacenabcthreshold was discussed in #1153 and refers to an old discussion https://www.mail-archive.com/[email protected]/msg03567.html which actually has quite a few relevant pieces of information and suggestions.
-
The nabc pitches are 1/4 the height of the gabc pitches, which suggests that both above and below the staff, the nabc neumes should be pushed up 3/4 as much as the gabc neumes go above/below the staff.
-
That thread envisioned a system where the gabc file could have three or more voices, but each one could be separately turned on or off and placed above or below the staff.
BTW, could we propose a change in NABC syntax, introducing another delimiter to split NABC sections? It would make it easier to implement syntax highlighting in this case.
I would submit that as another enhancement request.
I suggest deferring additionalbottomspacenabcthreshold until people have a chance to work with this code and identify what is needed. (There are also a number of tangential issues that I think are worth discussing separately.)
Regarding numbers versus above/below, I think the argument in favor of numbers is that the voices are implicitly numbered in the .gabc file (by their ordering). There was a suggestion in that old email thread to allow \gresetnabc{1}{above} or \gresetnabc{1}{below} to choose the positioning of each voice. I think that would not be hard to implement in this PR, as long as we could disallow (for now) positioning both voices above or both voices below. In such a setup, it certainly makes sense for the font to stick with the numbers rather than the position, and I think (but am not sure) that it makes more sense for the styles to stick with the numbers rather than the position too.
Thanks @lbssousa -- do you also have a few minutes to edit your Tollite portas example (or another example)? It looks like some of the nabc neumes could be better horizontally aligned with the corresponding gabc neumes. That will be helpful for the documentation, the tests, and deciding what defaults are reasonable.
Let me know if this one seems better:
name: Tollite portas;
annotation: Offert.;
annotation: II;
nabc-lines: 1;
%%
(f3)
Tol(ce/fgf|peGlsa6tohl|toppt2lss2lsim2)li(f|un|ta)te(f|un|ta) *()
por(f!gwh/ih/hf/fe~|qlppn1//pf2``vi>1lsm2|`````talse4qlhhclShi//clhi//st>hi)tas,(f|un|vi) (,)
prín(f/hhh|unlst8//tshi|```vi-lse4//tshi)ci(h|un|ta)pes,(hji|/to|//tolss2)
ves(ih/hh/hvFE/f!gwhf|//clhh////ds1////cl`unhalsa2////qlppn1sun1|/cllss2///bv///ciS1lse2////taqlhh!clhh)tras:(f|un|ta) (:)
et(fge|/tolsh9|``toM1lse4lslm2)
e(h|un|vi)le(hif|/tolsh9|``toM1lse4lss2)vá(hhh/jvIH/hvGF|//tslst2///puhjsu1sun1////////puhgsu1sun1|///ts-///ciSlss1lsc2///cilsc2)mi(gf|or|cl)ni,(f|un|ta) (,)
por(f!gwh/ih|qlppn1cl>1ltsj6|//cl>hhlss6)tæ(f|un|ta)
æ(hfhh|polsa6orhj|//cllss2vs-)ter(ef|peG|pe>1)ná(kxhi!kvJI|////peGhjpuhksu1sun1|//cihjppt2lss7)les,(ih|clG|/cl-) (:)
et(hf|clG|````cl-lse4)
in(hi|pe>1|pe>1)tro(ih|clG|/cl-lss2)í(hf!ivHGF|/clhipuhjsu2sun1|posu3lsl2lse4)bit(fhffe|//peGpuocGlsa5|````peSlse4//pr-hg) (;)
Rex(ef!hhi|peGunhllsa2peGhl|`vi-ppt2lss2/pqhm)
gló(kx?j/kvIH|////////unpuhksu1sun1|////////vi-lsl2cilss2)ri(hg|clG|````cl-lse4lsal9)æ.(hh/hf|//tssun1lsa5|///ds//cl-) (,)
(h/ih/hh//hh/hf/gxdxih/gge/ih/hh/hd/ev|vi//cllsn9///ds1hh////pflst6pupfhdlst6ds1hd/visun1lsh8viSpeG|vi-/cllss2/////ds////ds/cllse4///////////clS////tglsi1////clSlsm2////dslse2////cl-/vi-) (::)
Instead of using the /s, can you do something like (gabc1|nabc1|nabc1|gabc2|nabc2|nabc2) to do the alignment?
Instead of using the
/s, can you do something like(gabc1|nabc1|nabc1|gabc2|nabc2|nabc2)to do the alignment?
Not in this example, because the Laon neumes and the SG ones don't always match the same exact GABC segment.
Example: in the first word "portas", attached to syllable "por", you have two GABC segments (ih and hf) which matches a single Laon neume (pf2), and two SG neumes (cl and cl).
A better approach is proposed in issue #1665.
OK, leaving aside the /'s and `'s for now, does the example look right now? Is there maybe something missing at the very end of the nabc above?
Should the nabc below be moved up, closer to the staff?
OK, leaving aside the /'s and `'s for now, does the example look right now? Is there maybe something missing at the very end of the nabc above?
Yes, there should be something missing in the Laon neumes. Look at this excerpt from Graduale Triplex:
Should the nabc below be moved up, closer to the staff?
I think it could be moved a little bit lower, because it's still overlapping the staff at some points (ex.: first syllable in "Tollite", the word "Rex" in "Rex gloriae")
In the GT the neumes often overlap the staff, but is that something not desirable for new scores? I can increase nabcbelowlinesheight from 0.5cm to 0.6cm.
In the GT the neumes often overlap the staff, but is that something not desirable for new scores? I can increase
nabcbelowlinesheightfrom 0.5cm to 0.6cm.
This is because the ancient neumes were drawn by hand directly on 1974's GR, which is a photocopy of 1908's GR, so that's no reserved space for those neums.
In Graduale Novum (2011, 2018), there's a large space between staves and lyrics baselines, so that the ancient neums can be drawn by hand with no overlapping.
Here's nabcbelowlinesheight = 0.6cm.
The default abovelinesnabcraise is set to be the same as the default abovelinestextraise, to avoid breaking existing scores. But the neumes above do overlap the staff in some places.
If there's anything that needs to be changed in this PR. please let me know!
It's OK for me. My other demands are being already handled in other issues. If Gregorio maintainers have nothing more to say, I think this PR could be merged as is.
The only thing remaining for merge is checking the change against the test repository and creating a new test which shows the feature in action. I've started the former (though others may want to check it on their own machines). For the latter, the most recent example whose output was posted here would make a good candidate for the new test.