[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-user
Subject:    Re: aligning melisma and non-melisma lyrics across staves in the same system
From:       Thomas Morley <thomasmorley65 () gmail ! com>
Date:       2015-11-30 23:47:27
Message-ID: CABsfGyVfp_Jvy3+CYBozMKpupTQuoXPgUGana_aJ4nYdEFZpbg () mail ! gmail ! com
[Download RAW message or body]

2015-11-28 23:54 GMT+01:00 Kieren MacMillan <kieren_macmillan@sympatico.ca>:
> Hi Thomas,
> 
> Thanks for the detailed and helpful response!
> 
> > If you want to attract me working on some of your most pressing
> > issues, please write short, add a compilable code-example (no link)
> > and give feed-back.
> 
> I will make sure to do that.

Thanks.

> Now as to your proposed solution…
[...]
> 
> > How should the lyrics of third Staff be aligned?
> 
> I guess in a perfect world, the engraver would only "couple" lyrics which are \
> exactly the same string as a melisma-aligned lyric. So in the case of the example \
> you provided, the alignment of the lyrics for the third staff would be unaffected \
> (i.e., would align as per default); *however*, if there were a fourth staff with \
> the same lyrics as the third staff, and one of those were melismatic, then the \
> lyrics for the third and fourth staff would "couple up" with regard to alignment. 
> 1. Does that make sense?
> 2. Is it feasible to implement?

Yes, parts of it works already. Look at the attached image.
In first bar the lyrics are aligned correctly I'd say.
Though not in 3rd bar. "three" is offsetted as well, it shouldn't.

The problem is how to test equality?
For strings it's trivial, but LyricText also allows for markup.
Thus "blue" and \markup \with-color #red "blue" should return true for
some equality-test.
Maybe I'll go for length of grob-extent or stencil-extent, though I
have to test if these values are available early enough.
At any rate, with this method "blue" and "elub" will probably return
false positive...

> 
> > Maybe affecting 'self-alignment-X is the wrong method at all,
> > instead I could probably set 'X-offset.
> 
> Perhaps someone else [with a more encyclopedic knowledge of the back-end] can weigh \
> in on that. I am (and always have been) a little confused by the difference — and \
> especially interaction — of these two parameters. 
> 1. They seem to have the same effect, once the math is worked out (i.e., \
> ‘self-alignment-X is proportional to the width of the LyricText grob, whereas \
> ‘X-offset is an absolute value). I don't see any difference between them in terms \
> of the effect they have on [horizontal] spacing, etc. 
> 2. On the other hand, I have recently found that there are potentially frustrating \
> interactions between them. For example, the "center-on-word" snippet appears to \
> render #'self-alignment-X untweakable, and it also appears to render \
> lyricMelismaAlignment incapable of accepting non-integral values. (I intend to code \
> a minimal example, but am currently too swamped to do so, which is why it's not \
> been made into an issue.)


I think David answered already sufficiently about the difference,
although I'm still not sure how to proceed.
Likely I'll go for 'self-alignment-X only ...

Cheers,
  Harm


["melisma-align-03.png" (image/png)]

_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


[prev in list] [next in list] [prev in thread] [next in thread]