gabc header: handle transported modes

[eroux]

gabc header mode can now contain only one arabic number, but some pieces require to indicate that the mode is "transported". Quoting:

Each mode should finish with a fixed note: 1st and 2nd finish in D, 3rd and 4th in E, 5th and 6th in F and 7th and 8th in G. But in manuscripts sometimes this doesn't happen, and you can find, for example, a 6th mode that finishes in C: it's a 6th transported a 5th up.
This should be indicated because cantores must know what note is the first to start psalmic tone.

So maybe the convention (and the code) for mode header should be one arabic number + an optional t (ie: 6t)?

[henryso]

Currently the mode header is used for the first annotation (rewritten in Roman numerals) when no explicit annotation is given. Would 6t then show up as VI t. (or something) to indicate the transposed 6-mode melody, or would it still just show up as VI?

[eroux]

Good point, here it would appear in the annotation too, but not in the same style as the mode, it would be VI small caps and t in lower case italic (I think)... so maybe there could be a new style?

[henryso]

If we really want to be general about it, we could instead have an additional header, like mode-modifier which would accept any string and would output its string value in a separate style after the mode. This way, third-party software that happens to parse the mode header won't break. What do you think?

[eroux]

That's a more generic solution indeed, ok

[olivierberten]

I guess these should use mode-modifier:

[olivierberten]

Or should we add a mode-termination header since the Antiphonale Monasticum puts them all while most books don't, where a transposition should be displayed anyway.

And what about Tonus Peregrinus? And C,D,E modes? aren't they allowed anymore?

[olivierberten]

See http://forum.musicasacra.com/forum/discussion/9137/psalm-tones-besides-the-usual-ones

[rpspringuel]

The mode (and mode-modifier) field wouldn't work in these instances anyway because of the two annotation lines. mode only applies when there is no annotation field. If there is an annotation field than that becomes the ruling field (though it can be supplanted by an explicit call to \greannotation in the project document). To have two lines, as in these cases it is necessary to have two annotation fields:

annotation: 4 Ant.;
annotation: \textsc{vii} a;

[rpspringuel]

If one didn't want the first line of the above pictured annotations, then one could use the mode and mode-modifier fields as follows (for the first example):

mode: 1;
mode-modifier: g 2;

[olivierberten]

I'm thinking more about archival and automatisation: if one wants to store the piece in a database, he would add the office-part (antiphon), mode (7), mode-termination (a). If you want to use it in a service and use the Antiphonale convention, you could automatically put "4 Ant." (4th antiphon) as first annotation and "VII a" as 2nd annotation while the Liber way would be "4. Ant." and "7. a" and the Graduale does "Antiph." "7."

But it gets more complicated when you have both termination and transposition...

[henryso]

You can use the header capture feature to capture the headers and build the annotation in TeX in any way you like, or even push into Lua if it's really complex.

[olivierberten]

Another "funny" mode: t.irreg.

[olivierberten]

What I'm trying to explain is: if I want to automate booklet creation, I need standard fields. Can I do that with gabc or does it have to be sticked to a database? If D mode or Tonus Peregrinus aren't valid anymore, I can't use a generic booklet creation script, for instance. And if termination and transposition sit in the same header, I can't choose if I want only one of them, or even have them both together...

Needless to say that wasn't possible until now anyway... but if we try to improve it, why not try to have it a bit more complete ;-)

[henryso]

You can create any number of extended headers, capture them in TeX in any combination with the "standard" headers, and then do whatever you want with them in TeX/Lua.

[olivierberten]

So, are Solesmes Antiphonales so exotic they are not worth standard headers? ;-)

And do you also confirm one shouldn't put anymore any other mode than the 8 more common ones in the mode header?

[olivierberten]

I think I'm also a bit confused by the mix of metadata and "presentational" headers. Most headers are giving information about the score while annotations are purely for rendering intent. Not really sure they should be there at all...

[henryso]

Should I modify gregorio to take any name as a custom header? For backward compatibility, we could reserve some names for existing system headers and promise all new system headers will start with gregorio-. This way, all headers (like manuscript and office-part) that don't influence system behavior will be considered a custom header and the system header list can be reduced and be made less crazy to parse.

The mode header accepts a number from 1-8. Anything else will produce undefined behavior. How it got this way predates me. I've always used \greannotation (or its old form) from TeX for the text above the initial.

[olivierberten]

It might be the way to go indeed... Out of the 23 documented headers, only 6 do influence the rendering... and some of these were added rather recently... That said, there are already GregorioTeX functions to achieve the same result. So we might as well come back to a situation where none of the headers get used. I don't know anybody using Gregorio who's not customizing the main tex file anyway...

We might want to decide whether the intent of gabc format is first archival or rendering.

[eroux]

Well, this discussion is quite interesting, here are some insights:

• gabc headers were first thought as metadata with conventions (ie: mode in arabic number), so that it could be treated automatically by some analysis software or a database (such as gregobase)
• but they also contained some presentation (like annotation), so it's kind of a mix, just like gabc is

Personally, I think it's quite important to be able to differentiate the different modes in the gabc header, and if there was only one way to modify modes, a convention could be established in mode-modifier convention, but if there are several of them, it will just be confusing...

The ideal solution for me would be:

• standard metadata headers for the different mode modifiers in gabc (@olivierberten could you provdide us with a detailed list of the types and values?)
• a default handling on the TeX side that would just take all the modifiers (in a certain order) and typeset them as they are used now in mode-modifer (a solution based on \GreHeader), and this solution could be overriden by users who want to typeset them in a different way...

I'm no hardcore gregorio user, so feel free to discard my opinion!

What do you think?

[jakubjelinek]

For me too, if the headers can be easily queried from TeX or lua.

[henryso]

@jakubjelinek All the headers are now (in 4.1) passed from gabc to TeX. You can use the \gresetheadercapture command to send specific headers to specific macros.

[rpspringuel]

What is our policy on user-redefinition of GregorioTeX-supplied macros? It would seem most flexible to call \GreMode with three arguments, with the default being whatever we define here, but I know we've been moving to using styles instead of redefining macros for styling.

Personally I'm opposed to relying on people redefining commands to get something done. There's no way we can prevent people from doing it, but redefining commands requires some knowledge of the package's internals in order to avoid creating problems and thus should be reserved for advanced users. Common things which we expect novice users to want to customize should be provided with commands that allows them to that in a straight forward manner. That was the point of shifting to the style system.

Now, to what extent this qualifies as something particular to an advanced user or something a relative novice might want to do, I leave to others. I just wanted to weigh in on this aspect since the style system was my initiative.

[henryso]

@rpspringuel Given three inputs (this being the case here), I want to allow the user to order/omit them in any way they like. Do you have any suggestions for the best way to allow them to do this?

[rpspringuel]

There are just 6 ways to order 3 inputs when all are included. Adding the ability to omit some of them increases the number of possible cases a bit, but not beyond reason. A fairly generic internal using a \gre@count@modeorder flag to specify the order sequence and a \ifgre@showmodea, \ifgre@showmodeb, and \ifgre@showmodec boolean flags to specify which of the three should be shown would look like this:

\ifcase\gre@count@modeorder%
  %case 0 = abc
    \ifgre@showmodea...\fi%
    \ifgre@showmodeb...\fi%
    \ifgre@showmodec...\fi%
  \or %case 1 = acb
    \ifgre@showmodea...\fi%
    \ifgre@showmodec...\fi%
    \ifgre@showmodeb...\fi%
  \or %case 2 = bac
    \ifgre@showmodeb...\fi%
    \ifgre@showmodea...\fi%
    \ifgre@showmodec...\fi%
  \or %case 3 = bca
    \ifgre@showmodeb...\fi%
    \ifgre@showmodec...\fi%
    \ifgre@showmodea...\fi%
  \or %case 4 = cab
    \ifgre@showmodec...\fi%
    \ifgre@showmodea...\fi%
    \ifgre@showmodeb...\fi%
  \or %case 5 = cba
    \ifgre@showmodec...\fi%
    \ifgre@showmodeb...\fi%
    \ifgre@showmodea...\fi%
  \else\gre@bug...%
\fi%

One would then need at least 1, possibly 4, \greset... macros to change the flag settings.

However, I'm not sure that we need to be that generic here. It seems that there may be some reasonable rules which can be applied to these fields which reduces the number of cases. For instance, doesn't mode always come first?

[rpspringuel]

Oh, and it should be pointed out that if one wants the mode number to be in small caps, then the text representation should use lowercase roman numerals not uppercase (i.e. iii instead of III). Right now \GreMode uses uppercase, while the default style is for small caps. One of those needs to be changed.

[henryso]

The "down-casing" of the Roman numerals brings up an interesting problem: what if the user changes the style of mode to not use small caps?

[rpspringuel]

Well, if the user wants capitals but not small caps, they have a couple of options:

1. As I mentioned in New parameter initialraise #589, the answer to this question provides a method for creating a \ucshape command which can be used in place of \scshape in the style for the mode. This will force the Roman numerals to use regular uppercase letters.
2. I've recently discovered the environ package which provides an alternative syntax for defining environments. With this syntax it is possible to define a simple uppercasing environment as \NewEnviron{ucase}{\MakeUppercase{\BODY}}. This can then be used in the style definition for the mode to force the letters to uppercase.

We decided before not to include the \ucshape command in GregorioTeX (as being outside the scope of the package). Perhaps we should revisit that decision or at least include links in the documentation to these two options?

[henryso]

This comment is going to be a bit of a mess because I don't have it clear in my head, but here goes:

I was actually considering something like \ucshape, but, as you know, people do very strange stuff when you let them, so for example, let's say for whatever reason, they decide mode should be 6b. They don't want small caps, but rather that this be printed as VIb. Do we chalk stuff like this up to "use annotations, instead"? Further, since people typically see Roman numerals as capitals, might it be better to actually render Arabic numbers as capitals and then do the "down-casing" in the style (i.e., the opposite of \ucshape)? But then you'd run into problems where people want to render 6A as ivA in small caps.

The only "clean" answer I can come up with is to define \GreRomanI, \GreRomanII, and so on. Then have a macro which redefines these as lower case Roman numerals or uppercase Roman numerals or Arabic numerals, with the default being lower case Roman numerals meant to be used with the default small caps style (or perhaps upper case, for backwards compatibility). gregorio (the program) would translate any initial Arabic numerals to these macros before passing to \GreMode

Is that a bad idea?

[rpspringuel]

Hmm... I don't think that \GreRomanI etc. is the way to go (it just seems cumbersome), but the suggestion got me thinking of the \Roman and \roman command which LaTeX provides for formating counters. Some quick searching shows that these are based on the TeX primative \romannumeral which takes, surprise surprise, a numeric argument an produces the lowercase roman numeral equivalent (i.e. \romannumeral 3 produces iii). Perhaps then the way to do this is to not convert to roman numerals when passing to \GreMode but rather pass the Arabic number and then use a command TeX side to convert that to roman numerals on the spot (the primative for lower case, something based on it for uppercase).

[henryso]

How about this, then: if the first character of mode is an Arabic numeral from 1-8, it gets converted to \GreModeNumber{x} before being passed to \GreMode. Then we have a configuration that causes \GreModeNumber to convert it in some way. The implementation details can thus be left in TeX.

[rpspringuel]

I think that could work. It would require us to define one internal (a capitalizing equivalent to \romannumeral) and then have a setting which aliased \GreModeNumber to either our internal or the primitive (or \relax if the user wanted Arabic numbers for some reason) as desired. That's a whole lot less code for us to maintain and it should be fairly straight forward.

[henryso]

If I \let\GreModeNumber\romannumeral, when I try to use it as \GreModeNumber{6}, TeX tells me that the { is not a number, so I think we'll need to create a simple wrapper for lowercase Roman numeral.

[rpspringuel]

That's unexpected, but not a terribly big deal. Indeed, in some respects it makes things more consistent:

\def\gre@romannumeral#1{\romannumeral #1}%
\def\gre@Romannumeral#1{\MakeUppercase{\romannumeral #1}}%

[henryso]

Well, besides the fact that \MakeUppercase doesn't work in plain TeX, I'll be doing something like that.

[rpspringuel]

I forgot that was a LaTeX specific command. In that case what you need is \uppercase\expandafter{\romannumeral #1}

✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝
Br. Samuel, OSB
(R. Padraic Springuel)
PAX ☧ ΧΡΙΣΤΟΣ

On Jan 14, 2016, at 9:19 AM, Henry So [email protected] wrote:

Well, besides the fact that \MakeUppercase doesn't work in plain TeX, I'll be doing something like that.

—
Reply to this email directly or view it on GitHub.

[henryso]

As pointed out by @rpspringuel, we currently use bold and small caps (by default) for the mode number, but we are using upper case Roman numerals. What should I do about this? There are numerous options, but the two that seem most obvious (as also mentioned by @rpspringuel):

1. Keep using upper case, but only use the bold style for the mode number. This is the backwards compatible option.
2. Use lower case Roman numerals and continue to use bold and small caps for the default styling. This will break scores since the Roman numerals would then actually be in small caps. This might be a better expression of the intent of the styling that we have had in place.

Finally, how should the mode-differentia be styled? Just bold?

[eroux]

I think option 2 is better, but I don't have a very strong opinion, and bold seems fine for mode-differentia

[henryso]

N.B. I have changed my mind about implementing arbitrary ordering of the mode parts until someone actually asks for that feature. If implemented as specified by @rpspringuel, it seems a fairly compartmentalized change, but there's no need to implement stuff that no one will be using.

[henryso]

If anyone has any further comments on #785, please let me know; otherwise I will merge the pull request and re-close this issue tonight.