Re: Need edition-engraver-compatible extended glissandi, will pay for solution if necessary

[Jan-Peter Voigt]

Hello Mason,

I just have an idea how I *would* try to approach a solution. Once I 
needed a lyrics syllable attached to an extender line at a given time. 
So I used the extender stencil and first attached the syllable on top of 
it at a given x-offset. Then I added a property to the corresponding 
note to receive an accurate x-offset. I'll have a look into that code later.
I can't say if it is easy to apply this technique on the 
*non*-horizontal glissando-line. We'll see.


Jan-Peter


Am 19.05.2018 um 23:16 schrieb Mason Hock:

In my music, I frequently use
- glissandi during which the performer rearticulates with a particular rhythm, 
represented with headless steams
- glissandi that extend longer than a bar or otherwise require intermediate 
headless stems to clarify duration, with a slur indicating that the performer 
should not rearticulate

My current solution is based on the hack[1] recommended in the documentation. 
Here is an example:


\version "2.19.81"
\language "english"

% starts an extended glissand
glon = {
   \override NoteColumn.glissando-skip = ##t
   \hide NoteHead
   \override NoteHead.no-ledgers = ##t
   \override Stem.thickness = #0.5
   \override Accidental #'stencil = ##f
}
% terminates an extended glissando
gloff = {
   \revert NoteColumn.glissando-skip
   \undo \hide NoteHead
   \revert Glissando #'stencil
   \revert NoteHead.no-ledgers
   \revert Stem.thickness
   \revert Accidental #'stencil
}
% slightly increase slope of glissando so that line is
% not perfectly horizontal when glissing between notes
% on same staff line/space
glup = { \once\override Glissando.extra-dy = #0.5 }
gldown = { \once\override Glissando.extra-dy = #-0.5 }

\relative c' {
   \glup c8 \glissando \glon c-_ d-_ e-_ \tuplet 5/4 { e-_ f-_ g g a } |
   \gloff a a \gldown a \glissando \glon a a a \gloff af4 |
   \gldown af2 \glissando \gldown g4( \glissando \glon f |
   e) \gloff e r2 |
}


This hack has several flaws.
- The stems are all different distances from the glissando line.
- Articulations have a noticably inconsistent slope.
- Selecting the least-bad pitch for each hidden note is tedious.
- Even slight changes to horizontal spacing can ruin the vertical position of 
the hidden notes.
- The position of a stem is not musical content and should not be represented 
by a pitch.

These flaws add up to a serious problem: Not only is the stem placement 
regardless of which hidden pitches I choose, but because horizontal spacing 
affects which pitches are least-bad, there is no way to choose the hidden 
pitches to be optimal for multiple editions. In order to fix this with edition 
engraver, I would have to tweak each stem individually for each edition, which 
would not realistically be maintainable.

A proper implementation of extended glissandi would place each intermediate 
stem a fixed distance from the gliss line. It would also be nice to tweak the 
slope of all gliss lines globally, something I can not do now because the 
extra-dy value is different for ascending and descending glissandi, but this 
would be a convenience, not a necessity.

The ideal syntax would resemble this:

c8 \gliss-end c c c c \gliss-end f

and result in a gliss from c to f, where
- the intermediate eighth note stems are all exactly the same distance from the 
gliss line
- the slope of the gliss line is slightly increased like in my example above

However, the bare minimum I need is for the stems to be automatically 
positioned vertically, and (if I need to tweak the slope manually) for them to 
be positioned relative to the gliss line *after the slope tweak*.

I don't understand Scheme or Lilypond's internals well enough to do this 
myself. If the solution is non-trivial for someone who does know Scheme and and 
Lilypond well, enough, I am willing to pay them for their time spent on the 
solution. The solution could be in the form of an include, or a feature of 2.19.

If anyone can help me with this, please let me know approximately how many 
hours of work you would expect it to take and what you would consider fair 
compensation for the amount of time spent.

Thanks,

Mason

[1] 
http://lilypond.org/doc/v2.19/Documentation/notation/expressive-marks-as-lines#glissando



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




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

Re: naming a glyph

[David Kastrup]

David Kastrup  writes:

> Freeman Gilmore  writes:
>
>> ​
>>
>> Where are the rules for naming a glyph located?And where is the
>> list of *reserved
>> words*?
>
> The latter is in lily/lily-lexer.cc .  I have no idea whether there is a
> place in the internals

I mean, a place in the documentation.

> where you could see them listed.  At least I don't remember one.

-- 
David Kastrup

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

Re: naming a glyph

[David Kastrup]

Freeman Gilmore  writes:

> ​
>
> Where are the rules for naming a glyph located?And where is the
> list of *reserved
> words*?

The latter is in lily/lily-lexer.cc .  I have no idea whether there is a
place in the internals where you could see them listed.  At least I
don't remember one.

-- 
David Kastrup

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

naming a glyph

[Freeman Gilmore]

​

Where are the rules for naming a glyph located?And where is the
list of *reserved
words*?

Thank you,

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

Re: Combining full bar rests with omitted grobs in between

[Saul Tobin]

I wrote a function that does something similar to what you need. There may
be newer or better ways to do it, but it's what I use.

Saul

On Fri, May 18, 2018 at 1:12 AM, Davide Liessi 
wrote:

> Dear all,
> is there a way to combine the two full bar rests in one multimeasure
> rest in the following example?
>
> \version "2.19.81"
> \new Staff <<
>   \compressFullBarRests
>   {
> s1
> \once \omit Score.MetronomeMark
> \tempo "test"
>   }
>   {
> R1*2
>   }
> >>
>
> Use case: I have all tempo marks for the full score and parts in one
> variable, but I need to hide a couple of tempo marks in one of the
> parts (requested by the conductor).
>
> I tried the approaches mentioned in the thread
> http://lists.gnu.org/archive/html/lilypond-user/2014-11/msg00267.html
> but they didn't work, probably because omitting the grob only makes it
> invisible and with null extent but does not delete it.
>
> Is there a solution?
> Is there a way to actually delete an omitted grob?
>
> Best wishes.
> Davide
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>


rest_combiner.ily
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Need edition-engraver-compatible extended glissandi, will pay for solution if necessary

[Mason Hock]

In my music, I frequently use
- glissandi during which the performer rearticulates with a particular rhythm, 
represented with headless steams
- glissandi that extend longer than a bar or otherwise require intermediate 
headless stems to clarify duration, with a slur indicating that the performer 
should not rearticulate

My current solution is based on the hack[1] recommended in the documentation. 
Here is an example:


\version "2.19.81"
\language "english"

% starts an extended glissand
glon = {
  \override NoteColumn.glissando-skip = ##t
  \hide NoteHead
  \override NoteHead.no-ledgers = ##t
  \override Stem.thickness = #0.5
  \override Accidental #'stencil = ##f
}
% terminates an extended glissando
gloff = {
  \revert NoteColumn.glissando-skip
  \undo \hide NoteHead
  \revert Glissando #'stencil
  \revert NoteHead.no-ledgers
  \revert Stem.thickness
  \revert Accidental #'stencil
}
% slightly increase slope of glissando so that line is
% not perfectly horizontal when glissing between notes
% on same staff line/space
glup = { \once\override Glissando.extra-dy = #0.5 }
gldown = { \once\override Glissando.extra-dy = #-0.5 }

\relative c' {
  \glup c8 \glissando \glon c-_ d-_ e-_ \tuplet 5/4 { e-_ f-_ g g a } |
  \gloff a a \gldown a \glissando \glon a a a \gloff af4 |
  \gldown af2 \glissando \gldown g4( \glissando \glon f |
  e) \gloff e r2 |
}


This hack has several flaws.
- The stems are all different distances from the glissando line.
- Articulations have a noticably inconsistent slope.
- Selecting the least-bad pitch for each hidden note is tedious.
- Even slight changes to horizontal spacing can ruin the vertical position of 
the hidden notes.
- The position of a stem is not musical content and should not be represented 
by a pitch.

These flaws add up to a serious problem: Not only is the stem placement 
regardless of which hidden pitches I choose, but because horizontal spacing 
affects which pitches are least-bad, there is no way to choose the hidden 
pitches to be optimal for multiple editions. In order to fix this with edition 
engraver, I would have to tweak each stem individually for each edition, which 
would not realistically be maintainable. 

A proper implementation of extended glissandi would place each intermediate 
stem a fixed distance from the gliss line. It would also be nice to tweak the 
slope of all gliss lines globally, something I can not do now because the 
extra-dy value is different for ascending and descending glissandi, but this 
would be a convenience, not a necessity.

The ideal syntax would resemble this:

   c8 \gliss-end c c c c \gliss-end f

and result in a gliss from c to f, where
- the intermediate eighth note stems are all exactly the same distance from the 
gliss line
- the slope of the gliss line is slightly increased like in my example above

However, the bare minimum I need is for the stems to be automatically 
positioned vertically, and (if I need to tweak the slope manually) for them to 
be positioned relative to the gliss line *after the slope tweak*.

I don't understand Scheme or Lilypond's internals well enough to do this 
myself. If the solution is non-trivial for someone who does know Scheme and and 
Lilypond well, enough, I am willing to pay them for their time spent on the 
solution. The solution could be in the form of an include, or a feature of 2.19.

If anyone can help me with this, please let me know approximately how many 
hours of work you would expect it to take and what you would consider fair 
compensation for the amount of time spent.

Thanks,

Mason 

[1] 
http://lilypond.org/doc/v2.19/Documentation/notation/expressive-marks-as-lines#glissando


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

Re: Maintaining font-size regardless of staff-size

[David Kastrup]

Torsten Hämmerle  writes:

> dak wrote
>> David Kastrup 
>
>> dak@
>
>>  writes:
>> 
>> I think it's more likely that LilyPond messes up when reusing fonts with
>> a particular size under different circumstances and your "correction"
>> just keeps it from reusing a font, instead calculating a fresh one.
>
> By Belenos, right you are!
>
> The exact value of the additional homoeopathic "correctional" term doesn't
> even matter.
> 0.001 is too small, but changing it to 0.002 will suddenly change the
> spacing from "catastrophic" to "correct".
> Making it too big, however, will result in a noticeable change in glyph size
> (and spacing).
>
> Be that as it may, obviously we need to re-trigger /something/... 

I read in lily/modified-font-metric.cc the following:

Stencil
Modified_font_metric::text_stencil (Output_def *state,
const string ,
bool feta,
const string _str) const
{
  Box b;
  if (Pango_font *pf = dynamic_cast (orig_))
{
  Stencil stc = pf->text_stencil (state, text, feta, features_str);

  Box b = stc.extent_box ();

  b.scale (magnification_);
  Stencil scaled (b, stc.expr ());
  return scaled;
}

  return Font_metric::text_stencil (state, text, feta, features_str);
}

This only adjusts stencil dimensions for magnification_ without
adjusting the stencil.  For a Pango font, that is.

For a non-Pango font, it doesn't adjust anything.

I have really no clue about how font inclusion works but this appears
extraordinarily fishy.

-- 
David Kastrup

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

Re: Maintaining font-size regardless of staff-size

[Torsten Hämmerle]

dak wrote
> David Kastrup 

> dak@

>  writes:
> 
> I think it's more likely that LilyPond messes up when reusing fonts with
> a particular size under different circumstances and your "correction"
> just keeps it from reusing a font, instead calculating a fresh one.

By Belenos, right you are!

The exact value of the additional homoeopathic "correctional" term doesn't
even matter.
0.001 is too small, but changing it to 0.002 will suddenly change the
spacing from "catastrophic" to "correct".
Making it too big, however, will result in a noticeable change in glyph size
(and spacing).

Be that as it may, obviously we need to re-trigger /something/... 

Thanks,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: Maintaining font-size regardless of staff-size

[David Kastrup]

David Kastrup  writes:

> Torsten Hämmerle  writes:
>
>> Thomas Morley-2 wrote
>>> Hmm, there's still some horizontal difference.
>>
>> Hi Harm,
>>
>> The idea of adding 'pt was brilliant, because it lead me into the right
>> direction:
>>
>> *The exact reason...*
>> ... is the co-operation between the (outside) Pango world and the (inside)
>> TeX-like world:
>> An American (Pango) point is 1/72 inch, a TeX point used internally is
>> 1/72.27 inch - that's all!
>> This tiny deviation leads to an enormous mismatch between glyph and font
>> metrics scaling.
>
> Uh, that's 0.4% or so.  How does an "enormous mismatch" come about then?

I think it's more likely that LilyPond messes up when reusing fonts with
a particular size under different circumstances and your "correction"
just keeps it from reusing a font, instead calculating a fresh one.

-- 
David Kastrup

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

Re: Maintaining font-size regardless of staff-size

[David Kastrup]

Torsten Hämmerle  writes:

> Thomas Morley-2 wrote
>> Hmm, there's still some horizontal difference.
>
> Hi Harm,
>
> The idea of adding 'pt was brilliant, because it lead me into the right
> direction:
>
> *The exact reason...*
> ... is the co-operation between the (outside) Pango world and the (inside)
> TeX-like world:
> An American (Pango) point is 1/72 inch, a TeX point used internally is
> 1/72.27 inch - that's all!
> This tiny deviation leads to an enormous mismatch between glyph and font
> metrics scaling.

Uh, that's 0.4% or so.  How does an "enormous mismatch" come about then?

-- 
David Kastrup

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

Re: Maintaining font-size regardless of staff-size

[Torsten Hämmerle]

Thomas Morley-2 wrote
> Hmm, there's still some horizontal difference.

Hi Harm,

The idea of adding 'pt was brilliant, because it lead me into the right
direction:

*The exact reason...*
... is the co-operation between the (outside) Pango world and the (inside)
TeX-like world:
An American (Pango) point is 1/72 inch, a TeX point used internally is
1/72.27 inch - that's all!
This tiny deviation leads to an enormous mismatch between glyph and font
metrics scaling.

This can be corrected directly in the calculation of magnification by adding
a correctional value to ref-size:

 (magnification (/ size (+ ref-size 0.04215

11 * 72.27/72 - 11 = 0.04215

Using this effective magnification (also for baseline-skip and word-space),
the resulting texts will retain exactly the same glyph height and the same
spacing:

 

I've also added some TextScript \markup including skylines (can't be seen in
the above illustration), because this didn't work correctly either with the
original \abs-fontsize command.

%%

\version "2.19.81"

#(ly:set-option 'debug-skylines #t)

#(define-markup-command (abs-fontsize-torsten layout props size arg)
  (number? markup?)
  #:properties ((word-space 0.6) (baseline-skip 3))
  #:category font
  "Use @var{size} as the absolute font size (in points) to display
@var{arg}.
Adjusts @code{baseline-skip} and @code{word-space} accordingly.

@lilypond[verbatim,quote]
\\markup {
  default text font size
  \\hspace #2
  \\abs-fontsize #16 { text font size 16 }
  \\hspace #2
  \\abs-fontsize #12 { text font size 12 }
}
@end lilypond"
  (let* ((ref-size (ly:output-def-lookup layout 'text-font-size 11))
 (text-props (list (ly:output-def-lookup layout
'text-font-defaults)))
 (magnification (/ size (+ ref-size 0.04215
(interpret-markup
 layout
 (cons
  `((baseline-skip . ,(* magnification baseline-skip))
(word-space . ,(* magnification word-space))
(font-size . ,(magnification->font-size magnification)))
  props)
 arg)))

\header {
  title =
\markup
  \override #'(box-padding . 0)
  \box \concat {
\abs-fontsize-torsten #11 "X let’s see how long X"
\with-color #red \abs-fontsize #11 "XX"
  }
}

#(set-global-staff-size 18)
 \book { { b'1^\markup \abs-fontsize-torsten #20 "Test" } }

#(set-global-staff-size 26)
 \book { { b'1^\markup \abs-fontsize-torsten #20 "Test" } }

#(set-global-staff-size 10)
 \book { { b'1^\markup \abs-fontsize-torsten #20 "Test" } }

%


All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: Overriding Score.SystemStartBar once at the beginning

[Thomas Morley]

2018-05-19 12:06 GMT+02:00 jasonflatley :
> I am trying to make a jazz lead sheet template. One requirement is that the
> treble clef and key signature should only appear in the first system, and
> the subsequent systems should begin with a bar line. This picture shows what
> I have so far (generated by the lilypond code at the end of this message).
>
> 
>
> I don't want the bar line at the very beginning, to the left of the treble
> clef.
>
> So I tried to override Score.SystemStartBar for just the first system. I
> tried various permutations of \override and \once in either the layout block
> or near the %%% in the melody section, using statements like the following:
> --\override Score.SystemStartBar #'collapse-height = #30
> --\override Score.SystemStartBar #'X-offset = -10
> --\override Score.SystemStartBar.break-visibility = #'#(#f #f #f)
>
> I can't seem to override anything once, and then set it back.
>
> Any suggestions?

SystemStartBar is usually a multi-line (and thus broken) spanner.
To affect only a certain part of it you need to use the technics explained here:
http://lilypond.org/doc/v2.19/Documentation/extending-big-page#difficult-tweaks

Leading to the argument of the 'after-line-breaking-override below.

I post the whole reformated layout. Please obtain not to exceed 80
characters per line in code.
Otherwise comments, broken by an email-client will mess all up.

\layout {
  \context {
\Score
\remove "Bar_number_engraver"
% make only the first clef visible
\override Clef #'break-visibility = #'#(#f #f #f)
% make only the first time signature visible
\override KeySignature #'break-visibility = #'#(#f #f #f)
\override SystemStartBar #'after-line-breaking =
  #(lambda (grob)
(let* ((orig (ly:grob-original grob))
   (siblings (if (ly:grob? orig)
 (ly:spanner-broken-into orig) '(

(ly:grob-set-property! grob 'collapse-height
  (if (and (pair? siblings) (equal? grob (car siblings)))
  10
  1
  }
}

HTH,
  Harm

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

Re: Combining full bar rests with omitted grobs in between

[David Kastrup]

Davide Liessi  writes:

> 2018-05-18 11:02 GMT+02:00 David Kastrup :
>> You'd need to work with tags and alternative passages.
>
>> Thomas Morley  writes:
>>> The different length of s1 and R1*2 will always result into a splitted
>>> MultiMeasureRest, afaik.
>
> Thanks for your answers.
>
> For the record, I solved my problem using tags to filter the \tempo
> marks and then applying \mergeSkips from
> http://lists.gnu.org/archive/html/lilypond-user/2013-12/msg01085.html
> to merge the spacer rests and avoid splitting the multimeasure rests
> (in the original file I had spacer rests filling the full length of
> the piece).
>
> Indeed, I noticed that elements inside removed tags are not shown by
> \displayMusic (hence \mergeSkips can merge the spacer rests).
> At what point is tagged content removed?

When you call \remove/keepWithTags.  The music function returns the
cleaned music expression.  This is completely obvious and transparent
functionality, meaning that if you call \remove/keepWithTags inside of
\relative, you might get inconvenient octave differences due to the
removed sequences.

> What parts of LilyPond's code are responsible for that?

\remove/keepWithTags .  They are only called explicitly by the user so
far.  It's conceivable that we'll add command line options for such
effects and/or some default tags for midi/layout processing, but so far
nothing of the kind has been done yet.  And the midi/layout stuff would
actually be tricky since the obvious place for such processing is during
scorification, and at that time the output to be used is not yet fixed.
And we don't have similarly employed hooks during "bookification" so it
would seem a bit heavy-handed to introduce that kind of stuff there.

-- 
David Kastrup

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

Re: Combining full bar rests with omitted grobs in between

[Davide Liessi]

2018-05-18 11:02 GMT+02:00 David Kastrup :
> You'd need to work with tags and alternative passages.

> Thomas Morley  writes:
>> The different length of s1 and R1*2 will always result into a splitted
>> MultiMeasureRest, afaik.

Thanks for your answers.

For the record, I solved my problem using tags to filter the \tempo
marks and then applying \mergeSkips from
http://lists.gnu.org/archive/html/lilypond-user/2013-12/msg01085.html
to merge the spacer rests and avoid splitting the multimeasure rests
(in the original file I had spacer rests filling the full length of
the piece).

Indeed, I noticed that elements inside removed tags are not shown by
\displayMusic (hence \mergeSkips can merge the spacer rests).
At what point is tagged content removed?
What parts of LilyPond's code are responsible for that?

Best wishes.
Davide

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

Re: Maintaining font-size regardless of staff-size

[Thomas Morley]

2018-05-19 16:02 GMT+02:00 Thomas Morley :
> 2018-05-16 16:26 GMT+02:00 David Sumbler :
>> At the moment I define variables for formatting title, composer etc. at
>> the start of a score separately for each staff-size that I use.
>>
>> A simple question: is there a way of getting the same layout and font-
>> sizes for the opening headings of, say, a part with 20-point staves and
>> a full score with 16-point staves without having to define the layout
>> twice?
>>
>> Using \abs-fontsize does not work, because the horizontal spacing is
>> still affected by the global staff size.
>>
>> David
>
>
> Hi David,
>
> I tried this and that and now come up with below.
>
> Seems the results are consistent, I recommend further testings, though.
> I'm not sure why it seems to work now, but I'm not a font-expert.
> The text is now a (very) little taller, but I'd say it's a good trade-off


Hmm, there's still some horizontal difference.
I'll return to it later, have to leave now.

Cheers,
  Harm

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

Re: Procedure for set-paper-size in \paper ?

[David Kastrup]

Thomas Morley  writes:

> 2018-05-19 9:45 GMT+02:00 David Kastrup :
>> Thomas Morley  writes:
>
> Uh, oh, another typo/oversight.
> Note to self: Don't post anything while being overtired...
>
>>
>> Now if you want to execute only conditionally, you either need to wrap
>> in lambdas or use a macro rather than a procedure:
>>
>> #(define-macro (proc bool x y)
>>(if bool x y))
>>
>> \paper {
>>   #(if #t (set-paper-size "a8" 'landscape) (set-paper-size "a8"))
>> }

Talk about type/oversight: I don't even use the proc macro here.  You
need to write it instead of "if" in the paper block, or the example does
not make a whole lot of sense.

>> Note that this will only work with a _literal_ #f or #t as argument:
>> you'll likely want to have some actual condition evaluated at runtime,
>> like some variable name.  Then you'll need to write
>>
>> #(define-macro (proc bool x y)
>>   `(if ,bool ,x ,y))
>
> Thanks for the insights,

The last bit is a whole lot of quasiquote obviously equivalent to

(list 'if bool x y)

But in the context of macro expansions, using quasiquotes is sort of
customary for emphasizing the structure of what gets returned rather
than how it is getting built.

-- 
David Kastrup

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

Re: Maintaining font-size regardless of staff-size

[Thomas Morley]

2018-05-16 16:26 GMT+02:00 David Sumbler :
> At the moment I define variables for formatting title, composer etc. at
> the start of a score separately for each staff-size that I use.
>
> A simple question: is there a way of getting the same layout and font-
> sizes for the opening headings of, say, a part with 20-point staves and
> a full score with 16-point staves without having to define the layout
> twice?
>
> Using \abs-fontsize does not work, because the horizontal spacing is
> still affected by the global staff size.
>
> David


Hi David,

I tried this and that and now come up with below.

Seems the results are consistent, I recommend further testings, though.
I'm not sure why it seems to work now, but I'm not a font-expert.
The text is now a (very) little taller, but I'd say it's a good trade-off
.
Looking at the output of the examples one can definetly state
abs-fontsize is buggy like hell.


#(define-markup-command (abs-fontsize-harm layout props size arg)
  (number? markup?)
  #:properties ((word-space 0.6) (baseline-skip 3))
  #:category font
  "Use @var{size} as the absolute font size (in points) to display @var{arg}.
Adjusts @code{baseline-skip} and @code{word-space} accordingly.

@lilypond[verbatim,quote]
\\markup {
  default text font size
  \\hspace #2
  \\abs-fontsize #16 { text font size 16 }
  \\hspace #2
  \\abs-fontsize #12 { text font size 12 }
}
@end lilypond"
  (let* ((ref-size (ly:output-def-lookup layout 'text-font-size 12))
 (text-props (list (ly:output-def-lookup layout 'text-font-defaults)))
 (magnification (/ size ref-size)))

(interpret-markup
 layout
 (cons
  `((baseline-skip . ,(* magnification baseline-skip))
(word-space . ,(* magnification word-space))
(font-size
  .
  ,(+ (magnification->font-size magnification)
  (ly:output-def-lookup layout 'pt
  props)
 arg)))


\header {
  title =
\markup
  \override #'(box-padding . 0)
  \box
  \line \box {
\abs-fontsize-harm #10 "Absolute Font Size"
\abs-fontsize #10 "Absolute Font Size"
  }
}

#(set-global-staff-size 26)
 \book { { b'1 } }

#(set-global-staff-size 20)
 \book { { b'1 } }

#(set-global-staff-size 10)
 \book { { b'1 } }


Cheers,
  Harm

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

Re: Procedure for set-paper-size in \paper ?

[Thomas Morley]

2018-05-19 9:45 GMT+02:00 David Kastrup :
> Thomas Morley  writes:
>
>> Hi all,
>>
>> (1)
>> consider the following code (working as expected):
>>
>> \paper {
>>   #(if #t (set-paper-size "a8" 'landscape) #(set-paper-size "a8"))
>> }
>>
>> \score { { R1 } \layout { ragged-right = ##f } }
>>
>> Switching from #t to #f results in different paper-size, as desired.
>
> Unlikely as you write #(set-paper-size ...) here, see below.
>
>>
>> (2)
>> But trying to put it in a procedure, it always returns the true-case:
>>
>> #(define (proc bool x y)
>>   (if bool x y))
>>
>> \paper {
>>   #(proc #f (set-paper-size "a8" 'landscape) #(set-paper-size "a8"))
>> }
>
> Uh, the return value is irrelevant.  It always _executes_ the true case.
> It also executes the false case but that is not overly interesting since
> the false case is a vector consisting of the elements 'set-paper-size
> and "a8" since you write #(...) while already in Scheme, the syntax for
> vector literals.

Uh, oh, another typo/oversight.
Note to self: Don't post anything while being overtired...

>
> Now if you want to execute only conditionally, you either need to wrap
> in lambdas or use a macro rather than a procedure:
>
> #(define-macro (proc bool x y)
>(if bool x y))
>
> \paper {
>   #(if #t (set-paper-size "a8" 'landscape) (set-paper-size "a8"))
> }
>
> Note that this will only work with a _literal_ #f or #t as argument:
> you'll likely want to have some actual condition evaluated at runtime,
> like some variable name.  Then you'll need to write
>
> #(define-macro (proc bool x y)
>   `(if ,bool ,x ,y))
>
> --
> David Kastrup

Thanks for the insights,
  Harm

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

Overriding Score.SystemStartBar once at the beginning

[jasonflatley]

I am trying to make a jazz lead sheet template. One requirement is that the
treble clef and key signature should only appear in the first system, and
the subsequent systems should begin with a bar line. This picture shows what
I have so far (generated by the lilypond code at the end of this message).


 

I don't want the bar line at the very beginning, to the left of the treble
clef.

So I tried to override Score.SystemStartBar for just the first system. I
tried various permutations of \override and \once in either the layout block
or near the %%% in the melody section, using statements like the following:
--\override Score.SystemStartBar #'collapse-height = #30
--\override Score.SystemStartBar #'X-offset = -10
--\override Score.SystemStartBar.break-visibility = #'#(#f #f #f)

I can't seem to override anything once, and then set it back.

Any suggestions?



\version "2.18.2"

\header {
title = "First System Bar Line Example"
}

\paper {
indent = 0\mm
}

\layout {
\override Score.Clef #'break-visibility = #'#(#f #f #f) % make only the
first clef visible
\override Score.KeySignature #'break-visibility = #'#(#f #f #f) % make only
the first time signature visible
\override Score.SystemStartBar #'collapse-height = #1 % allow single-staff
system bars
\context {\Score \remove "Bar_number_engraver"}
}


melody = \relative c'' {  
  
%%% Try to put something here to make just the bar line to left of treble
clef disappear

\numericTimeSignature
c4 c c c 
c c c c
c c c c
c c c c \break

c4 c c c 
c c c c
c c c c
c c c c \break

c4 c c c 
c c c c
c c c c
c c c c \bar "|."

}


\score {<<\new Staff { \melody }>>}




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: spacing of gracenote beams

[Torsten Hämmerle]

Amy McGlothlin wrote
> Is there something I can adjust to make the spacing of the stems
> of the gracenotes equal in this case?

Hello Amy,

While, as Andrew pointed out, grace note beaming in general may leave
something to be desired, the special bagpipe grace ornaments are a case of
their own:
Each of them has been specially defined in bagpipe.ly and I agree that the
spacing of \grip isn't very balanced because the second G "slips" below the
d far above.

But, fortunately, this can be corrected by just providing a custom
definition of \grip: when applying some extra \stemspace, everything can be
shifted to obtain a more balanced look. This has been done in some standard
definitions, it hasn't been done for \grip, though.

After including "bagpipe.ly", you can change/add whatever you want, e.g.:

  grip  = { \pgrace { G32[ \stemspace #'(0 . 0.4) d G] } }

\stemspace in this case just adds a bit of space to the right of the middle
stem.

And that's what it looks like (comparing n the original/adapted spacing):

 

Beannachtaí,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

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

Re: Procedure for set-paper-size in \paper ?

[David Kastrup]

Thomas Morley  writes:

> Hi all,
>
> (1)
> consider the following code (working as expected):
>
> \paper {
>   #(if #t (set-paper-size "a8" 'landscape) #(set-paper-size "a8"))
> }
>
> \score { { R1 } \layout { ragged-right = ##f } }
>
> Switching from #t to #f results in different paper-size, as desired.

Unlikely as you write #(set-paper-size ...) here, see below.

>
> (2)
> But trying to put it in a procedure, it always returns the true-case:
>
> #(define (proc bool x y)
>   (if bool x y))
>
> \paper {
>   #(proc #f (set-paper-size "a8" 'landscape) #(set-paper-size "a8"))
> }

Uh, the return value is irrelevant.  It always _executes_ the true case.
It also executes the false case but that is not overly interesting since
the false case is a vector consisting of the elements 'set-paper-size
and "a8" since you write #(...) while already in Scheme, the syntax for
vector literals.

Now if you want to execute only conditionally, you either need to wrap
in lambdas or use a macro rather than a procedure:

#(define-macro (proc bool x y)
   (if bool x y))

\paper {
  #(if #t (set-paper-size "a8" 'landscape) (set-paper-size "a8"))
}

Note that this will only work with a _literal_ #f or #t as argument:
you'll likely want to have some actual condition evaluated at runtime,
like some variable name.  Then you'll need to write

#(define-macro (proc bool x y)
  `(if ,bool ,x ,y))

-- 
David Kastrup

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