Re: accidentalStyle choral: too many accidentals in situations with ties
Hi,
agreed, this is unpleasant. FWIW, it's the same behavior in the piano
style, which I based choral on.
I had to make up my mind whether this is intended or not, but the fact
that making up my mind took so long suggests that it's probably not... ;-)
The key idea of the choral style is to make sure that both singers (many
following only one voice, but some referring to their neighbors at least
occasionally) and instrumentalists (especially piano players for colla
parte) have common and distinct notes highlighted. Unfortunately, the
common practice of not repeating accidentals for tied notes intervenes here.
I was wondering if, for that purpose, the lower left (tied) cis4 should
get a sharp, and both cis4 on the second beat would be shown without
accidentals. The top left sharp is forced, hence not printing the lower
left one might be misleading for a top-staff singer suddenly
double-checking whether his colleagues downstairs have the same note. On
the other hand, showing a sharp there makes the tie look like a slur for
the bottom-staff singer, which is arguably even worse. And of course a
multi-staff following musician is expected to know the measure before
and to realize the meaning of the tie.
But if the lower left sharp is omitted, the lower right one is forced,
and then printing the top right one kinda fits the intention of the
choral style. Also, it's cautionary, as choral-cautionary shows.
Independent of "intended or not": it's ugly, I have to admit.
In any case, I don't really see a quick fix (on my Scheme level, at
least). And I agree that, at least for piano and piano-cautionary, it's
a clear case of undesired behavior.
Cheers,
Alex
On 2020-04-16 15:26, Simon Albrecht wrote:
Hello everyone,
I found a kind of situation in which the ‘choral’ accidental style
produces too many accidentals:
\version "2.19.84"
\new ChoirStaff \with {
\accidentalStyle choral
} <<
{ cis'1 4 4 }
{ cis'1~4 4 }
>>
See attachment for output: the last note in the top staff shouldn’t get
an accidental.
Due to an unrelated issue, I couldn’t test 2.21.0, but I guess there’s
no reason why it would be different.
Best, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: AccidentalSuggestion only for cautionary accidentals?
Hi Malte,
I second your opinion about cautionary accidentals as used in musica
ficta. As a workaround, the following probably produces what you want:
- automatic accidentals are untouched (which might actually _not_ be
what you want)
- ! gets typeset as Accidental
- ? gets typeset as AccidentalSuggestion
Not heavily tested, but it does the job for me. YMMV.
cautionaryAsSuggestions =
#(define-music-function (m) (ly:music?)
;; Caveat: not usable for chords!
(music-map
(lambda (ev)
(if (and (ly:music-property ev 'force-accidental #f)
(ly:music-property ev 'cautionary #f))
(make-music 'SequentialMusic
'elements (list (make-music 'ContextSpeccedMusic
'context-type 'Bottom
'element (make-music 'PropertySet 'once #t
'value #t 'symbol 'suggestAccidentals))
(music-map (lambda (orig)
(ly:music-set-property! orig
'cautionary #f)
orig)
ev)))
ev))
m))
#(set! toplevel-music-functions
(cons cautionaryAsSuggestions toplevel-music-functions))
HTH,
Alexander
On 31.08.19 20:37, Malte Meyn wrote:
> Hi list,
>
> currently setting suggestAccidentals to ##t lets the Accidental_engraver
> make AccidentalSuggestion grobs instead of both Accidental and
> AccidentalCautionary grobs. Shouldn’t this replacement be done only for
> cautionary accidentals? When transcribing mensural music, one needs both
> Accidental grobs (for accidentals present in the facsimile) and
> AccidentalSuggestion grobs (for implicit musical ficta accidentals). Any
> opinions on that?
>
> Cheers,
> Malte
>
> %%
>
> \version "2.19.83"
>
> \markup { without suggestAccidentals: }
> \relative {
> \time 2/1
> \set Staff.timeSignatureFraction = 2/2
> c''1 d
> bes1 a2 g
> a d1 cis?2
> d\breve
> }
>
> \markup { current output: }
> \relative {
> \set suggestAccidentals = ##t
> \time 2/1
> \set Staff.timeSignatureFraction = 2/2
> c''1 d
> bes1 a2 g
> a d1 cis?2
> d\breve
> }
>
> \markup { suggested output: }
> \relative {
> \time 2/1
> \set Staff.timeSignatureFraction = 2/2
> c''1 d
> bes1 a2 g
> a d1 \once \set suggestAccidentals = ##t cis?2
> d\breve
> }
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
smime.p7s
Description: S/MIME Cryptographic Signature
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Completion_heads_engraver flaws [was: Completion_heads_engraver doesn't play nicely with lyric alignment]
Hi all,
I found another issue while trying to wrap my head around when exactly
the completionBusy and melismaBusy should be set.
In the following MWE, the positioning of slurs over notes splitted by
the Completion_heads_engraver lacks something. (See the attached image.)
Obviously, there are things that it cannot be reasonably expected to
cope with (e.g., making no completion on staccati, or pushing a fermata
to the last note head), but slurs seem like a common thing in, e.g.,
baroque music where I expect a use for the Completion_heads_engraver.
(For "PhrasingSlur"-like, I refer to
https://music.stackexchange.com/questions/56941/should-slurs-encompass-tied-notes-from-before-and-or-after
which is non-authoritative, but the accepted answer somewhat matches my
intuition. I typically prefer the first variant for clarity, though, if
space allows.)
\version "2.19.82"
\paper { ragged-last = ##f }
\markup "e.g., Boosey & Hawkes (PhrasingSlur-like); also recommended in
Gould p. 62"
\score {
{ b2 b2(~ b2 a2~ a2 b2~ b2) b2 }
}
\markup "also correct, perhaps better for non-vocal music (personal
opinion)?"
\score {
{ b2 b2~ b2( a2~ a2 b2)~ b2 b2 }
}
\markup "half-baked output with Completion_heads_engraver..."
\score {
{ b2 b1( a1 b1) b2 }
\layout {
\context {
\Voice
\remove Note_heads_engraver
\consists Completion_heads_engraver
}
}
}
I presume that means that I'll have to resort to two different sources
for Mensurstriche and "modern" layouts, but I mention it anyway for the
sake of completeness.
Cheers,
Alex
smime.p7s
Description: S/MIME Cryptographic Signature
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Completion_heads_engraver doesn't play nicely with lyric alignment
Some more investigation:
in Lyric_engraver::process_music, the LyricText's self-alignment-X is
set according to lyricMelismaAlignment. If I add a separate check for
completionBusy there, things change:
lyric-engraver.cc:84:
if (last_text_
&& voice
&& (to_boolean (voice->get_property ("melismaBusy"))
/* the following is new */
|| to_boolean (voice->get_property ("completionBusy")))
&& !to_boolean (context ()->get_property ("ignoreMelismata")))
last_text_->set_property ("self-alignment-X",
get_property ("lyricMelismaAlignment"));
But:
1.) I don't know why this changes anything at all - completionBusy is in
the default list of melismaBusyProperties, and I assume that means it
*should* be acknowledged by default anyways. Cause apparently, the
single "melismaBusy" captures all other properties from that list,
including Ties, Slurs, and explicit melisma?
2.) The modified variant is too eager: it also left-aligns non-splitted
notes if there are more fine-grained events in a different voice:
\version "2.19.82"
\paper { ragged-last = ##f }
\score {
<<
{ c'4 c'4 c'4 c'4 c'4 c'4 c'2 }
{ c'4 c'4 c'4 c'4 c'2 c'2 }
\addlyrics { These should all be center-aligned. __ Right? }
>>
}
\score {
<<
{ c'4 c'4 c'4 c'4 c'4 c'4 c'2 }
{ c'4 c'4 c'4 c'4 c'2 c'2 }
\addlyrics { These should all be center-aligned. __ Right? }
>>
\layout {
\context {
\Voice
\remove Note_heads_engraver
\consists Completion_heads_engraver
}
}
}
gives the attached output with the above change in lyric-engraver.cc. So
apparently, completionBusy is set because when encountering the first
half note, it's not yet clear whether the note *might* be split later
on, and that decision is only taken on the moment which doesn't have
anything to do with this voice.
In other words, completionBusy tells whether the
Completion_heads_engraver is running behind the scenes, not whether it
actually changes anything.
But in that case, completionBusy should not belong to the
melismaBusyProperties?
Something's fishy here, AFAICS...
Cheers,
Alex
On 20.05.19 13:58, Alexander Kobel wrote:
Hi all,
I'd expect the two scores in the following excerpt to be identical, alas
they aren't: Notes splitted into tied notes by the
Completion_heads_engraver produce melismata as expected, but don't cause
the Lyrics to be left-aligned accordingly. (See the attached output.)
\version "2.19.82"
\paper { ragged-last = ##f }
\score {
{ c'4 c'4 c'4 c'4~ c'4 }
\addlyrics { This should be left-aligned. __ }
}
\score {
{ c'4 c'4 c'4 c'2 }
\addlyrics { This should be left-aligned. __ }
\layout {
\context {
\Voice
\remove Note_heads_engraver
\consists Completion_heads_engraver
}
}
}
Unfortunately, this seems to imply that there is no easy/clean way to
produce a Mensurstriche layout and a "standard" layout with splitted
notes from the same source.
In case this is a known (but, in this case, AFAICS undocumented) flaw,
or unlikely to have an easy fix: I'd be happy to hear about an
workaround for same-source ditions, if someone has one in mind.
Cheers,
Alex
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
smime.p7s
Description: S/MIME Cryptographic Signature
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Completion_heads_engraver doesn't play nicely with lyric alignment
Hi all,
I'd expect the two scores in the following excerpt to be identical, alas
they aren't: Notes splitted into tied notes by the
Completion_heads_engraver produce melismata as expected, but don't cause
the Lyrics to be left-aligned accordingly. (See the attached output.)
\version "2.19.82"
\paper { ragged-last = ##f }
\score {
{ c'4 c'4 c'4 c'4~ c'4 }
\addlyrics { This should be left-aligned. __ }
}
\score {
{ c'4 c'4 c'4 c'2 }
\addlyrics { This should be left-aligned. __ }
\layout {
\context {
\Voice
\remove Note_heads_engraver
\consists Completion_heads_engraver
}
}
}
Unfortunately, this seems to imply that there is no easy/clean way to
produce a Mensurstriche layout and a "standard" layout with splitted
notes from the same source.
In case this is a known (but, in this case, AFAICS undocumented) flaw,
or unlikely to have an easy fix: I'd be happy to hear about an
workaround for same-source ditions, if someone has one in mind.
Cheers,
Alex
smime.p7s
Description: S/MIME Cryptographic Signature
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: extenders over bar lines in 2.19.55 [was: Automatic Lyric Extenders]
Hi David, hi all, On 2017-02-19 15:58, David Kastrup wrote: > Michael Gerdau <m...@qata.de> writes: > >> Am 18.02.2017 um 21:15 schrieb Alexander Kobel: >>> [Bug report summary:] >>> >>> Extenders are not drawn anymore for melismata that include notes that >>> are not bar-aligned, starting somewhere between 2.19.50 and 2.19.55. >>> M(N)WE attached - the first and second score should have extenders until >>> the last note. >> >> I've tried this on 2.19.50 - 2.19.55 and it seems as if it used to work >> until 2.19.54, i.e. apparently it is a 2.19.55 regression (which kind of >> explains why I had not seen this problem before :) ) >> >> The first example has an extender only because the default minimum >> length is 1.5. if that is reduced to 0 that extender vanishes altogether >> in 2.19.55. > > This is a consequence of > > commit 6c6d1f6ac9e6a7a9aba760dcbb41b4fbbc8f0536 > Author: David Kastrup <d...@gnu.org> > Date: Sat Feb 4 14:43:47 2017 +0100 > > Issue 5053/2: Fix extendersOverRests property > > This previously behaved as always-on. Argh, sure. Should have thought about that after the earlier, similar report from 2017-02-15... > This program part now works as intended. Unfortunately, > extendersOverRests appears to be a misnomed property, so the resulting > effective change from extendersOverRest being interpreted as ##t > regardless of its setting to having it default to ##f affects more than > extenders over rests. Not sure about the original intention. I see the point for having the choice to stop extenders over rests (as the documentation suggests). The "side effects" are hardly what I expect, and I don't immediately see a use for that. > Maybe one should let the setting default to ##t for now and try matching > its documentation to its behavior before changing the default back to > ##f. +1. Right now, the cure seems to do more harm than good, at least from a user's point of view... Concerning "matching doc to behavior": do you intend to change rather docs, behavior, or both? On a somewhat, but not quite, unrelated note, concerning https://sourceforge.net/p/testlilyissues/issues/4509/ and https://codereview.appspot.com/313240043: Do you want/need any input there, or are you merely keeping a log of your pondering? I feel somewhat involved as Knut's and your "Rietveld proxy", but I'm not sure whether or how I can assist. (Note: I don't intend to push by any means; I've got a wagonload of way more important things to deal with these days...) Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
extenders over bar lines in 2.19.55 [was: Automatic Lyric Extenders]
[Bug report summary:]
Extenders are not drawn anymore for melismata that include notes that
are not bar-aligned, starting somewhere between 2.19.50 and 2.19.55.
M(N)WE attached - the first and second score should have extenders until
the last note.
Hi Michael,
On 2017-02-18 18:59, Michael Gerdau wrote:
I actually meant using an include file like the attached and not having
to add the music function locally at all.
Since this include file had been posted I've been using it with great
pleasure and like it very much.
great that you found the snippet useful. Please note that this is a
"workaround" that happens to do a (surprisingly) good job. A proper,
more mature integration of automatic extenders is in the works, but
after initial enthusiasm, it turned to be a bit more invasive than
expected. I hope that there will be some news on that front "soon".
There is one problem I'd like to vanish.
It seems extender lines stop at the end of a bar (this seems to hold for
the autoextender as well as for extender lines drawn by appending '__'
to a syllable - never realized that before). However in the attached
example I would like the extender line end in Bar 3.
However, this problem seems unrelated (as you remark, it's completely
independent of automatic extenders) and 2.19.55-ish, hence I cross-post
to bug-lilypond:
Extenders seem not to be drawn anymore for melismata that include notes
that are not bar-aligned. Note that in your original example, already
the first note is longer than measure 1; that seems to be the culprit.
Attached is a more detailed example.
Did you, by chance, spot the problem already on earlier dev releases? I
did not see it on 2.19.50 (which I just uninstalled, unfortunately), and
I don't have intermediate versions available right now.
Cheers,
Alexander
\version "2.19.55"
\relative c' { r2. c4.~( c4 cis8 d2.~ d4.) }
\addlyrics { foo __ }
\relative c' { r2. c4~( c4 cis8 d2.~ d4.) }
\addlyrics { foo __ }
\relative c' { r2. c4~( c4 cis4 d2~ d4.) }
\addlyrics { foo __ }
\relative c' { \time 3/4 r2. c4.~( c4 cis8 d2.~ d4.) }
\addlyrics { foo __ }
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Extenders are not printed for lyrics associated with multi-staff contexts
Ahem, I hit "send" too early. On 2017-01-02 18:38, Alexander Kobel wrote: Going over the get_voice_to_lyrics function in lily/lyric-engraver.cc, I eventually noticed that correct extenders are printed for lyrics assigned to Staff and one of the above [container] groups *unless there is a ChordNames context.* [...] when the following is added: % \set searchForVoice = ##f % \set associatedVoiceContext = ##f \set associatedVoice = #"" \set associatedVoiceType = #'Staff as seen in the attached lyr-ctx.ly. And, on a second try, turns out that only the last two lines are required. Also, associatedVoice has to be the empty string, not just any non-existing value. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Extenders are not printed for lyrics associated with multi-staff contexts
Dear all,
an update to my previous bug report.
First, I attach a slightly simplified and enhanced test case, including
lyrics attached to ChordNames, TabStaff and FiguredBass. The latter does
not work. I guess that's reasonable, because there is little point to
have a FiguredBass without a companion Staff; on the other hand, I'm not
sure if it points to a structural deficiency of the association
algorithm, because AFAICS the FiguredBass is probably not that different
from a ChordNames context when it comes to alignment...
Second, w.r.t. ChoirStaves/GrandStaves/StaffGroups, I tried to find my
way through the codebase and figure out why no extenders are created.
Going over the get_voice_to_lyrics function in lily/lyric-engraver.cc, I
eventually noticed that correct extenders are printed for lyrics
assigned to Staff and one of the above contained groups *unless there is
a ChordNames context.* (That's why the ChordNames lines are commented
out in the attached file...)
Maybe those settings could be applied per default for lyrics assigned to
container contexts once someone more knowledgeable than I can resolve
the issue with ChordNames?
Cheers,
Alexander
On 2016-12-26 16:31, Alexander Kobel wrote:
Dear all,
since the advent of 2.19.50, it is possible to attach lyrics to
different contexts than just a voice: "The \addlyrics function now
works with arbitrary contexts incuding Staff."
Indeed, for Staves, it works like a charm AFAICS. However, when
attached to a ChoirStaff, GrandStaff or StaffGroup, no extenders are
generated. (Nb: the *alignment* with notes / music columns works
perfectly fine, just the extender generation fails.)
Attached is a test case. The lyrics lines for the three multi-staff
contexts should look like the single-staff line, as far as I can tell.
Best,
Alexander
\version "2.19.50"
\paper { ragged-last = ##f }
one = { b'8 4 8( 4) 4 }
two = { \autoBeamOff g'8 8 8 8~ 8[ 8] 8[ 8] }
fbass = \figuremode { \bassFigureExtendersOn <5 3>8 <5 3\!>8 <5 3> <5\! 3\!>8 <5 3>8 8 <5\! 3\!> <5 3> }
lyrChords = \lyricmode { Foo bar xyzzy. __ _ Foo! }
lyrOne = \lyricmode { Foo bar xyzzy. __ Foo! }
lyrTwo = \lyricmode { Foo bar __ _ xyzzy. __ Foo! __ }
commonLyr = \lyricmode {
\set searchForVoice = ##f
\set associatedVoiceContext = ##f
\set associatedVoice = #""
\set associatedVoiceType = #'Staff
Foo bar __ _ xyzzy. __ _ Foo! __ _
}
lyrFbass = \lyricmode { Foo bar __ _ xyzzy. __ _ _ Foo! __ _ }
beats = \lyricmode { ^ ^ ^ ^ ^ ^ ^ }
\score {
<<
% \new ChordNames = "ChordNames" \one
% \new Lyrics \lyricsto ChordNames = "ChordNames" { \set stanza = "ChordNames" \lyrChords }
% \new Lyrics \lyricsto ChordNames = "ChordNames" \beats
\new TabStaff = "TabStaff" \transpose c c, << \one \\ \two >>
\new Lyrics \lyricsto TabStaff = "TabStaff" { \set stanza = "TabStaff" \commonLyr }
\new Lyrics \lyricsto TabStaff = "TabStaff" \beats
\new Staff = "staff" << \new Voice = "VoiceOne" { \voiceOne \one }
\new Voice = "VoiceTwo" { \voiceTwo \two } >>
\new Lyrics \with { alignAboveContext = "staff" } \lyricsto "VoiceOne" { \set stanza = "1st Voice" \lyrOne }
\new Lyrics \with { alignAboveContext = "staff" } \lyricsto "VoiceOne" { \beats }
\new Lyrics \lyricsto "VoiceTwo" { \set stanza = "2nd Voice" \lyrTwo }
\new Lyrics \lyricsto "VoiceTwo" \beats
\new Staff = "Staff" << \one \\ \two >>
\new Lyrics \lyricsto Staff = "Staff" { \set stanza = "Staff" \commonLyr }
\new Lyrics \lyricsto Staff = "Staff" \beats
\new ChoirStaff = "ChoirStaff" << \one \\ \two >>
\new Lyrics \lyricsto ChoirStaff = "ChoirStaff" { \set stanza = "ChoirStaff" \commonLyr }
\new Lyrics \lyricsto ChoirStaff = "ChoirStaff" \beats
\new GrandStaff = "GrandStaff" << \one \\ \two >>
\new Lyrics \lyricsto GrandStaff = "GrandStaff" { \set stanza = "GrandStaff" \commonLyr }
\new Lyrics \lyricsto GrandStaff = "GrandStaff" \beats
\new StaffGroup = "StaffGroup" << \one \\ \two >>
\new Lyrics \lyricsto StaffGroup = "StaffGroup" { \set stanza = "StaffGroup" \commonLyr }
\new Lyrics \lyricsto StaffGroup = "StaffGroup" \beats
\new FiguredBass = "FiguredBass" \fbass
% \new Lyrics \lyricsto FiguredBass = "FiguredBass" { \set stanza = "FiguredBass" \lyrFbass }
% \new Lyrics \lyricsto FiguredBass = "FiguredBass" \beats
>>
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Extenders are not printed for lyrics associated with multi-staff contexts
Dear all,
since the advent of 2.19.50, it is possible to attach lyrics to
different contexts than just a voice: "The \addlyrics function now
works with arbitrary contexts incuding Staff."
Indeed, for Staves, it works like a charm AFAICS. However, when
attached to a ChoirStaff, GrandStaff or StaffGroup, no extenders are
generated. (Nb: the *alignment* with notes / music columns works
perfectly fine, just the extender generation fails.)
Attached is a test case. The lyrics lines for the three multi-staff
contexts should look like the single-staff line, as far as I can tell.
Best,
Alexander
\version "2.19.50"
\paper { ragged-last = ##f }
one = { b'8 4 8( 4) 4 }
two = { \autoBeamOff g'8 8 8 8~ 8[ 8] 8[ 8] }
lyrOne = \lyricmode { Foo bar xyzzy. __ Foo! }
lyrTwo = \lyricmode { Foo bar __ _ xyzzy. __ Foo! __ }
commonLyr = \lyricmode { Foo bar __ _ xyzzy. __ _ Foo! __ _ }
beats = \lyricmode { ^ ^ ^ ^ ^ ^ ^ }
\score {
<<
\new Staff = "staff" <<
\new Voice = "VoiceOne" { \voiceOne \one }
\new Voice = "VoiceTwo" { \voiceTwo \two }
>>
\new Lyrics \with { alignAboveContext = "staff" } \lyricsto "VoiceOne" { \set stanza = "1st Voice" \lyrOne }
\new Lyrics \with { alignAboveContext = "staff" } \lyricsto "VoiceOne" { \beats }
\new Lyrics \lyricsto "VoiceTwo" { \set stanza = "2nd Voice" \lyrTwo }
\new Lyrics \lyricsto "VoiceTwo" { \beats }
\new Staff = "Staff" <<
\new Voice { \voiceOne \one }
\new Voice { \voiceTwo \two }
>>
\new Lyrics \lyricsto Staff = "Staff" { \set stanza = "Staff" \commonLyr }
\new Lyrics \lyricsto Staff = "Staff" { \beats }
\new ChoirStaff = "ChoirStaff" <<
\new Staff = "upperCS" { \new Voice { \one } }
\new Staff = "lowerCS" { \new Voice { \two } }
>>
\new Lyrics \with { alignAboveContext = "lowerCS" } \lyricsto ChoirStaff = "ChoirStaff" { \set stanza = "ChoirStaff" \commonLyr }
\new Lyrics \with { alignAboveContext = "lowerCS" } \lyricsto ChoirStaff = "ChoirStaff" { \beats }
\new GrandStaff = "GrandStaff" <<
\new Staff = "upperGS" { \new Voice { \one } }
\new Staff = "lowerGS" { \new Voice { \two } }
>>
\new Lyrics \with { alignAboveContext = "lowerGS" } \lyricsto GrandStaff = "GrandStaff" { \set stanza = "GrandStaff" \commonLyr }
\new Lyrics \with { alignAboveContext = "lowerGS" } \lyricsto GrandStaff = "GrandStaff" { \beats }
\new StaffGroup = "StaffGroup" <<
\new Staff = "upperSG" { \new Voice { \one } }
\new Staff = "lowerSG" { \new Voice { \two } }
>>
\new Lyrics \with { alignAboveContext = "lowerSG" } \lyricsto StaffGroup = "StaffGroup" { \set stanza = "StaffGroup" \commonLyr }
\new Lyrics \with { alignAboveContext = "lowerSG" } \lyricsto StaffGroup = "StaffGroup" { \beats }
>>
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Setting font families for entire document in LilyPond version 2.18.2.
Hi Miroslaw,
not sure if I understand correctly what you mean.
It is perfectly possible to write a file CustomTemplate.ly with a
content like that:
\paper {
#(define fonts
(make-pango-font-tree "Times New Roman"
"Nimbus Sans,Nimbus Sans L"
"Luxi Mono"
(/ staff-height pt 20)))
}
and include it with the command you mentioned. For reference on the
command used herein, see
http://lilypond.org/doc/v2.18/Documentation/notation/fonts#entire-document-fonts
If you need further adjustments, e.g. for the font size of the lyrics,
you can also have global layout blocks in that file:
\layout {
\context {
\Lyrics
\override LyricText.font-size = #0
}
}
or similar overrides.
HTH,
Alexander
On 2016-12-20 20:25, Mirosław Doroszewski wrote:
Setting font families for entire document in LilyPond version 2.18.2.
Setting font families for entire document is not possible in template
added to document with \include. If is many documents in a book, there
is necessary to set font families in each document separately. But
this solution not always working. And if there is 500 documents in a
song book?
So, please, make solution: setting font families be possible by adding
single template with \include to document.
For instance:
\version "2.18.2"
\include "CustomTemplate.ly"
{...}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Development manuals. Was: Re; New LilyPond website
(Bcc'ing bug-lilypond now. What a useful feature! ;-)) On 2016-11-29 16:18, Phil Holmes wrote: [...] In fact, I tend to be confused about the different layout and sectioning of the manual pages for stable and unstable. Now suddenly I wonder whether in the long run it would be a good idea to have an identical structure for downloads, manuals, regtests etc. for stable and unstable, but use a different (background) color (scheme) for the two? [...] Actually, it would make much more sense to split the manuals and download page for the development version in the same way it's split for the stable version, I think? Yes, that's what I meant. I hesitated to propose that because it seems more invasive, and I don't have time nor texinfo (?) knowledge to take care of that myself. Also, there is a bit of difference in content that would need some thought: most prominently, the regression tests (that are not on the user manual page for a good reason, I guess), or the contributor's guide. I understand the reason for two different layouts, to keep things as accessible as possible for the active contributors. But probably we have a significant number of users running unstable on a daily basis, but who are non-(yet-)developers and would prefer an equivalent layout. TIA, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Missing #anchor on website links
On 2016-11-29 15:59, Alexander Kobel wrote: [...] Could someone who knows how to do it adjust the links to the unstable manual on [...] http://lilypond.org/development.html Sorry, wrong clipboard entry. This should have been the stable manuals page at http://lilypond.org/manuals.html (box "Other material", entry "Development: manuals for the unstable version") [...] TIA, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Missing #anchor on website links
On 2016-11-29 15:29, Erik Ronström wrote: [...] While the old site may not be the most beautiful (although I have seen worse!), it is very functional, with good overview and almost all resources available with a single click from the first screen, without any scrolling. [...] I agree that the current one is very functional for me with one exception: the links to the manual of the developer version. And I just realized why. Could someone who knows how to do it adjust the links to the unstable manual on http://lilypond.org/ (navigation side bar, section "Unstable Release", link "Manuals 2.19.x") http://lilypond.org/development.html (box "Other material", entry "Development: manuals for the unstable version") to point to http://lilypond.org/development.html#Manuals-2 instead of just http://lilypond.org/development.html ? As it is now, I constantly click those links and go back and forth again, because the Manuals box is on the bottom of the dev version page and not visible on my screen without scrolling. First reaction: "I must have missed the 'Manuals' link and clicked on 'Download 2.19.x' instead..." In fact, I tend to be confused about the different layout and sectioning of the manual pages for stable and unstable. Now suddenly I wonder whether in the long run it would be a good idea to have an identical structure for downloads, manuals, regtests etc. for stable and unstable, but use a different (background) color (scheme) for the two? Thanks in advance, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: broken mpost binary from TeXLive
On 09/04/2013 11:40 AM, Werner LEMBERG wrote: As far as TL goes, there were no releases of mpost between TL'12 and TL'13. We did not do any bug-fix binaries in 2012 (and I sincerely hope we never have to again). So all I can say is that mpost 1.802, the original TL 2013 binary, has the bug. The TL'12 version was 1.504. Thanks. So it probably makes sense to exclude 1.504 mpost --version 1.803 in the configure script. Julien, can you take care of that? Hm. Missed that issue earlier. This whole thing is very suspicious in the sense that mpost 1.803 segfaults on ARM architectures (from Arch Linux' texlive-bin). The same version (as announced by the package repositories' numbers) works fine on my x86_64 Arch environment. I placed a report under https://github.com/archlinuxarm/PKGBUILDs/issues/550 since I assumed it to be an Arch Linux on ARM-only problem, but now I'm curious whether part of the bug survived... I probably won't be able to test until next week, but I'll investigate a bit more then (and probably try to contact the TeXLive gurus). Best, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Most popular French users request : bar numbering of alternatives
On 2011-11-28 09:44, Colin Hall wrote: On Mon, Nov 28, 2011 at 01:04:06AM +0100, Xavier Scheuer wrote: Dear LilyPond developers, Dear Bug Squad members, could you add this enhancement request to the tracker? Thanks! This is by far the most popular enhancement request from the French users mailing list: Bar numbering of repeat volta _alternatives_. Currently LilyPond counts the measures of each alternative as normal, unrepeated, measures hence incrementing the currentBarNumber in both alternative 1. and 2.. Several references supports what is actually asked by many users: bar numbering of alternatives should not be counted twice. Thanks, Xavier. Added to the tracker as issue 2059: http://code.google.com/p/lilypond/issues/detail?id=2059 Looks like a duplicate of http://code.google.com/p/lilypond/issues/detail?id=785 with some additional links... Best, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Minor website typo
On 2011-11-26 12:27, Colin Hall wrote: On Sat, Nov 26, 2011 at 12:11:22PM +0100, Helge Kruse wrote: There is a little typo on http://www.lilypond.org/text-input.de.html. You read FagottNoteb where it should be FagottNoten. The figure just below should also read Transposition für F-Instrumente instead of F-Instrumen. Best, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \fill-line, \column bug
On 9/20/11 12:52 PM, a...@bflat.demon.co.uk wrote: The following snippet produces the desired effect with LilyPond version 2.12.3, but the output is shifted off the left of the page in version 2.14.2 (pdfs attached) I don't have my LilyPond setup available, so I have to tell you what I remember. Try \left-column instead of \column, or add a \left-align. There was a deliberate change in the choice of reference points and, thus, extents of markups with center-alignment during the development of LilyPond 2.13 which causes this unexpected behaviour. IIRC, this problem occured on lilypond-user before, I just could not find it right now. For the record, I don't think it's a bug or regression, rather a deliberate change in semantics. HTH, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \fill-line, \column bug
On 9/20/11 12:52 PM, a...@bflat.demon.co.uk wrote:
I'm not top posting.
The following snippet produces the desired effect with LilyPond version 2.12.3,
[...]
\markup \fill-line {
\line {
\column {
And do you really need the \line after \fill-line?
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug in ties over barlines
On 2011-01-31 11:04, Jan Warchoł wrote:
[...] If the last note in the
following example doesn't get a natural, it's *impossible* to tell
that it's not another ces:
ces'1~ | ces'
ces'1( | c')
It may be argued that the slur looks different than the tie, but it's
not enough.
I'm sure that engraving books will agree with me - may someone check this?
Now that I have a brand new copy of Gardner Read's Music Notation in
my bookshelf since just yesterday, I do. I didn't yet read the whole
book, though...
In the chapter for accidentals (p. 131), it says:
It is not necessary to repeat the accidental before a tied note. The
tie itself serves to prolong the effect of the accidental. The one
exception to this general rule occurs when the note or notes affected by
an accidental and tied over the barline come at the end of a system or
at the bottom of the page.
Which is what we all know.
Regarding slurs, I found exactly nothing. But I'm absolutely sure, if
Read had written anything about it, it would be: If in doubt whether
the reader will know what to do: make it clear. Or, rather: Write the
natural, dummy. He constantly advocates the use of notation that eases
the understanding of the music, and disapproves any elements that are
hardly possible to distinguish or perform.
And this may be an example just too obvious that he felt the need to
comment it.
Not that I know a single instance where this occurs, though. In a piano
piece that requires a moderately trained player, perhaps I'd leave it
out; but only in the case of chords which are very clear to interpret.
Yet, in any other case, I consider it good style to write the natural
even when there's no slur. In particular for a single voice, say a
two-note melisma in choral music.
By the way: if you have { r2.. cis8( | c2!) r2 } all over the place,
and then there suddenly comes a { r2 cis2~ | cis2 r2 }, you'd expect an
additional sharp there too, don't you?
Just my two pence...
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug in ties over barlines
On 2011-01-31 21:06, James Lowe wrote:
-Original Message-
From: Alexander Kobel n...@a-kobel.de
By the way: if you have { r2.. cis8( | c2!) r2 } all over the place,
and then there suddenly comes a { r2 cis2~ | cis2 r2 }, you'd expect an
additional sharp there too, don't you?
Hmm...why not use (in your example) { r2.. cis8( | c2?) r2 } which to me
makes more sense. [...]
No one (as I can see) has spoken about the ? Vs ! And I think that's the
difference for me. It depends on what is already sharp/flat in the key
signature as a musician. ! Means it isn't and ? Means it is but 'be aware'
right?
Ah, good point. I didn't actually think about the ? vs. ! difference;
probably it's just a matter of personal taste of the engraver. In this
situation, I guess both can be reasoned: the cautionary since the key
signature says it should be c by default anyway, and the mandatory
accidental (without parentheses) because tie and slur could not be
distinguished otherwise, so it's indeed at least semi-mandatory.
But IMHO the important point here is the fact that the notation can be
ambigous without the accidental, and is definitely clear with it. No
matter if ? or !.
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \center-column sometimes appears not to reserve space.
On 2010-12-19 13:26, Phil Holmes wrote: Reinhold Kainhofer reinh...@kainhofer.com wrote in message news:201012151811.36267.reinh...@kainhofer.com... Am Mittwoch, 15. Dezember 2010, um 15:43:42 schrieb David Kastrup: It would appear that the middle column has no horizontal size at all. I think that's a regression in comparison to the last stable version. Nope, no regression, it was also broken in 2.12.3 I've slightly lost track of this. Bug or no Bug? I'd say no bug, but the whole range of horizontal alignment commands sometimes yield quite surprising output (from the user's POV; formally, it's fine). IIUC, a center or right alignment implies a negative left x-extent value, which gives funny results with concat. I dimly remember that Reinhold once tried to change this. (It'd be a lot easier to understand for the user if the left extent started at 0). But he recognized that this will affect a large number of small tweaks and features, like compound time signatures, and he decided to drop the idea. Might be interesting for GLISS, though. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.39: Yet another vertical spacing bug...
On 2010-11-21 05:13, Joe Neeman wrote: On Sat, Nov 20, 2010 at 5:10 AM, Alexander Kobel n...@a-kobel.de mailto:n...@a-kobel.de wrote: See the attached example; with the increased 'nonstaff-nonstaff-spacing, the ChordNames run into the staves they belong to. No, it wasn't known. And now, it's fixed in git. Thanks for the report, Perfect; thank you very much. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
2.13.39: Yet another vertical spacing bug...
...or is it known already? I completely lost track of what are
different bugs and which are not.
See the attached example; with the increased 'nonstaff-nonstaff-spacing,
the ChordNames run into the staves they belong to.
Note that this is not an artifical example; it's a simplistic, but
common setting of simple chants with several stanzas.
By the way, I generally think that the distance between ChordNames and
Lyrics above should be larger by default; they have no padding without
tweaking the defaults. I'm not sure how to define this, though...
Should one just increase the distance between systems?
Cheers,
Alexander
\version 2.13.39
lyr = \lyricmode { \repeat unfold 4 { Foo bar foo bar foo bar foo bar foo bar foo bar foo baz! Xyz -- zy! } }
ch = \chordmode { \repeat unfold 2 { a2 b | c d | e f | g1 } }
mus = \repeat unfold 4 { \repeat unfold 16 { a'8 } \break }
\score {
\new ChordNames \ch
\new Staff { \new Voice = mus \mus }
\new Lyrics \lyricsto mus \lyr
\new Lyrics \lyricsto mus \lyr
\new Lyrics \lyricsto mus \lyr
\new Lyrics \lyricsto mus \lyr
\layout {
\context {
\Lyrics
%% Comment the next line and no collisions occur.
\override VerticalAxisGroup #'nonstaff-nonstaff-spacing #'space = #4
}
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 146 in lilypond: bar counters for normal bars
On 2010-11-19 15:37, Phil Holmes wrote: lilyp...@googlecode.com wrote in message Comment #5 on issue 146 by lemzwerg: bar counters for normal bars http://code.google.com/p/lilypond/issues/detail?id=146 It's simply not implemented yet. Someone has to add a RepeatCounter grob (in analogy to PercentRepeatCounter). I'm struggling to understand the difference between what's requested in 146 and what is delivered with the current LilyPond implementation of bar/measure numbers. Hi, Phil, see e.g. http://lsr.dsi.unimi.it/LSR/Item?id=651. Which is sort of a really, really nasty workaround to implement them; I have a vague idea about making it only singly-really nasty, and adopting it for better spacing, but I won't deal with it before 2.14. is there. Even then, it'll be far from an easy-to-use solution. The bar counters are stand-alone staff-like thingies which can be printed at an arbitrary position of the score (above, below, or even in between for large scores). The bar numbers should be centered between bar lines, and typically the font much more present or dominant than for measure numbers. I think they are primarily intended for conductor's scores. (Note this is what I feel bar counters should look like, and it's similar to what Werner implemented in the much simpler http://lsr.dsi.unimi.it/LSR/Item?id=473. For a proper enhancement, we should have a look in some notation guidebook.) Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 146 in lilypond: bar counters for normal bars
On 2010-11-19 18:17, Valentin Villenave wrote:
On Fri, Nov 19, 2010 at 3:48 PM, Alexander Kobeln...@a-kobel.de wrote:
(Note this is what I feel bar counters should look like, and it's similar to
what Werner implemented in the much simpler
http://lsr.dsi.unimi.it/LSR/Item?id=473. For a proper enhancement, we
should have a look in some notation guidebook.)
Werner's workaround is quite clever actually. Wouldn't it be enough to
just create an easy-to-use macro around it?
Well, I appreciate the pragmatical solution, but IMHO it lacks three
important things.
First, RehearsalMarks cannot (easily) be printed there, and I think they
should be offered per default. I don't know if that'd be possible if we
wrap the percent repeat voice into a separate context and add a
\consists Mark_engraver, but I assume that should work. Whether text
scripts should be allowed - well, they don't do any harm, so we could do
this, too.
Second, IIUC the PercentRepeat approach is (currently) unusable with
time changes; the numbering always starts at 1 (or, rather, 2), since
you have to start a new \repeat percent x { s[new-measure-length] }
section. Keeping up with the measure numbers would imply considerable
tweaking, as in really reading out the current (global) measure number.
And imagine a piece with time change in every or nearly every bar (not
too uncommon that, say, 3/2+2/2 renaissance or more modern music gets
notated that way): That'd mean that no bar count is printed _at all_,
since the PercentRepeats lag by one measure.
But IMHO the single big no-no to add this as a macro is that the user
has to manually specify the length (and measure structure, for time
changes) of the counted music. That's unnecessarily complicated, just
to print some property that is /already there/ globally, namely in
measure numbers (and Score.RehearsalMarks, if you want them). I would
not want to cement such a highly redundant syntax. What we actually
want is some context that automagically extends over the whole piece,
and which we can position like any staff or lyrics line.
(Um. Context keeping themselves alive... Sounds hard.)
If, however, this should be possible easily, then of course by all means
do so. And if the first two points can be easily accomplished, but the
third does not look feasible in the medium-term, then do so as well.
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LyricText #'font-series = #'bold-narrow ?!
On 2010-10-28 02:30, Ralph Palmer wrote: On Wed, Oct 20, 2010 at 9:27 AM, Valentin Villenave valen...@villenave.net mailto:valen...@villenave.net wrote: Hi Alexander, CC-ing to the bug list just in case. On Wed, Oct 20, 2010 at 2:39 PM, Alexander Kobel n...@a-kobel.de mailto:n...@a-kobel.de wrote: why does LyricText #'font-series default to #'bold-narrow? [...] Greetings - I'm directing this primarily to bug-list folks. This was submitted over a week ago, and I see no action. Did I miss something? [...] Hi, Ralph, thanks for your attention, but it's fixed (by commit d0c8a258b168c41a3d40f714c55f8fccadfe7d8c). Werner and I forgot to send a note to the bug- list, sorry. I don't understand fonts or typefaces or their parameters well, so I don't understand whether there is a bug or not. Since we don't offer a bold-narrow style in Century Schoolbook (and most other fonts don't as well), the fallback was the regular font anyway. So it's been an unexpected expected (desired) behaviour. [1] This observation makes me wonder: is it possible to define different font basenames for several series of, say, the serif default font? Some of my favourite fonts come in two flavours for normal spacing and condensed spacing, and my workaround - if I need both - is to define the condensed one as the monospace font to have easy access on it. Which works, but is a complete abuse of the monospace entry. The Real Thing would be to say GarmdITC Bk BT is my default serif font, with default proportions, GarmdITC BkCn BT is the corresponding condensed font. Some typefaces even need the same for bold, ultra-bold or something like this (e.g. Arial vs. Arial Black). And when 'font-series is switched, of course the appropriate basename should be chosen. This might count as enhancement request. Postponed, if you ask me. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
\new Score
[branched from -user: 'Where does \override Score.BarNumber ... go']
On 2010-09-03 15:41, Graham Percival wrote:
On Fri, Sep 03, 2010 at 10:16:06AM +0200, Alexander Kobel wrote:
But this makes me wonder: I vaguely remember a distinction of \score
and \new Score, which I can't find in the docs.
The distinction is that \new Score should not be used, and issue
1033 is to remove it entirely from the docs.
Hm, I see. And I recognized the potential problems.
But in the light of a consistent syntax and semantic, I see no reason
(from the users POV) to disallow it. After all, the real top-level
context is a \book {}, isn't it, and I don't see a point in disallowing
a \new Score construct just like \new Staff.
From a syntactical POV, I see the following pros for \new Score:
- You can write \with { ... } for every other context but \Score, which
(for consistency) should also work with \new Score.
- When there's a \new Foo Bar, there's also a \context Foo Bar, which
makes the same as a parallel instantiation of all Bar's.
- [Quoting Rune from
http://www.mail-archive.com/lilypond-de...@gnu.org/msg14713.html]:
I know that the \score-statement is a syntactical construct, but I
think it would be nice to hide this fact from the users.
I think we could make the use of score-block much more intuitive if
changing the syntax to \new \Score and adding an implicit
sequential-statement to the score.
I think the Real Thing would be to fix \new Score s.t. it works properly
in the above manner, right?
I agree it's useful to remove all mentions from the docs for now, but I
suggest to keep a allow \new Score (postponed) issue there.
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: after-title-spacing: space includes title
On 2010-09-28 17:59, Phil Holmes wrote:
Mark Polesky markpole...@yahoo.com wrote in message
news:25356.6360...@web83405.mail.sp1.yahoo.com...
Mark Polesky wrote:
NR 4.1.2 Page formatting - Vertical dimensions says...
after-title-spacing:
space – the amount of stretchable space between the
baseline of a title and the center of the staff that
follows it;
But compiling a test file with annotate-spacing suggests
that the space is measured from the *top* of a title,
not the *baseline*.
Mark,
I can't test on 13.35 since it hasn't been released. Can you confirm
whether this is a problem with 13.24?
It is.
The following snippet eases the recognition (at least for
minimal-distance, but it's the same for space):
\header { title =
}
\paper { after-title-spacing = #'((minimum-distance . 0) (padding . -10)) }
\repeat unfold 8 { c''2 c'' }
Besides, sorry for not putting this to the list:
http://codereview.appspot.com/1710046/ It's an issue about the
correct description of vertical spacing variables in the docs, and I
mentioned Mark's observation in my last update this morning.
I'd have included the doc fix if it were for sure that the behaviour
stays for 2.14 (which I assume - the policy on the other entries was:
document the current algorithm, and don't change anything unless a user
gives reasonable complaints).
@ Mark: Is it only that the docs are plain wrong, or do you really need
the baseline-alignment for some reason?
@ Joe: That said, I think the baseline of the bottommost line of the
header would be the natural place to measure the space from, since one
does not have to change the spacing alist when adding a new header
field. Do I miss something there? Would that be a lot of trouble to
change?
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: after-title-spacing: space includes title
On 2010-09-28 19:03, Graham Percival wrote: On Mon, Sep 27, 2010 at 10:39:40PM -0700, Mark Polesky wrote: NR 4.1.2 Page formatting - Vertical dimensions says... after-title-spacing: I haven't read the patch in detail, but does this have anything to do with this 3-month old spacing doc patch? http://codereview.appspot.com/1710046 http://code.google.com/p/lilypond/issues/detail?id=1158 Nope, not quite, but it's similar. That's the one in which I added the remark. ;-) Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
\transpose and \relative
Dear bug squad, dear developers, is there a particular semantical or syntactical reason (other than implementation left to do) why \transpose does not respect \relative mode? If not: I know of the agreement not to file known issues mentioned in the docs as enhancement requests in the bug tracker, but I guess this might be a candidate for GLISS. Is there a topic list where I can leave a note? Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: FullCadenzaRest?
On 2010-09-08 19:44, Xavier Scheuer wrote: On 8 September 2010 18:51, Alexander Kobeln...@a-kobel.de wrote: Hi, all, is there a proper way to have a FullCadenzaRest during a cadenza? [...] It'd be really nice to have an equivalent to R for a full cadenza (or part thereof between two bar lines). Hi! Why not use a separate variable for cadenza and #(ly:export (mmrest-of-length MyCadenza)) as it is suggested in the doc NR 1.2.6 Special rhythmic concerns Aligning to cadenzas http://lilypond.org/doc/v2.13/Documentation/notation/special-rhythmic-concerns.html#aligning-to-cadenzas ? Okay, this spares the manual counting of the length of the notes. But note that this is NOT a cadenza in the sense of \cadenzaOn / \cadenzaOff, since it amounts to _metered_ music, while \cadenzaOn introduces an _unmetered_ section. Thus, the approach suggested is just a clever way of doing my example 3, isn't it? Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Add prefix to lyrics
[cross-posted from -user to bug-, see footnote]
On 2010-09-02 13:51, Kieren MacMillan wrote:
Wouldn't this be easier? [...]
\relative { g'2 f }
\addlyrics { \override LyricText #'self-alignment-X = #0.75 Pro - phe --
tan }
Well, yes, but it doesn't really give the expected output, since the
LyricHyphen does not use the glyph of the LyricText font, but instead a
custom line markup.
I never managed to understand this rationale in the first place, and
there even is a note in the sources to change this behaviour. [1]
But for what is implemented now, I don't see how to do this without
excessive ugly Scheme-hacking, like Neil proposed. Once I also tried to
exchange the LyricHyphen stencil to mimic LyricText, but to no avail -
AFAICS, the alignment of the hyphens is more or less hard-coded in the
C++ part.
@ Robert:
In summary, I don't think there is an easier way. I might be wrong, though.
Cheers,
Alexander
[1]
lily/lyric-hyphen.cc: (line 555-556)
TODO: should extract hyphen dimensions or hyphen glyph from the font.
I could not find it in the bug tracker, though, thus my cross-post to
the bug- list.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: countPercentRepeats: print number 1?
On 2010-08-17 22:20, Xavier Scheuer wrote: Hi! [...] Is it possible to tweak countPercentRepeats in order to print the number 1 above the first normal (i.e. with the notes instead of the percent symbol) measure of a percent repeated measure? I'm not looking for a *dirty* workaround, such as using a text attached to an invisble MultiMeasureRest, so it does the trick. [...] When I wrote my *really* dirty workaround not too long ago (search for BarNumberStaff in the mailing list, since the LSR is down right now), I came to the conclusion that this is not easily supported out-of-the-box. And if it is not, could it be implemented in a not-too-distant future? (in this case, could a gentle Bug Squad member open a new issue for this?) This is AFAIK a quite common practice and should be do-able (at least a possible option) without needing some tricky workaround, IMO. +1. At the very least, even if it's not common practice, it should do no harm to add this option for both MultiMeasureRests and PercentRepeats, neither should it be too hard for someone who understands what's going on internally and knows how the first number gets suppressed. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: countPercentRepeats: print number 1?
On 2010-08-17 22:50, Neil Puttock wrote: On 17 August 2010 21:20, Xavier Scheuerx.sche...@gmail.com wrote: Is it possible to tweak countPercentRepeats in order to print the number 1 above the first normal (i.e. with the notes instead of the percent symbol) measure of a percent repeated measure? No. In the first bar, there's no PercentRepeat (and you can't force one to be created). Oops, sorry, I see now the difference between those options for a MultiMeasureRest and the PercentRepeat. For the former, there already is the grob, and it just lacks the number. In the second case, the number is not suppressed; rather, no PercentRepeat is there at all, and we have to dig deeper to create/simulate one. Anyway, the request sounds reasonable to me. It's probably feasible using a scheme engraver: the counter would be similar to a MultiMeasureRestText object, spanned between successive barlines. Such an engraver might be interesting to have in general - I can't see a simple way (other than hijacking the MultiMeasureRestText) to center a markup above a measure, right? Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tremolo with more than two notes
On 2010-07-06 18:01, Phil Holmes wrote:
Helge Kruse helge.kruse-nos...@gmx.net wrote in message
news:loom.20100706t155232-...@post.gmane.org...
Since the documentation says that only two notes tremolos I think this
is a
feature request and not a bug.
I need to write a piece with a tremolo like fast repetition. But since
there are three notes in this repetition, the
\repeat tremolo n { x y }
doesn't work. How can I achieve such notation?
Minimal example:
\score {
\new Staff {
\time 3/4
\repeat tremolo 2 { b8. c' }
\repeat tremolo 3 { b8. c' d }
}
}
Helge,
Please post this question to lilypond-user where there are likely to be
more people able to help.
Hi,
this actually has been forked from -user and should be regarded as a
feature request: Support for tremoli of more than two notes. A
workaround is given on -user, but it's just cheating by tweaking the
appearance of note heads.
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: collision bug?
On 2010-06-22 07:20, James Bailey wrote:
On 21.06.2010, at 21:55, Kieren MacMillan wrote:
Hi all,
There appear to be at least two collisions in this small snippet that
are unsightly: the first flat and the preceding rest, and the second
flat and the preceding ledger line.
Regression?
If this is to be added as a regression, can you say which version
produces acceptable output?
Hi,
AFAICS it's between 2.13.24 (and earlier) and 2.13.25 (see attached
outputs).
Cheers,
Alexander
\version 2.13.25
\include english.ly
thenotesI = \relative g' {
g2( af)
}
thenotesII = \relative af {
r8 af( df ef f2)
}
\score {
\new Staff \thenotesI \\ \thenotesII
attachment: collision-2.13.24attachment: collision-2.13.25___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
(2.13.x) bottom-system-spacing
Hi, Joe,
this is following a problem on -user which Kieren helped me to solve
(mostly).
http://lists.gnu.org/archive/html/lilypond-user/2010-06/msg00309.html
I think I stumbled across an inconsistency of bottom-system-spacing, though:
From the docs (NR 4.1.2), bottom-system-spacing should specify the
spacing to the top of the bottom margin. From my experiments however,
it seems that only minimum-distance behaves this way, while padding
relates to the top of the /footer/ instead.
While I actually prefer the way padding works, I'm unsure whether that's
a bug or not. In the latter case: should minimum-distance also relate
to the top of the footer, for consistency? I attach a snippet showing
the behaviour - try to comment out line 14 to see what I mean.
By the way, is it correct and desired that foot-separation does not
exist anymore?
Cheers,
Alexander
\version 2.13.24
\pointAndClickOff
low = { \repeat unfold 23 { c''1 } c1 }
high = \repeat unfold 24 { c''1 }
\paper {
ragged-last-bottom = ##f
%% padding relates to the top of the footer,
bottom-system-spacing = #'((minimum-distance . 0) (padding . 0))
%% while minimum-distance relates to the top of the bottom margin.
bottom-system-spacing = #'((minimum-distance . 5) (padding . -inf.0))
oddFooterMarkup = \markup {
\with-color #red \filled-box #'(20 . 90) #'(0 . 5) #0
}
evenFooterMarkup = \markup {
\with-color #green \filled-box #'(20 . 90) #'(0 . 3) #0
}
}
\score {
\new Staff {
\low \pageBreak
\high \pageBreak
\low \pageBreak
\high \pageBreak
\high \pageBreak
\low \pageBreak
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: (2.13.x) bottom-system-spacing
On 2010-06-18 14:31, Joe Neeman wrote: On Fri, 2010-06-18 at 13:08 +0200, Alexander Kobel wrote: From the docs (NR 4.1.2), bottom-system-spacing should specify the spacing to the top of the bottom margin. From my experiments however, it seems that only minimum-distance behaves this way, while padding relates to the top of the /footer/ instead. padding, in general, controls the amount of whitespace that must be present. [...]As far as I can see, this is consistent with the way that all the spacing variables work. That's clear... (even though the other bottom-system-spacing variables refer to the middle line of the bottom staff and the top of the bottom margin) ... but this is where I see the inconsistency - why not the top of the footer? But I may be completely wrong, since minimum-distance does not consider the extents of staves (or markups like footer?) at all, AFAICS. (Besides, I guess the difference only is visible for obscure hacks, since usually padding will dominate minimum-distance.) By the way, is it correct and desired that foot-separation does not exist anymore? I did intend to remove it, yes. Is there some important functionality that can't be obtained without it? No, I think it's functionally equivalent. IIUC, you can increase the bottom-system-spacing 'padding by the amount of desired foot-separation, scaled to staff spaces? It's just that foot-separation is a much simpler variable for the common user to set than bottom-system-spacing, and it looks easier for backward compatibility. Not that there is backward compatibility, though, since vertical spacing changed so much for the good. Thanks, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: (2.13.x) bottom-system-spacing
On 2010-06-18 16:02, Joe Neeman wrote: On Fri, 2010-06-18 at 15:47 +0200, Alexander Kobel wrote: On 2010-06-18 14:31, Joe Neeman wrote: On Fri, 2010-06-18 at 13:08 +0200, Alexander Kobel wrote: (even though the other bottom-system-spacing variables refer to the middle line of the bottom staff and the top of the bottom margin) ... but this is where I see the inconsistency - why not the top of the footer? For the same reason that between-system-spacing uses the center of the staff and not the edge. The height of the footer can vary from page to page and if we use it then the vertical spacing will not be consistent. Okay, I see now. Maybe this should be mentioned in the docs, then. No, I think it's functionally equivalent. IIUC, you can increase the bottom-system-spacing 'padding by the amount of desired foot-separation, scaled to staff spaces? It's just that foot-separation is a much simpler variable for the common user to set than bottom-system-spacing, and it looks easier for backward compatibility. Not that there is backward compatibility, though, since vertical spacing changed so much for the good. Perhaps foot-separation by itself was simpler, but bottom-system-spacing is consistent with all of the other new variables and we don't need two different variables for the same thing. True. Again, a hint in the docs, where foot-separation used to be, might be useful. Thanks again, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: (2.13.x) bottom-system-spacing
On 2010-06-18 17:02, Graham Percival wrote: On Fri, Jun 18, 2010 at 3:42 PM, Alexander Kobeln...@a-kobel.de wrote: On 2010-06-18 16:02, Joe Neeman wrote: For the same reason that between-system-spacing uses the center of the staff and not the edge. The height of the footer can vary from page to page and if we use it then the vertical spacing will not be consistent. I don't have a clue what you're talking about, but it sounds like something that falls under the small doc additions after looking at documentation suggestions: True, and understood. ;-) I'll try to figure something out, but give me until Sunday evening or even Monday. I'm just leaving for the weekend. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Regression?: Melismata disturb note head distances in 2.13.x
Hi, all,
I think I stumbled across a regression regarding note head distances
with melismata in 2.13.24, compared to 2.12.3, which is not yet in the
tracker. Anybody to confirm and/or add to the tracker? (PNGs attached,
the PDFs are too large for the -bug list. 64KB is darn small these days...)
A workaround can be seen in the snippet, but it requires quite a bit
more writing when you actually want to use the induced melismata by
manual beaming.
I also tried to find the exact commit causing the regression. Looks
like it's some commit for 2.13.5: hit
http://lilypond.org/test/v2.13.5-0/compare-v2.13.3-9/index.html and
scroll down for an output distance of 10.998043 for the regtest
lyric-ignore-melisma-alignment.ly, or 10.875328 for
lyrics-melisma-beam.ly. You can see there that the spacing between the
quavers gets uneven, probably caused by the Whee! syllable.
I looked at the git log (only commit descriptions, not the code, yet),
and could find that there were some changes to the automatic and manual
beam behaviour going on, mainly for the beam direction shortcuts in
manual beams. I'm not sure if this is the correct place to investigate
this, though, because spacing also changes with ties and manual
melismata, not just manual beams, as shown in the attached snippet.
On a side note, we seem to be short of a regtest for melismata where
syllables have a relevant length to check those issues. The additional
space in both snippets is visible, but not quite too present for a
regtest, and Ky -- ri -- e might not be the best text in
lyric-melisma-manual.ly.
Cheers,
Alexander
\pointAndClickOff
\paper {
#(set-paper-size a4 'landscape)
ragged-last-bottom = ##f
}
\score {
\context Voice = v \relative c' { c16\melisma c c c\melismaEnd c\melisma c c c\melismaEnd c\melisma c c c\melismaEnd c\melisma c c c\melismaEnd }
\new Lyrics \lyricsto v \lyricmode {
\override LyricText #'self-alignment-X = #LEFT
\override LyricText #'extra-spacing-width = #'(+inf.0 . -inf.0)
AAA __ BBB __ _ CCC
}
\header { piece = \markup \column { expected (manually tweaked) side-effects from extra-spacing-width tweak not demonstrated here, e.g. possible collisions with SpanBars } }
}
\score {
\context Voice = v \relative c' { c16( c c c) c( c c c) c( c c c) c( c c c) }
\new Lyrics \lyricsto v \lyricmode { AAA __ BBB __ _ CCC }
\header { piece = with slurs (correct in 2.12.3 and 2.13.24) }
}
\score {
\context Voice = v \relative c' { c16~ c~ c~ c c~ c~ c~ c c~ c~ c~ c c~ c~ c~ c }
\new Lyrics \lyricsto v \lyricmode { AAA __ BBB __ _ CCC }
\header { piece = with ties (REGRESSION: correct in 2.12.3, wrong note distances in 2.13.24) }
}
\score {
\context Voice = v \relative c' { \autoBeamOff c16[ c c c] c[ c c c] c[ c c c] c[ c c c] }
\new Lyrics \lyricsto v \lyricmode { AAA __ BBB __ _ CCC }
\header { piece = \autoBeamOff and manual beaming (REGRESSION: correct in 2.12.3, wrong note distances in 2.13.24) }
}
\score {
\context Voice = v \relative c' { c16\melisma c c c\melismaEnd c\melisma c c c\melismaEnd c\melisma c c c\melismaEnd c\melisma c c c\melismaEnd }
\new Lyrics \lyricsto v \lyricmode { AAA __ BBB __ _ CCC }
\header { piece = \markup \column { \melisma and \melismaEnd (wrong lyric alignment (issue 773) for syllables w/o manual skip in both 2.12.3 and 2.13.24, but REGRESSION: additionally wrong note distances in 2.13.24 } }
}
attachment: melismata-2.12.3.pngattachment: melismata-2.13.24.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Regression?: Melismata disturb note head distances in 2.13.x
On 2010-06-16 11:31, Alexander Kobel wrote: Hi, all, I think I stumbled across a regression regarding note head distances with melismata [...] I also tried to find the exact commit causing the regression. [...] Update: It's somewhere between git branches release/2.13.3-0 and release/2.13.4-1. Still no clue which commit, though. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1116 in lilypond: Title not centered
On 2010-06-13 23:58, lilyp...@googlecode.com wrote: Comment #1 on issue 1116 by jameseli...@googlemail.com: Title not centered http://code.google.com/p/lilypond/issues/detail?id=1116 For the record (and in the hope that I fixed it and it doesn't matter anyway): This is certainly a regression between 2.13.11 and 2.13.12 (and thus against 2.12.x, too). Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tie positioning in chords with large intervals [engraving-nitpick?]
On 2010-06-07 18:07, Phil Holmes wrote:
Looks like this hasn't been progressed. Should it be raised as a bug?
Since nobody else seems to answer: Yes please, as far as I'm concerned.
Engraving-nitpick seems the right category to me, it's certainly a minor
issue.
[from another message]
(yes - I am working my way through .bugs for likely outstanding issues.)
While you're at it: Could you have a look at this one on -devel, too?
http://www.mail-archive.com/lilypond-de...@gnu.org/msg29267.html
It's been pinged just a few days ago, but it looks like is falling into
oblivion once again. Probably because it's hard to specify the desired
behaviour really well, but I think Kieren made a good effort in
http://lists.gnu.org/archive/html/lilypond-user/2008-06/msg00591.html.
Alexander Kobel n...@a-kobel.de wrote in message
news:4b570f21.3070...@a-kobel.de...
Hi, all,
in the attached example the tie positioning is not quite what I'd expect
to be the favourite option (on 2.13.11).
It's about chords with large intervals in between, where the tie can be
fitted into the space between note heads. This looks strange when the
inner ties exceed the range of the outer ties of the chord.
For stem-up chords, a simple workaround is adding transparent notes to
the chord, to block the empty space in between. For stem-down chords,
I'd prefer the tie (between the c'') to be a mirrored version of the
bottom tie (between the a'), i.e. attached to the center of the left
note head instead of either the left or the right side of it; this I
could not achieve with an additional note.
Would it be sensible to crop the range of interior ties to the union of
the extents of the outer ties in general?
Cheers,
Alexander
\relative c'' {
g d g,4~ g d g,
g d b g4~ g d b g
g d g,4~ g d b g
g d g,4~ g d \tweak #'transparent ##t b g
a' c, a4~ a c, a
a e c a4~ a e c a
a e c a4~ a c, a
a \tweak #'transparent ##t e c a4~ a c, a
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [Priorities]: Issue 884 is a regression
On 2010-06-02 12:55, Alexander Kobel wrote: As an additional enhancement request, it'd be nice to have a localized variant of page-count between \pageBreaks. E.g., I could imagine todefine page-breaks Sorry, this should read page-count, of course. either as an integer that gives the total number of pages, [...] with with I mean the expected behaviour until 2.12.x. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
[Priorities]: Issue 884 is a regression
[ Sorry, attachments were to large in the first attempt - see the link below. ] Dear bug squad, following the discussion spacing/breaking issue on -user, I'm sure that issue 884 http://code.google.com/p/lilypond/issues/detail?id=884 is a regression, but not classified as such. For verification, I [attached] created output from 2.12.3 (Ubuntu Lucid stable) and 2.13.22 for the very snippet in the bug tracker; 2.12.3 renders two pages as expected, 2.13.22 makes it four. Check out the files under http://lists.gnu.org/archive/html/lilypond-user/2010-06/msg1.html; they're just too big to post them on -bug. IMHO, the earlier variant is the expected one, so it should not be a documentation issue as mentioned in the bug report: Even _if_ you wanted to specify a certain number of pages between \pageBreaks, you often don't want the _same_ number between all manual breaks (which is what you actually specify via page-count as of 2.13.x). Rather, you want to add \pageBreak at critical points like the beginning of a new section or a really good page turn for performances, and leave the rest up to Lilypond. Besides, page-count just implies that you specify the total number of pages, doesn't it? As an additional enhancement request, it'd be nice to have a localized variant of page-count between \pageBreaks. E.g., I could imagine to allow the definition of page-count either as an integer that gives the total number of pages (expected behaviour until 2.12.x), or as a list of integers specifying the number of pages between consecutive \pageBreaks. If \pageBreak really divides the piece into different chunks, as Chris suggested in the bug report, the latter might actually be easier to implement than the first variant. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: BUG? (+ workaround) \change Staff produces wrong stem lengths (2.13.22)
On 2010-05-31 15:31, Neil Puttock wrote: On 31 May 2010 14:12, Alexander Kobeln...@a-kobel.de wrote: A workaround is to create a temporary new Voice context, but I think this is actually a bug. Opinions? I think this is the same problem as issue #487: http://code.google.com/p/lilypond/issues/detail?id=487 Yeah. Thanks Neil, missed that one; I'm pretty sure it's the same bug. I mentioned the workaround there for the sake of completeness. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: s or \skip - bug or expectable behaviour?
The following looks like fairly a minimal example for the behaviour you
encountered.
NR 1.2.2, Invisible rests, says that \skip requires an explicit
duration. But it is not mentioned / unspecified that this duration
argument counterintuitively is not remembered for the following chords,
contrary to the s spacer rests.
\repeat unfold 9 r4 \\
{
b2 s4 b
b2 \skip 4 b
}
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: centered dynamics piano template broken on 2.13.11?
Ken wrote:
I'm not top posting.
I just started to work on a new score using the centered dynamics template
(below). [...] Typically, I start to % things out when I encounter a
problem , but even after I commented everything out and basically reverted to
the original template, I still had crash. thoughts or input?
The Dynamics context as in the template (or at least very similar) is
built-in in 2.13.x, so the main error comes from the redefinition of
Dynamics. Things should just work if you remove the whole \layout { ..
} block from the score; the template in it's current state is deprecated
for 2.13.
No idea why it complains about Skip_event_swallow_translator, though...
HTH,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug report: Collision between accidental and tremolo
Graham Percival wrote: Looks like exactly the same bug. Thanks for the report, but no further action can be taken. No problem. Just wanted to be sure that it's not missed in case you think it's not the same bug. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug with LSR Item #233 (hairpin with centred dynamics)?
Kieren MacMillan wrote: Hi all, It appears that the snippet http://lsr.dsi.unimi.it/LSR/Item?id=233 does not respect the Staff fontSize (e.g., as set in a \with block). 1. What's the explanation? 2. What's a workaround? Hi, Kieren, I guess the reason is that the markup text is evaluated w.r.t. the Hairpin grob, which usually does not hold a font-size property, and thus is not affected by the fontSize setting. Thus, the grob-interpret-markup falls back to the per-score layout defaults, which is font-size = #0. The workaround is to use a \override Hairpin #'font-size = #42 in the \with block (for your favourite value of 42, of course). HTH, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Vertical spacing bug with TabStaff
Hi,
the attached file causes the last (Tab)Staff to run into the footer and
below.
Looks related to http://code.google.com/p/lilypond/issues/detail?id=850
- but the error still occurs in the current git snapshot, and this one
is marked as fixed.
Cheers,
Alexander
\version 2.13.7
\header {
title = Take some space
subtitle = Sorry about this clutter:
subsubtitle = I could not get the collision without it.
composer = The repeat / volta also seems to matter
arranger = Look at the bottom system!
}
x = \repeat unfold 3 e'' e4
notes = {
\time 3/4
\repeat volta 2 { \repeat unfold 7 \x }
\alternative {
{ \x \x }
{ \x \x }
}
\repeat unfold 50 \x
%% With manual page breaks, everything is fine again.
% \repeat unfold 30 \x \pageBreak \repeat unfold 20 \x
}
\score {
\new Staff \notes
\new TabStaff \notes
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bar in incorrect place when using \partial and \alternate volta repeats
P. Kayex wrote:
I start with a partial and I have a volta 2 section (with no alternate) and
the next bar after the repeat is 'measured' correctly from the preceding bar.
However in the next section where there is an alternate volta section, the bar
after the first repeat is broken incorrectly (as I see it) and I get a bar
check failure. I am expecting it to put a bar before the last dotted minim.
Hi, Pete,
the semantics for repeats with upbeats are explained in
http://lilypond.org/doc/v2.13/Documentation/notation/Long-repeats#Normal-repeats
In essence, you need the following layout (note the positions and
durations of the \partials):
TrumpetUpper = {
\key f \major
\time 2/2
\partial 4
\repeat volta 2 { c4 | c c c c | c r r }
\repeat volta 2 { a | a a a a | a a a a }
\alternative {
{ | g g g g | \partial 2. g g g }
{ | f f f f | f f f }
}
e | e e e
}
\score {
\new Staff \relative c'' { \TrumpetUpper }
}
Cheers,
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SpanBar and Lyrics [now also new: with Segfault]
Alexander Kobel wrote: Neil Puttock wrote: 2009/11/26 Alexander Kobel n...@a-kobel.de: since nobody came up with a solution to this one As a temporary workaround, you could try \once \override LyricText #'extra-spacing-width = #'(+inf.0 . -inf.0) though this might not work very well in tightly spaced lyrics. Oh, perfect; thank you very much! That's already enough for my needs right now. After looking at the explanation of #'extra-spacing-width, it came to my mind that it's even better to use #'(+inf.0 . 0) for syllables to the right of the bar line, and #'(0 . -inf.0) for syllables to the left. But, anyway - thanks a lot. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: change Pitch, strange behavior
Valentin Villenave wrote:
2009/11/27 Alexander Kobel n...@a-kobel.de:
But... it's nothing to do with \changePitch. Remove this command, and the
result looks the same.
I disagree (see below).
Hey, but I disagree, too (see below)! *squeak* ;-)
The reason why the rests look strange is
that the change Pitch gives them a different pitch and therefore
affects their vertical placement.
Nope. Look at the first staff of the attached snippet. There, the first
argument is running out of notes, and the rests stay on top. No matter
if \changePitch was used or not.
Gilles, perhaps it might be worth
adding a filter to leave rests alone?
Well, something actually goes wrong there; which seems to be the case
when both voices have rests at the same positions. Did not dig into it,
but see for yourself in the second staff of the snippet.
Uhm, by the way: Do we have the same version of \changePitch? I use the
one Stefan linked in his initial mail on this subject, which seems to be
the most recent one. Right?
http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00556.html
I'm not gonna add a new issue named \partcombine sucks -- we already
know it does :)
+1.
Valentin, if you did not gave up on \partcombine yet, feel free to add
another bug: \partcombine (also) sucks if the user tries to force it to deal
with music extracts of different lengths.
Does it? The following snippet looks fine to me:
{
c'1
\partcombine { d' d' d' d' } { d' c' c' }
c'
}
Well, admitted. Here you have a point. Let's say,
ln -s /dev/null /usr/share/lilypond/bugs/partcombine
echo \partcombine (also) sucks (at least) if it's given an input
ending in a rest and a shorter second argument.
/usr/share/lilypond/bugs/partcombine
See the last staff, with r instead of d in the last quarter of the first
argument your example.
So, and now off I go, to a brithday party, and work on changing my very
own pitch.
Cheers,
Alexander
inline: cp.png\include changePitch.ily
oben= { e''' 4. g''' gis'''4 g'''4. r r4 | }
obenNoRests = { e''' 4. g''' gis'''4 g'''4. g''' g'''4 | }
untenI = { g''4. bes'' c'''4 es'''4. }
untenII = { g''4. bes'' c'''4 es'''4. r r4 | }
untenIII= { g''4. bes'' c'''4 es'''4. s s4 | }
\new Staff { R1 \partcombine \oben \untenI \bar ||
R1 \partcombine \obenNoRests \untenI \bar ||
R1 \partcombine \oben { \changePitch \oben \untenI } }
\new Staff { R1 \partcombine \oben \untenII \bar ||
R1 \partcombine \obenNoRests \untenII \bar ||
R1 \partcombine \oben { \changePitch \oben \untenII } }
\new Staff { R1 \partcombine \oben \untenIII \bar ||
R1 \partcombine \obenNoRests \untenIII \bar ||
R1 \partcombine \oben { \changePitch \oben \untenIII } }
\partcombine { d' d' d' r } { d' c' c' }
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: change Pitch, strange behavior
Stefan Thomas wrote:
Dear Alexander,
look at the attached jpg-file. In my opinion the quarter-rests look strange!
Ugh. Okay, admitted.
But... it's nothing to do with \changePitch. Remove this command, and
the result looks the same.
Worse, if you add spacer rests in the second voice, no rests will be
drawn at all; seems like a variant of
http://code.google.com/p/lilypond/issues/detail?id=261.
Let's face it, \partcombine sucks. I quit using it long ago, since the
trouble compared to writing a simple {} {} and spacer rests in the
second part is just not worth it, IMHO.
Alas, it'd be great if it worked, though.
Valentin, if you did not gave up on \partcombine yet, feel free to add
another bug: \partcombine (also) sucks if the user tries to force it to
deal with music extracts of different lengths.
Stefan, in your case, however, there's an easy workaround: append s s
onto unten, and the \changePitch result will be enlarged by the two
rests. For some reason I did not investigate further, appending r r
does not work, but IIRC changePitch intentionally ignores rests in one
argument - after all, it should replace pitches, and rests don't have any.
Cheers,
Alexander
\include changePitch.ily
oben = { e''' 4. g''' gis'''4 g'''4. r r4 | }
untenI = { g''4. bes'' c'''4 es'''4. }
untenII = { g''4. bes'' c'''4 es'''4. r r4 | }
untenIII = { g''4. bes'' c'''4 es'''4. s s4 | }
\new Staff { R1 \partcombine \oben \untenI \bar ||
R1 \partcombine \oben { \changePitch \oben \untenI } }
\new Staff { R1 \partcombine \oben \untenII \bar ||
R1 \partcombine \oben { \changePitch \oben \untenII } }
\new Staff { R1 \partcombine \oben \untenIII \bar ||
R1 \partcombine \oben { \changePitch \oben \untenIII } }
inline: cp.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SpanBar and Lyrics [now also new: with Segfault]
Dear all (especially Valentin, i.e.),
since nobody came up with a solution to this one, could you please add
this to the bug tracker?
I'm attaching a more clean version of the input file, and suggest the
following text.
Note that the second example in the file produces a segfault for me,
with 2.12.2 and 2.13.7; is this related by any chance? If so, perhaps it
should go into the same bug report, otherwise it should be split. At
least, someone could test on her system if it's just my fault.
Thanks,
Alexander
SpanBars affect Lyric spacing even if allow-span-bar = #f
+
In the following snippet, the position of the second long-syllable
should not be influenced by the span-bar-event since there is no span
bar line between the two bottom-most staves.
The spacing is correct if the Span_bar_engraver is removed from the
Score context.
Unfortunately, I don't know where exactly the problem is - I see the
following possible reasons:
- Even with allow-span-bar, a transparent bar line gets drawn through
the whole system and affects positioning of other elements.
- The Lyrics positioning does only check for the existence of a
span-bar-event on this very position, not whether it's in the same range.
- The span-bar-event is not aware between which staves to draw a bar
line, and thus the Lyrics can't possibly guess whether they should
consider ignore this particular bar line position.
(Improbable, since the bar line is - correctly - not drawn, so the
event generated should know about it. = Is the span-bar-event one per
score or one per staff?)
Alexander Kobel wrote:
Hi, all,
does anybody know of a way to make Lyrics _not_ to respect a SpanBar
going through the whole score?
I want to keep the Span_bar_engraver for some bar lines, but I have
longer syllables in the lyrics which disturb the spacing at other
barlines. Thus I want them to ignore those barlines and rather use
\whiteout or something there.
\version 2.13.7
\score {
\new Staff { \repeat unfold 24 { c''8 } \bar |. }
\new ChoirStaff
\new Staff {
\override Staff.BarLine #'allow-span-bar = ##f
\override Staff.SpanBar #'allow-span-bar = ##f %% seems to do nothing at all
\new Voice = upper \repeat unfold 6 { c''2 }
\revert Staff.BarLine #'allow-span-bar
}
\new Lyrics \lyricsto upper \lyricmode {
%% long-syllables position should not be affected by the forbidden SpanBar
long-syllable a b c long-syllable d
}
\new Staff \repeat unfold 6 { c''2 }
\layout {
\context {
\Score
\consists Span_bar_engraver
}
}
}
%{
%% Commenting this score in yields a Segfault with both 2.12.2 and 2.13.7-8.
\score {
\new StaffGroup \with {
\consists Span_bar_engraver
} {
\new Staff { \repeat unfold 24 { c''8 } \bar |. }
\new Staff \repeat unfold 24 { c''8 }
}
\new ChoirStaff
\new Staff {
\new Voice = upper \repeat unfold 6 { c''2 }
}
\new Lyrics \lyricsto upper \lyricmode {
%% long-syllables position should not be affected by the SpanBar in the above StaffGroup
long-syllable a b c long-syllable d
}
\new Staff \repeat unfold 6 { c''2 }
\layout {}
}
%}
inline: spanbar.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Segmentation fault with \ and \!
Michael DePriest wrote: This line (measure 11 of the piece I'm working on) works just fine if I compile it without dynamics: [...] But if I add a diminuendo, [...] I get this in the terminal: GNU LilyPond 2.10.33 Hi, Michael. 2.10.33 is quite old. I don't have anything near around for testing; it does not look like that much of a change, but I strongly suggest that you switch to 2.12.something - this may already help, if it's a bug fixed since then. Processing `file.ly' Parsing... Interpreting music... [8][16][24][32][33] Preprocessing graphical objects...Segmentation fault I have other crescendos and diminuendos in the piece. No problem here, only using your input in a single-staff score, with 2.13.7. One thing that comes into my mind: (at least) if you have MIDI output, you need to specify a start loudness - like \f, \p or somewhat - before the first hairpin dynamic (\ or \). Anyway, this should not cause a segfault, but at least there's a chance it helps. Otherwise, I guess we need at least a full working minimal example of the bug; still, chances are that everything looks better on 2.12 or 2.13. HTH, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Links in snippet repository
Hi, yesterday I realized that the links in the sidebar of the snippet repository of 2.12 are broken: The topmost categories (Pitches, Rhythms, ...) expand, but the anchors of the single snippets always refer to the top of the page (i.e. http://.../snippets/Pitches#Pitches, e.g.). Now I recognized that also some of the links of 2.13 are broken: e.g. in the snippet list, section Editorial annotations, Analysis brackets above the staff and the two following snippet entries in the sidebar (Applying note head styles ..., Avoiding collisions ...) share the same URL (fine) and anchor (broken). http://lilypond.org/doc/v2.13/input/lsr/lilypond-snippets/Editorial-annotations#Analysis-brackets-above-the-staff should read: http://lilypond.org/doc/v2.13/input/lsr/lilypond-snippets/Editorial-annotations#Applying-note-head-styles-depending-on-the-step-of-the-scale and in line 151 of this file, a name=Analysis-brackets-above-the-staff/a should read: a name=Applying-note-head-styles-depending-on-the-step-of-the-scale/a (or, even better:) a name=Applying-note-head-styles-depending-on-the-step-of-the-scale / Further, for the correctly linked entries, the corresponding a name=Snippet-name / tag appears twice, in addition to a a name=snippet-name.ly / (line 113, 116 in the above file). (For version 2.12, these anchors (that should be a name=Snippet-name /) all look like a name=Category / - so in a sense, the links in the sidebar are correct, but the anchors in the main content are broken.) The problem also remains in the one-big-page view. I'm not entirely sure, but I suppose the broken links in 2.13 are exactly those which appear in multiple sections, and the first instance is correctly linked, while the second, third, and so on, occurence only has a link to the section. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug report: measure numbering after repeat with alternativeendings
Mats Bengtsson wrote:
This is another incarnation of Issue 355, which in my opinion is a clear
bug.
However, I'm not equally certain that the bar numbering always is done
the way Paul proposes
and would have to look through my collection of scores to see what is
the most common typesetting
practice.
Does anybody have authoritative information on how the bar numbering
should be done with alternative
endings?
/Mats
Well, it's certainly not authoritative, but since I admire the engraving
practice in the Bärenreiter Urtext editions...
In several piano reductions, they use running measure numbers along the
repeats, and depict both numbers, repeats in parentheses, like this:
(18)
|:---||||
6 (22)
||||||
12 (28) {1. }
|||||---:|
33
{2. }
||||||
39
||||||
I think it's particularly useful to denote the measure number of the
first repeated measure, even if it's in the middle of a line.
Note that the volta bars are counted, too.
This way, each point in time is uniquely identified, which should please
both the programmer's and the conductor's view.
Of course, things get ugly if there is a part repeated more than once; I
haven't spotted such a thing in my Bach scores from Bärenreiter. By the
way, if the whole piece gets repeated, they don't print bar numbers for
each stanza.
Also, one could argue to use the same numbering scheme for D.C., D.S. or
Coda constructions - at least for D.C. and D.S. without jumps in the
end, they don't do that. I don't have an example with a Coda.
On the other hand, more complicated constructions with = 3 repeats
typically appear in more modern popular music, where AFAIK everybody
tends to use the stanza numbers in the rehearsals.
Just my two pence...
Alexander
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tempo mark doesn't forget explicitly given bpm, v. 2.11.60
Valentin Villenave wrote: [...] The ultimate enhancement would be that when you type \tempo Andante LilyPond would recognize it and attribute a default Andante tempo to the MIDI rendering... but maybe that's science-fiction. [...] I guess this would neither be necessary nor good. There's a myriad of tempo mark texts, some (most?) with different meanings w.r.t. the piece they occur in. You cannot really think about handling all this, and even if you do, I guess the time for this may better be spent on other things. Most of the time, you will have to manually adjust the context settings anyway, and don't gain anything. My two pence... On the other hand, I could imagine something like a Metronome mark spanner: (Real-world example for the relevant part; and yup, incalzando has other meanings besides just tempo, but that's not the point here...) \tempo 4 = 76 c1 d1\startTempoSpan incalzando 4 = 76 4 = 63 % Start here at tempo 4 = 76 e1 f1 g1\stopTempoSpan% Here, tempo 4 = 63 is reached and kept The print output probably matches the normal Text spanner, since one usually wouldn't want to print explicit tempi (at least, this is how I've handled such things so far, as well as some prints I've seen); but the semantics clearly are different. Especially, MIDI output could gradually increase or decrease the speed without further manual adjustment. That would definitely be a nice-to-have... Uh, yeah, and I second the break-align-interface wish there... Cheers Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: horizontal spacing issue
Mark Polesky wrote: Hey all, not sure if this is really a bug. [...] Regardless, the docs imply that changing paper-width changes line-width, and it just doesn't seem so. I don't know enough to know if this is a bug, but I'm happy to report my confusion to someone that might. I guess this is intended. The notion line-width defaults to paper-width - 20 mm AFAIK just means that's the default value for all default-paper-sizes. But, if anyone looks into this code, I come up with another suggestion: Would it be an easy thing to implement a two-page layout (as LaTeX allows for larger document types)? This means, we could set left-margin for odd and even page numbers seperately. Or is there already some scheme hack that does this? Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Enhancement request: alternative segno symbol
Dear developers, as remarked on the user list and seconded by Werner, I propose a new symbol for dal segno, as shown in the attached pictures, which is not in the current feta font. It looks similar to a section symbol (§) with one additional curl, and may be useful since it's printed across the staff and, thus, does not collide with simultaneous rehearsal marks (see the picture). This clearly is not an urgent matter, but if the font guy(s?) have spare time and nothing else to do... The picture is taken from Bosworth Co.: Lobt den Herrn der Welt (Willy Trapp / Henry Purcell: Trumpet Voluntary); if someone cares, I can provide a higher resolution scan of the symbol. Cheers Alexander inline: 01.pnginline: 02.png___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
