Discussion: what to do with a neume in between two neumes that are the same syllable

[JoyfulGen]

This situation came up in a discussion with @annamorphism and Phoebe in Halifax. It has to do with a "syllable sandwich": a neume between two neumes that are the same syllable. It's not an actual bug, but it did create confusion, so I thought I'd share the discussion to see if something should be done about it, or not! @yinanazhou your wisdom is particularly needed.

Here's the situation: In Einsie 118v (mei file below), in the neume highlight, there are two neumes next to each other that are both blue (we'll call them 1 and 2), so they look like they're one neume:

However, they're not one neume. You can select one, and the other won't get selected. This means that you can't ungroup them, because they're not grouped in the first place. The reason for this is that that staff contains a very long pink syllable:

Neume 1 is part of the pink syllable, but neume 2 is not, so neume 2 appears after all the neumes of the pink syllable in the MEI. This is why they're the same colour: in the MEI, neume 2 appears a whole colour cycle after neume 1.

The "fix" is simple: ungroup the pink syllable and the order rights itself automatically. However, if a user knows about the colour system (as is ideal!), it's confusing if neume colours appear wrong.

The way this happened in the first place is this:

• Pick a long syllable
• Add a punctum to a neume within that syllable
• Group neume and neume components
• That neume will automatically be removed from the syllable.

This is what creates the syllable sandwich and subsequent colour confusion. I have two questions about this:

1. Should something be done about this at all? As I said, it's not a bug at all and Neon's logic is impeccable, so it could be left as is, with a warning or something.
2. If something is done, then what? Maybe the automatic-removal-of-neume-from-syllable could be abolished? But that sounds pretty significant.

All thoughts welcome!

118v neume order confusion.mei.zip

[yinanazhou]

I can certainly remove the automatic-removal-of-neume-from-syllable function. What do you think @annamorphism ?

[annamorphism]

Hmmm...I am trying to think of situations where I do want this behaviour and how they stack up against those where I might not, like the above. It seems to me that if you are inserting a note into the middle of some long syllable you probably would want it to stay part of that syllable most of the time, right? Or does that introduce something weird?

I am not sure this really solves the problem/confusion that started this thread though. If the user inserted Neume 2 themselves, they (theoretically) already know that it's separate from Neume 1; and if the MEI file had it that way already, then Neon's warnings when you insert a neume into a syllable won't help them, because they didn't cause it. I'm inclined to leave as-is, though I recognize it has the potential to cause confusion.

[yinanazhou]

It seems to me that what causes confusion is that when the user inserts a neume (syllable), and groups the new neume (syllable) and a neume already in the long syllable, the latter one automatically gets removed from the syllable, and forms a new syllable. I can add a check so that if the neumes are not in the same syllable, they cannot be grouped. In this way, the user will have to merge the two syllables first, and then group neumes. What do you think @annamorphism and @JoyfulGen ?

[annamorphism]

The problem I foresee is that sometimes you are in a scenario where you are adding a neume onto the end of an (incorrect) long syllable, and you might not want to have to group and ungroup again. For example, suppose the neumes/neume components should group (pppqqqq)(ww) (where the parentheses denote syllables) but the output you are correcting is (pppqqqqq.) Right now you add in w, split the q neume, and group the neume/neume component with the last q; this gives you the desired (pppqqqq)(ww) in four steps. With the check you would (I think) end up having to merge syllables and split after: (pppqqqqq)(w)-->(pppqqqqqw)-->(pppqqqqzw)-->(pppqqqqww)-->(ppp)(qqqq)(ww)-->(pppqqqq)(ww), which is two extra steps (unless there is a better solution? I'm out of practice) It does avoid the confusing situation above, but my instinct is that the situation of it being mildly inconvenient would outweigh the ones where it is significantly more convenient/less confusing, just because having to create a new syllable at the end of something is more common than inserting a neume into a really long syllable. @JoyfulGen would know much better than me, though...

[JoyfulGen]

I agree with @annamorphism that having to group a component with the entire syllable before grouping it with a neume would be inconvenient. The main issue I perceive is that the user needs to be in the neume highlight to group neumes properly. To group a new component with the syllable first, the user would have to go back and forth between neume and syllable highlight while correcting neumes, which would take more time.

@yinanazhou, would it be possible to try removing the automatic-removal-from-syllable function? I honestly can't predict exactly how it'll affect correction, but I'd be super curious to see. Is this possible without too much trouble?

[yinanazhou]

I've tested a bit about removing the automatic-removal-from-syllable function. I notice that in this way, there is no option left for neumes. The user can select two syllables and merge syllables, and select neume components to group them into a neume. Does it make sense that if the user select two adjacent neumes in the same syllable, Neon provides an option to group these two separate neumes into one? Please let me know what you think @annamorphism and @JoyfulGen

[annamorphism]

I think the logic seems sound! I'm not sure it won't remind us of an earlier version of Neon where grouping was more restrictive, but we'll see.

[JoyfulGen]

@yinanazhou I'm confused now... If the neume selector has no use anymore, then we're back to the issue where grouping a neume component with an entire syllable is overly time-consuming. Would it be possible to still use the neume selector to group a new neume component to a neume like before, with the difference that that neume stays within its syllable? Or does that break things?

[yinanazhou]

@JoyfulGen there might be some misunderstanding. So now, if we have syllable A with neume B and C, and syllable D with neume E and F, the user can group neume C and E, resulting in syllable A with neume B, syllable G with neume C and E, and syllable D with neume F. If we remove the function, this will not be possible. Instead, the user can group neume B and C into a new neume G. In the case you mentioned, it will be possible because a single neume component itself is also a neume.

[yinanazhou]

Found these related issues: #938 and #946

[annamorphism]

My turn to be confused...

Would it be possible to still use the neume selector to group a new neume component to a neume like before, with the difference that that neume stays within its syllable?

@JoyfulGen you're talking about a newly added neume/neume component that lives in its own (new) syllable, right? If so, how do we know which syllable is the one that needs to stay and which one needs to go? (I mean, I know how you and I know, but how does Neon know?)

[yinanazhou]

In the case of a newly inserted neume component, the user will need to first merge it into the target syllable, and then group it with the target neume using the new group-neume button. Does this make sense?

[yinanazhou]

Hi @JoyfulGen I've pushed the temporary changes! Please let me know how you like it. If it works well, I will further optimize it verovio.

[JoyfulGen]

@yinanazhou I've tried the temporary changes for a while and had a chat with @annamorphism and Halifax Phoebe. We think that even though these changes make semantic sense, they're adding to correction complexity and time. Would it be ok to undo the change?

We were trying to think of an alternative solution and we wondered if this would work: when the user adds a new glyph to a page and that glyph is in the middle of a syllable, the syllable splits in two. This would avoid the whole syllable sandwich situation and also ensure that the colour order is always correct.

[yinanazhou]

Hi @JoyfulGen and @annamorphism, I've reverted the changes about neume grouping.

The alternative solution is definitely doable, but I'm worried that Neon shouldn't do anything without the user's permission. I can try to add a notification to the user saying they are inserting a glyph in the middle of a syllable, and warn the user that the color might be wrong. What do you think?