Closed goursaud closed 3 years ago
It looks like the fermata as single sign inside a variant cannot find its preceeding element, even if it doesn't follow another variant.
Is there an indespensable reason to put the inserted fermata into its own variant?
You could as well do it like: {var="md" CS14 CS49 edF edB : "md*" Luc : "mc" Car}
In the case of an added fermata it would be as well {var="md" X Y : "md*" Z}
It is of course a different approach, but you could think about doing it like that... or is there anything that speaks against this workaround?
I know the workaround you suggest does work, but it's not ideal. I've been trying to include in variants only the things that vary, and to distinguish the original copying from processes of correction or addition. In this case, the original copyist of Luc wrote md along with CS14 and CS49, and the fermata was added as a correction -- and I want to be able to indicate that. If I were to give (simplifying)
<piece: {mensural: void}, {staf: 5, black}> <part: 1> {var="md" Luc CS14 CS49 : "md*" Luc^c}
it would be indistinguishable from a case where the corrector erased the original minim and wrote another with the fermata. Analogous cases to this do occur, which is why I want to be able to distinguish them. Does this make sense?
An alternative (probably better) way to tag this might be
<piece: {mensural: void}, {staf: 5, black}> <part: 1> {var="md{var=(ins.) "*" Luc^c}" Luc CS14 CS49 : "mc" Car}
but I don't think that was working either, probably because the insertion is nested within another variant.
I'm guessing that what's happening here is similar but not identical to what happens with signa congruentiae when they cause trouble in variants and ligatures -- the resulting behaviour isn't quite the same. Probably the code isn't quite the same, but it probably ought to be, since both fermatas and signa congruentiae behave the same way notationally. (Tinctoris, FWIW, treats them both as special kinds of dots...)
Thanks, Jeff
On 25 Jun 2020, at 12:05, Anna Plaksin notifications@github.com wrote:
It looks like the fermata as single sign inside a variant cannot find its preceeding element, even if it doesn't follow another variant.
Is there an indespensable reason to put the inserted fermata into its own variant? You could as well do it like: {var="md" CS14 CS49 edF edB : "md" Luc : "mc" Car} In the case of an added fermata it would be as well {var="md" X Y : "md" Z}
It is of course a different approach, but you could think about doing it like that... or is there anything that speaks against this workaround?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Okay, so the ^*
or ^c
indicates another scribal state within a source. Now it starts to make sense... I was already wondering about these sigla.
Then it makes perfect sense to indicate these states. This is why I asked.
In this case, it would be preferable to use nested variants because it gives a better chance to relate the items to each other.
But yes, this isn't working yet either.
In that case, it seems like nested variants are a very useful feature. I will look into the parser to see how this can be solved... but the rendering would be a different issue.
Nested variants in the music do work a lot of the time. There are just a few things that break them like this. At the moment nested variants in
On 25 Jun 2020, at 13:06, Anna Plaksin notifications@github.com wrote:
Okay, so the ^* or ^c indicates another scribal state within a source. Now it starts to make sense... I was already wondering about these sigla. Then it makes perfect sense to indicate these states. This is why I asked. In this case, it would be preferable to use nested variants because it gives a better chance to relate the items to each other. But yes, this isn't working yet either.
In that case, it seems like nested variants are a very useful feature. I will look into the parser to see how this can be solved... but the rendering would be a different issue.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
It is indeed necessary for a fermata to know to which note it belongs. This is the reason why the parser breaks... not just in case of nested variants but in any case where a single fermata is the content of a variant.
Therefore it is necessary to construct an elaborate method for a fermata to find its associated note even on a different level of hierarchy.... kind of a tricky task, as it seems that the fermata doesn't know its parent when it is parsed... Possible solution: make sure contents of readings know their parent reading and then working on another function to find an associated note, if there isn't one just before rendering... (Note to myself...)
It seems like I was finally able to solve the problem:
If you would like to play around with it, use https://earlymusictheory.github.io/JohannesTinctoris/Tinctoris/editor/music/
<piece: {mensural: void}, {staf: 5, black}>
<part: 1 >
<label>Check single variants</label>
{clef: C8} Bd Bd md{var=(ins.) "*" Luc^c} Bd Bd md{var=(ins.) "?" Luc^c} md{var=(ins.) "." Luc^c}
</part>
<part: 2 >
{staf: 5, black}
<label>Fermata breaks parser #12 -- nested variant approach</label>
{clef: C8} Bd Bd {var="md{var=(ins.) "*" Luc^c}" Luc CS14 CS49 : "mc" Car} Bd {var="md{var=(ins.) "?" Luc^c}" Luc CS14 CS49 : "mc" Car} Bd {var="md{var=(ins.) "." Luc^c}" Luc CS14 CS49 : "mc" Car}
</part>
</piece>
An inserted fermata following a variant breaks the parser:
`<piece: {mensural: void}, {staf: 5, black}> <part: 1> PL7-9 {var=(ins.) "bbb" CS14^*} maa
`