lilypond-book bug?
I'm using version 2.3.16. I was used to the following giving me two
fragments side by side with a small space between them. With this, it
seems that the second has been printed on top of the first.
%\version "2.3.16"
\documentclass[11pt,letterpaper]{article}
\usepackage[latin1] {inputenc}
\setlength{\oddsidemargin}{1.0in}
\setlength{\textwidth}{6.5in}
\setlength{\parindent}{0.0in}
\setlength{\topmargin}{0.0in}
\setlength{\headheight}{0.0in}
\setlength{\headsep}{0.0in}
\setlength{\topskip}{0.0in}
\setlength{\textheight}{9.0in}
\pagestyle{empty}
\begin{document}
\begin[raggedright]{lilypond}
\relative c''' { a4 \bar "||" }
\end{lilypond}
\begin[raggedright]{lilypond}
\relative c''' { a4 \bar "||" }
\end{lilypond}
\end{document}
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[minor bug] Weird tail in Metronome docs
There's a weird tail on the dotted quarter note in the metronome marks page: http://www.lilypond.org/doc/v2.3/Documentation/user/out-www/lilypond/ Metronome-marks.html I can't reproduce this when I execute lilypond on the example manually. - Graham ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0 -- gnome backend
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes: > Han-Wen Nienhuys writes: > >> I recall that it wasn't so long ago that not all distributions shipped >> with fontconfig, which is instrumental in getting fonts from >> ~/.fonts/ configured correctly. > > That's it! xset/xlsfonts has nothing todo with gnome/pango fonts. It > seems gnome-font-install doesn't either. > > It's the fontconfig package; lilypond fonts should show up in fc-list. > > My fontconfig documentation says it looks in /usr/share/fonts and > ~/.fonts. To have fontconfig look in other directories, make a > > ~/.fonts.conf: > > > > ~/cvs/savannah/lilypond/lilypond/mf/out > > (without the closing tag) $ cat ~/.fonts.conf ~/cvs/lilypond/mf/out $ fc-cache -f $ fc-list | grep -i lilypond LilyPond\-feta\-din:style=Regular LilyPond\-feta\-braces\-a:style=Regular LilyPond\-feta\-braces\-c:style=Regular LilyPond\-feta\-braces\-b:style=Regular LilyPond\-feta\-braces\-e:style=Regular LilyPond\-feta\-braces\-d:style=Regular LilyPond\-feta\-braces\-g:style=Regular LilyPond\-feta\-braces\-f:style=Regular LilyPond\-feta\-braces\-i:style=Regular LilyPond\-feta\-braces\-h:style=Regular LilyPond\-feta\-nummer:style=Regular LilyPond\-parmesan:style=Regular LilyPond\-feta:style=Regular but still no feta glyphs displayed when invoking lilypond -fgnome. I'll try with defoma. nicolas ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: still a cue problem
[EMAIL PROTECTED] writes:
>
> > The shift of the rest is not due to the empty group but because
> > of the \voiceOne and \voiceTwo that are applied to the first and
> > second voice of the << {...} \\ {...} >> construct.
> > Among others, the \voiceOne macro does
> > \override MultiMeasureRest #'staff-position = #4
>
> Thanks for the explanation.
>
> > So, it's not only a matter of ignoring the empty group, it's also a
> > matter of applying different property settings to another Voice.
> > However, if you are happy with the default centered rest position
> > also in the parts with cue notes, then you could do
> > << {\revert MultiMeasureRest #'staff-position R1 } \\
> > {possible cue notes }>>
>
> Unfortunately, this is not acceptable. I still wonder whether it is
> possible to make
>
> << { ... } \\ { } >>
>
> equivalent to
>
> { ... }
>
> this is, to prevent creation of \voiceOne and \voiceTwo at all. I can
> imagine that this is handled as a special exception to the normal
> parsing rules -- the assumption is of course that an empty group
> within << >> isn't used for other purposes.
No, this is a broken solution. The proper solution would be to
make a \quoteDuring music function
\quoteDuring #"trp" { ..music.. }
which is expanded to << \quote \\ ..music.. > or { music }
by means of a music function. This function would work similar to the
expansion of \\ .
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Jazz articulations in version 2.2
On Thu, 23 Sep 2004 13:00:19 +0200
Mats Bengtsson <[EMAIL PROTECTED]> wrote:
> Developers/hackers, here's something to improve on. The best
> alternative is to add support for these jazz articulations
> in the font and in some appropriate engraver.
> A quicker fix (?) might be to translate my hacky solution into
> a Scheme function that can be applied on the note.
>
> I used a trick, namely to fool Lilypond into drawing the postscript
> code as a replacement for an ordinary dot of a dotted note.
> Of course, it doesn't work of you want a fall or raise on a note
> that's dotted from the beginning.
>
> Anyway, this is hopefully better than nothing and it avoids the
> extra-offset settings that most others have used when trying to
> place some arbitrary object close to a note. Also, it should
> reserve the necessary horizontal space. It should be possible to
> override horizontally placed fingering instructions instead of
> dots to get a solution that works with dotted notes as well.
>
> I don't know what the bend is supposed to look like, but it's
> probably easy to do a similar macro for that as well.
Would it be possible, and of any help, if I sent you a scanned image of
a piece of music that has these articulations?
--
chip
> \version "2.2.0"
>
>
> makefall = {
>\once \override Dots #'print-function = #Text_item::print
>\once \override Dots #'X-extent = #'(-.5 . 2)
>\once \override Dots #'text = #"\\embeddedps{0.2 setlinewidth -0.2
> -0.2 moveto 0.5 -0.2 1.2 -1 1.2 -2 rcurveto stroke}"
> }
>
> makeraise = {
>\once \override Staff.DotColumn #'direction = #left
> \once \override Dots #'print-function = #Text_item::print
>\once \override Dots #'X-extent = #'(-2 . 0.5)
> % \once \override Dots #'extra-offset = #'(-.5 . 0)
>\once \override Dots #'text = #"\\embeddedps{0.2 setlinewidth 0.2
> -0.2 moveto 0 -1 -0.7 -1.8 -1.2 -2 rcurveto stroke}"
> }
>
> makefallz = {
>\once \override Dots #'print-function = #Text_item::print
>\once \override Dots #'X-extent = #'(-.5 . 2)
>\once \override Dots #'text = #"\\embeddedps{0.1 setlinewidth -0.4
> -0.2 moveto 1 1 5 { 0.7 0.1
> rlineto -0.5 -0.5 rlineto } for stroke}"
> }
>
> makeraisez = {
>\once \override Staff.DotColumn #'direction = #left
>\once \override Dots #'print-function = #Text_item::print
>\once \override Dots #'X-extent = #'(-2 . 0.5)
> % \once \override Dots #'extra-offset = #'(-.5 . 0)
>\once \override Dots #'text = #"\\embeddedps{0.1 setlinewidth 0.4
> -0.2 moveto 1 1 5 { -0.7 0.1 rlineto 0.5 -0.5 rlineto } for stroke}"
> }
>
>
> \score {
>\notes \relative c'' {
> a4 \makeraise a4.*2/3 \makefall a4.*2/3 a4
> a4 \makeraisez a4.*2/3 \makefallz a4.*2/3 a4
>}
>\paper { raggedright = ##t}
> }
>
>
> /Mats
>
> [EMAIL PROTECTED] wrote:
> > On Wed, 22 Sep 2004 10:40:23 +0200
> > Mats Bengtsson <[EMAIL PROTECTED]> wrote:
> >
> >
> >>The scriptHorizontal property has been removed in version 2.2, i.e.
> >>there is no support for typesetting an arbitrary script to the
> >>left or right of a note head. Instead, there is now special support
> >>for doing this for fingerings.
> >>
> >>/Mats
> >
> >
> > Okay, that's fine. But how do I work around this? There's got to be
> > a way to create the articulations.
> >
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>>On Tue, 21 Sep 2004 16:25:32 +0200
> >>>Mats Bengtsson <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>
> The current syntax for changing object properties is described at
> http://lilypond.org/doc/v2.2/Documentation/user/out-www/lilypond/
> >La>>
> >>>yout-tunings-within-contexts.html#Layout%20tunings%20within%20cont
> >ex>>ts>
> >>>
> However, the syntax examples you show have never been correct and
> even though it has been modified by convert-ly, the original at
> the end of this email cannot possibly have worked in any LilyPond
> version I can think of. If you go back to
> http://lists.gnu.org/archive/html/lilypond-user/2002-10/msg00130.
> >ht>>
> >>>ml>and run convert-ly on that code, you should get the correct
> >>>syntax.>
> >>>
> /Mats
> >
> >
> > You refer to a list message and mention it will work after running
> > convert-ly, but it doesn't, and in todays reply say it can't be
> > done. I realize this application is written for the person scoring
> > classical music, but there are a lot of people using it for more
> > modern music as well. There's got to be a way to add modern
> > articulations with writing entire sections of new code in every
> > piece we transcribe/write. That just doesn't make sense.
> >
> > How hard could it be to just add the articulations to the feta font?
> > Seems that would be most logical thing to do.
> >
> > Regards,
> > Chip
> >
> >
> >
> >>>Once again, thanks. I have almost a working test document. The
> >>>desired articulations appear on the printed page but not in the
> >>>correct positions. I can probably fix that by tweaking the n
Re: failed assertion in 2.3.18
Russ Ross writes: > I just compiled 2.3.18 on a Debian system and got this error: > > lilypond: ../flower/include/array.hh:149: T& Array::elem_ref(int) > const [with T = void*]: Assertion `i >=0&&i I got a similar error on 2.2.2 and 2.2.5 under Cygwin. I was working > with a rather large source file, so I started removing parts and > deleting measures until I came up with the smallest example that still > crashed it; That is nice, and it helped me a lot in adding the new feature, but if you get a crash, sending the whole .ly is OK. Usually, creating a small test case is waste of time. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lyrics problems: Bar_engraver, à (SS) , ü, hyphens
> > Finally, hyphens within words are not always displaying properly.
> > Where before they would be centered between two syllables, now they
> > sometimes stick to the second syllable.
>
> I don't think I have seen this problem. Could you find an example?
Certainly; here's a snippet from a recitative that shows the problem:
\version "2.3.18"
altoNotes = \relative c'' {
a8 d, c' b b b r fis |
dis dis dis e fis r r b, |
}
altoLyrics = \lyricmode {
J\"un -- ger t\"o -- richt strei -- ten, daß
die -- ses from -- me Weib mit
}
\score {
\simultaneous {
\context Staff = altoStaff
\context Voice = altoVoice {
\autoBeamOff
\clef treble
\key b \minor
\altoNotes
}
\lyricsto altoVoice \new Lyrics \altoLyrics
}
\paper {}
}
In this example "Jün -- ger" and "tö -- richt" both show the problem,
rendering as something like "Jün -ger" and "tö -richt" respectively.
If you comment out the second measure, the problem is corrected: as
the first measure expands the hyphens move to the center.
By coincidence, the example also happens to include both a 'ß' and two
'ü's that render incorrectly, which you indicated was a known issue
with character encodings.
Thanks,
Russ
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lyrics problems: Bar_engraver, à (SS), ü, hyphens
Russ Ross wrote: I've just compiled Lilypond 2.3.18 and noticed a couple of differences in lyrics output: Before (in 2.2.x) I'd put this in my \paper section to prevent lyrics overlapping bar lines: \context \LyricsContext \consists "Bar_engraver" convert-ly changes \LyricsContext to \Lyrics but this no longer seems to work. I now have lyrics overlapping bar lines in numerous old scores. This bug is easily confirmed at http://lilypond.org/doc/v2.3/input/regression/out-www/collated-files.html#lyrics-bar.ly The second things I noticed was with the German ß character which now seems to be rendered SS. Not sure if this is a problem with my setup, or a bug that has been introduced to Lilypond. I'm including ß directly, not using some variation of the TeX/LaTeX \SS. \"u used to give a ü character, but now it seems to give a u with a hyphen (or something) overlapping it. Has the syntax for these changed, or do I have something wrong in my setup? It's a known bug in 2.3.18 that the font encoding isn't handled correctly. Finally, hyphens within words are not always displaying properly. Where before they would be centered between two syllables, now they sometimes stick to the second syllable. I don't think I have seen this problem. Could you find an example? /Mats ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
lyrics problems: Bar_engraver, à (SS), ü, hyphens
I've just compiled Lilypond 2.3.18 and noticed a couple of differences in lyrics output: Before (in 2.2.x) I'd put this in my \paper section to prevent lyrics overlapping bar lines: \context \LyricsContext \consists "Bar_engraver" convert-ly changes \LyricsContext to \Lyrics but this no longer seems to work. I now have lyrics overlapping bar lines in numerous old scores. The second things I noticed was with the German ß character which now seems to be rendered SS. Not sure if this is a problem with my setup, or a bug that has been introduced to Lilypond. I'm including ß directly, not using some variation of the TeX/LaTeX \SS. \"u used to give a ü character, but now it seems to give a u with a hyphen (or something) overlapping it. Has the syntax for these changed, or do I have something wrong in my setup? Finally, hyphens within words are not always displaying properly. Where before they would be centered between two syllables, now they sometimes stick to the second syllable. These seem to happen generally in my old scores, but if you'd like a specific example of any of these issues I'd be happy to pick out a sample. Thanks, Russ ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
failed assertion in 2.3.18
I just compiled 2.3.18 on a Debian system and got this error: lilypond: ../flower/include/array.hh:149: T& Array::elem_ref(int) const [with T = void*]: Assertion `i >=0&&ihttp://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: still a cue problem
> The shift of the rest is not due to the empty group but because
> of the \voiceOne and \voiceTwo that are applied to the first and
> second voice of the << {...} \\ {...} >> construct.
> Among others, the \voiceOne macro does
> \override MultiMeasureRest #'staff-position = #4
Thanks for the explanation.
> So, it's not only a matter of ignoring the empty group, it's also a
> matter of applying different property settings to another Voice.
> However, if you are happy with the default centered rest position
> also in the parts with cue notes, then you could do
> << {\revert MultiMeasureRest #'staff-position R1 } \\
> {possible cue notes }>>
Unfortunately, this is not acceptable. I still wonder whether it is
possible to make
<< { ... } \\ { } >>
equivalent to
{ ... }
this is, to prevent creation of \voiceOne and \voiceTwo at all. I can
imagine that this is handled as a special exception to the normal
parsing rules -- the assumption is of course that an empty group
within << >> isn't used for other purposes.
On the other hand, making an empty \quote expand to a special Grob
which simply resets the vertical rest positions of the other voice(s)
to the default is probably better from a syntactical point of view.
Werner
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Jazz articulations in version 2.2
Developers/hackers, here's something to improve on. The best
alternative is to add support for these jazz articulations
in the font and in some appropriate engraver.
A quicker fix (?) might be to translate my hacky solution into
a Scheme function that can be applied on the note.
I used a trick, namely to fool Lilypond into drawing the postscript
code as a replacement for an ordinary dot of a dotted note.
Of course, it doesn't work of you want a fall or raise on a note
that's dotted from the beginning.
Anyway, this is hopefully better than nothing and it avoids the
extra-offset settings that most others have used when trying to
place some arbitrary object close to a note. Also, it should
reserve the necessary horizontal space. It should be possible to
override horizontally placed fingering instructions instead of
dots to get a solution that works with dotted notes as well.
I don't know what the bend is supposed to look like, but it's
probably easy to do a similar macro for that as well.
\version "2.2.0"
makefall = {
\once \override Dots #'print-function = #Text_item::print
\once \override Dots #'X-extent = #'(-.5 . 2)
\once \override Dots #'text = #"\\embeddedps{0.2 setlinewidth -0.2
-0.2 moveto 0.5 -0.2 1.2 -1 1.2 -2 rcurveto stroke}"
}
makeraise = {
\once \override Staff.DotColumn #'direction = #left
\once \override Dots #'print-function = #Text_item::print
\once \override Dots #'X-extent = #'(-2 . 0.5)
% \once \override Dots #'extra-offset = #'(-.5 . 0)
\once \override Dots #'text = #"\\embeddedps{0.2 setlinewidth 0.2
-0.2 moveto 0 -1 -0.7 -1.8 -1.2 -2 rcurveto stroke}"
}
makefallz = {
\once \override Dots #'print-function = #Text_item::print
\once \override Dots #'X-extent = #'(-.5 . 2)
\once \override Dots #'text = #"\\embeddedps{0.1 setlinewidth -0.4
-0.2 moveto 1 1 5 { 0.7 0.1
rlineto -0.5 -0.5 rlineto } for stroke}"
}
makeraisez = {
\once \override Staff.DotColumn #'direction = #left
\once \override Dots #'print-function = #Text_item::print
\once \override Dots #'X-extent = #'(-2 . 0.5)
% \once \override Dots #'extra-offset = #'(-.5 . 0)
\once \override Dots #'text = #"\\embeddedps{0.1 setlinewidth 0.4
-0.2 moveto 1 1 5 { -0.7 0.1 rlineto 0.5 -0.5 rlineto } for stroke}"
}
\score {
\notes \relative c'' {
a4 \makeraise a4.*2/3 \makefall a4.*2/3 a4
a4 \makeraisez a4.*2/3 \makefallz a4.*2/3 a4
}
\paper { raggedright = ##t}
}
/Mats
[EMAIL PROTECTED] wrote:
On Wed, 22 Sep 2004 10:40:23 +0200
Mats Bengtsson <[EMAIL PROTECTED]> wrote:
The scriptHorizontal property has been removed in version 2.2, i.e.
there is no support for typesetting an arbitrary script to the
left or right of a note head. Instead, there is now special support
for doing this for fingerings.
/Mats
Okay, that's fine. But how do I work around this? There's got to be a
way to create the articulations.
[EMAIL PROTECTED] wrote:
On Tue, 21 Sep 2004 16:25:32 +0200
Mats Bengtsson <[EMAIL PROTECTED]> wrote:
The current syntax for changing object properties is described at
http://lilypond.org/doc/v2.2/Documentation/user/out-www/lilypond/La
yout-tunings-within-contexts.html#Layout%20tunings%20within%20contex
ts>
However, the syntax examples you show have never been correct and
even though it has been modified by convert-ly, the original at
the end of this email cannot possibly have worked in any LilyPond
version I can think of. If you go back to
http://lists.gnu.org/archive/html/lilypond-user/2002-10/msg00130.ht
ml>and run convert-ly on that code, you should get the correct
syntax.>
/Mats
You refer to a list message and mention it will work after running
convert-ly, but it doesn't, and in todays reply say it can't be done.
I realize this application is written for the person scoring classical
music, but there are a lot of people using it for more modern music as
well. There's got to be a way to add modern articulations with writing
entire sections of new code in every piece we transcribe/write. That
just doesn't make sense.
How hard could it be to just add the articulations to the feta font?
Seems that would be most logical thing to do.
Regards,
Chip
Once again, thanks. I have almost a working test document. The
desired articulations appear on the printed page but not in the
correct positions. I can probably fix that by tweaking the numbers,
I just have to find the doc that explains what each number means.
Anyway, here is the results of running convert-ly and then running
the interpreter. There are several property-type errors...
thanks
Chip
convert-ly -e test.ly
convert-ly (GNU LilyPond) 2.2.2
Processing `test.ly' ... Applying conversions: 2.1.1, 2.1.2, 2.1.3,
2.1.4, 2.1.7, 2.1.10, 2.1.11, 2.1.12, 2.1.13, 2.1.14, 2.1.15,
2.1.16, 2.1.17, 2.1.18, 2.1.19, 2.1.20, 2.1.21, 2.1.22, 2.1.23,
2.1.24, 2.1.25, 2.1.26, 2.1.27, 2.1.28, 2.1.29, 2.1.30, 2.1.31,
2.1.33, 2.1.34, 2.1.36, 2.2.0,
Process convert-ly exited with code 0
lilypond test.ly
lilypond (GNU LilyPond) 2.2.2
Running lilypond-bin.
\version header in manual .ly snippets
Hi! The example templates in section 3 of the manual (Documentation/user/examples.itely) currently contain a '\version "2.3.16"' header. Shouldn't this header be automatically inserted when dissecting the .itely file? Greetings, Jürgen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: still a cue problem
The shift of the rest is not due to the empty group but because
of the \voiceOne and \voiceTwo that are applied to the first and
second voice of the << {...} \\ {...} >> construct.
Among others, the \voiceOne macro does
\override MultiMeasureRest #'staff-position = #4
So, it's not only a matter of ignoring the empty group, it's
also a matter of applying different property settings to another
Voice. However, if you are happy with the default centered rest
position also in the parts with cue notes, then you could do
<< {\revert MultiMeasureRest #'staff-position R1 } \\
{possible cue notes }>>
/Mats
Werner LEMBERG wrote:
I'm quite successfully using \quote, and in parts it works fine.
There is still a problem with full scores.
Assume that the file `trumpet.ily' is included both by `trumpet.ly'
(to create the trumpet part) and `score.ly' (to create the full
score). To produce a cue I have this code in trumpet.ily:
<< { R1 } \\
{ \small \quote "flute" 1 } >>
This works fine in trumpet.ly since the both the first and the second
block contains data. In `score.ly', only the upper block is used
because \quote intentionally expands to nothing by saying
\set Score.quotedEventTypes = #'()
at the top of `score.ly'. Consequently, the code is equivalent to
<< { R1 } \\
{} >>
As you can see, the second group is empty. Lilypond accepts that, but
it doesn't completely ignore the empty group: It shifts the whole rest
up. To get correctly positioned whole rests I currently have to do
this:
\tag #'score { R1 }
\tag #'trumpet << { R1 } \\
{ \small \quote "flute" 1 } >>
(and applying the tags accordingly), but this is really ugly IMHO and
a lot of additional work.
Is it possible to make lilypond really ignore an empty group, without
any side effects? Perhaps \quote can expand to an object which says
`Please ignore me completely'. Or am I missing something?
Werner
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
