Re: Lyricmode Voices within Repeat Volta

[Valentin Villenave]

On 2/2/19, Mike iLL  wrote:
> I seem to be almost there, but the repeat signs are not produced by the
> following code

Greetings,
there are spurious curly braces in your code. I’ve removed them and
replaced one \new Voice with \context Voice (which allows you to
re-use an existing context rather than creating a new one every time):

%

melody = \relative c'' {
  \clef treble
  \key c \major
  \time 3/4
  \set Score.voltaSpannerDuration = #(ly:make-moment 3/4)
  #(ly:expect-warning "cannot end volta")
  \repeat volta 2 {
\new Voice = "chorus" {
  \voiceOne
  c2. | d | e | d |
  c |
}
e4 d c | e4 d c | e4 d c |
  }
  \alternative {
\new Voice = "verse" {
  c2. | d | e | f |
  g | f | e | d |
}
\context Voice = "verse" {
  c | d | e | f |
  e | f | e | c |
}
  }
}


chorus =  \lyricmode {
  These are words they are.
}

verse =  \lyricmode {
  This one here will
  be the first verse.
  This one here will
  be the se -- cond.
}


harmonies = \chordmode {
  c2.
}

\score {
  <<
\new ChordNames {
  \set chordChanges = ##t
  \harmonies
}
\new Staff  {
  \new Voice = "main" { \melody }
}
\new Lyrics \lyricsto "chorus" \chorus
\new Lyrics \lyricsto "verse" \verse
  >>
}

%

Hope this helps!

Cheers,
V.

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

Re: Can we change text font while keep it italic?

[Fan Hongtao]

Aaron,

Thank you for your help & Happy Spring Festival
 .

On Tue, Jan 29, 2019 at 11:56 PM Aaron Hill 
wrote:

> On 2019-01-29 12:51 am, Fan Hongtao wrote:
> > User backend properties
> > <
> http://lilypond.org/doc/v2.18/Documentation/internals/user-backend-properties
> >
> > says:
> >
> >> font-name (string)
> >> Specifies a file name (without extension) of the font to load. This
> >> setting overrides
> >> selection using font-family, font-series and font-shape.
> >
> > So I try to reset these properties.
> >
> > \version "2.18.2"
> > \markup {
> >   \override #'(font-name . "Century")
> >   \override #'(font-family . roman)
> >   \override #'(font-series . medium)
> >   \override #'(font-shape . italic)
> >   \italic { Hello, world. }
> > }
> >
> > Unfortunately, it does not work. Any suggestion?
>
> When you specify font-name, you are effectively telling LilyPond not to
> use font-family, font-series or font-shape.  That is what the
> documentation means when it says that setting overrides font selection.
> Commands like \italic will have no effect once you have set a font-name.
>   See the following:
>
> 
> \version "2.19.82"
>
> \markup {
>\override #'(font-name . "Roboto") "Regular"
>\override #'(font-name . "Roboto, Bold") "Bold"
>\override #'(font-name . "Roboto, Italic") "Italic"
> }
>
> \paper { #(define fonts (set-global-fonts #:sans "Roboto")) }
> \markup \sans { "Regular" \bold "Bold" \italic "Italic" }
> 
>
> The first case above uses the font-name to explicitly select a font.
> Note that you must include the style within the name.  This option is
> useful for one-off fonts.
>
> The second case above redefines one of the provided font families and,
> as such, will work with the markup commands like \italic.  This option
> is best for most general use, as it ensure consistent font usage
> throughout a document.
>
> LilyPond defines three font families for text: roman, sans, and
> typewriter.  With a little bit of work, you technically can define your
> own family in addition to these:
>
> 
> \version "2.19.82"
>
> \paper {
>#(define fonts
>  (let ((n (set-global-fonts))
>(factor (/ staff-height pt 20)))
>(add-pango-fonts n 'handwriting "Alex Brush" (* 1.5 factor))
>n))
> }
>
> #(define-markup-command (handwriting layout props arg) (markup?)
>(interpret-markup layout
>  (prepend-alist-chain 'font-family 'handwriting props) arg))
>
> \markup { This is \handwriting hand-written text. }
> 
>
> -- Aaron Hill___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>


-- 
Best Wishes,
Fan Hongtao

I have a dream.
http://fanhongtao.github.io/ 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Please test new lilypond installers

[Karlin High]

> > ld-elf.so.1: Shared object "libm.so.4" not found, required by "lilypond"
> >
> > Are there any further efforts anyone would like to see made here?
>
> Maybe, installing compat6x package is required.

# pkg install compat6x-amd64

...and it did indeed fix the issue. LilyPond seems fully functional.

Next, I want to make a FreeBSD 32-bit VM, and see about reviving an
iMac G5 to test the PowerPC installers. Although I doubt there's a
very big user base for those.
-- 
Karlin High
Missouri, USA

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

Lyricmode Voices within Repeat Volta

[Mike iLL]

What I’m aiming to do is have a “chorus” which includes a non-lyrical ending, 
followed again by verses, each with varied notation.

It looks like:

START SONG
Melody and Lyrics
Melody Only
FIRST ENDING
Melody and Lyrics
SECOND ENDING
Melody and Lyrics
REPEAT SIGN

I imagine I would want:

Repeat Volta
Voice associated with \lyricsto.
Voice not associated with \lyricsto.
Alternative
Voice associated with \lyricsto.
Alternative
Voice associated with \lyricsto.

I seem to be almost there, but the repeat signs are not produced by the 
following code:

melody = \relative c'' {
  \clef treble
  \key c \major
  \time 3/4 
  \set Score.voltaSpannerDuration = #(ly:make-moment 3/4)
  #(ly:expect-warning "cannot end volta") 
  \repeat volta 2 {
\new Voice = "chorus" {
\voiceOne 
c2. | d | e | d |
c |
}
e4 d c | e4 d c | e4 d c |
}
\alternative {
\new Voice = "verse" {
{
c2. | d | e | f | 
g | f | e | d | 
}
{
c | d | e | f | 
e | f | e | c | 
}
}
}
}

chorus =  \lyricmode {
These are words they are.
}

verse =  \lyricmode {
This one here will 
be the first verse.
This one here will
be the se -- cond.
}


harmonies = \chordmode {
c2.
}

\score {
  <<
\new ChordNames {
  \set chordChanges = ##t
  \harmonies
}
\new Staff  {
\new Voice = "main" { \melody }
}
\new Lyrics \lyricsto "chorus" \chorus
\new Lyrics \lyricsto "verse" \verse
  >>

I’m not sure if that’s because of the \new Voice within the \alternative 
section, or perhaps something else. Maybe the approach here is totally off-base.

Thanks a lot, community, for your feedback.


Mike iLL Kilmer
m...@madhappy.com
http://www.madhappy.com



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

Re: select a note in a chord

[Valentin Villenave]

On 2/2/19, David Kastrup  wrote:
> What you flatteringly call "my" thought would additionally maintain
> "circular" order of the pitches, basically rotating pitches and then
> octavating as needed to make sure that later pitches don't end up before
> earlier pitches.

Yep. That would be a great idea… now that you mention it :-)

> Maybe the cleanest in a musical sense would be if an "inversion" split
> the set of pitches into two, the ones preceding the inversion point and
> the ones afterwards and then raise the octaves of the preceding pitches
> en bloc such that the first inverted pitch becomes higher than the last
> non-inverted pitch.

That’s more or less what I have in mind. Now I have to devise a
somehow not-entirely-ugly implementation, which is where it gets
unnatural to me.

> That would not be exactly like repeated application of \raiseNote (which
> could in theory end up "flattening" more than one interval happening to
> be larger than an octave)

Indeed. Flattened intervals are the antithesis of what we’re looking
for here (if anything, interesting voicings come down to doing the
opposite: injecting larger-than-octave intervals inside clustered
chords primarily consisting of many seconds and thirds).

Cheers,
V.

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

Re: text block as spanner

[David Nalesnik]

Hi,

On Sat, Feb 2, 2019 at 2:13 PM Thomas Morley  wrote:
>
> Am Sa., 2. Feb. 2019 um 21:09 Uhr schrieb Thomas Morley
> :
>
> > A bold workaround is to define the whole infrastructure for
> > TextSpanners with new/renamed events (class and type), grobs,
> > engravers and
> > start/stop-commands.
>
> I forgot to point to a limitation
> The provided 'text-spanner->text' doesn't care for line-breaks.
>
> Cheers,
>   Harm

There is this: https://www.mail-archive.com/lilypond-user@gnu.org/msg105826.html

Not sure if anything needs to be updated.

Best,
David

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

Re: text block as spanner

[Thomas Morley]

Am Sa., 2. Feb. 2019 um 21:09 Uhr schrieb Thomas Morley
:

> A bold workaround is to define the whole infrastructure for
> TextSpanners with new/renamed events (class and type), grobs,
> engravers and
> start/stop-commands.

I forgot to point to a limitation
The provided 'text-spanner->text' doesn't care for line-breaks.

Cheers,
  Harm

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

Re: select a note in a chord

[David Kastrup]

Valentin Villenave  writes:

> On 1/29/19, Davide Bonetti  wrote:
>> Ok, now it works well!
>
> Greetings everybody,
>
> David K. raised an interesting question with regard to the
> \invertChords function:
> https://codereview.appspot.com/365840043/#msg18
>
> Basically (IIUC), he’s thinking that
>
> \invertChords 1 
>
> should ideally result in
>
> 
>
> rather than
>
> 
>
> (as the current implementation produces).
>
> Any thoughts?

David Kastrup did not think anything like that.  While it seems like an
actually quite worthwhile thought, my concern in the review rather was
that with the c'' ending up in the middle of the result chord, it will
come up earlier for another octavation in higher-numbered inversions
than the f'' would.  So my idea rather was to not use repeatedly a 2nd
inversion for the sake of generating higher inversions but rather figure
out the notes to be octavated from the initial chord and then octavate
all of them at once, not disturbing their relative order.

What you flatteringly call "my" thought would additionally maintain
"circular" order of the pitches, basically rotating pitches and then
octavating as needed to make sure that later pitches don't end up before
earlier pitches.

That could end up saner and it would actually work in repeated
application of \raiseNote without requiring rewriting the internals of
\invertChords .

My objection was more addressing a mathematical/programming
inconsistency rather than bothering with musical sense.  But addressing
this from the musical end, regarding its actual effect rather than its
logical ramifications, might be a saner approach.

Maybe the cleanest in a musical sense would be if an "inversion" split
the set of pitches into two, the ones preceding the inversion point and
the ones afterwards and then raise the octaves of the preceding pitches
en bloc such that the first inverted pitch becomes higher than the last
non-inverted pitch.

That would not be exactly like repeated application of \raiseNote (which
could in theory end up "flattening" more than one interval happening to
be larger than an octave) but probably be the most "musically" correct
and predictable way to do this.

-- 
David Kastrup

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

Re: text block as spanner

[Thomas Morley]

Am Do., 31. Jan. 2019 um 10:27 Uhr schrieb Leo Correia de Verdier
:
>
> Dear List!
>
> I’m still learning lilypond and working on a piece with long text 
> instructions that appear over a note or group of notes. So far I have managed 
> to achieve this by hacking off the stencils from text spanners and replacing 
> them with the line wrapped markup, but I feel there should be a neater 
> solution out there that I just haven’t thought or learned about. This hack 
> has also reached it’s limits because it has created the need for multiple 
> simultaneous text spanners (not in the example). While I could go further 
> down the hack road by placing additional spanners in separate voices with 
> spacer rests or starting to destroy trill spanners too, that would just 
> increase the mess. Could you please point me towards a tidier path? :)
>
> Thanks a lot!
>
> /Leo
>
> \version "2.19.80"
>
> longTextInstr =
> #(define-music-function (alongtext)
>(string?)
>#{
>  \once \override Staff.TextSpanner.stencil =
>  #(lambda (grob)
> (let* ((grob-X (interval-length
> (ly:stencil-extent (ly:line-spanner::print grob) X)))
>(layout (ly:grob-layout grob))
>(props (ly:grob-alist-chain grob
> (ly:output-def-lookup layout
>   'text-font-defaults
>
>   (ly:text-interface::interpret-markup layout props
> #{ \markup {
>   \override #(cons 'line-width grob-X)
>   \wordwrap-string #alongtext }
> #})
>   ))
>#}
>)
>
> \relative {
>   c'1 \longTextInstr "this is a long text instruction to be printed 
> line-wrapped over a group of notes"
>   d \startTextSpan
>   e f
>   e \stopTextSpan
>   d
> }
Hi Leo,

you're code is fine. It does exactly what it is supposed to do.
You could consider, making it a tweak and you could use
'grob-interpret-markup' to avoid finding 'layout' 'props' yourself.

Though, it's a kown limitation that you can't use more than one
TextSpanner per Voice.

You already found the usual workaround: Additional Voices.

A bold workaround is to define the whole infrastructure for
TextSpanners with new/renamed events (class and type), grobs,
engravers and
start/stop-commands.

\version "2.19.82"

\include "multiple-spanner-grobs-engravers.ly"

\createSpannersAndEngravers  #'(X Y Z)

\layout {
  \context {
\Global
\grobdescriptions #all-grob-descriptions
  }
  \context {
\Voice
\consists \XTextSpannerEngraver
\consists \YTextSpannerEngraver
\consists \ZTextSpannerEngraver
  }
}

#(define (text-spanner->text text)
  (lambda (grob)
(let* ((grob-X
 (interval-length
   (ly:stencil-extent (ly:line-spanner::print grob) X
  (grob-interpret-markup grob
#{
  \markup \override #(cons 'line-width grob-X) \wordwrap-string #text
#}

txtI =
"this is a long text instruction to be printed line-wrapped over a group of
notes"


txtII =
"this is another long text instruction to be printed line-wrapped below a group
of notes"

\relative {
  c'1
  d
-\tweak stencil #(text-spanner->text txtI)
\startTextSpan
-\tweak stencil #(text-spanner->text txtII)
_\x-start
  e f
  e \stopTextSpan
  d \x-stop
}

HTH,
  Harm
%% Example for creating multiple custom text spanners
%% Based on:
% http://lilypond.org/doc/v2.18/input/regression/collated-files.html
% look for:
% ‘scheme-text-spanner.ly’

\version "2.19.82"

#(define (add-grob-definition grob-name grob-entry)
   (let* ((meta-entry   (assoc-get 'meta grob-entry))
  (class(assoc-get 'class meta-entry))
  (ifaces-entry (assoc-get 'interfaces meta-entry)))
 (set-object-property! grob-name 'translation-type? ly:grob-properties?)
 (set-object-property! grob-name 'is-grob? #t)
 (set! ifaces-entry (append (case class
  ((Item) '(item-interface))
  ((Spanner) '(spanner-interface))
  ((Paper_column) '((item-interface
 paper-column-interface)))
  ((System) '((system-interface
   spanner-interface)))
  (else '(unknown-interface)))
ifaces-entry))
 (set! ifaces-entry (uniq-list (sort ifaces-entry symbolsymbol (format #f "~aTextSpanEvent" name))
(ly:camel-case->lisp-identifier 
  (string->symbol (format #f "~aTextSpanEvent" name)))
(string->symbol (format #f "~aTextSpanner" name))
(string->symbol (format #f "~aTextSpannerEngraver" name))
(string->symbol (string-downcase (format #f "~a-start" name)))
(string->symbol (string-downcase (format #f "~a-stop" name)
name-list))
(

Re: "Mensurstriche" (barlines between systems) and Repeat signs.

[Thomas Morley]

Hi Aaron,

I'm a bit verbose below (even repeating things you already know),
because we're on the user-list and I hope more folk gets involved that
way.

Am Sa., 2. Feb. 2019 um 14:21 Uhr schrieb Aaron Hill :
>
> On 2019-02-02 2:29 am, Thomas Morley wrote:
> > Am Fr., 1. Feb. 2019 um 20:19 Uhr schrieb Malte Meyn
> > :
> >>
> >> Am 01.02.19 um 18:42 schrieb Aaron Hill:
> >> > That very much sounds like a bug and should be reported.  The final
> >> > argument is the span setting which should be agnostic of start and end
> >> > styles and vice versa.
> >> Hm … I don’t think that this is correct: How about
> >> \defineBarLine ".|:-||" #'("||" ".|:" ".|")
> >> ? If the span bar ".|" would be used at all positions, the output at
> >> line breaks wouldn’t be correct: the "||" bar at the line end would
> >> have
> >> a ".|" span bar too …
> >
> > I don't see any bug [ . . . ]
>
> Allow me to elaborate on how I see \defineBarLine as potentially
> confusing given its naming and arguments:
>
> \defineBarLine doesn't actually define anything.  It is the name of the
> bar line itself that defines it.  I do not have to use \defineBarLine to
> be able to say \bar "foo".  Instead, I need only ensure there are valid
> barline-print-procedures for "f" and "o", and that process doesn't
> involve \defineBarLine at all.  All that \defineBarLine does is
> associate additional information with an already, implicitly defined bar
> line.

I don't think you're correct.

You can always try:
{ R1 \bar "foo" R1 }
with completely undefined behaviour of "foo"
-> No bar-line is printed
(The resulting programming errors are due to the use of a
MultiMeasureRest, though.)


Defining print-procedures, like

#(add-bar-glyph-print-procedure
  "f"
  (lambda (grob extent) (grob-interpret-markup grob "f")))
#(add-bar-glyph-print-procedure
  "o"
  (lambda (grob extent) (grob-interpret-markup grob "o")))

%\defineBarLine "foo" #'("f" "o" "|")

{ R1 \bar "foo" R1 }

will return the same result, "foo" is still not available.
-> No bar-line is printed

But if you uncomment the %\defineBarLine above, it works.
-> the "foo"-bar-line _is_ printed
\defineBarLine fills 'bar-glyph-alist and 'span-bar-glyph-alist,
making their entries available (printable) for the \bar-command.

Or try in a fresh ly-file:

#(set! (@@ (lily) bar-glyph-alist) '())

{ R1  R1 }

All bar-lines are gone ...

>
> One could argue that the definition of a bar line by name alone is
> incomplete so one needs to use \defineBarLine, but in actuality the
> implementation has default values for spanning behavior and line
> breaking behavior.  \defineBarLine is there to replace these default
> values.

Well, the default values are set by define-bar-line or defineBarLine
in the relevant alists.
Defining a print-procedure and assigning a glyph to it as done by
'add-bar-glyph-print-procedure' means that the alist
'bar-glyph-print-procedures' is filled.
Without calling define-bar-line or \defineBarLine (for me it's almost
the same) nothing is available/printable.

Both, the schemish define-bar-line or \defineBarLine may be used to
get modified bar-lines, bar-line-variants or complete new bar-lines
(needs some more preluminary work, ofcourse)

Currently defineBarLine or it's scheme-sibling says:
For \bar "string0" behave
  like "string1" at line end
  like "string2" at line-start
  like "string3" for the span-bar

string0 to 3 should have printing-procedures, ofcourse.

I don't see anything wrong here.

One could think of:
\defineBarLine
  "name"
  #'(string1 string2 string3) %% for the behaviour of BarLines (end,
middle, start of line)
  #'(string4 string5 string6) %% for the behaviour of the SpanBars
(end, middle, start of line)

But I have a hard time seeing this as an improvement lol

Though, we're now at the topic how to improve the user interface.
Here some work could be done, admittedly.
(I remember David K. complained as well, some time ago ...)

> Perhaps the naming could be improved, but given my limited time
> I am struggling to come up with a better verb than "define" that evokes
> the correct idea better enough to justify a name change.
>
> The second argument to \defineBarLine is a list of three strings,
> however the purpose and interpretation of those strings is not
> identical.  The first two elements are related to line breaking so there
> is rationale to group them in a list, but the third is completely
> unrelated as it deals with spanning behavior.  The first two elements
> are names of other bar lines that are substituted at line breaks,
> whereas the third is read only a series of symbols used to define the
> shape and look of the span.  Again, the third element does not seem to
> belong in a list with the others.
>
> Seeing this list of three strings that by all outward appearances look
> related, their purpose and interpretation is muddled.  In this
> particular instance, I did not immediately realize the line breaking
> values are intended to result in additiona

Re: select a note in a chord

[Valentin Villenave]

On 1/29/19, Davide Bonetti  wrote:
> Ok, now it works well!

Greetings everybody,

David K. raised an interesting question with regard to the
\invertChords function:
https://codereview.appspot.com/365840043/#msg18

Basically (IIUC), he’s thinking that

\invertChords 1 

should ideally result in



rather than



(as the current implementation produces).

Any thoughts?

Cheers,
V.

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

Re: "Mensurstriche" (barlines between systems) and Repeat signs.

[Noeck]

Hi,

I probably don't understand all the implications and I am certainly not
suggesting to change the function signature. But while we are at it:

A definition is usually “name” = “the thing to be defined”.

In the current \defineBarLine function, I always wondered why the first
argument contains a real barline and not just a name for it:

\defineBarLine ".|:-||" #'("||" ".|:" ".|")

The first argument mixes barlines and a suffix. ‘.|:’ is a real bar line
and the ‘-||’ part is a name extension. In order to cleanly separate the
name and the definition, this would me much clearer:

\defineBarLine "myname" #'("||" ".|:" ".|:" ".|")
i.e. "name" #'(start middle end span)

"name" could still be ".|:-||" – or anything else.

Cheers,
Joram

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

Re: Please test new lilypond installers

[Masamichi Hosoda]

> $ uname -a
> FreeBSD freebsd-hyperv 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  
> amd64

> ld-elf.so.1: Shared object "libm.so.4" not found, required by "lilypond"
> 
> Are there any further efforts anyone would like to see made here?

Maybe, installing compat6x package is required.

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

Re: "Mensurstriche" (barlines between systems) and Repeat signs.

[Aaron Hill]

On 2019-02-02 2:29 am, Thomas Morley wrote:
Am Fr., 1. Feb. 2019 um 20:19 Uhr schrieb Malte Meyn 
:


Am 01.02.19 um 18:42 schrieb Aaron Hill:
> That very much sounds like a bug and should be reported.  The final
> argument is the span setting which should be agnostic of start and end
> styles and vice versa.
Hm … I don’t think that this is correct: How about
\defineBarLine ".|:-||" #'("||" ".|:" ".|")
? If the span bar ".|" would be used at all positions, the output at
line breaks wouldn’t be correct: the "||" bar at the line end would 
have

a ".|" span bar too …


I don't see any bug [ . . . ]


Allow me to elaborate on how I see \defineBarLine as potentially 
confusing given its naming and arguments:


\defineBarLine doesn't actually define anything.  It is the name of the 
bar line itself that defines it.  I do not have to use \defineBarLine to 
be able to say \bar "foo".  Instead, I need only ensure there are valid 
barline-print-procedures for "f" and "o", and that process doesn't 
involve \defineBarLine at all.  All that \defineBarLine does is 
associate additional information with an already, implicitly defined bar 
line.


One could argue that the definition of a bar line by name alone is 
incomplete so one needs to use \defineBarLine, but in actuality the 
implementation has default values for spanning behavior and line 
breaking behavior.  \defineBarLine is there to replace these default 
values.  Perhaps the naming could be improved, but given my limited time 
I am struggling to come up with a better verb than "define" that evokes 
the correct idea better enough to justify a name change.


The second argument to \defineBarLine is a list of three strings, 
however the purpose and interpretation of those strings is not 
identical.  The first two elements are related to line breaking so there 
is rationale to group them in a list, but the third is completely 
unrelated as it deals with spanning behavior.  The first two elements 
are names of other bar lines that are substituted at line breaks, 
whereas the third is read only a series of symbols used to define the 
shape and look of the span.  Again, the third element does not seem to 
belong in a list with the others.


Seeing this list of three strings that by all outward appearances look 
related, their purpose and interpretation is muddled.  In this 
particular instance, I did not immediately realize the line breaking 
values are intended to result in additional lookups for determining 
spanning behavior; although it does make perfect sense now.  We might 
not want to have the same spanning behavior at the line breaks as we do 
with the bar line in the middle of a line.  But why then is the spanning 
behavior placed so far away from the named bar line whose definition is 
being refined, and why is it grouped with the line breaking behavior to 
which it is otherwise agnostic?


Would it be worth considering a refactoring of the \defineBarLine 
function to keep concerns better separated?  Consider:


\defineBarLine "bar" #'("end" "begin" "span")
% becomes
\defineBarLine "bar" "span" #'("end" "begin")

Here the spanning behavior is clearly more closely associated with the 
bar by its proximity to the name of the bar line.  The line breaking 
values are still grouped in a list to continue to provide a visual 
reminder of their related purpose but are kept away from the bar line 
name.


Alternately, the \defineBarLine function could be split:

\defineBarLine "bar" #'("end" "begin" "span")
% becomes
\setBarLineSpanning "bar" "span"
\setBarLineBreaking "bar" "end" "begin"

We gain some clarity and self-documentation; and in fact, the line 
breaking arguments no longer need to be grouped in a list.  Users who 
only need to change the default behavior for one aspect need only use 
its associated function.  But would the added verbosity be a justifiable 
cost?



-- Aaron Hill

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

Re: Please test new lilypond installers

[Karlin High]

On Tue, Jan 29, 2019 at 3:20 AM Knut Petersen  wrote:

> lilypond-2.21.0-1.freebsd-64.sh

I have little experience with FreeBSD, but decided to have a go at this.

Intel Core i5-2400 3.10 GHz
Windows 10 Pro x64 Version 1803
Hyper-V virtual machine, 2 processors and 2 GB RAM

$ uname -a
FreeBSD freebsd-hyperv 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  amd64

Executing the LilyPond installer goes like this. I renamed the installer

lilypond installer for version 2.21.0 release 1,
x86_64 build.
For a list of options, abort (^C) then do:
sh ./lilypond-2.21.0-1.freebsd-64.sh --help

Warning: this build is not optimized for your architecture;
please install a amd64 build instead.

Press C to install the program anyway (not recommended),
E to only extract the program files, or any other key to exit.

Well, I pressed C. This is what VMs are for, right? Install seemed to
go OK. But running lilypond says this:

ld-elf.so.1: Shared object "libm.so.4" not found, required by "lilypond"

Are there any further efforts anyone would like to see made here?
-- 
Karlin High
Missouri, USA

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

Re: "Mensurstriche" (barlines between systems) and Repeat signs.

[Thomas Morley]

Am Fr., 1. Feb. 2019 um 20:19 Uhr schrieb Malte Meyn :
>
> Am 01.02.19 um 18:42 schrieb Aaron Hill:
> > On 2019-02-01 9:04 am, Malte Meyn wrote:
> >> Am 01.02.19 um 16:53 schrieb Aaron Hill:
> >>> "" is already a valid bar line that has an empty glyph, so just
> >>> extend that one:
> >>>
> >>> 
> >>> \version "2.19.82"
> >>>
> >>> \defineBarLine "-span" #'("|" "|" "|")
> >>> \layout { \context { \Score defaultBarType = "-span" } }
> >>> \new StaffGroup << \new Staff \repeat unfold 12 b'4
> >>> \new Staff \repeat unfold 12 b'4 >>
> >>> 
> >>
> >> That’s not enough: #'("|" "|" "|") will make full bar lines at line
> >> breaks. When I try #'("" "" "|") instead, no span bar is printed at
> >> line end. But the following seems to work:
> >
> > I goofed when I posted my solution, as I had intended it to be #'("" ""
> > "|"), since it was meant to be only the span bar.
> >
> >> • in the middle of a line, the staff bar is taken from the name "-m"
> >> and the span bar from the third argument "|"
> >> • at the begin of a line, the second argument is used: "" is an empty
> >> staff bar *with empty span bar* (default for "" bar lines)
> >> • at the end of a line, the first argument is used: "" is not
> >> sufficient here, because the span bar is taken from the "" definition
> >> instead of the third argument; setting the first argument to "-m"
> >> looks into the third argument of this definition.
> >
> > That very much sounds like a bug and should be reported.  The final
> > argument is the span setting which should be agnostic of start and end
> > styles and vice versa.
> Hm … I don’t think that this is correct: How about
> \defineBarLine ".|:-||" #'("||" ".|:" ".|")
> ? If the span bar ".|" would be used at all positions, the output at
> line breaks wouldn’t be correct: the "||" bar at the line end would have
> a ".|" span bar too …

I don't see any bug, neither I understand:

> But I don’t know why we have the span bar argument at all then …

Anyway, if a new barline is wished (with a new glyph, like "m"), it
needs to be defined from scratch.
The NR says:
"If additional elements are needed, LilyPond provides a simple way to
define them. For more information on modifying or adding bar lines,
see file ‘scm/bar-line.scm’."

Well, this is not very verbose ... lol ...  but to explain it, would
beyond the Notation _Reference_, rather the Extending Manual could be
amended.
We have ‘bar-line-define-bar-glyph.ly’ in the regtests, though.
lilypond.org/doc/v2.19/input/regression/8d/lily-e521e794.ly
(This example avoids caring about span-bars, though, setting span-bars to "")

In short:
A barline-printing-procedure, with the required arguments 'grob' and
'extent' needs to be assigned to a glyph (of string-length 1) via
'add-bar-glyph-print-procedure'.
Then the new barline could be defined via '\defineBarLine' or it's
scheme-equivalent 'define-bar-line' An example:

\version "2.19.82"

#(define (make-foo-bar-line grob extent)
  (let* ((stil
   (box-stencil
 (grob-interpret-markup grob (make-vcenter-markup "FOO"))
 0.2 0.1))
 (stil-x-extent (ly:stencil-extent stil X)))
;; To get span-bars correct, some moving is needed
(ly:stencil-translate-axis
  (ly:make-stencil (ly:stencil-expr stil) stil-x-extent extent)
  (interval-center extent)
  Y)))

#(add-bar-glyph-print-procedure "f" make-foo-bar-line)
#(define-bar-line "f" "f" "f" "f")


\score {
  \new StaffGroup \with { \override SpanBar.color = #red }
<<
  \repeat unfold 10 R1
  \repeat unfold 10 R1
  {
R1
\bar "f"
r1^\markup \raise #20 \null
\repeat unfold 8 R1
  }
>>
  \layout {
\context {
  \Score
  defaultBarType = "f"
}
  }
}

For the topic of Mensurstriche, Malte already pointed out the howto:
\defineBarLine "-m" #'("-m" "" "|")

Which does not need a new printing procedure, but is an alternative to ""-bar.


Cheers,
  Harm

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