Re: how difficult would it be to have “auto-correct spacing” (even for just a single measure)?
> > If you look at the first measure of the third system, you can see > > that the note spacing is distorted by various things (lyrics, > > accidentals, etc.). But clearly there’s more than enough horizontal > > room to make those eighth notes absolutely even — in fact, that kind > > of thing is what the majority of my post-data-entry tweak time is > > dedicated to. [Again: When I used Finale , it took hours or > > even days to get from “the data is all in” to looking like this > > already looks… so I’m not complaining!] > > You are aware of https://lsr.di.unimi.it/LSR/Item?id=1154 ? It looks like the spacing is not really distorted by the lyrics here but rather by the accidentals, so that snippet won't help much (what it does is basically making the spacing engine forget about lyrics, then space them itself). There might be ways to reduce the importance of accidentals in the spacing problem, but I don't really recall this, it's been a long time. It's interesting though that adding \override Score.SpacingSpanner.spacing-increment = 5 in \layout evens out the spacing a lot. Of course, for a longer score, this will spread out the music, so it's not really a solution, but it might be worth trying to flank that measure with \newSpacingSection and give it a different spacing-increment. Jean signature.asc Description: This is a digitally signed message part
Re: how difficult would it be to have “auto-correct spacing” (even for just a single measure)?
>> You are aware of https://lsr.di.unimi.it/LSR/Item?id=1154 ? > > Oh! I vaguely recall that. Thanks for the reminder. > > I believe I applied it to my score, but it didn‘t make a change in > m7. It might be because of the accidentals…? (See modified snippet > acting as MWE, below.) Unfortunately modifying the snippet to take > accidentals into account is WAY above my pay grade. Well, the lyrics don't make any difference in spacing, see attached image. This means that LilyPond itself does the wider spacing... Maybe you can play around with the spacing parameters of accidentals and note heads to reduce the horizontal space. Werner
Re: how difficult would it be to have “auto-correct spacing” (even for just a single measure)?
Hi Werner,
> You are aware of https://lsr.di.unimi.it/LSR/Item?id=1154 ?
Oh! I vaguely recall that. Thanks for the reminder.
I believe I applied it to my score, but it didn‘t make a change in m7. It might
be because of the accidentals…? (See modified snippet acting as MWE, below.)
Unfortunately modifying the snippet to take accidentals into account is WAY
above my pay grade.
Thanks,
Kieren.
%%% SNIPPET BEGINS %%%
\version "2.25.11"
\language "english"
% Snippet author: Jean Abou Samra
% Original thread:
https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00087.html
%
% This snippet gets rid of uglinesses in note spacing caused by lyrics.
% By default, LilyPond always puts a lyric word exactly centered under
% the note it attaches to. When there is a long lyric word, LilyPond reserves
% space between notes so that there will be no collisions in the lyrics.
% However, this can lead to uneven note spacing. This snippet completely
% removes the presence of lyrics in note spacing so that it is natural
% according to the note lengths, and uses a spacing algorithm that shifts
% lyrics automatically in order to avoid collisions.
%
% Some technical comments follow.
%
% The spacing problem is set up as a quadratic optimization problem. Each
% lyric word has a strength value (by default, all words have a strength
% of 1.0). The demerit associated to a lyric word is s(x-p)², where s
% is the strength, x is the X coordinate and p is the ideal X coordinate
% where the lyric word would be centered on its associated note. An
% acceptable solution is a solution where no lyric words collide. The
% weight of a solution is the sum of the demerits for each of the words.
% Solving the lyric spacing problem means finding an acceptable solution
% of minimal weight.
%
% In practice, words should not touch each other, but maintain a minimum
% distance between each other (controlled by LyricSpace.minimum-distance
% and LyricHyphen.minimum-distance). This is reduced to the form above
% by widening one of the two words for each LyricSpace or LyricHyphen
% grob, by the amount given by the minimum-space property.
%
% The algorithm to solve the lyric spacing problem uses dynamic programming
% and runs in linear time. We add words one by one from left to right. After
% adding each word, the problem given by the words added so far is solved.
% The base case (zero words) is trivial. To add a word, it is very intuitive,
% and not hard to prove, that the following technique works: if adding
% the word at its optimal position produces no collision, then keep it
% there; else, make this word 'push' on its left neighbor and move these
% two words simultaneously to the left until the optimal position for
% these two words together is reached; if this still produces a collision
% then add the third word and consider the three words stuck together, etc.
% Note that once two words have been stuck together, they won't need
% to be taken apart again: they will be adjacent ("stuck") in the final
% configuration.
%
% Written in this form, this algorithm looks quadratic. While probably
% acceptable in usual scores, this might become a problem with
ly:one-line-breaking.
% However, with a bit of simple algebra, you can see that optimizing for two
% words stuck together (and, by extension, any finite number of words stuck
% together) is equivalent to optimizing for one single (imaginary) combined
% word, of which the length is the sum of the two lengths, the strength is
% the sum of the strengths, and the optimal coordinate is given by a simple
% formula (see the code). Therefore, instead of simultaneously considering
% two words stuck together, you can replace them with just one fresh problem
% variable. At each word added during the algorithm, there is a constant
processing
% overhead, plus an overhead linear in the number of times a word is newly
% stuck to a group, forming a new group. If you imagine that all words start
% out black, and every word becomes white as soon as its group is stuck to
% the group on the left, it is clear that the total number of "add to group"
% operations is linear in the number of words. At the end, there is a
% step to compute the offset of each word from that of its group, which
% is made linear by caching the offset of a group as soon as it is
% visited. In this way, the total number of operations is linear.
%
% #(ly:set-option 'compile-scheme-code)
#(use-modules (ice-9 match)
(ice-9 hash-table)
(oop goops))
%% convenience stuff:
#(define-syntax-rule (transform! lval proc)
(set! lval (proc lval)))
#(define ->
(make-procedure-with-setter
(lambda (instance . path)
(let loop ((instance instance) (path path))
(match path
((slot)
(slot-ref instance slot))
((slot . rest)
(loop (slot-ref instance slot)
rest)
(lambda (instance . args)
(let loop ((instance instance) (args args))
Re: how difficult would it be to have “auto-correct spacing” (even for just a single measure)?
> If you look at the first measure of the third system, you can see > that the note spacing is distorted by various things (lyrics, > accidentals, etc.). But clearly there’s more than enough horizontal > room to make those eighth notes absolutely even — in fact, that kind > of thing is what the majority of my post-data-entry tweak time is > dedicated to. [Again: When I used Finale , it took hours or > even days to get from “the data is all in” to looking like this > already looks… so I’m not complaining!] You are aware of https://lsr.di.unimi.it/LSR/Item?id=1154 ? Werner
how difficult would it be to have “auto-correct spacing” (even for just a single measure)?
Hi all, It is difficult to put into words how happy I am using Lilypond. I had to use Sibelius for a project last year, and it was pure torture. As the old saying [almost] goes: “They’ll have to pry Lilypond out of my cold, dead hands!” Exhibit A: I’m in data-entry mode (i.e., not concerned about visuals/tweaking *at all*), and the screenshot attached is what the top half of the page of my octavo score looks like at this moment. Incredible! There are zero [!!] manual tweaks on that page — what you see is what comes out “automagically”, based solely on Lilypond’s amazing layout engine and my stylesheets. So obviously what follows is a “first world problem” of the highest order… If you look at the first measure of the third system, you can see that the note spacing is distorted by various things (lyrics, accidentals, etc.). But clearly there’s more than enough horizontal room to make those eighth notes absolutely even — in fact, that kind of thing is what the majority of my post-data-entry tweak time is dedicated to. [Again: When I used Finale , it took hours or even days to get from “the data is all in” to looking like this already looks… so I’m not complaining!] I would love to be able to say “Dear Specialized Scheme Engraver: Please take measure 7, even out the note-spacing, and make the ‘obvious’ necessary adjustments so that everything looks amazing.” How difficult would such a function/engraver be to design? Thanks, Kieren. __ My work day may look different than your work day. Please do not feel obligated to read or respond to this email outside of your normal working hours.
Re: Trouble with concat in a markup command
Thanks for the tip, Valentin, great to know about this.
On Sat, May 4, 2024 at 3:22 AM Valentin Petzel wrote:
> Hello Alec,
>
> note that since 2.24 we have a neat markup function
> \with-string-transformer,
> which is called whenever a string is found, and does a lot of the logic
> for
> you (such as making sure this is called upon a string, not a complex
> markup:
>
> \markup
> \with-string-transformer
> #(lambda (layout props str)
> (if (> (string-length str) 0)
> (let ((last-char (string-ref str (1- (string-length str
>(prefix (substring str 0 (1- (string-length str)
>(cond
> ((char=? last-char #\#)
> (markup
> #:concat (prefix #:hspace 0.2 #:fontsize -2.5 #:raise 0.6
> #:sharp)))
> ((char=? last-char #\b)
> (markup
> #:concat (prefix #:hspace 0.2 #:fontsize -2.5 #:raise 0.6
> #:flat)))
> (else str)))
> str))
> { "A#" "Bb" }
>
> But then I’d think maybe here it would be useful to have an option for
> regex
> matching in \replace ...
>
> Cheers,
> Valentin
Re: Trouble with concat in a markup command
A-ha! That makes sense and works great, thanks David.
On Sat, May 4, 2024 at 1:54 AM David Kastrup wrote:
> Alec Bartsch writes:
>
> > I'm attempting to write a markup command that, in addition to other
> > formatting, strips a trailing # or b character off the end of the text
> > argument and replaces it with the appropriate accidental markup. I think
> > I'm super-close but stuck on the proper syntax for passing a markup list
> to
> > the concat. Here's what I've got so far:
> >
> > #(define-markup-command (page-header layout props text) (markup?)
> > "Page header style including optional trailing accidental"
> > (let* (
> > (last-char (string-ref text (1- (string-length text
> > (prefix (substring text 0 (1- (string-length text
> > )
> > (interpret-markup layout props
> > (markup #:override '(font-name . "Avenir Heavy") #:fontsize 5
> > (make-concat-markup (cond
> > ((char=? last-char #\#) (list prefix #:hspace 0.2
> > #:fontsize -2.5 #:raise 0.6 #:sharp))
> > ((char=? last-char #\b) (list prefix #:hspace 0.2
> > #:fontsize -2.5 #:raise 0.6 #:flat))
> > (else (list text))
> > ))
> > )
> > )
> > )
> > )
> >
> > \markup \page-header "Key of Bb"
>
> The markup macro is something that works so-soish. As a macro, it
> doesn't wait for its arguments to be evaluated but looks at them before
> they are being evaluated. It (hopefully) won't look inside a function
> call like make-concat-markup. #{ \markup ... #} tends to behave more
> predictable if slower. Fixing this up for your use case you'd write
> something akin to
>
>
>
> --
> David Kastrup
>
Re: Markuplist and formatted text
I’m printing out attribution information in which the title of a work from
which the text was translated is in italics. Attached is an example of the my
results before I started this thread. The comma after “Sponsa Christi” is in
italics (as you suggested was the more normal typographic practice) because it
was inside the \italic command (and directly attached to “Christi”. I was
looking to turn it upright since the comma isn’t part of the title of the
original sequence.
The wrapping in this case is being handled by a modified \wordwrap-field, which
was based on a discussion on the mailing list 6 years ago:
https://www.mail-archive.com/lilypond-user@gnu.org/msg131928.html. At the time
I hadn’t considered the possibility of punctuation that I didn’t want formatted
in the same way as the text it would be “attached” to, and recent work had me
exploring that possibility. If need be, I can post that tool in it’s current
form, but in creating my MWE I tried to use standard LilyPond commands as much
as possible, and would rely on applying it to my non-standard command myself
(which I have done for the solution that has been posted using \wordwrap-lines).
I’ll point out that at this point the \wordwrap-lines solution works (now that
I understand where it’s allowed to make wrapping decisions), at this point my
questions are purely about understanding your (David’s) comments about
\wordwrap-string.
✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036
PAX ☧ ΧΡΙΣΤΟΣ
> On May 4, 2024, at 1:31 PM, David Kastrup wrote:
>
> "Fr. Samuel Springuel" writes:
>
>> Okay, so then I need to break up the string to create separate markups
>> (except in the critical location around the italics text:
>>
>> \version "2.24.3"
>>
>> \markuplist \wordwrap-lines { test test test test test test test test
>> test test test test test test test test test test test test test test
>> test test test test \concat { \italic { "italic text" }"," } test test
>> test test test test test test test test test test test test test test
>> test test test test test test test }
>>
>> I can’t seem to get \wordwrap-string to work in this context (even
>> after switching \markuplist to \markup). It barfs if \concat is
>> inside of it (unrecognized escape string) and if it’s put inside
>> \concat, then it only applies to the immediate string, not the
>> resulting concatenated whole.
>
> What is the actual problem you are trying to solve here?
>
> --
> David Kastrup
Ordinary_Time_Sundays.pdf
Description: Adobe PDF document
Re: Tunable Context Properties
On 2024-05-04 8:06 am, Fr. Samuel Springuel wrote:
1) Can I establish that shortVocalName should default to vocalName at
the top level of the file (effectively placing it where I can transport
it over to my format file)?
Yes, you do something like this:
\version "2.24.3"
\layout {
\context {
\Lyrics
\override InstrumentName.stencil =
#(lambda (grob)
;; Use long-text for text, as needed.
(or (markup? (ly:grob-property grob 'text))
(ly:grob-set-property! grob 'text
(ly:grob-property grob 'long-text)))
(system-start-text::print grob))
}
}
If vocalName is set but not shortVocalName, then the value of vocalName
(long-text) is copied into the shortVocalName (text). This gives you
some flexibility as you can define them independently as needed.
2) Can I automate the numbering so that I don’t have to manually number
the verses? I’ve seen http://lsr.di.unimi.it/LSR/Item?id=543, but this
has two problems: one, the counter increments each time the markup is
printed, which is problematic for verse numbers which should stay the
same within a verse, no matter how many times it is printed, and only
increment between verses. Two, it introduces a spurious space after
the counter that I don’t know how to get rid of.
I would use more helper functions to automate things. Consider:
\version "2.24.3"
\layout {
\context {
\Lyrics
\override InstrumentName.self-alignment-X = #RIGHT
}
}
stanza =
#(define-scheme-function (stanza) (markup?)
(let ((markup #{ \markup \italic #stanza #}))
#{ \with { vocalName = #markup shortVocalName = #markup } #}))
autoStanza =
#(let ((ctr 0))
(define-scheme-function (fmt) ((string? "~d."))
(set! ctr (1+ ctr))
#{ \stanza #(format #f fmt ctr) #}))
\layout { ragged-right = ##t }
music = \relative { f' g a c | \break c a g f | \break f e d c }
verseI = \lyricmode { \repeat unfold 12 a }
verseII = \lyricmode { \repeat unfold 12 b }
verseIII = \lyricmode { \repeat unfold 12 c }
verseIV = \lyricmode { \repeat unfold 12 d }
\new Staff
<<
\new Voice = "mel" { \music }
\new Lyrics \with \autoStanza \default \lyricsto "mel" { \verseI }
\new Lyrics \with \autoStanza "~@(~:r.~)" \lyricsto "mel" { \verseII }
\new Lyrics \with \autoStanza "~@r." \lyricsto "mel" { \verseIII }
\new Lyrics \with \autoStanza "~(~:@r.~)" \lyricsto "mel" { \verseIV }
Note above that \stanza takes care of setting both vocalName and
shortVocalName to the same markup, so the stencil override I showed is
not necessary. I am also doing the work within the \with block for each
Lyrics context rather than \setting. You could modify this logic to use
\set instead if you needed to change the vocalName/shortVocalName.
You'd need to use define-music-function rather than
define-scheme-function.
The \autoStanza takes care of the counter logic, although it only
supports one global counter. For most scores, this is probably
sufficient. The formatting string gives you some customization options
based on the formatted printing facility within Scheme. If you used
this a lot, it probably make sense to define the format strings with
sensible naming:
ordinal = "~@(~:r.~)"
newRomanUpper = "~@r."
oldRomanLower = "~(~:@r.~)"
%% . . .
\new Lyrics \with \autoStanza \oldRomanLower \lyricsto "mel" { ... }
In fact, you could take automation even further to reduce typing:
lyricsWithAutoStanzaOrdinal =
#(define-music-function (lyrics) (ly:music?)
#{ \new Lyrics \with \autoStanza \ordinal \lyricsto mel $lyrics #})
%% . . .
\lyricsWithAutoStanzaOrdinal \verseII
-- Aaron Hill
Re: Markuplist and formatted text
On Sat 04 May 2024 at 11:18:52 (-0400), Fr. Samuel Springuel wrote:
> How do I get the comma (which is not italicized) attached to the italics text
> just before it?
>
> \version "2.24.3"
>
> \markuplist \wordwrap-lines { test test test \italic { italic text }, test
> test test }
You concat it.
\markuplist \wordwrap-lines { test test test test test test test test test test
test test test test test test test test test test test test, test test test
test test test test test test test test test }
\markuplist \wordwrap-lines {test test test test test test test test test test
test test test test test test test test test test test test test test test test
test test \concat { \italic { "italic text" } "," } test test test }
Cheers,
David.
mark.pdf
Description: Adobe PDF document
Re: Markuplist and formatted text
"Fr. Samuel Springuel" writes:
> Okay, so then I need to break up the string to create separate markups
> (except in the critical location around the italics text:
>
> \version "2.24.3"
>
> \markuplist \wordwrap-lines { test test test test test test test test
> test test test test test test test test test test test test test test
> test test test test \concat { \italic { "italic text" }"," } test test
> test test test test test test test test test test test test test test
> test test test test test test test }
>
> I can’t seem to get \wordwrap-string to work in this context (even
> after switching \markuplist to \markup). It barfs if \concat is
> inside of it (unrecognized escape string) and if it’s put inside
> \concat, then it only applies to the immediate string, not the
> resulting concatenated whole.
What is the actual problem you are trying to solve here?
--
David Kastrup
Re: Markuplist and formatted text
Okay, so then I need to break up the string to create separate markups (except
in the critical location around the italics text:
\version "2.24.3"
\markuplist \wordwrap-lines { test test test test test test test test test test
test test test test test test test test test test test test test test test test
\concat { \italic { "italic text" }"," } test test test test test test test
test test test test test test test test test test test test test test test test
}
I can’t seem to get \wordwrap-string to work in this context (even after
switching \markuplist to \markup). It barfs if \concat is inside of it
(unrecognized escape string) and if it’s put inside \concat, then it only
applies to the immediate string, not the resulting concatenated whole.
✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036
PAX ☧ ΧΡΙΣΤΟΣ
> On May 4, 2024, at 1:13 PM, David Kastrup wrote:
>
> "Fr. Samuel Springuel" writes:
>
>> Word wrapping does not appear to be functioning in this solution:
>>
>> \version "2.24.3"
>>
>> \markuplist \wordwrap-lines {\concat { "test test test test test test
>> test test test test test test test test test test test test test test
>> test test test test test test test test test test test test test
>> "\italic { "italic text" }", test test test" }}
>>
>> The text just runs of the page to the right.
>
> That is as intended. \wordwrap-lines breaks between individual markups,
> and you only have one.
>
> You probably want \wordwrap-string (there is no \wordwrap-string-lines
> though that would give you a markup list).
>
> --
> David Kastrup
Re: Markuplist and formatted text
"Fr. Samuel Springuel" writes:
> Word wrapping does not appear to be functioning in this solution:
>
> \version "2.24.3"
>
> \markuplist \wordwrap-lines {\concat { "test test test test test test
> test test test test test test test test test test test test test test
> test test test test test test test test test test test test test
> "\italic { "italic text" }", test test test" }}
>
> The text just runs of the page to the right.
That is as intended. \wordwrap-lines breaks between individual markups,
and you only have one.
You probably want \wordwrap-string (there is no \wordwrap-string-lines
though that would give you a markup list).
--
David Kastrup
Re: Markuplist and formatted text
Word wrapping does not appear to be functioning in this solution:
\version "2.24.3"
\markuplist \wordwrap-lines {\concat { "test test test test test test test test
test test test test test test test test test test test test test test test test
test test test test test test test test test "\italic { "italic text" }", test
test test" }}
The text just runs of the page to the right.
✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036
PAX ☧ ΧΡΙΣΤΟΣ
> On May 4, 2024, at 11:30 AM, Jean Brefort wrote:
>
> Try this:
> \markuplist \wordwrap-lines {\concat { "test test test "\italic { "italic
> text" }", test test test" }}
>
> Le samedi 04 mai 2024 à 11:18 -0400, Fr. Samuel Springuel a écrit :
>> How do I get the comma (which is not italicized) attached to the
>> italics text just before it?
>>
>> \version "2.24.3"
>>
>> \markuplist \wordwrap-lines { test test test \italic { italic text },
>> test test test }
>>
>> ✝✝
>> Fr. Samuel, OSB
>> (R. Padraic Springuel)
>> St. Anselm’s Abbey
>> 4501 South Dakota Ave, NE
>> Washington, DC, 20017
>> 202-269-2300
>> (c) 202-853-7036
>>
>> PAX ☧ ΧΡΙΣΤΟΣ
>>
>>
>
Re: Markuplist and formatted text
"Fr. Samuel Springuel" writes: > How do I get the comma (which is not italicized) attached to the > italics text just before it? You got your question answered by another use already, so I'll just add that typesetters will usually tend to give punctuation the shape of the word adjacent to it for typographical rather than logical wholesomeness. That LilyPond makes it programmatically awkward to change shape without intervening space is not intentional; rather it is a side effect from punctuation usually being placed immediately adjacent to the preceding word. -- David Kastrup
Re: Markuplist and formatted text
Try this:
\markuplist \wordwrap-lines {\concat { "test test test "\italic { "italic text"
}", test test test" }}
Le samedi 04 mai 2024 à 11:18 -0400, Fr. Samuel Springuel a écrit :
> How do I get the comma (which is not italicized) attached to the
> italics text just before it?
>
> \version "2.24.3"
>
> \markuplist \wordwrap-lines { test test test \italic { italic text },
> test test test }
>
> ✝✝
> Fr. Samuel, OSB
> (R. Padraic Springuel)
> St. Anselm’s Abbey
> 4501 South Dakota Ave, NE
> Washington, DC, 20017
> 202-269-2300
> (c) 202-853-7036
>
> PAX ☧ ΧΡΙΣΤΟΣ
>
>
Markuplist and formatted text
How do I get the comma (which is not italicized) attached to the italics text
just before it?
\version "2.24.3"
\markuplist \wordwrap-lines { test test test \italic { italic text }, test test
test }
✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036
PAX ☧ ΧΡΙΣΤΟΣ
Tunable Context Properties
I’m using the vocalName and shortVocalName context properties in Lyrics and for
a particular project, I always set them to be the same thing (i.e. so that the
verse numbers appear on every line). Right now, that means putting two “\set”
commands in each Lyrics context in order to set both properties. I’m looking
to simplify this and thus am looking for two things:
1) Can I establish that shortVocalName should default to vocalName at the top
level of the file (effectively placing it where I can transport it over to my
format file)?
2) Can I automate the numbering so that I don’t have to manually number the
verses? I’ve seen http://lsr.di.unimi.it/LSR/Item?id=543, but this has two
problems: one, the counter increments each time the markup is printed, which is
problematic for verse numbers which should stay the same within a verse, no
matter how many times it is printed, and only increment between verses. Two,
it introduces a spurious space after the counter that I don’t know how to get
rid of.
My MnonWE (with the counter in place):
\version "2.24.0"
% This is where my \include "format.ily" would go.
#(define counter-alist '())
#(define-markup-command (counter layout props name) (string?)
"Increases and prints out the value of the given counter named @var{name}.
If the counter does not yet exist, it is initialized with 1."
(let* ((oldval (assoc-ref counter-alist name))
(newval (if (number? oldval) (+ oldval 1) 1)))
(set! counter-alist (assoc-set! counter-alist name newval))
(interpret-markup layout props
(markup (number->string newval)
music = { c c c c | \break c c c c | \break c c c c }
verseI = \lyricmode { a a a a a a a a a a a a }
verseII = \lyricmode { b b b b b b b b b b b b }
verseIII = \lyricmode { c c c c c c c c c c c c c }
\new Staff
<<
\new Voice = "mel" { \music }
\new Lyrics \lyricsto "mel" {
\set vocalName = \markup { \counter #"versenumber". }
\set shortVocalName = \markup { \counter #"versenumber". }
\verseI }
\new Lyrics \lyricsto "mel" {
\set vocalName =\markup { \counter #"versenumber". }
\set shortVocalName = \markup { \counter #"versenumber". }
\verseII }
\new Lyrics \lyricsto "mel" {
\set vocalName = \markup { \counter #"versenumber". }
\set shortVocalName = \markup { \counter #"versenumber". }
\verseIII }
>>
✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036
PAX ☧ ΧΡΙΣΤΟΣ
Re: Transparent box around notes
Thanks, I'll check it out! Il ven 3 mag 2024, 14:23 K. Blum ha scritto: > Hi Paolo, hi David, > > I've replaced the current stencil function with the one from the > openLilyLib "frames" module (which has even more capabilities). > Here is the result: > https://github.com/KlausBlum/Ly-Boxer-Snippet > If you like, please feel free to experiment or add further things... > > I'll try to send you an invitation to give you full access to that repo. > (Never done that before, but I'll find my way...) > > If anyone else is interested, please send a short message. :-) > > Cheers, > Klaus >
Re: Trouble with concat in a markup command
Hello Alec,
note that since 2.24 we have a neat markup function \with-string-transformer,
which is called whenever a string is found, and does a lot of the logic for
you (such as making sure this is called upon a string, not a complex markup:
\markup
\with-string-transformer
#(lambda (layout props str)
(if (> (string-length str) 0)
(let ((last-char (string-ref str (1- (string-length str
(prefix (substring str 0 (1- (string-length str)
(cond
((char=? last-char #\#)
(markup
#:concat (prefix #:hspace 0.2 #:fontsize -2.5 #:raise 0.6
#:sharp)))
((char=? last-char #\b)
(markup
#:concat (prefix #:hspace 0.2 #:fontsize -2.5 #:raise 0.6
#:flat)))
(else str)))
str))
{ "A#" "Bb" }
But then I’d think maybe here it would be useful to have an option for regex
matching in \replace ...
Cheers,
Valentin
signature.asc
Description: This is a digitally signed message part.
Automatic indent
Hello,
I’ve been wondering just now: Wouldn’t it be possible to use the break-align-
symbol mechanism to allow for dynamic indents? Take this as example:
<<
\new Staff \with { instrumentName = "ins" } {
\override Score.BreakAlignment.break-align-orders =
#(make-vector 3 '(cue-end-clef
ambitus
breathing-sign
time-signature
clef
cue-clef
staff-bar
key-cancellation
key-signature
custos
left-edge))
\key cis\major
c'
}
\new Staff { c' }
>>
<<
\new Staff \with { instrumentName = "ins" } {
\key cis\major
c'
}
\new Staff { c' }
>>
So clearly the break alignment interface would allow placing things before the
left edge. Of course the staff symbol stencil would need to be adjusted to take
this into account and not start early, but say if we did not place left edge
in a fixed location, but say we had a technical left edge (start of line) and a
staff left edge (start of staff). Then it should be possible to place things
like instrument names as break aligned grobs either before the technical left
edge for current behaviour, but also between technical left edge and staff left
edge. This way the start of the staff should dynamically depend on the
instrument name, and using space-alist we could still have an indent as
minimum space between the left edges.
This should also mean that instrument names could become much more accessible.
Cheers,
Valentin
signature.asc
Description: This is a digitally signed message part.
Re: output-filename with variable
Hello cord,
note that \fromproperty is a markup command, which is interpreted later with
the right context. The output-filename does not actually want a markup, so
you’d need to be careful here.
If you really want to do this you can extract values from the top level header
or from the header of the current book or bookpart (if present):
#(define (from-header symbol)
(let* ((book-header
(if $current-book (ly:book-header $current-book) #f))
(bookpart-header
(if $current-bookpart (ly:book-header $current-bookpart) #f))
(headers (list bookpart-header book-header $defaultheader))
(headers (filter (lambda (x) x) headers))
(headers-alist (headers-property-alist-chain headers)))
(ly:chain-assoc-get (symbol-concatenate 'header: symbol) headers-alist)))
This will do the trick:
\header {
title = "title"
}
#(display (from-header 'title))
#(newline)
\book {
\header {
title = "title2"
}
#(display (from-header 'title))
#(newline)
\bookpart {
\header {
title = "title3"
}
#(display (from-header 'title))
#(newline)
}
}
But keep in mind that this depends on the order of execution:
\header {
title = "title"
}
#(display (from-header 'title))
works out,
#(display (from-header 'title))
\header {
title = "title"
}
does not. So you need to gurantee that this function is always called after
you define your header!
Cheers,
Valentin
Am Samstag, 4. Mai 2024, 10:58:28 MESZ schrieb corde...@disroot.org:
> Hello everyone,
>
> Is there a simple way to have the output-filename as a variable (the title
> of the main header)?
>
> This one doesn’t recognise the property as a string:
>
> \paper {
> output-filename = \fromproperty #'header:title
> }
>
> Thank you all,
> cord
signature.asc
Description: This is a digitally signed message part.
output-filename with variable
Hello everyone,
Is there a simple way to have the output-filename as a variable (the title of
the main header)?
This one doesn’t recognise the property as a string:
\paper {
output-filename = \fromproperty #'header:title
}
Thank you all,
cord
Re: Trouble with concat in a markup command
Alec Bartsch writes:
> I'm attempting to write a markup command that, in addition to other
> formatting, strips a trailing # or b character off the end of the text
> argument and replaces it with the appropriate accidental markup. I think
> I'm super-close but stuck on the proper syntax for passing a markup list to
> the concat. Here's what I've got so far:
>
> #(define-markup-command (page-header layout props text) (markup?)
> "Page header style including optional trailing accidental"
> (let* (
> (last-char (string-ref text (1- (string-length text
> (prefix (substring text 0 (1- (string-length text
> )
> (interpret-markup layout props
> (markup #:override '(font-name . "Avenir Heavy") #:fontsize 5
> (make-concat-markup (cond
> ((char=? last-char #\#) (list prefix #:hspace 0.2
> #:fontsize -2.5 #:raise 0.6 #:sharp))
> ((char=? last-char #\b) (list prefix #:hspace 0.2
> #:fontsize -2.5 #:raise 0.6 #:flat))
> (else (list text))
> ))
> )
> )
> )
> )
>
> \markup \page-header "Key of Bb"
The markup macro is something that works so-soish. As a macro, it
doesn't wait for its arguments to be evaluated but looks at them before
they are being evaluated. It (hopefully) won't look inside a function
call like make-concat-markup. #{ \markup ... #} tends to behave more
predictable if slower. Fixing this up for your use case you'd write
something akin to
#(define-markup-command (page-header layout props text) (markup?)
"Page header style including optional trailing accidental"
(let* (
(last-char (string-ref text (1- (string-length text
(prefix (substring text 0 (1- (string-length text
)
(interpret-markup layout props
(markup #:override '(font-name . "Avenir Heavy") #:fontsize 5
(make-concat-markup (cond
((char=? last-char #\#) (list prefix (markup #:hspace 0.2
#:fontsize -2.5 #:raise 0.6 #:sharp)))
((char=? last-char #\b) (list prefix (markup #:hspace 0.2
#:fontsize -2.5 #:raise 0.6 #:flat)))
(else (list text))
))
)
)
)
)
\markup \page-header "Key of Bb"
--
David Kastrup
Trouble with concat in a markup command
I'm attempting to write a markup command that, in addition to other
formatting, strips a trailing # or b character off the end of the text
argument and replaces it with the appropriate accidental markup. I think
I'm super-close but stuck on the proper syntax for passing a markup list to
the concat. Here's what I've got so far:
#(define-markup-command (page-header layout props text) (markup?)
"Page header style including optional trailing accidental"
(let* (
(last-char (string-ref text (1- (string-length text
(prefix (substring text 0 (1- (string-length text
)
(interpret-markup layout props
(markup #:override '(font-name . "Avenir Heavy") #:fontsize 5
(make-concat-markup (cond
((char=? last-char #\#) (list prefix #:hspace 0.2
#:fontsize -2.5 #:raise 0.6 #:sharp))
((char=? last-char #\b) (list prefix #:hspace 0.2
#:fontsize -2.5 #:raise 0.6 #:flat))
(else (list text))
))
)
)
)
)
\markup \page-header "Key of Bb"
This works in the no-accidental case but otherwise generates an error like
this:
fatal error: make-concat-markup: Invalid argument in position 1. Expect:
markup list, found: ("Key of B" #:hspace 0.2 #:fontsize -2.5 #:raise 0.6
#:flat).
Being new to scheme, I've tried various syntactical tweaks which all result
in different error messages. (Also I welcome any advice on alternate
approaches.)
Thanks,
Alec
