lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug in lyric syllable magnetic snap


From: Alexander Kobel
Subject: Re: bug in lyric syllable magnetic snap
Date: Tue, 28 May 2019 15:43:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

Hi,

On 27.05.19 22:34, Thomas Morley wrote:
Am Mo., 27. Mai 2019 um 10:40 Uhr schrieb Alexander Kobel <address@hidden>:

unless I additionally engage
    http://lsr.di.unimi.it/LSR/Item?id=1090
to replace Lily's built-in hyphens by the "proper" Lyric's font hyphens;
then it breaks again.

I did not have a very close look yet; I thought replacing ly:stencil? by
(not ly:stencil-empty?) might help, but that's not it. I'll give it
another shot as soon as time permits.

Instead of doing:
(filter
   (lambda (hyphen)
     (ly:stencil? (ly:grob-property hyphen 'stencil)))
   hyphen-grobs)

It works with
(cdr hyphen-grobs)

Tbh, I've no clue why ...

not quite, over here - I get complaints about (cdr '()) in some cases in a non-trivial score. I assume if there are hyphens across breaks, and the new system does not start with a syllable right away? But that's just guesswork for the time being.
If I replace by

  (if (pair? hyphen-grobs) (cdr hyphen-grobs) '())

then I get no errors, but no merging of syllables either (with or without the aforementioned snippet from the LSR).


Anyways, I really appreciate your effort. My take-home message is that

a) in case I'll have plenty of time to spare, this might be worthwhile to investigate (and actually understand), and

b) in any case, the magnetic snapping is *great*, but should be used in a "supervised" manner. diffpdf is my friend here. And it's easy enough to locally disable snapping if there is a need to.


Regarding b), there are some potential issues / wishlist features that are not truly captured in the overall approach in the best possible way. E.g., the following is suboptimal (some ASCII art to follow, make sure you use a monospace font):

|   o    o       % <-- note heads ;-)
| abcde-fgh

should compress to

|   o    o
|  abcdefgh

rather than

|   o    o
| abcdefgh

as it currently does.
This is even more pronounced if the last syllable is very short and actually ends up left of the last note:

|   o   o
| abcde-f

should better not become

|   o   o
| abcdef

as it currently does.

So, in the best of all worlds, the "merged" syllables should be centered under the related note heads. Of course, also ignoring punctuation, as seen in <http://lsr.di.unimi.it/LSR/Item?id=888>... ;-)

Bonus points, if afterwards the horizontal spacing decisions could be retaken for the rest of the line (probably merging the closest pair, then the second-closest and so on; or even better: merging syllables in the order of "distraction" or "penalty" to the natural horizontal note spacing, to make sure that note spacing reflects note durations well).

Also, the positioning of the hyphens is currently not adjusted after the syllables are merged:

|  o    o      o
|  a-bcdefgh - i

should compress to

|  o    o      o
| abcdefgh  -  i
          ^^ ^^      % <-- note the position of the hyphen
instead of

|  o    o      o
| abcdefgh   - i
          ^^^ ^

(Obviously, the problem already exists in the current version without re-centering the combined pair of syllables; it's just harder to visualize on an ASCII grid.)


That being said, in almost all real-world cases with roughly equal syllable lengths, David's and Mike's original snippet (and, hence, your first fix) already tremendously improve the quality in cramped conditions. You helped a great deal to make it more reliable unless some user tries to assemble the jack of all trades without understanding the fundamentals... (*cough*)


Cheers,
   Harm

Thanks,
Alex

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]