Unicode accidentals vs. Markup accidentals
Surprisingly, typing the Unicode characters for accidental symbols does not
produce the same font output as using the markup commands:
<<
\new Staff {
c'1^"B♭"
c'1^"C♯"
c'1^"D♮"
}
\new Staff {
c'1^\markup { B \flat }
c'1^\markup { C \sharp }
c'1^\markup { D \natural }
}
>>
And neither looks particularly great IMO.
Re: Unknown expression mark
It looks to me like a short fermata: https://lilypond.org/doc/v2.22/Documentation/f5/lily-0fe2acbd.png which you may call in lilypond via "\shortfermata" However, it might also be a staccato and marcato, with more context (the rest of the score) the answer might be more clear. -William On 1/14/23 12:58, Alberto Simões wrote: Hello, Friends Anyone knows: - what is this expression mark (in terms of the player) - how to mimic this in Lilypond? Thank you! Alberto -- + -- + |William Rehwinkel - Oberlin College and | | Conservatory '24 | | will...@williamrehwinkel.net | | PGP key: | | https://williamrehwinkel.net/static/pubkey.txt | + -- + OpenPGP_signature Description: OpenPGP digital signature
Re: how would one cross-reference two [or more] books?
Le 14/01/2023 à 21:51, Jeff Olson a écrit :
On 1/13/2023 1:27 PM, Jean Abou Samra wrote:
LilyPond 2.24.1 is planned for the end of January or early February.
Whether it includes this mostly depends on whether Ivan Maidanski has
released BDWGC 8.2.3 by then.
Thanks for the update, Jean! Could you also help me understand what
was happening with \page-ref in my original post? E.g., ...
What causes \page-ref to fail for labels outside of the current \book?
Can the caller of \page-ref predict when it would fail, so as to avoid
calling it if it would fail?
Or if you have to let it fail, can the last arg (default) be replaced
with a callback that would undo the conversion of a label into a
stencil? I considered checking the output stencil of \page-ref, but
doesn't that have specific position info included that would make it
difficult to match against?
Why does the "Sav0" invocation of \save-page-refs behave as though it
is being called after the "Sav1" and "Sav2" invocations, while, in
contrast, the four invocations of \indexItem ("Top", "No.1", "No.2"
and "No.3") leave side effects in the index showing their results in
the order of appearance?
Clearly Lilypond isn't just "executing" commands to completion in
order of appearance or the ordinary table-of-contents at the beginning
of a document wouldn't work. Maybe that's just old imperative thinking
vs functional thinking, but some of these temporal issues make it look
dysfunctional at times.
What's the right way to think about these issues?
Sorry, I currently have little time to look into this / other
priorities. Maybe someone else can chime in.
Best,
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Re: how would one cross-reference two [or more] books?
On 1/13/2023 1:27 PM, Jean Abou Samra wrote:
LilyPond 2.24.1 is planned for the end of January or early February. Whether it
includes this mostly depends on whether Ivan Maidanski has released BDWGC 8.2.3
by then.
Thanks for the update, Jean! Could you also help me understand what was
happening with \page-ref in my original post? E.g., ...
What causes \page-ref to fail for labels outside of the current \book?
Can the caller of \page-ref predict when it would fail, so as to avoid
calling it if it would fail?
Or if you have to let it fail, can the last arg (default) be replaced
with a callback that would undo the conversion of a label into a
stencil? I considered checking the output stencil of \page-ref, but
doesn't that have specific position info included that would make it
difficult to match against?
Why does the "Sav0" invocation of \save-page-refs behave as though it is
being called after the "Sav1" and "Sav2" invocations, while, in
contrast, the four invocations of \indexItem ("Top", "No.1", "No.2" and
"No.3") leave side effects in the index showing their results in the
order of appearance?
Clearly Lilypond isn't just "executing" commands to completion in order
of appearance or the ordinary table-of-contents at the beginning of a
document wouldn't work. Maybe that's just old imperative thinking vs
functional thinking, but some of these temporal issues make it look
dysfunctional at times.
What's the right way to think about these issues?
Jeff
Re: defineBarLine confusion
Jean Abou Samra writes: > Le 14/01/2023 à 07:14, David Zelinsky a écrit : >> I have submitted a bug report, and I'm working on submitting a patch. > > > Did you see that Harm has already submitted a patch for this? > > https://gitlab.com/lilypond/lilypond/-/merge_requests/1813 > > Best, > Jean Yes, I just saw it. You guys are quick! Many thanks. -David
Re: Unknown expression mark
On Sat, 14 Jan 2023 at 19:05, Alberto Simões wrote: > > And in lilypond, _^ is similar enough :-) Hello, For me it looks more like a \shortfermata . See the list of articulations, as mentioned in NR 1.3.1 Expressive marks attached to notes. https://lilypond.org/doc/v2.24/Documentation/notation/list-of-articulations Cheers, Xavier -- Xavier Scheuer
Parenthesize whole note
Hello dear Pondmates,
for some question on SE I constructed a nice little function for
parenthesizing or bracketing whole notes (rather than just note heads this
includes heads, stems, flags, dots, tremolo and accidentals).
I’m posting it here in the hope this might prove useful for some out there.
This does not currently work with Beaming.
Cheers,
Valentin% modification for scm/stencil.scm:parenthesize-stencil that allows to specify direction
#(define* (parenthesize-stencil
stencil half-thickness width angularity padding #:optional (direction CENTER))
"Add parentheses around @var{stencil}, returning a new stencil."
(let* ((y-extent (ly:stencil-extent stencil Y))
(lp ((@@ (lily) make-parenthesis-stencil)
y-extent half-thickness width angularity 1))
(rp ((@@ (lily) make-parenthesis-stencil)
y-extent half-thickness width angularity -1)))
(if (<= direction CENTER)
(set! stencil (ly:stencil-combine-at-edge stencil X LEFT lp padding)))
(if (>= direction CENTER)
(set! stencil (ly:stencil-combine-at-edge stencil X RIGHT rp padding)))
stencil))
% modification for scm/stencil.scm:bracketify-stencil that allows to specify direction
#(define* (bracketify-stencil stil axis thick protrusion padding #:optional (direction CENTER))
"Add brackets around @var{stil}, producing a new stencil."
(let* ((ext (ly:stencil-extent stil axis))
(lb (ly:bracket axis ext thick protrusion))
(rb (ly:bracket axis ext thick (- protrusion
(if (>= direction CENTER)
(set! stil
(ly:stencil-combine-at-edge stil (other-axis axis) 1 rb padding)))
(if (<= direction CENTER)
(set! stil
(ly:stencil-combine-at-edge stil (other-axis axis) -1 lb padding)))
stil))
%%% Change Stem.stencil to #(parenthesize-note ...) to paranthesize a whole note. Use
%%% key arguments to change details e.g. #(parenthesize-note #:thickness 0.2)
%%% We are not directly using this to calculate stencil, but rather use this in
%%% Stem.before-line-breaking, as else we get circular dependency warnings for
%%% Stem.Y-extent with Flags.
%%%
%%% WARNING: THIS IS NOT COMPATIBLE WITH BEAMS!
%%% THIS WILL TRY TO ADD EXTRA SPACE TO THE STEM SO IT DOES NOT COLLIDE!
%%% THIS MIGHT PRODUCE AWKWARD RESULTS!
#(define* (parenthesize-note #:key
(addleft 0)
(addright 0)
(addtop 0)
(addbottom 0)
(thickness 0.2)
(width 0.4)
(angularity 0)
(direction CENTER)
(bracket #f)
(bracket-protrusion 0.25)
(bracket-padding 0.1))
(lambda (grob)
(let* ((orig (ly:grob-property grob 'stencil))
(orig (if (not (ly:stencil? orig)) empty-stencil orig))
; Collect all grobs belonging to note from Stem (Flag, Heads, Accidentals)
(flag (ly:grob-object grob 'flag))
(trem-flag (ly:grob-object grob 'tremolo-flag))
(heads (ly:grob-object grob 'note-heads))
(heads (ly:grob-array->list heads))
(accidentals (map (lambda (head) (ly:grob-object head 'accidental-grob))
heads))
(dots (map (lambda (head) (ly:grob-object head 'dot))
heads))
(all-add-grobs (append (list flag trem-flag) heads accidentals dots))
(all-add-grobs (filter (lambda (x) (not (null? x))) all-add-grobs))
; Determine X extents of each such grob relative to Paper Column (second X parent of Stem).
; This is necessariy as Accidentals do not have the Note Column as parent
(all-x-exts (map (lambda (g) (ly:grob-extent g (ly:grob-parent (ly:grob-parent grob X) X) X))
all-add-grobs))
; Determine Y extents of each such grob relative to Vertical Axis Group (second Y parent of Stem).
; This is necessariy as Tremolo Flags do not have the Note Column as parent
(all-y-exts (map (lambda (g) (ly:grob-extent g (ly:grob-parent (ly:grob-parent grob Y) Y) Y))
all-add-grobs))
(all-x-exts (filter (lambda (x) (not (null? x))) all-x-exts))
(all-y-exts (filter (lambda (x) (not (null? x))) all-y-exts))
; Add extent of this stencil
(ext-x (ly:grob-extent grob (ly:grob-parent grob X) X))
(ext-y (ly:grob-extent grob (ly:grob-parent grob Y) Y))
; Get offset of grob
(off-x (ly:grob-property grob 'X-offset))
(off-y (ly:grob-property grob 'Y-offset))
; Add stencil extents
(all-x-exts (cons ext-x all-x-exts))
(all-y-exts (cons ext-y all-y-exts))
; unify
Re: Unknown expression mark
On Sat, Jan 14, 2023 at 6:02 PM Alberto Simões wrote: > > > On Sat, Jan 14, 2023 at 5:58 PM Alberto Simões > wrote: > >> Hello, Friends >> >> Anyone knows: >> - what is this expression mark (in terms of the player) >> - how to mimic this in Lilypond? >> >> > As per Wikipedia, it looks like a Marcato -- > https://en.wikipedia.org/wiki/Marcato > And in lilypond, _^ is similar enough :-)
Re: Font change in 2.24.0 Figured bass "4"
On Sat, 2023-01-14 at 18:50 +0100, Jean Abou Samra wrote: > Le 14/01/2023 à 18:27, Richard Shann a écrit : > > I didn't get a response to this email, > > ?? You got a reponse from Werner last Monday. While there can be > distribution delays on this list, you were in the direct recipients > of > the email so it is a mystery if it didn't reach you. Ah, I should have checked the archives - I did think it *very* strange - I haven't received either the direct or the mailing list versions of that message. I did have a power cut in the recent storms that required fixing my file system and several things were broken (I had to re- install guile) but the emails seemed ok. > > You can always read it again at > > https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00168.html > > Please confirm that you received this email... yes, everything fine now - thank you very much! Richard
Re: Unknown expression mark
On Sat, Jan 14, 2023 at 5:58 PM Alberto Simões wrote: > Hello, Friends > > Anyone knows: > - what is this expression mark (in terms of the player) > - how to mimic this in Lilypond? > > As per Wikipedia, it looks like a Marcato -- https://en.wikipedia.org/wiki/Marcato
Unknown expression mark
Hello, Friends Anyone knows: - what is this expression mark (in terms of the player) - how to mimic this in Lilypond? Thank you! Alberto
Re: defineBarLine confusion
Le 14/01/2023 à 07:14, David Zelinsky a écrit : I have submitted a bug report, and I'm working on submitting a patch. Did you see that Harm has already submitted a patch for this? https://gitlab.com/lilypond/lilypond/-/merge_requests/1813 Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: defineBarLine confusion
Flaming Hakama by Elaine writes: > Here is something I wrote up for a blog post during the 2.18 days. > > I am not sure if it applies to your case, but it sounds like you probably > are not yet familiar with how barlines are defined. Which is not > surprising, since they are not well documented. Which is why I created > these notes in the first place, to help myself understand how they work. Thanks. The documentation would definitely benefit from a description as detailed as you gave. It took me a while but I did eventually figure out how this all is supposed to work. > Looking at your example, I think the first place you are going off is that > you do not define the barlines using ##t, ##f, you instead put the > characters that correspond to what you want to appear in those places. On the contrary, the documentation clearly states that these are valid values for the end, beginning, and span arguments. > The second issue is that you seem to be modifying the last argument, which > is the barlines to appear between staves. But your example has only one > staff, so your MWE is not exercising that feature. That's exactly the point. Since there is only one staff, the last argument should have no effect. And yet it does. And the effect is to truncate the mid-bar specification and only use its first character. In fact, I have identified where in the code this is happening, and it is clearly a bug. I have submitted a bug report, and I'm working on submitting a patch. -David
Re: Font change in 2.24.0 Figured bass "4"
Le 14/01/2023 à 18:27, Richard Shann a écrit : I didn't get a response to this email, ?? You got a reponse from Werner last Monday. While there can be distribution delays on this list, you were in the direct recipients of the email so it is a mystery if it didn't reach you. You can always read it again at https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00168.html Please confirm that you received this email... OpenPGP_signature Description: OpenPGP digital signature
Re: Font change in 2.24.0 Figured bass "4"
I didn't get a response to this email, but I stumbled across this the
presence of these glyphs
fattened.four
fattened.four.alt
at
https://lilypond.org/doc/v2.24/Documentation/notation/the-emmentaler-font#figured-bass-symbol-glyphs
and it would seem that the change to figured bass going to version 2.24
is to switch to using the alt versions of the glyphs.
Is anyone able to help me get control of the choice of glyph armed with
this information?
Richard
On Mon, 2023-01-09 at 16:52 +, Richard Shann wrote:
> The figure "4" in figured bass is coming out with a stunted upright
> in
> the new release
>
> 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> %\version "2.20.0"
> \version "2.24.0"
> \score {
> \new Staff <<
> \context Staff \figuremode { <4> }
> \new Voice { \clef bass c }
> >>
> }
> 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> gives a strange-looking 4 which resembles an upside-down 7 with a
> smudge on it, quite difficult to decipher (see attached examples).
>
> Is this a bug and how can I access the previously used font?
>
> Richard Shann
>
Re: Title font changed?
As a follow up, I can confirm that installing the fonts manually from https://github.com/ArtifexSoftware/urw-base35-fonts also fixed the problem. Can be a work around if you want to stick with the Homebrew installation. > Op 14 jan. 2023, om 10:30 heeft Bart Kummel het volgende > geschreven: > > Hi Jean, > > Thanks for your reply. Very insightful! I wonder why Google didn’t come up > with a link to this issue… > > Anyway, it looks like the solution will be merged into Homebrew’s main soon. > I might be able to just wait for it. I’ll keep an eye on the issue. > > Thanks again! > > Best, > Bart > >> Op 13 jan. 2023 om 21:04 heeft Jean Abou Samra het >> volgende geschreven: >> >> >> >> >>> Le 13 janv. 2023 à 20:19, b...@kummelweb.nl a écrit : >>> >>> Hi, >>> >>> Since I upgraded tot Lilypond 2.24, I noticed that the title font changed. >>> It looks much more like standard Times New Roman now, instead of the >>> beautiful Lilypond text font. (See the attached images: old.png is how it >>> used to be, new.png is after upgrading to 2.24.) >>> >>> I can't find anything about a change of the text font in the CHANGED page, >>> so I figure there should be something wrong with my install. >> >> >> Yes, there is. It’s a bug in Homebrew. See >> https://github.com/Homebrew/homebrew-core/issues/119476 >> >> Please use the binaries from lilypond.org until this is fixed. >> >> Best, >> Jean >>
Re: Title font changed?
Hi Jean, Thanks for your reply. Very insightful! I wonder why Google didn’t come up with a link to this issue… Anyway, it looks like the solution will be merged into Homebrew’s main soon. I might be able to just wait for it. I’ll keep an eye on the issue. Thanks again! Best, Bart > Op 13 jan. 2023 om 21:04 heeft Jean Abou Samra het > volgende geschreven: > > > > >>> Le 13 janv. 2023 à 20:19, b...@kummelweb.nl a écrit : >>> >> Hi, >> >> Since I upgraded tot Lilypond 2.24, I noticed that the title font changed. >> It looks much more like standard Times New Roman now, instead of the >> beautiful Lilypond text font. (See the attached images: old.png is how it >> used to be, new.png is after upgrading to 2.24.) >> >> I can't find anything about a change of the text font in the CHANGED page, >> so I figure there should be something wrong with my install. > > > Yes, there is. It’s a bug in Homebrew. See > https://github.com/Homebrew/homebrew-core/issues/119476 > > Please use the binaries from lilypond.org until this is fixed. > > Best, > Jean >
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
I could have thought of that... Thanks David for the tip and Jean for opening the issue. I'll use the workaround until then... Le vendredi 13 janvier 2023 à 14:03, David Wright a écrit : > On Fri 13 Jan 2023 at 19:30:29 (+), nitra...@posteo.net wrote: > > I was talking about the first note of each measures after the Key Signature. > > But you were right, it is the default spacing. > > > > About the distance between different accidentals, consider the example > > bellow. You can see a difference between the "Reference staff" and number > > "C" in the "Corrected Output". It looks like an extra space has been added > > between the key cancellation and the new one. > [ … ] > > grob > > (+ (- (interval-end (ly:grob-extent can parent X)) > > (ly:grob-relative-coordinate grob parent X)) > >0.7) > > X > > \music > > } > > Change 0.7 to 0.1 and you can make the cancellation almost touch the > new key signature, so pick your value to taste, I guess. > > You might need to check how a particular value behaves when staves > are stretched or compressed while breaking the music into lines. > (Your Reference staff has slightly different measure lengths from > the Corrected output.) > > Cheers, > David.
