Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

That went smoothly without any problems. The contrib documentation
describes it really well and more importantly, the usual configure/make
commands just work like expected.

I will have a look at the patches and their effect on my scrores on
Saturday.

Cheers,
Joram

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

>> I won't be able to do more testing until the weekend.
>>
>> Can I compile lilypond on Ubuntu?
> 
> Ofcourse.

Thanks.

>> I've read
>> http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-compiling-lilypond#ubuntu
> 
> Useful as well:
> http://lilypond.org/doc/v2.19/Documentation/contributor/setting-up

Thanks, git is already in place.

Cheers,
Joram

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

Re: exchange LyricHyphen with a "proper" hyphen

[Thomas Morley]

2016-12-14 23:12 GMT+01:00 Noeck :
> Thank you both! That looks good. I tested it with one vocal score. I
> won't be able to do more testing until the weekend.
>
> Can I compile lilypond on Ubuntu?

Ofcourse.

> I've read
> http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-compiling-lilypond#ubuntu

Useful as well:
http://lilypond.org/doc/v2.19/Documentation/contributor/setting-up

Cheers,
  Harm

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Thank you both! That looks good. I tested it with one vocal score. I
won't be able to do more testing until the weekend.

Can I compile lilypond on Ubuntu?
I've read
http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-compiling-lilypond#ubuntu
But if you already know that it won't work because of XYZ (guile,
dependencies, ...), I would be happy to know before.

Cheers,
Joram

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

Hi.

On 2016-12-10 20:23, Knut Petersen wrote:

Am 07.12.2016 um 23:59 schrieb Thomas Morley:

So here a very first shot.


Thanks for your work. I think the attached code shows a problem of your
code ...


Back on the topic for this thread. I also noticed that behavior, and I 
thought I have a fix for that in my variant used in the Reger score. 
Unfortunately, the "fix" was broken and produced the erroneous clashing 
hyphen in the one syllable.


So, the failed "centering" of the real hyphen over the pseudo-hyphen 
still is a problem (which I don't have a solution for), but Harm's 
original code seems stable in the sense that it does not introduce 
additional hyphens.
Sorry for that confusion, I should have mentioned that I adapted the 
code - it only occured to me now that this was the problem.



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

Hi Knut, hi all.

On 2016-12-12 00:52, Knut Petersen wrote:

Hi Alexander

IIUC (I didn't compile it in), your patch inhibits extenders on a
single note, correct?


Yes.


Is that really what we want unconditionally,


Currently we get a short extender ... that is imho of no use and should
be killed.


I agree, but I don't know whether others have a use for it. But if it's 
possible to have it controlled by a context property, as Simon 
suggested, that's even better. Also, convert-ly would be happy about that...


OTOH, IMHO, your idea is the one and only sane default. And I actually 
think that, per default, extenders everywhere should be automatic 
(although that might be a change that is not automatically convert-ly'able):
I've seen too many Lily engravings on CPDL et al. where missing 
extenders make the difference between a "perfectly usable (though still 
tweakable)" and a "confusing, but better than nothing" score. They have 
clearly been created by motivated, but inexperienced users who simply 
lack the awareness or the know-how to add them.



or are there reasonable use cases where one might want to have an
extender printed after a single note?


No really ... but ... yes. In a situation like << { c1 } { a8 (g f g a2
) } >>  it could be usefull.
Would need an override ...


Found one more: http://lsr.di.unimi.it/LSR/Item?id=1006
A special situation anyway, but still valid.


Second: Did you test with broken extenders? Like
{ c1 d \break e f } \addlyrics { c de __ _ f }? Asking because there
should be an extender for "de" across the break despite the fact that
both the d and e are "alone" on that line. Such an extender may never
be killed.

The 2nd part of the extender is killed by the "if (heads.size () < 2)".
That could be changed to "if (left_edge->internal_has_interface
(ly_symbol2scm ("lyric-syllable-interface")) && heads.size () < 2)".


Sounds good.


It's late now, good night.


Of course, no hurry; didn't mean to make you work overhours in your 
spare time. ;-) I just wanted to get this out of my head and into the 
wild before I forget.



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Hi Alexander
IIUC (I didn't compile it in), your patch inhibits extenders on a single note, correct? 


Yes.

Is that really what we want unconditionally, 


Currently we get a short extender ... that is imho of no use and should be 
killed.


or are there reasonable use cases where one might want to have an extender 
printed after a single note?


No really ... but ... yes. In a situation like << { c1 } { a8 (g f g a2 ) } >>  
it could be usefull.
Would need an override ...


Second: Did you test with broken extenders? Like
{ c1 d \break e f } \addlyrics { c de __ _ f }? Asking because there should be an extender for 
"de" across the break despite the fact that both the d and e are "alone" on 
that line. Such an extender may never be killed.

The 2nd part of the extender is killed by the "if (heads.size () < 2)". That could be changed to "if 
(left_edge->internal_has_interface (ly_symbol2scm ("lyric-syllable-interface")) && heads.size () < 
2)".

It's late now, good night.

Knut



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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Hi,

> That’s a design question. There are styles which use extenders on single
> notes (e.g. for very wide c.f. notes),

I also think I have seen it for long notes, for instance in a final measure.

I could also think of a situation where a voice splits up into two in
the final measure (bass voices sometimes do). Then it would be handy to
write the lyrics according to the main (and then upper) voice. But the
new temporary voice could have a melisma calling for an extender line.

{
  <<
\new Staff <<
  \new Voice = "one" { a'4 a' a' a' \voiceOne a'1 \bar "|." }
  \new Voice  { s1 \voiceTwo  a4 b c' d' }
>>
\new Lyrics \lyricsto "one" { A B C D
  \override Lyrics.LyricExtender.minimum-length = #8.5
  E __ }
  >>
}

> so I think it should ideally be controlled by a context property.

+1

There could be two options:
a) Extender length is always at least minimum-length
b) Extenders shorter than a threshold length are omitted.

It seems like currently single note (non-melisma) extenders choose
option (a) which looks bad in most cases: Either they need to be
lengthened (like the override above) or they should be suppressed.

For an automatic extender creation, there could be two options:
a) only explicit extenders are printed (current behaviour)
b) extenders are printed for melismata

Cheers,
Joram

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

Re: exchange LyricHyphen with a "proper" hyphen

[Simon Albrecht]

On 11.12.2016 23:33, Alexander Kobel wrote:
IIUC (I didn't compile it in), your patch inhibits extenders on a 
single note, correct? Is that really what we want unconditionally, or 
are there reasonable use cases where one might want to have an 
extender printed after a single note? 


That’s a design question. There are styles which use extenders on single 
notes (e.g. for very wide c.f. notes), so I think it should ideally be 
controlled by a context property.


Best, Simon

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-11 17:24, Knut Petersen wrote:

Am 11.12.2016 um 09:05 schrieb Simon Albrecht:

Sorry to ask so bluntly, but can it really be that simple? I thought a
solution must consider the x-extent of the syllable vs. the melisma as
well…


I think this is sufficiently easy to handle with the scheme callback. 
That might not necessarily be the most performant or elegant solution, 
but it works well. I guess one reason is that extenders do not interfere 
with horizontal spacing, and the x-extents can be readily read from the 
stencil; otherwise, we'd have to spend way more effort.



As you can see from 0001-Better-lyric-extender-handling.patch it needs
one more change,
and and automatic solution (don't write "__" but get extenders where
they are needed)
requires the scheme code by Alexander.

But at the moment I think this is all that is needed, and yes, it seems
to be that simple.


IIUC (I didn't compile it in), your patch inhibits extenders on a single 
note, correct? Is that really what we want unconditionally, or are there 
reasonable use cases where one might want to have an extender printed 
after a single note?


Second: Did you test with broken extenders? Like
{ c1 d \break e f } \addlyrics { c de __ _ f }? Asking because there 
should be an extender for "de" across the break despite the fact that 
both the d and e are "alone" on that line. Such an extender may never be 
killed.


Other than that, I have no worries about your changes - but as I said, I 
didn't compile.



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Am 11.12.2016 um 09:05 schrieb Simon Albrecht:

On 11.12.2016 08:37, Knut Petersen wrote:

The attached patch should solve your problem.


Thanks for having a look into it! Would you mind posting your patch as reply 
under issue 4509, to keep the information in one place?


No. Now and here's the discussion, I see no need to split it up into two 
threads at different locations.
Of course, you are free to add links to this thread ;-)


Sorry to ask so bluntly, but can it really be that simple? I thought a solution 
must consider the x-extent of the syllable vs. the melisma as well…


As you can see from 0001-Better-lyric-extender-handling.patch it needs one more 
change,
and and automatic solution (don't write "__" but get extenders where they are 
needed)
requires the scheme code by Alexander.

But at the moment I think this is all that is needed, and yes, it seems to be 
that simple.

If testing does not show problems, the code should be added to lilypond.

Todo:

- cleanup of c++ code
- proper documentation.

cu,
 Knut

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Hi Alexander!


Here's a first shot. Please test thoroughly...

#(define (has-hyphen? event)
   (let* ((art (ly:music-property event 'articulations))
  (is-hyphen? (lambda (ev) (eq? (ly:music-property ev 'name) 
'HyphenEvent
  (find is-hyphen? art)))

[]


Thanks a lot for that code. Works fine together with my 
0001-Better-lyric-extender-handling.patch.

cu,
 Knut

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Am 11.12.2016 um 10:08 schrieb David Kastrup:

Noeck  writes:


Btw, I realized that at least visually setting the min. length to 0
already makes the non-melismata hyphens disappear even without your code
to kill them:

\layout {
 \override Lyrics.LyricExtender.minimum-length = 0.0
}

{ a a( a) }
\addlyrics { A __ B __}

But one does not want extenders indistinguishable from fly specks, so 0
is a bad size to use.


I think also the minim-length should be handled differently in the c++ code.

Imho the use of minimum-length and documentation of minimum-length do not agree 
in current master,
so we have some freedom ;-)

cu,
 Knut

>From e37b3eeaca692db26a2384548c71d180f090c4a1 Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Sun, 11 Dec 2016 12:30:38 +0100
Subject: [PATCH] Better lyric extender handling

---
 lily/lyric-extender.cc | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lily/lyric-extender.cc b/lily/lyric-extender.cc
index 8afe2c5569..d05e71a41a 100644
--- a/lily/lyric-extender.cc
+++ b/lily/lyric-extender.cc
@@ -48,7 +48,7 @@ Lyric_extender::print (SCM smob)
 
   extract_grob_set (me, "heads", heads);
 
-  if (!heads.size ())
+  if (heads.size () < 2)
 return SCM_EOL;
 
   common = common_refpoint_of_array (heads, common, X_AXIS);
@@ -66,9 +66,8 @@ Lyric_extender::print (SCM smob)
 
   /* It seems that short extenders are even lengthened to go past the
  note head, but haven't found a pattern in it yet. --hwn 1/1/04  */
-  SCM minlen = me->get_property ("minimum-length");
-  Real right_point
-= left_point + (robust_scm2double (minlen, 0));
+  Real minlen = robust_scm2double (me->get_property ("minimum-length"), 0);
+  Real right_point = left_point + minlen;
 
   right_point = min (right_point, me->get_system ()->get_bound (RIGHT)->relative_coordinate (common, X_AXIS));
 
@@ -89,7 +88,7 @@ Lyric_extender::print (SCM smob)
   left_point += paddings[LEFT];
   Real w = right_point - left_point;
 
-  if (w < 1.5 * h)
+  if (w <= minlen)
 return SCM_EOL;
 
   Stencil mol (Lookup::round_filled_box (Box (Interval (0, w),
-- 
2.11.0

\version "2.19.53"
\language "deutsch"

\pointAndClickOff

% Requires Libertine Open Fonts from http://www.linuxlibertine.org/

\header {
  title = "Brich an, o schönes Morgenlicht"
  subtitle = "12. Choral – Weihnachtsoratorium"
  composer = "J. S. Bach"
  shortcomposer = "Bach"
  maintainer = "Joram Berger"
  maintainerWeb = "http://joramberger.de;
  style = "Baroque"
  source = "Breitkopf & Härtel, Leipzig, 1856"
  mutopiacomposer = "BachJS"
  mutopiapoet = "Johann Rist"
  mutopiaopus = "BWV 248"
  mutopiainstrument = "Choir (SATB)"
  license = "cc-by-sa"
  date = "1734"

 mutopialicense = "Creative Commons Attribution-ShareAlike 4.0"
 footer = "Mutopia-2016/04/22-1900"
 copyright = \markup {\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0) \right-column {\with-url #"http://www.MutopiaProject.org; {\abs-fontsize #9  "Mutopia " \concat {\abs-fontsize #12 \with-color #white \char ##x01C0 \abs-fontsize #9 "Project "}}}\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0 ) \center-column {\abs-fontsize #11.9 \with-color #grey \bold {\char ##x01C0 \char ##x01C0 }}\override #'(font-name . "DejaVu Sans,sans-serif") \override #'(baseline-skip . 0) \column { \abs-fontsize #8 \concat {"Typeset using " \with-url #"http://www.lilypond.org; "LilyPond " \char ##x00A9 " 2016 " "by " \maintainer " " \char ##x2014 " " \footer}\concat {\concat {\abs-fontsize #8 { \with-url #"http://creativecommons.org/licenses/by-sa/4.0/; "Creative Commons Attribution ShareAlike 4.0 International License "\char ##x2014 " free to distribute, modify, and perform" }}\abs-fontsize #13 \with-color #white \char ##x01C0 }}}
 tagline = ##f
}

#(define (lh-test-stencil arg)
 (lambda (grob)
   (if (ly:stencil? (ly:lyric-hyphen::print grob))
   (let* ((stil (ly:lyric-hyphen::print grob))
  (x-ext (ly:stencil-extent stil X))
  (dash-period (ly:grob-property grob 'dash-period))
  (arg-stil (grob-interpret-markup grob arg))
  (arg-stil-x-ext (ly:stencil-extent arg-stil X))
  (length-to-print (interval-length x-ext))
  (guess (max 0 (truncate (/ length-to-print dash-period
  (guessed-args-line-length (* guess dash-period))
  (line-length-diff (- length-to-print guessed-args-line-length))
  (line-length-diff-for-each-arg (/ line-length-diff guess))
  (first-arg-length (+ dash-period line-length-diff-for-each-arg))
  (first-arg-end-coord
  (/ (* first-arg-length
(- (interval-length x-ext)
   (interval-length arg-stil-x-ext)))
 length-to-print))
  (list-of-starts
(map
  (lambda (n) (* n first-arg-end-coord))

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-10 23:33, Alexander Kobel wrote:

On 2016-12-10 20:20, Noeck wrote:
[...]

Would it be possible to have automatic extender lines? For every melisma
there is an extender line if it would be longer than the minimum-length?


Hm. Iterate over lyrics and add Extender events for each syllable
without a hyphen? Sounds reasonable...


Here's a first shot. Please test thoroughly...

#(define (has-hyphen? event)
   (let* ((art (ly:music-property event 'articulations))
  (is-hyphen? (lambda (ev) (eq? (ly:music-property ev 'name) 
'HyphenEvent

  (find is-hyphen? art)))

#(define (add-extender! event)
   (ly:music-set-property! event 'articulations
 (append (ly:music-property event 'articulations) (list (make-music 
(quote ExtenderEvent)

   event)

add-lyric-extenders =
#(define-music-function (parser location lyrics) (ly:music?)
   (music-map
(lambda (event)
  (if (and (eq? (ly:music-property event 'name) 'LyricEvent)
   (not (has-hyphen? event)))
  (add-extender! event))
  event)
lyrics))

% ... and change lyrics definitions from
%   text = \lyricmode { ... }
% to
%   text = \add-lyric-extenders \lyricmode { ... }

Attached is how it will look like in your score. Not too bad...


Cheers,
Alexander
\version "2.18.2"
\language "deutsch"

% Requires Libertine Open Fonts from http://www.linuxlibertine.org/

\header {
  title = "Brich an, o schönes Morgenlicht"
  subtitle = "12. Choral – Weihnachtsoratorium"
  composer = "J. S. Bach"
  shortcomposer = "Bach"
  maintainer = "Joram Berger"
  maintainerWeb = "http://joramberger.de;
  style = "Baroque"
  source = "Breitkopf & Härtel, Leipzig, 1856"
  mutopiacomposer = "BachJS"
  mutopiapoet = "Johann Rist"
  mutopiaopus = "BWV 248"
  mutopiainstrument = "Choir (SATB)"
  license = "cc-by-sa"
  date = "1734"

 mutopialicense = "Creative Commons Attribution-ShareAlike 4.0"
 footer = "Mutopia-2016/04/22-1900"
 copyright = \markup {\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0) \right-column {\with-url #"http://www.MutopiaProject.org; {\abs-fontsize #9  "Mutopia " \concat {\abs-fontsize #12 \with-color #white \char ##x01C0 \abs-fontsize #9 "Project "}}}\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0 ) \center-column {\abs-fontsize #11.9 \with-color #grey \bold {\char ##x01C0 \char ##x01C0 }}\override #'(font-name . "DejaVu Sans,sans-serif") \override #'(baseline-skip . 0) \column { \abs-fontsize #8 \concat {"Typeset using " \with-url #"http://www.lilypond.org; "LilyPond " \char ##x00A9 " 2016 " "by " \maintainer " " \char ##x2014 " " \footer}\concat {\concat {\abs-fontsize #8 { \with-url #"http://creativecommons.org/licenses/by-sa/4.0/; "Creative Commons Attribution ShareAlike 4.0 International License "\char ##x2014 " free to distribute, modify, and perform" }}\abs-fontsize #13 \with-color #white \char ##x01C0 }}}
 tagline = ##f
}

#(set-global-staff-size 18.1)


\paper {
  ragged-bottom = ##f
  ragged-last-bottom = ##f
  last-bottom-spacing #'basic-distance = 15
  myStaffSize = #18.5
  fonts = #(make-pango-font-tree
"Linux Libertine O"
"Linux Biolinum O"
"Ubuntu Mono"
(/ myStaffSize 20))
}

\layout {
  \override Staff.ClefModifier.font-name = #"Century Schoolbook L bold italic"
  \override Staff.ClefModifier.extra-offset = #'(-0.3 . 0.07)
  \override Score.BarNumber.font-name = #"Century Schoolbook L"
}

global = {
  \key g \major
  \time 4/4
  \partial 4
  \autoBeamOff
  \accidentalStyle modern-voice
}

fe = \fermata

soprano = \relative c'' {
  \global
  \repeat volta 2 {
g4 | g a h8[ cis] d4 | d cis d\fe
h4 | c h a h | a2 g4
  } \break
  a4  | \once \override Score.BarNumber.break-visibility = #all-visible
  a h c c | h8[( a]) h4 a\fe
  h4 | h h c8[( d]) e4 | e dis e\fe
  fis4 | g h, c h | a2 a4\fe
  d4 | e d c h8[ c] | a2 g='4\fe
  \bar "|."
}

alto = \relative c' {
  \global
  \repeat volta 2 {
d4 | e fis d8[ e] fis4 | e8[ fis] g4 fis\fe
fis4 | e d8[ e] fis4 g | g( fis) d
  }
  fis8[ g] | a4. gis8 a[( gis]) a4 | a gis e\fe
  e8[ dis] | e4 e e8[( fis]) g[( fis]) | fis8[( g]) a4 g\fe
  a4 | g8[ a] h4 h8[( a]) a[( g]) | g2 fis4\fe
  g8[ fis] | e4 fis g8[( a]) d,4 | e( d) d='\fe
}

tenor = \relative c' {
  \global
  \repeat volta 2 {
h4 | h8[ c] ~ c d h[ a] a4 | a a a\fe
h8[a] | g[a] h[ c] d4 d | d4.( c8) h4
  }
  d8[ e] | fis[ e] d4 e fis | h, e8[ d] c4\fe
  g8[ a] | h[ c] d[ e] c4 cis | h h h\fe
  d4 | d g g,8[( a]) h4 | e8[( d e cis]) d4\fe
  d4 | d8[( c]) c[( h]) h[( a]) g4 | g8[( fis16 e] fis4) h=\fe
}

bass = \relative c' {
  \global
  \repeat volta 2 {
g8[ fis] | e4 d g fis8[ g] | a4 a, d\fe
dis4 | e8[ fis] g[ c,] c'[ h] a[ g] | d'4( d,) g
  }
  d4 | d'8[ c] h4 a dis, | e e a,\fe
  e'8[ fis] | g4 gis a ais | h h, e\fe
  d'8[ c] | h[ a] g[ fis] e[ fis] g[ e] | cis[ h cis a] d4\fe
  h4 | c d e8[ fis] g4 | \shape #'((0 . -0.2) (0 . -0.8) (0 . -0.8) (0 . 0)) 

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-11 11:04, Alexander Kobel wrote:

Hi Joram.

On 2016-12-11 09:28, Noeck wrote:

Hi Alexander,

Am 11.12.2016 um 01:17 schrieb Alexander Kobel:

Ah, no, here's the problem, as can be readily seen in the "Brich an, o
schönes Morgenlicht", first full measure


I don't think so. Because for notes like the second one in the soprano
voice ("an,"), the added extender line is very short and therefore
killed. It does not even require a sufficient minimum-length. [...]


Well, with my default settings, it isn't. For me, this measure would
look like the attached picture.


Argh, forget my previous mail. I added the layout block to the MIDI 
score, stupid me...



Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

Hi Joram.

On 2016-12-11 09:28, Noeck wrote:

Hi Alexander,

Am 11.12.2016 um 01:17 schrieb Alexander Kobel:

Ah, no, here's the problem, as can be readily seen in the "Brich an, o
schönes Morgenlicht", first full measure


I don't think so. Because for notes like the second one in the soprano
voice ("an,"), the added extender line is very short and therefore
killed. It does not even require a sufficient minimum-length. [...]


Well, with my default settings, it isn't. For me, this measure would 
look like the attached picture.
In general, I dislike setting the minimum-length too short; my default 
is 1.5 staff-line distances. Just the other day, I was affirmed by a 
measure of "In the bleak mid-winter" by Holst (attached excerpt from 
Oxford's engraving): The question arose (among non-native speakers) 
whether "Thronged" is supposed to be sung as one syllable or as "Throng 
-- ed". Here, the extender made clear that it should is meant as one 
syllable. In a slightly tighter setting, without the fifth verse, this 
extender might have been /really/ short, but still important.



It might not be robust enough, there may be problematic situations but I
could not find such a problem.


That's the main issue. Imagine a passage of semi-quavers in the other 
voices, and suddenly the extenders get large. Or think of BWV 140 
"Wachet auf" with the prolonged cantus firmus in soprano over the 
fast-moving rest of the choir...


Anyway, I'll try to have a look and see whether I can find an easy way 
to detect melismata...



Cheers,
Alexander
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: exchange LyricHyphen with a "proper" hyphen

[David Kastrup]

Noeck  writes:

> Btw, I realized that at least visually setting the min. length to 0
> already makes the non-melismata hyphens disappear even without your code
> to kill them:
>
> \layout {
> \override Lyrics.LyricExtender.minimum-length = 0.0
> }
>
> { a a( a) }
> \addlyrics { A __ B __}

But one does not want extenders indistinguishable from fly specks, so 0
is a bad size to use.

-- 
David Kastrup

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Btw, I realized that at least visually setting the min. length to 0
already makes the non-melismata hyphens disappear even without your code
to kill them:

\layout {
\override Lyrics.LyricExtender.minimum-length = 0.0
}

{ a a( a) }
\addlyrics { A __ B __}

Cheers,
Joram

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Hi Alexander,

Am 11.12.2016 um 01:17 schrieb Alexander Kobel:
> Ah, no, here's the problem, as can be readily seen in the "Brich an, o
> schönes Morgenlicht", first full measure

I don't think so. Because for notes like the second one in the soprano
voice ("an,"), the added extender line is very short and therefore
killed. It does not even require a sufficient minimum-length. You can
try this with your code:

{ a a }
\addlyrics { A __ }

It might not be robust enough, there may be problematic situations but I
could not find such a problem.

Cheers,
Joram


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

Re: exchange LyricHyphen with a "proper" hyphen

[Simon Albrecht]

On 11.12.2016 08:37, Knut Petersen wrote:

The attached patch should solve your problem.


Thanks for having a look into it! Would you mind posting your patch as 
reply under issue 4509, to keep the information in one place?
Sorry to ask so bluntly, but can it really be that simple? I thought a 
solution must consider the x-extent of the syllable vs. the melisma as well…


Best, Simon

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Hi Joram!

Ok, I misunderstood your problem.


What I do is shown here [like 1]:

 \new ChoirStaff <<
   \new Staff \soprano
   \addlyrics \text
   \new Staff \alto
   \addlyrics \text
   \new Staff { \clef "treble_8" \tenor }
   \addlyrics \text
   \new Staff { \clef "bass" \bass }
   \addlyrics \text
 >>

Or the same with
   \new Staff \new Voice = "soprano" \soprano
   \new Lyrics \lyricsto "soprano" \text
etc.

So each staff has its own lyrics context but the content is the same
variable. That works.


The attached patch should solve your problem. But it changes the c++ sources 
and requires
recompilation.

Probably it will not be accepted as it is possible to reimplement a 
Lyric_extender::print()
with the desired changes in scheme and to include it in any lilypond source 
that needs it ;-)


In principle, the information about where to put
extender lines is already given by the number of notes per syllable.

You don't want extenders and hyphens at the same time ...

cu,
 Knut
>From 62bfdf5eba38e4ff09830b81a17ac6eeed798785 Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Sun, 11 Dec 2016 07:54:34 +0100
Subject: [PATCH] Kill lyric extenders if number of heads < 2

This allows to reuse lyric definitions if they only
differ by some extenders.

Signed-off-by: Knut Petersen 
---
 lily/lyric-extender.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lily/lyric-extender.cc b/lily/lyric-extender.cc
index 8afe2c5569..441ceea34f 100644
--- a/lily/lyric-extender.cc
+++ b/lily/lyric-extender.cc
@@ -48,7 +48,7 @@ Lyric_extender::print (SCM smob)
 
   extract_grob_set (me, "heads", heads);
 
-  if (!heads.size ())
+  if (heads.size () < 2)
 return SCM_EOL;
 
   common = common_refpoint_of_array (heads, common, X_AXIS);
-- 
2.11.0

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

Hi again,

On 2016-12-10 23:33, Alexander Kobel wrote:

On 2016-12-10 20:20, Noeck wrote:

Hi Alexander,

where is this from: conditional-kill-lyric-extender-callback?
[...]
It is a perfect solution for a problem I had for quite some time:
In chorales (4 voices, mostly homophone), I often have common lyrics but
sometimes different melismata. So just because of one or two __, I have
to duplicate the lyrics up to four times or put several tags in there.
This conditional killing of the extender line allows to enter the __ in
the common lyrics and in all voices without melisma, it is removed
automatically. Very nice.


Sound perfectly valid. Never thought of it, despite the fact that I was
often annoyed by copy-pasting lyrics. But it should work like a charm.


Would it be possible to have automatic extender lines? For every melisma
there is an extender line if it would be longer than the minimum-length?


Hm. Iterate over lyrics and add Extender events for each syllable
without a hyphen? Sounds reasonable...


Ah, no, here's the problem, as can be readily seen in the "Brich an, o 
schönes Morgenlicht", first full measure: any __ in lyrics will 
unconditionally add an extender line, indifferent of whether there is a 
melisma or not. So this alone would not suffice; the callback would have 
to inspect the situation and kill the extender not just due to their 
length, but also if there is no melisma.


I'm not sure whether there is an easy (read: scheme-able) way to do so. 
Maybe one could exploit the fact that lyrics on melismata are 
left-aligned by default, while others are centered; but this sounds like 
a fragile and hackish approach. Probably there should be a cleaner way?



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-10 20:20, Noeck wrote:

Hi Alexander,

where is this from: conditional-kill-lyric-extender-callback?
Does it have any drawback?


Hi Joram,

glad it helped. It seems that I wrote it, probably modeled after a 
suggestion by Kieren:

  https://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00326.html
I'm genuinely surprised to rediscover my authorship there...

I'm not aware of any drawbacks, but I though the same from the lyric 
hyphen snippet...



It is a perfect solution for a problem I had for quite some time:
In chorales (4 voices, mostly homophone), I often have common lyrics but
sometimes different melismata. So just because of one or two __, I have
to duplicate the lyrics up to four times or put several tags in there.
This conditional killing of the extender line allows to enter the __ in
the common lyrics and in all voices without melisma, it is removed
automatically. Very nice.


Sound perfectly valid. Never thought of it, despite the fact that I was 
often annoyed by copy-pasting lyrics. But it should work like a charm.



Would it be possible to have automatic extender lines? For every melisma
there is an extender line if it would be longer than the minimum-length?


Hm. Iterate over lyrics and add Extender events for each syllable 
without a hyphen? Sounds reasonable...



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Hi Simon,

> Well… https://sourceforge.net/p/testlilyissues/issues/4509/ …

:) That's exactly what I meant.

With (a) this conditional-kill-lyric-extender-callback in Alexander's
files and (b) a "put extenders after every syllable" philosophy this
does not sound very complicated. (a) is quite short an easy to
understand, (b) is of course not elegant but it could work as all the
non-melisma extenders are killed by (a).

Best,
Joram



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

Re: exchange LyricHyphen with a "proper" hyphen

[Simon Albrecht]

On 10.12.2016 20:20, Noeck wrote:

Would it be possible to have automatic extender lines? For every melisma
there is an extender line if it would be longer than the minimum-length?


Well… …

Best, Simon

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Hi Knut,

Am 10.12.2016 um 20:37 schrieb Knut Petersen:
> Currently lyrics are attached to one voice, but you use them for up to
> four voices in a staff like "SA combined, lyrics, TB combined".
> A better lyrics engraver would allow to attach the lyrics to more than
> one voice and handle the special cases of lyric placement.

I am not sure if I understand you. How would you attach lyrics to
several voices in the same context?

What I do is shown here [like 1]:

\new ChoirStaff <<
  \new Staff \soprano
  \addlyrics \text
  \new Staff \alto
  \addlyrics \text
  \new Staff { \clef "treble_8" \tenor }
  \addlyrics \text
  \new Staff { \clef "bass" \bass }
  \addlyrics \text
>>

Or the same with
  \new Staff \new Voice = "soprano" \soprano
  \new Lyrics \lyricsto "soprano" \text
etc.

So each staff has its own lyrics context but the content is the same
variable. That works. In principle, the information about where to put
extender lines is already given by the number of notes per syllable.

Cheers,
Joram


[1]:
http://www.mutopiaproject.org/ftp/BachJS/BWV248/Bach_BrichAn/Bach_BrichAn.ly

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Hi Joram!

Would it be possible to have automatic extender lines? For every melisma
there is an extender line if it would be longer than the minimum-length?


Currently lyrics are attached to one voice, but you use them for up to four 
voices in a
staff like "SA combined, lyrics, TB combined".
A better lyrics engraver would allow to attach the lyrics to more than one 
voice and
handle the special cases of lyric placement. With that design automated extender
lines wouldn't be a problem 

cu,
 Knut

BTW: Nach einem Blick auf Deine Adresse: Gruß aus dem Vogelsberg ;-)

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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Am 07.12.2016 um 23:59 schrieb Thomas Morley:
So here a very first shot. 


Thanks for your work. I think the attached code shows a problem of your code ...

Knut

\version "2.19.53"

#(define (lh-test-stencil arg)
 (lambda (grob)
   (if (ly:stencil? (ly:lyric-hyphen::print grob))
   (let* ((stil (ly:lyric-hyphen::print grob))
  (x-ext (ly:stencil-extent stil X))
  (dash-period (ly:grob-property grob 'dash-period))
  (arg-stil (grob-interpret-markup grob arg))
  (arg-stil-x-ext (ly:stencil-extent arg-stil X))
  (length-to-print (interval-length x-ext))
  (guess (max 0 (truncate (/ length-to-print dash-period
  (guessed-args-line-length (* guess dash-period))
  (line-length-diff (- length-to-print guessed-args-line-length))
  (line-length-diff-for-each-arg (/ line-length-diff guess))
  (first-arg-length (+ dash-period line-length-diff-for-each-arg))
  (first-arg-end-coord
  (/ (* first-arg-length
(- (interval-length x-ext)
   (interval-length arg-stil-x-ext)))
 length-to-print))
  (list-of-starts
(map
  (lambda (n) (* n first-arg-end-coord))
  (iota (+ 1 guess)
 (ly:stencil-translate-axis
   (apply
 ly:stencil-add
 (map
   (lambda (x-val) (ly:stencil-translate-axis arg-stil x-val X))
   list-of-starts))
   (car x-ext) X))
   (ly:grob-suicide! grob


newLH = #(define-music-function (mrkp)(markup?)
#{
  \override LyricHyphen.after-line-breaking =
#(lambda (grob)
  (if (ly:stencil? (ly:lyric-hyphen::print grob))
  (ly:grob-set-property! grob 'stencil
(ly:stencil-add
  (stencil-with-color (ly:lyric-hyphen::print grob) red)
  ((lh-test-stencil mrkp ) grob)
#})

\paper { ragged-right = ##f }

\layout {
  \context {
\Lyrics
\newLH "¦"
\override LyricHyphen #'height = #0.6
  }
}

<<
\new Voice = "sopran" { c''2.. 8 \bar "|." }
\new Lyrics \lyricsto sopran { bro -- ken  }
>>


harmA.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Hi Alexander,

where is this from: conditional-kill-lyric-extender-callback?
Does it have any drawback?

It is a perfect solution for a problem I had for quite some time:
In chorales (4 voices, mostly homophone), I often have common lyrics but
sometimes different melismata. So just because of one or two __, I have
to duplicate the lyrics up to four times or put several tags in there.
This conditional killing of the extender line allows to enter the __ in
the common lyrics and in all voices without melisma, it is removed
automatically. Very nice.

Would it be possible to have automatic extender lines? For every melisma
there is an extender line if it would be longer than the minimum-length?

Best,
Joram

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-10 09:40, Knut Petersen wrote:

Am 10.12.2016 um 00:36 schrieb Alexander Kobel:

[...] And with this, all of this week's issues of mine are worked
around, and I can proudly present a beautiful little setting of a
beautiful little piece by Reger... :-)


Those old settings by Max Reger are really music that must not be
forgotten. Nice to see that you published te score on cpdl.org. I'd
recommend some fine tunings of ties etc ... e.g. bars 18, 20 ...


True, especially for bar 20 on the SA staff. Didn't spot the collision 
there. Perhaps the most readable approach is to shift the soprano fis to 
the left of the alto a?



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-10 11:50, Michael Gerdau wrote:

And with this, all of this week's issues of mine are worked around, and
I can proudly present a beautiful little setting of a beautiful little
piece by Reger... :-)


Nice one
(Others already mentioned the two hyphen in bar 30)

Would you share the source(s)?


Hi Michael,

well, sure. Find them in this mail, but consider it work in progress, in 
particular for the "support libraries"... I didn't attach them to my 
first one (and didn't put them on CPDL yet) for two reasons:


First, the stylesheet.ily sets fonts in a way that requires a patched 
Lilypond (https://codereview.appspot.com/108700043). It is barely 
noticeable in this score, since I don't use small caps, but only change 
bold to demi-bold; so a definition like
  #(define fonts (make-pango-font-tree "RomandeADF Std" "RomandeADF No2 
Std" "Luxi Mono" (/ staffSize 20)))
instead of make-romande-biolinum-mplus-font-tree and setting 
LyricText.font-family = #'sans should give almost identical results with 
an upstream version.


Second, as mentioned, the notes and lyrics should be in an okay shape, 
but all the .ily's will need some care at some point, and at least 
comments telling from whom or where I stole that code from 
(LSR/OpenLilyLib/Mailing list).


Anyway, feel free to have a look (and/or chase down the problem with the 
new lyric hyphen ;-))!



Cheers,
Alexander


nacht.tar.gz
Description: application/gzip
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

Hi all,

On 2016-12-10 08:33, Noeck wrote:

Dear Alexander,

a very nice score!


thanks Joram and Knut.


I don't like to spoil it but in the last line (measure 30) I see an
extra hyphen.


I like that you spoil, that's why I posted it - always better to hame 
some more pairs of eyes look at it and give feedback. I (and diffpdf) 
did not spot that one, compared to the CPDL version where I "only" 
tweaked the standard LyricHyphen to approximately match the LyricText 
one in thickness and position...



I guess it is no problem to remove it though. It is in the
lyrics of the upper and lower staff inside the syllable "ten" of
"deuten". So probably not an issue of harms code but just "te -- n"
instead of "ten"?


Unfortunately, the issue only occurs only with Harm's snippet.
My first thought is some incompatibility with other overrides, like the 
center-on-word, the font settings, or a callback the removes short 
extenders. However, I can comment all of those out, and still see the 
superfluous hyphen.
And I have a hard time to break it down to a minimal example. E.g., I 
can reduce to bass only and the issue still persists. Changing the font 
back to the default also is of no help, but changing the margins (while 
having line breaks at the same positions) is. Coincidentally, the 
lyric-syllable-magnetic-snap (from openlilylib) also has trouble dealing 
with this measure, and contracts deu -- ten to one entity although there 
is plenty of space between.


But right now, my reduction of the score is a total mess with comments 
here and there; I'll need to systematically approach this one and report 
back.



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Michael Gerdau]

> And with this, all of this week's issues of mine are worked around, and
> I can proudly present a beautiful little setting of a beautiful little
> piece by Reger... :-)

Nice one
(Others already mentioned the two hyphen in bar 30)

Would you share the source(s)?

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

signature.asc
Description: This is a digitally signed message part.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Am 10.12.2016 um 00:36 schrieb Alexander Kobel:




Maybe minimum-distance may help here, not tested though.


AFAICS for now: Works like a charm. Thanks a ton again.

And with this, all of this week's issues of mine are worked around, and I can proudly present a beautiful little setting of a beautiful little piece by Reger... :-) 


There are two wrong hypens: Bar 30, lyrics of Soprano / Alto and Bass: An additional hyphen is 
printed below the "e" of "ten".

Those old settings by Max Reger are really music that must not be forgotten. 
Nice to see that you published te score on cpdl.org.
I'd recommend some fine tunings of ties etc ... e.g. bars 18, 20 ...

cu,
 Knut

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Dear Alexander,

a very nice score!

I don't like to spoil it but in the last line (measure 30) I see an
extra hyphen. I guess it is no problem to remove it though. It is in the
lyrics of the upper and lower staff inside the syllable "ten" of
"deuten". So probably not an issue of harms code but just "te -- n"
instead of "ten"?

Best,
Joram

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-07 23:59, Thomas Morley wrote:

2016-12-07 22:03 GMT+01:00 Simon Albrecht :

On 07.12.2016 11:45, Alexander Kobel wrote:


I'm not sure whether Harm's proof of concept also involved
pre-compile-time modifications.



It certainly didn’t; Harm is a Schemer, not a C++ guy :-)


Indeed.

So here a very first shot.
For now I let display the new _and_ the colored default LyricHyphen.
You'll see a drawback already: In tight situations the default gets
shortened until it vanishs. This is not possible or at least not
desirable for characters taken from a font, imho.
Iirc this was already mentioned in the discussion the tracker links to.
Maybe minimum-distance may help here, not tested though.


AFAICS for now: Works like a charm. Thanks a ton again.

And with this, all of this week's issues of mine are worked around, and 
I can proudly present a beautiful little setting of a beautiful little 
piece by Reger... :-)



Cheers,
Alexander


nacht.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-07 23:59, Thomas Morley wrote:

[...] So here a very first shot.
For now I let display the new _and_ the colored default LyricHyphen.
You'll see a drawback already: In tight situations the default gets
shortened until it vanishs. This is not possible or at least not
desirable for characters taken from a font, imho.
Iirc this was already mentioned in the discussion the tracker links to.
Maybe minimum-distance may help here, not tested though.


Yes, now that my memory is awake again, I seem to recall that I 
mentioned that few years ago already. At least shrinking should be 
undesirable for more than a very few percent of the width, similar to 
the microtype settings in the namesake LaTeX package.
Since I typically increase minimum-distance /and/ plan to revisit the 
magnetic-syllable-snap openlilylib snippet for this piece again, I hope 
that it won't be an issue.


Anyway, beautiful work, thanks a lot. I did not try it yet in real life, 
but will do so on the weekend and report back. In your test case, it 
works like a charm.



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Thomas Morley]

2016-12-07 22:03 GMT+01:00 Simon Albrecht :
> On 07.12.2016 11:45, Alexander Kobel wrote:
>>
>> I'm not sure whether Harm's proof of concept also involved
>> pre-compile-time modifications.
>
>
> It certainly didn’t; Harm is a Schemer, not a C++ guy :-)

Indeed.

So here a very first shot.
For now I let display the new _and_ the colored default LyricHyphen.
You'll see a drawback already: In tight situations the default gets
shortened until it vanishs. This is not possible or at least not
desirable for characters taken from a font, imho.
Iirc this was already mentioned in the discussion the tracker links to.
Maybe minimum-distance may help here, not tested though.

\version "2.19.52"

#(define (lh-test-stencil arg)
 (lambda (grob)
   (if (ly:stencil? (ly:lyric-hyphen::print grob))
   (let* ((stil (ly:lyric-hyphen::print grob))
  (x-ext (ly:stencil-extent stil X))
  (dash-period (ly:grob-property grob 'dash-period))
  (arg-stil (grob-interpret-markup grob arg))
  (arg-stil-x-ext (ly:stencil-extent arg-stil X))
  (length-to-print (interval-length x-ext))
  (guess (max 0 (truncate (/ length-to-print dash-period
  (guessed-args-line-length (* guess dash-period))
  (line-length-diff (- length-to-print guessed-args-line-length))
  (line-length-diff-for-each-arg (/ line-length-diff guess))
  (first-arg-length (+ dash-period line-length-diff-for-each-arg))
  (first-arg-end-coord
  (/ (* first-arg-length
(- (interval-length x-ext)
   (interval-length arg-stil-x-ext)))
 length-to-print))
  (list-of-starts
(map
  (lambda (n) (* n first-arg-end-coord))
  (iota (+ 1 guess)
 (ly:stencil-translate-axis
   (apply
 ly:stencil-add
 (map
   (lambda (x-val) (ly:stencil-translate-axis arg-stil x-val X))
   list-of-starts))
   (car x-ext) X))
   (ly:grob-suicide! grob

%%%
%% EXAMPLES
%%%

\paper { ragged-right = ##f }

\layout {
  \context {
\Score
\override NonMusicalPaperColumn #'line-break-permission = ##f
  }
}

newLH =
#(define-music-function (mrkp)(markup?)
#{
  \override LyricHyphen.after-line-breaking =
#(lambda (grob)
  (if (ly:stencil? (ly:lyric-hyphen::print grob))
  (ly:grob-set-property! grob 'stencil
(ly:stencil-add
  (stencil-with-color (ly:lyric-hyphen::print grob) red)
  ((lh-test-stencil mrkp ) grob)
#})


tstI = { c'2. c'4 }
tstII = { c'1 \break c'1 }
tstIII = { c'1 \break r1 c'1 }

lhTest =
#(define-music-function (mkp m i)(markup? ly:music? index?)
#{
<<
  \new Voice \repeat unfold $i $m
  \new Lyrics
\with { \newLH $mkp }
\lyricsto "" { \repeat unfold $i { voo -- doo }  }
>>
#})

\lhTest "~" \tstI 1
\lhTest "~" \tstI 2
\lhTest "~" \tstI 3
\lhTest "~" \tstI 4
\lhTest "~" \tstI 5
\lhTest "~" \tstI 6
\lhTest "~" \tstI 7
\lhTest "~" \tstI 8
\lhTest "~" \tstI 9
\lhTest "~" \tstI 10
\lhTest "~" \tstI 11
\lhTest "~" \tstI 12


\lhTest "~" \tstII 1

\lhTest "~" \tstIII 1

Cheers,
  Harm

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

Re: exchange LyricHyphen with a "proper" hyphen

[Noeck]

Dear Harm,

> Anyway, I tried some coding resulting in the attached image.

Wow. I should know it better by now, but time after time I am astonished
at what you are able to achieve.

Cheers,
Joram


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

Re: exchange LyricHyphen with a "proper" hyphen

[Simon Albrecht]

On 07.12.2016 11:45, Alexander Kobel wrote:
I'm not sure whether Harm's proof of concept also involved 
pre-compile-time modifications.


It certainly didn’t; Harm is a Schemer, not a C++ guy :-)

Best, Simon

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

Hi Knut,

thanks for looking into that. IIUC (and without looking into your code - 
is it on Github or otherwise publicly avaiable?), it seems that you 
essentially add a text-interface to LyricHyphen. That's what would have 
been my idea as well, if I were up to it.


Rebuilding is not a problem - I usually use a self-compiled version 
anyway, though I try to avoid relying on it too much. But this would be 
a change that you can do once and for all in a separate style file, and 
if you use a vanilla version, you can just resort to not include that part.


I'm not sure whether Harm's proof of concept also involved 
pre-compile-time modifications. If not, that would be an ever better 
option for my taste. Otherwise, I'll come back to you... ;-) Thanks!



Cheers,
Alexander


On 2016-12-07 11:37, Knut Petersen wrote:

Hi Alexander!


every now and then, I use a font for lyrics where the hyphen is quite
different from Lilypond's LyricHyphen (in particular, sometimes it's
slightly slanted). That combined with lyrics where a hyphen has to
appear looks, well, ugly. (Recent example: a repetition of part of a
word that has to be written as { ro -- sen-, ro -- sen -- rot }.)

I failed with [...]



Did anyone ever successfully try to do that, or has an idea how to
approach such a tweak?


Yes, there is a solution in my local git repository. To activate the
code you would include something like

 \override Lyrics.LyricText #'font-size = #+1.5

  \override Lyrics.LyricHyphen.use-markup = ##t
  \override Lyrics.LyricHyphen.text = "-"
  \override Lyrics.LyricHyphen #'font-size = #'1.5
  \override Lyrics.LyricHyphen #'font-name = "OffenbacherSchwab OT"
  \override Lyrics.LyricHyphen #'minimum-distance = #0.8

into \layout{}. It's on top of some other changes either not published
or not accepted, but I could tear it out.

Of course, you would need to rebuild lilypond as the solution requires
changes to the c++ sources.

cu,
 Knut


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

Re: exchange LyricHyphen with a "proper" hyphen

[Knut Petersen]

Hi Alexander!

every now and then, I use a font for lyrics where the hyphen is quite different from Lilypond's LyricHyphen (in particular, sometimes it's slightly slanted). That combined with lyrics where a hyphen has to appear looks, well, ugly. (Recent example: a repetition of part of a word that has to be 
written as { ro -- sen-, ro -- sen -- rot }.)


I failed with [...]



Did anyone ever successfully try to do that, or has an idea how to approach 
such a tweak?


Yes, there is a solution in my local git repository. To activate the code you 
would include something like

 \override Lyrics.LyricText #'font-size = #+1.5

  \override Lyrics.LyricHyphen.use-markup = ##t
  \override Lyrics.LyricHyphen.text = "-"
  \override Lyrics.LyricHyphen #'font-size = #'1.5
  \override Lyrics.LyricHyphen #'font-name = "OffenbacherSchwab OT"
  \override Lyrics.LyricHyphen #'minimum-distance = #0.8

into \layout{}. It's on top of some other changes either not published or not 
accepted, but I could tear it out.

Of course, you would need to rebuild lilypond as the solution requires changes 
to the c++ sources.

cu,
 Knut

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-07 00:10, Thomas Morley wrote:

2016-12-06 23:41 GMT+01:00 Alexander Kobel :

On 2016-12-06 23:28, Simon Albrecht wrote:


On 06.12.2016 23:00, Alexander Kobel wrote:


replace the LyricHyphen "elementary stencil" by a properly printed
hyphen from the LyricText font



A very good request :-)




Oh, right. Yeah, I know that guy. Horrible person - always annoys the hell
out of me. ;-)

Time flies. Just imagine how I'll be in a few years: when it won't take me
five years to forget my questions and answers anymore, but only five
minutes... ;-)



rofl

Anyway, I tried some coding resulting in the attached image.
I should probably work it out (right now it's only a test _if_ it's
possible), maybe I give it a try next weekend.


Wow, that's very promising. Looking forward!


Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Thomas Morley]

2016-12-06 23:41 GMT+01:00 Alexander Kobel :
> On 2016-12-06 23:28, Simon Albrecht wrote:
>>
>> On 06.12.2016 23:00, Alexander Kobel wrote:
>>>
>>> replace the LyricHyphen "elementary stencil" by a properly printed
>>> hyphen from the LyricText font
>>
>>
>> A very good request :-)
>> 
>
>
> Oh, right. Yeah, I know that guy. Horrible person - always annoys the hell
> out of me. ;-)
>
> Time flies. Just imagine how I'll be in a few years: when it won't take me
> five years to forget my questions and answers anymore, but only five
> minutes... ;-)


rofl

Anyway, I tried some coding resulting in the attached image.
I should probably work it out (right now it's only a test _if_ it's
possible), maybe I give it a try next weekend.

Cheers,
  Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

On 2016-12-06 23:28, Simon Albrecht wrote:

On 06.12.2016 23:00, Alexander Kobel wrote:

replace the LyricHyphen "elementary stencil" by a properly printed
hyphen from the LyricText font


A very good request :-)



Oh, right. Yeah, I know that guy. Horrible person - always annoys the 
hell out of me. ;-)


Time flies. Just imagine how I'll be in a few years: when it won't take 
me five years to forget my questions and answers anymore, but only five 
minutes... ;-)



Cheers,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[Simon Albrecht]

On 06.12.2016 23:00, Alexander Kobel wrote:
replace the LyricHyphen "elementary stencil" by a properly printed 
hyphen from the LyricText font


A very good request :-) 



Best, Simon

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

Re: exchange LyricHyphen with a "proper" hyphen

[Alexander Kobel]

Hi Abraham,

On 2016-12-06 23:14, tisimst wrote:

Alexander,
[...]
I failed with
   \override LyricHyphen.text = #"-"
   \override LyricHyphen.stencil = #lyric-text::print
trying to replace the LyricHyphen "elementary stencil" by a properly
printed hyphen from the LyricText font.
[...]

I've looked into this before, but it requires a complete re-write of the
stencil function because the "elementary stencil" is actually a single
dashed line spanner rather than a bunch of line segments. I haven't been
able to come up with a working solution, though.


Duh, that's what I was afraid to hear. Can't say I'm surprised...
I know that the LyricHyphen features much more than a simple glyph 
internally, including shortening the hyphens (which I personally 
dislike, and rather leave it out, but that's a different story). Hence I 
assumed that it's not as simple as just resetting the stencil, but I 
rather hoped that there is a single place to inject it in the spanner. 
Well, probably no luck. Then I'll have to resort to less extraordinary 
fonts and adjusting the height and extent of the LyricHyphen...



Thanks,
Alexander

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

Re: exchange LyricHyphen with a "proper" hyphen

[tisimst]

Alexander,

On Tue, Dec 6, 2016 at 2:59 PM, Alexander Kobel-2 [via Lilypond] <
ml-node+s1069038n197715...@n5.nabble.com> wrote:

> Dear all,
>
> every now and then, I use a font for lyrics where the hyphen is quite
> different from Lilypond's LyricHyphen (in particular, sometimes it's
> slightly slanted). That combined with lyrics where a hyphen has to
> appear looks, well, ugly. (Recent example: a repetition of part of a
> word that has to be written as { ro -- sen-, ro -- sen -- rot }.)
>
> I failed with
>\override LyricHyphen.text = #"-"
>\override LyricHyphen.stencil = #lyric-text::print
> trying to replace the LyricHyphen "elementary stencil" by a properly
> printed hyphen from the LyricText font. Did anyone ever successfully try
> to do that, or has an idea how to approach such a tweak?
>

I've looked into this before, but it requires a complete re-write of the
stencil function because the "elementary stencil" is actually a single
dashed line spanner rather than a bunch of line segments. I haven't been
able to come up with a working solution, though.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/exchange-LyricHyphen-with-a-proper-hyphen-tp197715p197716.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user