annplaksin
commented
4 years ago Could you please answer me one short question:
Is this the expected positioning of the caret in a case of a nested variant?
Closed goursaud closed 3 years ago
annplaksin
commented
4 years ago Could you please answer me one short question:
Is this the expected positioning of the caret in a case of a nested variant?
JohannesTinctoris
commented
4 years ago Yes, the carets for all insertions into the music point downwards from one space above the staff. Carets for insertions into text and labels point upwards from the baseline of the text.
-jjd
On 23 Jul 2020, at 14:08, Anna Plaksin notifications@github.com wrote:
Could you please answer me one short question: Is this the expected positioning of the caret in a case of a nested variant?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
annplaksin
commented
4 years ago Okay, I know why the caret is positioned in the wrong place in that case, but it seems like this happens on purpose.
Maybe @DILewis could explain me, what MChoice.overPrevious() was intended to help with? Otherwise I will surely break something to fix this matter.
JohannesTinctoris
commented
4 years ago I'm not sure what's wrong where, but the horizontal position of the caret should be wherever the insertion is inserted (or begins, if it's more than a single symbol).
-jjd
On 24 Jul 2020, at 12:22, Anna Plaksin notifications@github.com wrote:
Okay, I know why the caret is positioned in the wrong place in that case, but it seems like this happens on purpose.
Maybe @DILewis could explain me, what MChoice.overPrevious() was intended to help with? Otherwise I will surely break something to fix this matter.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
annplaksin
commented
4 years ago I assumed the position of the caret is wrong here, according to Christian's description:
And the popup of the first variant looks kind of broken as well:
In the control example, where I only changed the S.c. to another note, the popup doesn't look broken and the caret is positioned where the insertion logically happens. This is the screenshot I shared above.
It seems like the different positioning of the caret as well as the "broken popup" has something to do with this function, because when I manipulate its return value, it looks like the control example... this is the only change in the positioning of the caret.
And it affects the popup as well.
So I was wondering, what originally has been intended with this function, because it only returns true if there is a fermata or an s.c. inside this variant.
(While I am writing this, I wonder if the only problem in that case is the nesting of the variants)
By the way, this is my test example:
<piece: {mensural: void}, {staf: 5, black}>
<part: 1><label>Control example</label>
{clef: C8} {solm: bb} {mens: O5 } BG SG .7 Sa BG <lig><obl>SG SF</obl></lig> SG .9 Sb Ba {var="SG {var=(ins.) "SF" Car} PS5 PS5" Luc Car edP : "PS5 PS5 SG" CS49 edF edB}
</part>
<part: 2><label>S.c. variant</label>
{clef: C8} {solm: bb} {mens: O5 } BG SG .7 Sa BG <lig><obl>SG SF</obl></lig> SG .9 Sb Ba {var="SG {var=(ins.) "?" Car} PS5 PS5" Luc Car edP : "PS5 PS5 SG" CS49 edF edB}
</part>
</piece>Right -- that position is all wrong; the caret for an inserted signum congruentiae belongs above the note it would apply to (the semibreve G), both in the main display and in the primary pop-up.
-jjd
On 24 Jul 2020, at 12:46, Anna Plaksin notifications@github.com wrote:
I assumed the position of the caret is wrong here, according to Christian's description:
And the popup of the first variant looks kind of broken as well:
In the control example, where I only changed the S.c. to another note, the popup doesn't look broken and the caret is positioned where the insertion logically happens. This is the screenshot I shared above.
It seems like the different positioning of the caret as well as the "broken popup" has something to do with this function, because when I manipulate its return value, it looks like the control example... this is the only change in the positioning of the caret. And it affects the popup as well. So I was wondering, what originally has been intended with this function, because it only returns true if there is a fermata or an s.c. inside this variant. (While I am writing this, I wonder if the only problem in that case is the nesting of the variants)
By the way, this is my test example:
<piece: {mensural: void}, {staf: 5, black}> <part: 1> {clef: C8} {solm: bb} {mens: O5 } BG SG .7 Sa BG
SG .9 Sb Ba {var="SG {var=(ins.) "SF" Car} PS5 PS5" Luc Car edP : "PS5 PS5 SG" CS49 edF edB} <part: 2> {clef: C8} {solm: bb} {mens: O5 } BG SG .7 Sa BG SG SF SG .9 Sb Ba {var="SG {var=(ins.) "?" Car} PS5 PS5" Luc Car edP : "PS5 PS5 SG" CS49 edF edB} SG SF — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
annplaksin
commented
4 years ago Okay, I might have found the problem:
var backtrack = curx -currentExample.events[eventi-1].startX;This backwards setting of the caret doesn't regard nested variants. This is the matter as well in the case of #12 after the parser problem has been fixed.
One question: would it be okay in the case of nested variants, where the nested one is an insertion, to have the caret just over the variant that contains the insertion?
JohannesTinctoris
commented
4 years ago That makes sense. This is often the accepted variant, so it would appear in the main text.
There's a functionality in the treatise interface, for music examples, that doesn't seem to exist in the music edition interface: when there is a nested variant within the accepted variant, that is shown in blue rather than green, and when the cursor hovers over the blue notation, both the main pop-up and the secondary pop-up pop up. As it is at present in the music edition interface, it's necessary to click on the main pop-up to make it persistent and then hover over the nested variant, which is less satisfactory.
On 24 Jul 2020, at 14:12, Anna Plaksin notifications@github.com wrote:
Okay, I might have found the problem:
var backtrack = curx -currentExample.events[eventi-1].startX; This backwards setting of the caret doesn't regard nested variants. This is the matter as well in the case of #12 after the parser problem has been fixed.
One question: would it be okay in the case of nested variants, where the nested one is an insertion, to have the caret just over the variant that contains the insertion?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
annplaksin
commented
4 years ago Okay, that sounds interesting... in fact it is available in the music editor, as seen in the screenshot of #16 Then I'll need to analyze how this is triggered exactely... or maybe I didn't see this earlier because the other issues deal all with nested insertions.
annplaksin
commented
4 years ago I think I solved it:
Please have a look at https://earlymusictheory.github.io/JohannesTinctoris/Tinctoris/editor/music/
<piece: {mensural: void}, {staf: 5, black}>
<part: 1><label>Nested S.c. variant</label>
{clef: C8} {solm: bb} {mens: O5 } BG SG .7 Sa BG <lig><obl>SG SF</obl></lig> SG .9 Sb Ba {var="SG {var=(ins.) "?" Car} PS5 PS5" Luc Car edP : "PS5 PS5 SG" CS49 edF edB}
</part>
</piece>
An inserted signum congruentiae nested within another variant displays its caret in the wrong place, differently in the main text and in the variant pop-up:
{clef: C8} {solm: bb} {mens: "O5" CS49 Car edF edB edP : (impl.) Luc} {var="BG SG" Luc CS49 edF edB edP : "BG." Car} <text>Agnus</text> .7 Sa BG <lig><obl>SG <text>de -</text> SF</obl></lig> SG {var=(ins.) ".9" Car} Sb Ba {var="SG {var=(ins.) "?" Car} PS5 PS5" Luc Car edP : "PS5 PS5 SG" CS49 edF edB} <text>i,</text>It ought to appear above the semibreve G at the end of the phrase, but in the main text it appears above the preceding breve a, and in the pop-up it is shoved some way to the right of the rest of the variant.