GENERAL DISCUSSION - VISUAL vs LOGIC in MENSURAL SIGNS (@sign.num/@sign.numbase vs. @num.ges/@numbase.ges)

[annplaksin]

Following our IG meeting on Thursday 18.11.2021, we narrowed the options down to two. I am trying to summarise the outcomes here and present the two options.

1. We don't solve the case of "Z" and restrict our solution to actual numbers. Encoding cases like "Z" (which is 3/2 drawn together) will be left to SMuFL glyphs, @altsym or @facs.
2. We still need a form to compute the semantic meaningful visual parts of a mensuration sign in addition to its interpreted meaning.
3. The solution should be renderable.
4. Rendering should follow a rule like:

   All attributes like @slash, @dot or @orient do always manipulate @sign.
   When there is @num and @numbase, render them stacked after the main sign encoded with @sign.
   @num alone follows the main sign.
   @numbase alone goes below the main sign.

5. There is a consent, that we need to fix the encoding of proportions as well. This topic is strongly connected but more complex, dealing with effects on particular note levels. This will be the content of another discussion. [adding the link to the other discussion as soon as it is there...]

Option 1: Using @sign.num/@sign.numbase

Adding new attributes on the visual side, as some sort of "sign data" and explaining, that this isn't meant to serve as a way to encode the meaning. @num/@numbase would be defined as attributes that contain the meaning of the sign, in terms of proportional duration manipulation.
The content would preferably be a positive integer, but then we need to think about the (not very common but existent) 15th-century cases like "O22" (Perfect major mode, imperfect minor mode, imperfect time, diminished twice, like <mensur sign=”O” sign.num=”2 2” modusmaior=”3” modusminor=”2” tempus=”2” num=”4” numbase=”1” />)

Here is a short and not exhaustive example to explain the intended usage:

• "3" as sesquialtera (3/2)...

<mensur sign.num="3" num="3" numbase="2"  />

• "3/2" as sesquialtera (3/2)...

<mensur sign.num="3" num="3" numbase="2"  />

Pro:

• This wouldn't change the treatment of partial imperfection which still uses @num/@numbase as attributes of <note>.

Con:

• This would make it necessary to encode both sets of attributes to ensure the rendering of the sign and resolution of a score; a bit redundant.

Question:

• Should we allow one or more positive integers (separated by spaces) as content?

Option 2: Using @num.ges/@numbase.ges

Using gestural attributes would conflate @num/@numbase more with the visual aspects. Adding gestural counterparts would allow encoding the meaning of the sign in cases it differs from the visual.
Both sets of attributes would need to contain positive integers only.

Here is the same short and not exhaustive example to explain the intended usage:

• "3" as sesquialtera (3/2)...

<mensur num="3" num.ges="3" numbase.ges="2"  />

or even

<mensur num="3" numbase.ges="2"  />

• "3/2" as sesquialtera (3/2)...

<mensur num="3" numbase="2"  />

Pro:

• We only need to use @num/@numbase if the meaning doesn't deviate from the sign. This would allow concise encoding.

Questions:

• Following the example, do we only need @numbase.ges in the case of "3"?
• How should be dealt with partial imperfection which still uses @num/@numbase as attributes of <note> as part of att.note.ges.mensural?
• How should be dealt with 15th-century cases like "O22"?

---

I hope I covered everything as good as possible, while adding a few questions that came into my mind while summarising this.
And as promised, I am trying to mention everybody that attended the meeting:
@martha-thomae @giulianodibacco @craigsapp @lpugin @ahankinson @pe-ro @davidrizo @karend27
If I accidentally forgot somebody, please add.

[martha-thomae]

Thanks, @annplaksin, for summarizing the discussion here. I am adding here another proposal that was discussed a bit on the music-encoding repo as another possible solution to handle visual vs. logical in addition to @sign.num/@sign.numbase vs. @num.ges/@numbase.ges: music-encoding/music-encoding#1015