New: Add division element to neumes module

[fujinaga]

The division element is currently missing from the neumes module. These symbols look like barlines but have a function similar to breath marks and rests, with no specific duration.

The lilypond documentation gives some examples of divisions: http://lilypond.org/doc/v2.18/Documentation/notation/typesetting-gregorian-chant#divisiones

They are also available as SMuFL symbols here: https://w3c.github.io/smufl/gitbook/tables/medieval-and-renaissance-staves.html

[rettinghaus]

I'm not against it, but why has this to be a new element? Couldn't rest be used with these additional values?

And <memberOf key="att.color"/> is missing.

[ahankinson]

They aren't quite rests; they mark out sections as well, and give indicators of phrasing and breaths. So their functions are part rest, part articulation, and part form.

[rettinghaus]

I'm aware of this, and probably it's best to introduce a new element for this.
But let's not use a modern english term, but use <divisio>(without the "n") instead, which seems to me to be more consistent within this repertoire. Otherwise people may confuse it with the <div> division.

[ahankinson]

The name of the element is consistent with the names given in the Liber Usualis

[rettinghaus]

That is a non-argument, as the allowed values in type are not major, minor, small, and final.

[ahankinson]

Hm. Perhaps they should be?

[rettinghaus]

Also I'm strongly against using @type to record meaning / visual appearance (see att.typed).
I'd prefer @form as part of att.divisio.log, as we use it for turns and mordents (see att.turn.log and att.mordent.log).

[ahankinson]

That's a great suggestion, and I agree

[kepper]

A lot of discussion has happened in #625, and I'm not sure the Neumes IG has given feedback to that. I believe a consensus is possible, since to me, it seems mostly a discussion on the names of things, but that consensus hasn't been expressed so far. I'm aware that it might be late to get this resolved for today's ODD Friday, but there's a final opportunity on November 29. May I ask @fujinaga, @ahankinson and @rettinghaus to revise the situation? It seems the Neumes IG has done its work, and we should get their changes into the schema now… Thanks everyone :)

[martha-thomae]

Do you mean October 29th, @kepper ?

[martha-thomae]

I don't think it is a good idea to call the element "divisio" because in the mensural module we already have a "divisio" attribute. In the case this attribute eventually gets promoted to an element, then we will have some conflicts between both modules.

I just spoke with @fujinaga and he says he doesn't care about the naming ("divisio" or "division").

[fujinaga]

@kepper So this original #618 can go ahead with the name "division".

[craigsapp]

I don't think it is a good idea to call the element "divisio" because in the mensural module we already have a "divisio" attribute. In the case this attribute eventually gets promoted to an element, then we will have some conflicts between both modules.

That is a good reason to avoid "divisio". Orginally there was a complaint that "division" is English and most terms in the old-music modules were in Latin. At the neume special interest group in May, a counter-complaint was that using "divisio" is proleptic, meaning that there is no documented name for these symbols, so creating a retrospective Latin name for them would be strange.

Another original complaint is that "division" is close to div and mdiv, so readability confusion can be caused by using a similar term for something with a very different function.

You might want to consider a more graphical description of the symbols, such as <vertical-line> or <vline> or <divLine>, since it is graphically a vertical line.

To match the symmetry with <barLine>, I would suggest the last one: <divLine>. This unites the strong graphical implication of such an element with its function.

[craigsapp]

I just spoke with @fujinaga and he says he doesn't care about the naming ("divisio" or "division").

I don't think so:

@kepper So this original #618 can go ahead with the name "division".

But you should wait to discuss the pluses/minuses of <division> versus <divLine> first.

[fujinaga]

I'm fine with .

[martha-thomae]

Sorry for closing, it was an accidental click.

[craigsapp]

You need to escape the angle brackets, otherwise no one knows if you voted for <division>, <divisio> or <divLine> 😉

To do that add backticks around the element name in brackets:

`<element>`

[fujinaga]

Sorry, I’m fine with divLine. Ich On Oct 22, 2020, at 15:58, Craig Stuart Sapp <notifications@github.com<mailto:notifications@github.com>> wrote: [Screen Shot 2020-10-22 at 12 57 47 PM]<https://user-images.githubusercontent.com/3487289/96923481-339bcb80-1466-11eb-8db5-eef6d7ca9240.png> You need to escape the angle brackets, otherwise no one knows if you voted for <division>, <divisio> or <divLine> 😉 To do that add backticks around the element name in brackets: `<element>` — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#618 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAH342OUDJQKBFI5UKCQAOLSMCFHDANCNFSM4IZEIZLA>.

[craigsapp]

This element would also be useful to extend into the CMN module, for cases where the music has barlines, but they do not imply meter. A good example of this is Charles Ives' second piano sonata:

https://petruccimusiclibrary.ca/files/imglnks/caimg/9/9f/IMSLP03928-Ives_-_Piano_Sonata_No2_%27Concord%27.pdf

Lots of places, but here is a specific example from page 55 of the PDF (or page 57 of the printed edition):

In this case the barlines are functioning as phrasing slurs, similar to the vertical lines in chant notation, and there is no implied metricness to these lines.

[kepper]

The argument to not use "divisio" is compelling. The decision wether it should be called "divLine" or "division" should be taken by the IG. Just for the record: I have some sympathy for "divLine", but let's see what the discussion during today's ODD meeting will bring…

[kepper]

the only thing that's left to decided seems the name, with the two options "division" and "divLine" being under consideration. That should be decided (and fixed, if necessary) today, and then things can be merged.

[kepper]

Hi @fujinaga, during today's ODD Thursday, we decided to go with <divLine>(thanks @craigsapp for that proposal). Could you please update your PR accordingly? In addition, could you rename the attribute @type to @form, as the first is a generic mechanism in MEI, and we try to keep it free from specific meanings in different contexts (not always to great successful). Also, please add membership to the att.color class… 

[kepper]

Hi @fujinaga, thanks for addressing this so swiftly. Two more minor queries, though: Could you please sort the class memberships alphabetically, and also the values of the @form attribute? Thanks very much :-)

[kepper]

wonderful 👍

[kepper]

thanks to @fujinaga and the whole IG for the continued work on this, and the endurance to get it into the specs ;-)

[fujinaga]

Thank you!

…

On Oct 29, 2020, at 9:16 AM, kepper ***@***.***> wrote: thanks to @fujinaga and the whole IG for the continued work on this, and the endurance to get it into the specs ;-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[craigsapp]

🥂