Allow "2/" in time signatures

[ahankinson]

Extract from a conversation in Slack from @BaMikusi:

2/ (which, according to RISM Online, appears in the data 78 times) is of course fully okay, being just another way of saying c/.

Adding an issue to track the decision.

[ahankinson]

My take is that we should not allow 2/ -- this is already fully covered as c/ and as 2/2. PAE doesn't need to cover all possible variants of a written symbol, it only needs to ensure that the musical intention is captured.

So I'm 👎 on this change.

[lpugin]

2/ is actually fairly common. It is available in MuseScore, for example

I think it can stay allowed, but I do not have a strong opinion on this. One question: would you replace 2/ with 2/2 or c/ ?

[ahankinson]

Looking at PAE v1, It's hard to say if 2/ was ever allowed, since the control over what was allowed and what was not is lacking.

Currently in PAE v2 the only time a slash is used is to separate two numbers (2/2) or c/, or in Mensural notation to indicate diminution (o/, etc.). So 2/ is not allowed (currently).

c/ is "syntactic sugar" for 2/2, so either are OK, but generally it would be 2/2, I think.

If we do allow it, we should probably also allow 3/.

But, like I said on slack, this is only used 78 times out of almost 2 million incipits, so I personally think it hasn't really reached the threshold of use to qualify it as an addition to the spec.

[lpugin]

I agree it is simpler not to allow it.

[BaMikusi]

Having been away yesterday I must note that the discussion has in the meantime somewhat run in a direction I didn't mean to set. My suggestion was not to necessarily add this to the PAE spec, I merely wanted to raise the question whether it might be useful for Verovio to display 2/ when encountered in any sort of data (non-PAE included) as apparently MuseScore does.

Frankly, any effort to exactly prescribe what is a correct time signature is off the mark, for the contemporaries (especially with mensural stuff) already disagreed, and I don't see the point in adding 78 items to our 362,000 c/ incipits (which no one will ever want to look at as a coherent group), while keeping such less frequent options seperate and thereby visible should be helpful for both musicians and scholars. To my mind, merging such subtypes into the supposedly equivalent greater categories is a bit like saying that it is enough to listen to a single Bach cantata since the others sound just the same anyway. For 99% of mankind indeed, but for 99% of RISM users likely not, and that's the audience we should be keeping in mind when displaying our data.

[ahankinson]

Frankly, any effort to exactly prescribe what is a correct time signature is off the mark

That's not what we're trying to do. We're trying to prescribe the time signatures that are acceptable in Pliane and Easie, which is necessarily a very restricted subset of all music notation. Other formats, like MEI or MusicXML, can represent this time signature. I just don't see the need for it in PAEC.

and I don't see the point in adding 78 items to our 362,000 c/ incipits (which no one will ever want to look at as a coherent group), while keeping such less frequent options seperate and thereby visible should be helpful for both musicians and scholars.

Every musical piece has something remarkable about it. The question is where that uniqueness should be remarked. In my reading of it, the most important function of PAEC is to serve as a method of melodic identification, where one melody in one source can be corresponded to another in another source, so that concordances can be found across the entire RISM database.

This goal is made much more difficult if we then decide that the individual features of single items are to be encoded in such a way that makes their uniqueness more important than their group identity. If we're tailoring the PAEC encoding down to the particular habits of a single scribe in a single source, then it only serves to make cross-comparison with other instances of that source more difficult.

I understand that this time signature can be important to some. The question isn't whether it should or shouldn't be captured in the cataloguing process -- it definitely should be, if it is so remarkable. But that is not the same as having it formalized as a part of the Plaine and Easie Code.

[ahankinson]

Put another way: It is already really complicated to check what is an acceptable and an unacceptable time signature in PAEC and to write those rules. Shortcuts, like c and c/ are grandfathered in, but I see 2/ as merely a shortcut for 2/2 (and, by extension, 3/ is a shortcut for 9/8.) Given that we're trying to simplify and standardize, these sorts of expansions seem to me to be superfluous.

[BaMikusi]

I don't quite see to what extent some variance in the time signature would have an impact on comparing the melodic lines. Other than cases where the user starts to filter specifically for time signatures -- but then the specfic variant in the source could just become even more important.

Alternatively, if we really wanted to eliminate shortcuts, the logical conclusion would be to also merge c/ with 2/2, which are also 'the same,' and by the same token c and 4/4, etc. And then, in another field to be introduced anew, one could start registering the actual form as written in the source -- whereby we have many old (and indeed odd) source descriptions where (not knowing the context) we cannot tell what the rare variant given in the record might exactly be eqivalent to, not to mention that even with more recent records the cataloger might not necessarily have the expertise to identify a supposed equivalent, and so we are much better off having her/him reflect (as much as s/he can) what s/he sees. With which I merely want to say that it would be plainly impossible to entirely clean up the time signature field the way you would envisage, and so we should rather learn to live with some minor inconstistencies -- rather than start 'correcting' our data retrospectively (without sufficent knowledge of the sources and their context) in ways that would inevitably make it even messier as a whole.

BTW, even if we had two separate fields for 'standard' and 'in the source' time signatures, the display in our records should by no means show a 2/2 for a 2/ incipit, for RISM is describing sources, which should appear on the screen (as much as possible) as the cataloger saw them in the original. If the actual time signature cannot be displayed by Verovio, better not show any time signature, and leave it to the interested user to reconstruct from a note (perhaps to be added by a script for all non-Verovio-compatible time signatures?) what the original has than show an 'equivalent' made up by us in the office.

All of which is not to imply as if I didn't understand the restricted functionalities of PAE, but it is something quite different to omit a slur than to arbitrarily change such an essential and conspicuous feature as a time signature.