Clef not printed when middleCPosition is changed
There is an example in the User Manual, section 1.1.3,
Displaying Pitches, subsection Clef which shows a bug. The
example is the one which shows the effect of changing the
three properties, clefGlyph, clefPosition and
middleCPosition. Changing middleCPosition does not cause a
new clef to be printed, although subsequent notes are
correctly shifted.
Here's an example which shows the bug in 2.10.20, and as the
manual for 2.11.32 also shows the incorrect behaviour I
guess it is still present in 2.11.
{
\clef treble
c'4
\set Staff.middleCPosition = #4
c'4
\set Staff.middleCPosition = #0
c'4
}
Trevor Daniels
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
FW: Clef not printed when middleCPosition is changed
From: Trevor Daniels [mailto:[EMAIL PROTECTED]
Sent: 08 October 2007 11:45
There is an example in the User Manual, section
1.1.3, Displaying Pitches, subsection Clef which
shows a bug. The example is the one which shows
the effect of changing the three properties,
clefGlyph, clefPosition and middleCPosition.
Changing middleCPosition does not cause a new
clef to be printed, although subsequent notes are
correctly shifted.
Here's an example which shows the bug in 2.10.20,
and as the manual for 2.11.32 also shows the
incorrect behaviour I guess it is still present in 2.11.
{
\clef treble
c'4
\set Staff.middleCPosition = #4
c'4
\set Staff.middleCPosition = #0
c'4
}
Apologies. I now see that this behaviour is correct - the
error is in the description in the manual. I shall rewite
this section to correctly reflect what the code actually
does.
Trevor Daniels
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Bug in beatLength processing in 12/16 time?
The recent note to -user from Matt Huber (24 Nov 07 20:27)
suggests there is a bug with the automatic beaming of 16th
notes in 12/16 time when beamLength is set to 2 or 3.
Here's a minimal example:
{
\time 12/16
\set Score.beatLength = #(ly:make-moment 1 16 ) % Correct
b16 b b b b b b b b b b b
\set Score.beatLength = #(ly:make-moment 2 16 ) % Wrong
b16 b b b b b b b b b b b
\set Score.beatLength = #(ly:make-moment 3 16 ) % Wrong
b16 b b b b b b b b b b b
\set Score.beatLength = #(ly:make-moment 4 16 ) % Correct
b16 b b b b b b b b b b b
% All higher beatLengths give correct beaming
}
Maybe I missed something in auto-beam.scm, but I can see
nothing there which affects the beaming of 1/16th notes in
12/16 time. Same fault in other time signatures too - I
tried 11/16 and 13/16 with same results.
Trevor Daniels
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Accidentals in ambitus collide
Two close accidentals in an ambitus collide.
\new Voice \with {
\consists Ambitus_engraver
}
\relative c'' {
aes4 cis
}
Also, I can find no override which separates them.
Trevor D
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Why can't I get a barline at the end of this
Paul Scott wrote on 09 December 2007 06:25
Trevor Daniels wrote:
This is the difference, taken from the new GDP
NR manual:
In addition, you can specify ||:, which is
equivalent to
|: except at line breaks, where it gives a
double bar line
at the end of the line and a start repeat at
the beginning
of the next line.
Subject: Re: Why can't I get a barline at the
end of this
unfortunatly I'am not and I do not understand
the difference
between ||: and |:
why does ||: exist and :|| not? seems
unlogical to me...
The second question is not answered and should be
considered something
like a bug.
The following leads to no bar line at the end of
the repeated section
since :|| is apparently undefined:
{ a'1 \repeat volta 2 { g'1 } \break \bar :|| f'1 g'1 }
It's not really a bug, as replacing :|| with :| will
do what you want. The LilyPond syntax defines |: ,
:|: and :| as the notation for manually inserting
repeat-related barlines. Then, because a start repeat
barline might need special processing if it occurs at the
end of a line, a special form of the notation is provided
to invoke this optional special processing - ||:. No
special processing is required for an end repeat barline,
so :|| is not required. You might argue that there
should be two forms of the syntax for the end-repeat
barline, which behave identically, but the lack of that
feature is hardly a bug.
Paul Scott
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
BarNumber outside-staff-priority not honoured?
The outside-staff-priority of BarNumber is set by default to
100, the lowest of all outside-staff objects, yet it appears
in 2.1.34 to be placed further from the staff than
DynamicText (250), DynamicLineSpanner (250), and
OttavaBracket(400). Here is an illustration of an extreme
situation, followed by a minimal example with DynamicText
alone.
% Illustrative example
\version 2.11.34
\relative c' {
\override Score.BarNumber #'break-visibility = ##(#t #t #t)
\override TextSpanner #'bound-details #'left #'text
= \markup { \small \bold Slower }
\dynamicUp
#(set-octavation 1)
c \startTextSpan c\pp c\ \tempo 4 = 72
c^Text \mark \default |
c c c\ff c \stopTextSpan \mark \default |
#(set-octavation 0)
c c c c
}
% Minimal example
\version 2.11.34
\relative c' {
\override Score.BarNumber #'break-visibility = ##(#t #t #t)
\dynamicUp
c c c c |
c\ c c c |
}
Trevor D
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: BarNumber outside-staff-priority not honoured?
Thanks for the explanation, Joe. I'll add this to the section I'm writing in the Learning Manual that deals with placing outside-staff objects. Trevor D -Original Message- From: Joe Neeman [mailto:[EMAIL PROTECTED] Sent: 18 December 2007 22:22 To: [EMAIL PROTECTED] Cc: bug-lilypond Subject: Re: BarNumber outside-staff-priority not honoured? On 12/19/07, Trevor Daniels [EMAIL PROTECTED] wrote: The outside-staff-priority of BarNumber is set by default to 100, the lowest of all outside-staff objects, yet it appears in 2.1.34 to be placed further from the staff than DynamicText (250), DynamicLineSpanner (250), and OttavaBracket(400). This is because BarNumber is placed at the score level while the other marks are placed at the staff level. You can change this by moving the bar number engraver to the topmost staff context of the score. Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Ambitus incorrect upper note
A bug in the ambitus engraver seems to have crept in between
2.11.34 and 2.11.36. The example in section 3.3.5 of the
Learning Manual at
http://kainhofer.com/~lilypond/Documentation/user/lilypond-l
earning/Adding-and-removing-engravers.html#Adding-and-removi
ng-engravers which was compiled with 2.1.36 is incorrect -
the top note should be a C, not a B. The same example
compiled in 2.11.34 is correct. Here's a minimal example:
\new Staff
\new Voice \with {
\consists Ambitus_engraver
}
\relative c'' {
\voiceOne
c a b g
}
Trevor D
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Incorrect note merging
Hi Valentin
Here's your first bug:
\version 2.11.34
% These two notes are different and should not be merged
{aes'8} \\ {a'}
{aes'8} \\ {a'?}
Trevor D
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: set associatedVoice and disappearing lyrics
Date: Sat, 26 Jan 2008 12:13:38 + (UTC)
From: Matti Aaltonen [EMAIL PROTECTED]
Subject: set associatedVoice and disappearing lyrics
To: bug-lilypond@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
I'm not top posting.
Hello.
This is my second try sending this. Thanks for
the advice Graham.
Anyway, I've tried the following and after I try
to associate the lyrics of the
second verse back to the original melody line the
text disappears:
I've been using Lilypond v. 2.11.37.
\paper{ ragged-right=##t }
\new Voice = melody {
\time 2/4
e4 e
\new Voice = alternate
{\stemDown a a }
{\stemUp d'2. }
\stemNeutral |
g4 g
}
\new Lyrics \lyricsto melody \lyricmode {
play the game
yes yes
}
\new Lyrics \lyricsto melody \lyricmode {
do not
\set associatedVoice = #alternate
play it
\set associatedVoice = #melody
no no
}
Cheers thanks,
Matti
This is not a bug, although it is an unattractive
feature of LilyPond. The \set associatedVoice
command must be placed one syllable before it
should take effect. That is, it should be placed
before it in this example. It then works
correctly.
This feature is documented in the manual.
Trevor D
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: pedal position
Stefan Thomas wrote on 28 January 2008 23:22
Dear Lilypond-users,
in the below quoted snippet I'm not happy with
the vertical priority of
the pedal-symbols and theDynamic.
I would like to have the pp , the crescendo
hairpin etc. above the
pedal-signs. But I dont know ho to do.
\once \override DynamicLineSpanner
#'outside-staff-priority = #1
doesn't work. What can I do?
Here is the short example:
\relative c''' {
\once \override DynamicLineSpanner
#'outside-staff-priority = #1
c2~\pp\sustainDown \times 2/3 {c4 b bes} |
aes8\ f \times 2/3 {d8-. bes8-.
ges8-.\p\sustainUp } r2 | }
Normally you would resolve this by setting the
outside-staff-priority for both objects, but it
seems the placement algorithm does not honour the
outside-staff-priority of the objects related to
piano pedals. If, outside-staff-priority is
set for SustainPedal, for example, DynamicText
moves closer to the staff, but the SustainPedal
does not move, causing the objects to crash.
Here's a minimal example, copied to -bug.
\relative c''' {
c2\pp\sustainDown
\override Voice.DynamicText #'outside-staff-priority = #1
\override Staff.SustainPedal #'outside-staff-priority =
#1000
c2\pp\sustainDown
}
Is this a bug or a feature to be documented?
Thanks for any advice,
Stefan
Trevor D
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Hairpin and Textscript
Thanks Mats. Actually the bug is in the manual :( The ottava spanner is created in the Staff context, but I omitted to specify the context in the \override in the example. \once \override Staff.OttavaBracket #'outside-staff-priority = #340 works fine (at least in 2.11.34) Trevor D -Original Message- From: Mats Bengtsson [mailto:[EMAIL PROTECTED] Sent: 05 February 2008 11:31 To: [EMAIL PROTECTED]; Lilypond bug Cc: [EMAIL PROTECTED] Subject: Re: Hairpin and Textscript Trevor Daniels wrote: ... http://kainhofer.com/~lilypond/Documentation/user/ lilypond-learning/index.html which shows a bug! The ottava bracket isn't moved no matter what value you specify, at least when I try with the latest 2.11.38 code from GIT. Unfortunately, this means that the example in the manual doesn't show what it's supposed to show, until this bug is fixed (if the bug fix takes long, the example can easily be modified to move the dynamics instead, which works as it should). /Mats ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Slow compile on Windows XP - font caching problem?
Yes, definitely a regression. I've gone back to using 2.11.34 which does not suffer this bug, as most of my documentation work is fiddling with tiny snippets, and a 1 minute delay every time I make a change makes it impossible to work. Trevor -Original Message- From: Mats Bengtsson [mailto:[EMAIL PROTECTED] Sent: 11 March 2008 10:29 To: Valentin Villenave Cc: [EMAIL PROTECTED]; Bug-Lilypond Subject: Re: Slow compile on Windows XP - font caching problem? Valentin Villenave wrote: 2008/3/10, Trevor Daniels [EMAIL PROTECTED]: Under 2.11.42 the fonts are cached in C:\Documents and Settings\[username]\.lilypond-fonts.cache-2. This also contains 2 small and one large (682 KB) files, but when LilyPond compiles it changes just the large file - every time. This is pretty certainly where the extra time is going, as the time stamp on this file updates around 45 secs after starting the compile. This may well be the same as the Vista slowness problem which was also related to font caching. Yes, I encountered the same problem on XP; it seems to re-calculate the font cache on every compilation, and therefore takes ages to compile anything. However, I didn't report it since I assumed I was doing something wrong. If this problem has appeared also on XP, then it's a regression bug. /Mats ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Slow compile on Windows XP - font caching problem?
Problem seen in 2.11.41 and 42, not in 2.11.34. I didn't install or download any intervening development releases. I'd be happy to try them, but how do I get the binaries for Windows? Trevor D -Original Message- From: Han-Wen Nienhuys [mailto:[EMAIL PROTECTED] Sent: 13 March 2008 01:36 To: Valentin Villenave Cc: [EMAIL PROTECTED]; Bug-Lilypond Subject: Re: Slow compile on Windows XP - font caching problem? this type of stuff is tricky. The last time we saw this, it was - dirs.push_back (lilypond_datadir + /fonts/otf/); - dirs.push_back (lilypond_datadir + /fonts/type1/); + /* Extra trailing slash suddenly breaks fontconfig (fc-cache 2.5.0) + on windows. */ + dirs.push_back (lilypond_datadir + /fonts/otf); + dirs.push_back (lilypond_datadir + /fonts/type1); can someone please post the exact version number where you've started seeing this? 2008/3/11, Valentin Villenave [EMAIL PROTECTED]: 2008/3/11, Trevor Daniels [EMAIL PROTECTED]: Yes, definitely a regression. I've gone back to using 2.11.34 which does not suffer this bug, as most of my documentation work is fiddling with tiny snippets, and a 1 minute delay every time I make a change makes it impossible to work. OK. That's it. I've opened a new issue: http://code.google.com/p/lilypond/issues/detail?id=588 Trevor: perhaps you should try the workaround described on http://code.google.com/p/lilypond/issues/detail?id=545#c1 Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Slow compile on Windows XP - font caching problem?
Thanks Graham :( OK - here are the results: 2.11.34-1 Compiles in 15 secs Uses .fontconfig directory 2.11.35-1 Fails with libguile2-17.dll not found Copied this in, then Fails with error about ice-9/boot-9.scm not in load path 2.11.35-2 Compiles in 15 secs, but Lots of error messages like Pango CRITICAL FT_Get_Glyph_Name() error invalid argument Glyph has no name Skipping Glyph U+ ... Century-Schl-Roma.otf Uses .fontconfig directory 2.11.36-1, 37-1, 41-1, 42-1 All compile slowly - 65 secs All use .lilypond-fonts directory Trevor D -Original Message- From: Graham Percival [mailto:[EMAIL PROTECTED] Sent: 13 March 2008 08:26 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Valentin Villenave; Bug-Lilypond Subject: Re: Slow compile on Windows XP - font caching problem? You're going to kick yourself over this: http://lilypond.org/download/binaries/ Cheers, - Graham On Thu, 13 Mar 2008 08:04:06 - Trevor Daniels [EMAIL PROTECTED] wrote: Problem seen in 2.11.41 and 42, not in 2.11.34. I didn't install or download any intervening development releases. I'd be happy to try them, but how do I get the binaries for Windows? Trevor D -Original Message- From: Han-Wen Nienhuys [mailto:[EMAIL PROTECTED] Sent: 13 March 2008 01:36 To: Valentin Villenave Cc: [EMAIL PROTECTED]; Bug-Lilypond Subject: Re: Slow compile on Windows XP - font caching problem? this type of stuff is tricky. The last time we saw this, it was - dirs.push_back (lilypond_datadir + /fonts/otf/); - dirs.push_back (lilypond_datadir + /fonts/type1/); + /* Extra trailing slash suddenly breaks fontconfig (fc-cache 2.5.0) + on windows. */ + dirs.push_back (lilypond_datadir + /fonts/otf); + dirs.push_back (lilypond_datadir + /fonts/type1); can someone please post the exact version number where you've started seeing this? 2008/3/11, Valentin Villenave [EMAIL PROTECTED]: 2008/3/11, Trevor Daniels [EMAIL PROTECTED]: Yes, definitely a regression. I've gone back to using 2.11.34 which does not suffer this bug, as most of my documentation work is fiddling with tiny snippets, and a 1 minute delay every time I make a change makes it impossible to work. OK. That's it. I've opened a new issue: http://code.google.com/p/lilypond/issues/detail?id=588 Trevor: perhaps you should try the workaround described on http://code.google.com/p/lilypond/issues/detail?id=545#c1 Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Slow compile on Windows XP - font caching problem?
Han-Wen, you wrote 17 March 2008 15:18 2008/3/13, Trevor Daniels [EMAIL PROTECTED]: OK - here are the results: 2.11.34-1 Compiles in 15 secs Uses .fontconfig directory 2.11.35-1 Fails with libguile2-17.dll not found Copied this in, then Fails with error about ice-9/boot-9.scm not in load path 2.11.35-2 Compiles in 15 secs, but Lots of error messages like Pango CRITICAL FT_Get_Glyph_Name() error invalid argument Glyph has no name Skipping Glyph U+ ... Century-Schl-Roma.otf Uses .fontconfig directory 2.11.36-1, 37-1, 41-1, 42-1 All compile slowly - 65 secs All use .lilypond-fonts directory Dang, this happened after a big refactoring of our build system. Is there anything interesting (eg. by way of diff -r) of /program files/lilypond/usr/etc/ directory between .34 and .36 ? Not really. A couple of minor changes in fonts/fonts.conf but nothing that seems significant. However, I noticed that usr/bin/libfontconfig-1.dll changed between 34-1 and 35-1, and again between 35-2 and 36.1, looking at the module size. Moving usr/bin/libfontconfig-1.dll from 34-1 into 42-1 seems to have no adverse effects on a couple of simple tests and fixes the long delay. Maybe this is a work-around for the problem? But maybe this introduces other errors. What should I use as a definitive test? An alternative is to build the cache, then delete or rename etc/fonts/font.config. This causes font-building to abort early with an error message, which also bypasses the timing problem. This also seems to have no adverse effect on a couple of simple tests, but I don't use any unusual fonts. Trevor D Han-Wen Nienhuys - [EMAIL PROTECTED] - Trevor D ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Slow compile on Windows XP - font caching problem?
Han-Wen Nienhuys wrote 18 March 2008 18:13 2008/3/18, Trevor Daniels [EMAIL PROTECTED]: Not really. A couple of minor changes in fonts/fonts.conf but nothing that seems significant. can you post the diff anyway? OK. Here's a diff -q first: Common subdirectories: LilyPond-2.11.36-1/usr/etc/fonts/conf.avail and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail Common subdirectories: LilyPond-2.11.36-1/usr/etc/fonts/conf.d and LilyPond-2.11.34-1/usr/etc/fonts/conf.d Files LilyPond-2.11.36-1/usr/etc/fonts/fonts.conf and LilyPond-2.11.34-1/usr/etc/fonts/fonts.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/fonts.dtd and LilyPond-2.11.34-1/usr/etc/fonts/fonts.dtd differ and here's a diff -q -r: Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/10-autohint.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/10-autohint.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/10-no-sub-pixel.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/10-no-sub-pixel.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/10-sub-pixel-bgr.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/10-sub-pixel-bgr.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/10-sub-pixel-rgb.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/10-sub-pixel-rgb.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/10-sub-pixel-vbgr.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/10-sub-pixel-vbgr.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/10-sub-pixel-vrgb.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/10-sub-pixel-vrgb.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/10-unhinted.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/10-unhinted.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/20-fix-globaladvance.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/20-fix-globaladvance.conf differ Only in LilyPond-2.11.34-1/usr/etc/fonts/conf.avail: 20-lohit-gujarati.conf Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/20-unhint-small-vera.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/20-unhint-small-vera.conf differ Only in LilyPond-2.11.36-1/usr/etc/fonts/conf.avail: 25-unhint-nonlatin.conf Only in LilyPond-2.11.34-1/usr/etc/fonts/conf.avail: 30-amt-aliases.conf Only in LilyPond-2.11.36-1/usr/etc/fonts/conf.avail: 30-metric-aliases.conf Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/30-urw-aliases.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/30-urw-aliases.conf differ Only in LilyPond-2.11.34-1/usr/etc/fonts/conf.avail: 40-generic.conf Only in LilyPond-2.11.36-1/usr/etc/fonts/conf.avail: 40-nonlatin.conf Only in LilyPond-2.11.36-1/usr/etc/fonts/conf.avail: 45-latin.conf Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/50-user.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/50-user.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/51-local.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/51-local.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/65-fonts-persian.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/65-fonts-persian.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/65-nonlatin.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/65-nonlatin.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/70-no-bitmaps.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/70-no-bitmaps.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/70-yes-bitmaps.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/70-yes-bitmaps.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.avail/80-delicious.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.avail/80-delicious.conf differ Only in LilyPond-2.11.34-1/usr/etc/fonts/conf.avail: README Files LilyPond-2.11.36-1/usr/etc/fonts/conf.d/20-fix-globaladvance.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.d/20-fix-globaladvance.conf differ Only in LilyPond-2.11.34-1/usr/etc/fonts/conf.d: 20-lohit-gujarati.conf Files LilyPond-2.11.36-1/usr/etc/fonts/conf.d/20-unhint-small-vera.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.d/20-unhint-small-vera.conf differ Only in LilyPond-2.11.34-1/usr/etc/fonts/conf.d: 30-amt-aliases.conf Only in LilyPond-2.11.36-1/usr/etc/fonts/conf.d: 30-metric-aliases.conf Files LilyPond-2.11.36-1/usr/etc/fonts/conf.d/30-urw-aliases.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.d/30-urw-aliases.conf differ Only in LilyPond-2.11.34-1/usr/etc/fonts/conf.d: 40-generic.conf Only in LilyPond-2.11.36-1/usr/etc/fonts/conf.d: 40-nonlatin.conf Only in LilyPond-2.11.36-1/usr/etc/fonts/conf.d: 45-latin.conf Files LilyPond-2.11.36-1/usr/etc/fonts/conf.d/50-user.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.d/50-user.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.d/51-local.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.d/51-local.conf differ Files LilyPond-2.11.36-1/usr/etc/fonts/conf.d/65-fonts-persian.conf and LilyPond-2.11.34-1/usr/etc/fonts/conf.d/65-fonts
RE: Tuplet brackets appear when I've asked them not to
-Original Message- From: Han-Wen Nienhuys [mailto:[EMAIL PROTECTED] Sent: 17 March 2008 15:10 To: [EMAIL PROTECTED] Cc: Graham Percival; [EMAIL PROTECTED]; bug-lilypond@gnu.org Subject: Re: Tuplet brackets appear when I've asked them not to 2008/3/10, Trevor Daniels [EMAIL PROTECTED]: It seems to need more than a doc change and an example. Investigating this code uncovers a program exception under XP, which I have just reported. Perhaps the docs should be changed to say that \acciaccatura should not be placed within \times brackets. The code works fine when the acciaccatura is moved outside, like this: I fixed the exception. It still doesn't work (you get a bunch of errors and no bracket.) I suggest to avoid this: what does it mean for a grace note to be inside a \times ? Grace notes inside tuplet brackets are fine except when the grace note is the first note in a staff. I've added this as a known issue in the Rhythm section of the NR. Han-Wen Nienhuys - [EMAIL PROTECTED] - Trevor D ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Slow compile on Windows XP - font caching problem?
I've now got my new laptop up and running, so at last I can check how LilyPond works under Vista. It works pretty well! :) Release 2.11.42-1 installed without problems and (apart from the very first run of around 50 secs) runs a trivial file in around 3 secs flat, including the conversion to pdf. So I don't see the slowness problem at all :) Well, it's good news for me, but not for diagnosing the problem others see. Some facts that might have a bearing: This was a clean install of Vista, not an upgrade. This was the very first LilyPond installation on this system. I had admin priviledges during the install, although removing them later has no effect on running LilyPond. The font cache was built in [user]/.lilypond-fonts.cache-2/ and contains the usual three files. BTW, the early message of mine about ice-9 not being in the load path on my XP system was a red herring - it was due to my path not being set correctly. Trevor D ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Slow compile on Windows XP - font caching problem?
Han-Wen Nienhuys, 21 March 2008 19:26 2008/3/21, Trevor Daniels [EMAIL PROTECTED]: Some facts that might have a bearing: This was a clean install of Vista, not an upgrade. This was the very first LilyPond installation on this system. I had admin priviledges during the install, although removing them later has no effect on running LilyPond. The font cache was built in [user]/.lilypond-fonts.cache-2/ and contains the usual three files. I just love microsoft operating systems But Vista is very pretty :) My best guess at this point is that this is some kind of permission problem. * Can you see what happens if you deinstall (as admin) and install (as admin) again? Not relevant to the immediate problem, but the de-install left three files behind: LilyPond/usr/bin/lily-pad-unicode.exe LilyPond/usr/share/lilypond/current/dvips/ps/lilyponddefs.ps LilyPond/usr/share/lilypond/current/dvips/ps/music-drawing-routines.ps as well as the three files in the font cache. I left these untouched and re-installed: The first run accessed just the two smaller files in the font cache, but still completed in less than 5 secs. Subsequent runs less than 3 secs on trivial files. * Can you see what happens if you deinstall (as admin) and install (without admin rights) again? Exactly the same - all short compile times. I de-installed again, this time deleting the font cache, and re-installed without admin rights. Now the first run takes c 1 min while it rebuilds the font cache, but subsequent runs are the usual 3 sec. The font cache was rebuilt in exactly the same place. Tried running as a different user, one without any priviledges and no admin rights. As expected, the first run took 50 secs to build the cache for this user - in [user]/.lilypond-fonts.cache-2 - but subsequent runs took the usual 3 secs. It seems my Vista runs LilyPond 2.11.42 perfectly. I can't make it run slowly. So we need to find a user with the problem to make any further progress. Perhaps worth mentioning - my OS is Vista Home Premium, fully patched up to today. Is it possible to find out the differences between the three versions of libfontconfig-1.dll? Might this may have been upgraded for Vista, since the later version fails on XP but works fine on Vista, as the above demonstrates? Han-Wen Nienhuys - [EMAIL PROTECTED] - Trevor D ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: no compile on version 2.11.43 for Windows XP
Date: Fri, 28 Mar 2008 01:20:41 -0300 From: Han-Wen Nienhuys [EMAIL PROTECTED] Subject: Re: no compile on version 2.11.43 for Windows XP To: Tom Richard [EMAIL PROTECTED] Cc: bug-lilypond@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 Can you try 2.11.43-2 (uploaded today)? Works fine on Vista Home Premium. (At least, the fault with 2.11.43-1 has gone and a few small snippets compiled correctly.) 2008/3/26, Tom Richard [EMAIL PROTECTED]: Version 2.10.33 for Windows XP compiles great. I have tried re-installing 2.11.43 3 times, carefully un-installing previous version every time. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen Trevor D ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Bug in whichBar?
There seems to be a bug in \set whichBar. Rather than setting the type of
barline to print at the end of the bars it prints a barline after every
following note. Surely this isn't correct? Here's a short example:
\version 2.11.44
\relative c' {
d d d d
\set Staff.whichBar = ||
e8 e e e
\unset Staff.whichBar
f f f f
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug in whichBar?
Of course! Timing (and bar lines) are handled in the Score context by
default. Setting Score.whichBar works fine. Thanks, Neil.
Trevor
- Original Message -
From: Neil Puttock [EMAIL PROTECTED]
To: Trevor Daniels [EMAIL PROTECTED]
Cc: Bug-Lilypond bug-lilypond@gnu.org
Sent: Tuesday, April 29, 2008 5:47 PM
Subject: Re: Bug in whichBar?
Hi Trevor,
2008/4/29 Trevor Daniels [EMAIL PROTECTED]:
There seems to be a bug in \set whichBar. Rather than setting the type
of
barline to print at the end of the bars it prints a barline after every
following note. Surely this isn't correct? Here's a short example:
\version 2.11.44
\relative c' {
d d d d
\set Staff.whichBar = ||
e8 e e e
\unset Staff.whichBar
f f f f
}
I think this needs the Timing alias to work properly:
\set Timing.whichBar = || works.
Regards,
Neil
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Multiple copies of LilyPond in Windows
Valentin Villenave wrote Actually, I was mainly referring to the installing/uninstalling process: on Windows, for instance, such a thing would be practically impossible (the installation takes ages, and the uninstall is even worse). I have been trying to use symlinks to have several different LilyPond installations and switch between them, but it remains quite painful -- especially since I am using both GUB shars (stable and unstable) and home-made compilations for my opera (because I need the accidental code from Rune's branch). For some time, I've even been using different user accounts, to have 2.10 in /home/stable/bin and 2.11 in /home/unstable/bin! It's quite easy to have several versions of LilyPond one account in Windows. All you need to do is rename the old LilyPond directory before installing the new version. To recover an old version for use then needs just two directory renames. Dead easy! I rename the old directories with the version number, like this: LilyPond 1.10.33-1, then I can easily select the version I want. At the moment I have five versions available. Renaming directories rather than uninstalling/reinstalling will lose any local additions, which are preserved by uninstall, so you may need to copy these over if you have any. Cheers, Valentin Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \tag can't follow \lyricsto
- Original Message -
Date: Mon, 14 Jul 2008 15:45:32 + (UTC)
From: Roman Stawski [EMAIL PROTECTED]
Subject: \tag can't follow \lyricsto
To: bug-lilypond@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
I'm not top posting.
The \tag command provokes a syntax error if it immediately follows a
\lyricsto
command. A work-around is to insert an empty expression {} between the
two.
\version 2.11.49
\paper{ ragged-right=##t }
\new Voice = dirge { c''1 }
\lyricsto dirge \new Lyrics { Whoops }
% {}% -- \tag provokes syntax error if this line is commented out
\tag #'harmony { a'1 }
The \tag command appears not to define a new Staff/Voice
implicitly, whereas {} does, so the command fails without
the {}. However, this seems a poor structure for an
input file, as it is quite unclear whether the tagged
line should generate a new staff, generate a new voice,
or be part of dirge. So, not really a bug, just a bad
input file.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \tag can't follow \lyricsto
Roman Stawski wrote
The \tag command provokes a syntax error if it immediately follows a
\lyricsto
command. A work-around is to insert an empty expression {} between the
two.
\version 2.11.49
\paper{ ragged-right=##t }
\new Voice = dirge { c''1 }
\lyricsto dirge \new Lyrics { Whoops }
% {}% -- \tag provokes syntax error if this line is commented out
\tag #'harmony { a'1 }
The \tag command appears not to define a new Staff/Voice
implicitly, whereas {} does, so the command fails without
the {}. However, this seems a poor structure for an
input file, as it is quite unclear whether the tagged
line should generate a new staff, generate a new voice,
or be part of dirge. So, not really a bug, just a bad
input file.
Trevor
I'm not sure that I understand your explanation. However, perhaps I
overpruned
my example. The following has explicit staves, yet it behaves exactly in
the
same way. I _think_ that in this case the input file is unambiguous.
---
\version 2.11.49
\paper{ ragged-right=##t }
\new Staff { \new Voice = dirge { c''1 } }
\lyricsto dirge \new Lyrics { Whoops }
% {}% -- \tag provokes syntax error if this line is commented out
\tag #'harmony \new Staff { a'1 }
---
Thanks for your answer. Let me know if I'm still off the track.
This discussion should really be on -user, so I'm copying
it there.
OK, I see what you are trying to do. The error is that
the order of the commands in the lyrics line is wrong,
and the \new Lyrics command should be followed by { .. }
just like \new Staff is. Then it works fine, like this:
\new Staff { \new Voice = dirge { c''1 } }
\new Lyrics { \lyricsto dirge { Whoops } }
\tag #'harmony \new Staff {a'1}
However, there is an easier way to include or exclude
the harmony, without using tags, like this:
harmony = { \new Staff {a'1} }
\new Staff { \new Voice = dirge { c''1 } }
\lyricsto dirge \new Lyrics { Whoops }
%\harmony %uncomment to include harmony
Tags are usually used for short sections of music.
You might find section 3.3.2 Different editions
from one source in the most recent version of the
2.11 docs worth a read - it was recently rewritten.
Roman
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tie control-points delete another tie
In fact what you call first voice and second voice
are both in the same Voice context. The tie
override affects both ties because they occur at the
same musical moment (assuming the tie in your second
voice is intended to be between the two notes
immediately following the override) and are in the
same context.
It's not clear what you are trying to achieve here,
as the ties without the override look ok.
Trevor
Message: 2
Date: Wed, 23 Jul 2008 14:48:34 + (UTC)
From: Marco Caliari [EMAIL PROTECTED]
Subject: Tie control-points delete another tie
To: bug-lilypond@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
I'm not top posting.
Dear all,
in the following snippet
\version 2.11.52
\paper{ ragged-right=##t }
\new Staff {
% first voice
{d''2 ~ d''
d''2 ~ d''}
% second voice in parallel
{f'2 f'
\once\override Tie #'control-points =
#'((1.5 . -0.5) (2 . 1) (7 . 2) (8 . -1))
f'2 f'}\\
% third voice
{c'2 c'
c'2 c'}
}
the \override command in the second voice deletes the tie in the first
voice
(the tie in the second voice is terrible, but it does not matter).
Best regards,
Marco
--
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
End of bug-lilypond Digest, Vol 68, Issue 26
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 653 in lilypond: \override inconsistency with ties in a polyphonic situation
Message: 6 Date: Sat, 26 Jul 2008 19:03:24 -0700 From: [EMAIL PROTECTED] Subject: Issue 653 in lilypond: \override inconsistency with ties in a polyphonic situation To: bug-lilypond@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; Format=Flowed Issue 653: \override inconsistency with ties in a polyphonic situation http://code.google.com/p/lilypond/issues/detail?id=653 Comment #1 by hanwenn: Don't use Tie to override concurrent ties. We have TieColumn #'tie-configuration for that. But the original report followed an attempt to modify the -shape- of a tie. #'tie-configuration only provides for repositioning the tie, doesn't it? OHIMS? Issue attribute updates: Status: Invalid ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 653 in lilypond: \override inconsistency with ties in a polyphonic situation
Han-Wen, you wrote:
Doing overrides on individual ties is not supported like this, exactly
because there
is no way to select them. Try \tweak,
\new Voice
{ c''-\tweak #'direction #-1 -~ c'' }
{ e'-\tweak #'direction #1 -~ e' }
This works fine with #'control-points too. Thanks.
(changing status so someone will update lsr/the manual.)
I've made a note to do this in NR 5
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: doc suggestion
Graham Percival wrote Wednesday, July 30, 2008 5:09 AM
LM 5 hasn't been touched as part of GDP, and AFAIK nobody has any
spare time to look at it. The only possibility is that Trevor
might spend a few hours on it after he's done the first update for
NR 6.
Actually it's NR 5 I'm just starting on (not NR 6),
since we reorganised the chapters.
Han-Wen is quite right - skylining now places the text
in this LM example correctly without using padding. For
now I'll drop a TODO in the .itely file as a reminder
to think of a better example.
- Graham
Trevor
On Wed, 30 Jul 2008 00:45:11 -0300
Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
there is a the following snippet in
5.1.4 Saving typing with variables and functions
but the example doesn't show how the padText works. I think skylining
handles this automaticallly. Maybe you should find a different
example?
padText =
#(define-music-function (parser location padding) (number?)
#{
\once \override TextScript #'padding = #$padding
#})
\relative c''' {
c4^piu mosso b a b
\padText #1.8
c4^piu mosso d e f
\padText #2.6
c4^piu mosso fis a g
}
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 653: \override inconsistency with ties in a polyphonic situation
Message: 4
Date: Mon, 28 Jul 2008 08:18:12 -0700
From: [EMAIL PROTECTED]
Subject: Issue 653 in lilypond: \override inconsistency with ties in a
polyphonic situation
To: bug-lilypond@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; Format=Flowed
Issue 653: \override inconsistency with ties in a polyphonic situation
http://code.google.com/p/lilypond/issues/detail?id=653
Comment #3 by hanwenn:
Doing overrides on individual ties is not supported like this, exactly
because there
is no way to select them. Try \tweak,
\new Voice
{ c''-\tweak #'direction #-1 -~ c'' }
{ e'-\tweak #'direction #1 -~ e' }
Further to my previous note, tweaking the properties
of ties in this way works correctly for both notes
in a two-note chord, but tweaking 'control-points
does not work for the second note in a chord. Here
are a few examples demonstrating the problem:
\relative c' {
% The tied chord tested
e~ a~ e a
e^~ a_~ e a
% All the following tweaks work on both notes of the chord ...
e -\tweak #'color #red ^~ a~ e a
e~ a -\tweak #'color #blue _~ e a
e -\tweak #'thickness #5 -~ a~ e a
e~ a -\tweak #'thickness #5 -~ e a
e -\tweak #'dash-fraction #0.5
-\tweak #'dash-period #1 -~ a~ e a
e~ a -\tweak #'dash-fraction #0.5
-\tweak #'dash-period #1 -~ e a
% ... except for these, which have no effect on the
% second note of the chord
e -\tweak #'control-points
#'((0.5 . -2) (1.5 . -6) (2.5 . -6) (3.5 . -2)) -~ a~ e a
e~ a -\tweak #'control-points
#'((1.5 . 0) (2.0 . 4) (2.5 . 4) (3.5 . 0)) -~ e a
a -\tweak #'control-points
#'((1.5 . 0) (2.0 . 4) (2.5 . 4) (3.5 . 0)) -~ e~ a e
a~ e -\tweak #'control-points
#'((0.5 . -2) (1.5 . -6) (2.5 . -6) (3.5 . -2)) -~ a e
}
This does seems to be a bug with the combination of
control points, ties and chords. Alternatively, I
can document this as a known issue.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Help with debugging apparent error in parser
Carl
This isn't a problem specific to chordmode. If you use
an identifier c you get a similar error about unexpected
notename_pitch whatever the input mode. The problem is
the identifier m.
Because m is a valid chord modifier and the parser/lexer
is scanning for chordmodifiers or pitchnames it considers
the m to be a chord modifier rather than a variable name.
It seem the parser/lexer relies on finding a token which
is invalid in the current input mode to cause termination
of that mode. So your first expression is ok because m
is invalid in notemode.
Such errors can be avoided by:
(a) placing all variable definitions before music
(b) not using single-character variable names.
Trevor
- Original Message -
From: Carl D. Sorensen [EMAIL PROTECTED]
To: lily-devel [EMAIL PROTECTED]; bug-lilypond@gnu.org
Sent: Friday, August 08, 2008 2:54 AM
Subject: Help with debugging apparent error in parser
Dear LilyPond team,
As I developed the transposable fretboards, I have apparently run into an
error in the parser.
When \chordmode is done, it apparently leaves the parser in a fragile state.
Let me show some code:
%%% Begin code
myDisplayMusic =
#(define-music-function (parser location music)
(ly:music?)
(display-scheme-music music)
(make-music 'SequentialMusic 'void #t))
%\myDisplayMusic c e g % Expression 1 -- no problem
\myDisplayMusic \chordmode{c} % Expression 2 -- causes error
m = \relative c' { c d e}
\context Staff {
\m
}
End code
If Expression 1 in the above code is uncommented, and expression 2 is
commented, the code compiles normally.
If Expression 1 is commented, and Expression 2 is uncommented, there is a
parse error:
parseerror.ly:14:0: error: syntax error, unexpected CHORD_MODIFIER
m = \relative c' { c d e}
parseerror.ly:17:2: error: unknown escaped string: `\m'
\m
parseerror.ly:17:2: error: syntax error, unexpected STRING
\m
parseerror.ly:16:0: error: errors found, ignoring music expression
\context Staff {
Even if Expression 1 is uncommented and follows Expression 2, I get the same
error. It appears that the parser somehow gets stuck using chordmode
parsing.
I have no idea how to debug this problem. Any suggestions? Or can anybody
fix this?
Thanks,
Carl
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Help with debugging apparent error in parser
Carl
You may be right, but the details of the parser/lexer logic
have so far defeated me. As it's late and as I'm away most of
Saturday I shall withdraw, beaten, from this discussion :(
Trevor
- Original Message -
From: Carl D. Sorensen [EMAIL PROTECTED]
To: Trevor Daniels [EMAIL PROTECTED]; lily-devel
[EMAIL PROTECTED]; bug-lilypond@gnu.org
Sent: Friday, August 08, 2008 10:10 PM
Subject: Re: Help with debugging apparent error in parser
On 8/8/08 3:09 AM, Trevor Daniels [EMAIL PROTECTED] wrote:
Carl
This isn't a problem specific to chordmode. If you use
an identifier c you get a similar error about unexpected
notename_pitch whatever the input mode. The problem is
the identifier m.
Because m is a valid chord modifier and the parser/lexer
is scanning for chordmodifiers or pitchnames it considers
the m to be a chord modifier rather than a variable name.
It seem the parser/lexer relies on finding a token which
is invalid in the current input mode to cause termination
of that mode. So your first expression is ok because m
is invalid in notemode.
I would agree with this, except for the problem that I can do
\myDisplayMusic \chordmode{c}
\myDisplayMusic \notemode {c}
which should put the parser back in notemode, and I still get the error with
m as an identifier. However, if I write
\myDisplayMusic \notemode{c}
I do not get the error with m as an identifier. Thus, it appears to me that
once the parser enters chordmode, it sets something that it doesn't clean up
when it moves from chordmode to notemode.
Such errors can be avoided by:
(a) placing all variable definitions before music
There is some justification in the documentation for being able to use void
music functions to set parser behavior in multiple locations.
(b) not using single-character variable names.
I agree. I don't use single-character variable names. This particular case
was identified in a regression test.
I could change the variable name in the regression test. However, there is
still a subtle bug that I have been observing that has to do with the parser
entering chordmode in a void music function that causes strange errors.
This experience causes me to believe that there is a bug in the parser
related to chordmode.
Thanks,
Carl
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics independent of notes
Andrew Hawryluk wrote Thursday, August 21, 2008 2:10 AM
On Tue, Aug 19, 2008 at 4:03 AM, Valentin Villenave
[EMAIL PROTECTED] wrote:
2008/8/12 Martin Klejch [EMAIL PROTECTED]:
%% the Lyrics independent of notes example (chapter 7.3.7.5 of the
manual)
%% gives errors: warning: Lyric syllable does not have note. Use
\lyricsto
%% or associatedVoice ...
I'm not sure this is a bug. Can anyone who has already used such
structures confirm?
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Lyrics-independent-of-notes.html
(if anyone has ever used it, that is :-)
Cheers,
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
I tried to get that same feature to work on a piece I was
re-engraving, but I got the same error message and a bunch of
improperly aligned lyrics. I tried the attached snippet and got these
complains from LilyPond:
GNU LilyPond 2.11.49
Processing `test.ly'
Parsing...
test.ly:0: warning: : no \version statement found, please add
\version 2.11.49
for future compatibility
Interpreting music...
test.ly:8:24: warning: Lyric syllable does not have note. Use
\lyricsto or associatedVoice.
lyr = \lyricmode {
I like my cat! }
[snip]
This seems like a regression. It looks OK in the
manual as that example has not been edited recently
and so has not been recompiled recently either. In
the file for my local doc build it was last compiled
on 27 April 08, and was OK then, probably with 2.11.44.
I'll try to locate the first release which failed.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics independent of notes
Trevor Daniels wrote Thursday, August 21, 2008 9:46 PM
Andrew Hawryluk wrote Thursday, August 21, 2008 2:10 AM
On Tue, Aug 19, 2008 at 4:03 AM, Valentin Villenave
[EMAIL PROTECTED] wrote:
2008/8/12 Martin Klejch [EMAIL PROTECTED]:
%% the Lyrics independent of notes example (chapter 7.3.7.5 of the
manual)
%% gives errors: warning: Lyric syllable does not have note. Use
\lyricsto
%% or associatedVoice ...
I'm not sure this is a bug. Can anyone who has already used such
structures confirm?
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Lyrics-independent-of-notes.html
(if anyone has ever used it, that is :-)
Cheers,
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
I tried to get that same feature to work on a piece I was
re-engraving, but I got the same error message and a bunch of
improperly aligned lyrics. I tried the attached snippet and got these
complains from LilyPond:
GNU LilyPond 2.11.49
Processing `test.ly'
Parsing...
test.ly:0: warning: : no \version statement found, please add
\version 2.11.49
for future compatibility
Interpreting music...
test.ly:8:24: warning: Lyric syllable does not have note. Use
\lyricsto or associatedVoice.
lyr = \lyricmode {
I like my cat! }
[snip]
This seems like a regression. It looks OK in the
manual as that example has not been edited recently
and so has not been recompiled recently either. In
the file for my local doc build it was last compiled
on 27 April 08, and was OK then, probably with 2.11.44.
I'll try to locate the first release which failed.
[replying to my own note]
I'm having difficulty getting old versions to work
properly and can't figure out why at the moment. Could
someone else try to locate when this example started
failing?
Trevor
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics independent of notes
Mats, you wrote Sunday, August 24, 2008 10:29 PM
Hold the horses, there seems to be a regression bug lurking
around here. I happened to have a copy of 2.11.34 installed
and using that, the two lyric lines in the following example
have the same alignment, whereas with 2.11.56 all syllables
of the bottom line are left aligned with the notes. I definitely
prefer the behaviour of 2.11.34.
I'm not so sure. There are other differences. Try adding an explicit
duration to the lyrics, say Left2, and compare them again.
This behaviour is better in 2.11.56.
The change occurred between 2.11.40 and 2.11.41, almost
certainly when a fix for 532 was applied on 24 Feb 08,
commit c1b4680ed477e2232629df6c59c7fd78d5583d0b.
This fixed the behaviour of lyrics when there is no
associated voice. In that case there is nothing to
align the lyrics to, so it is not surprising that the
alignment overrides do not work.
I prefer the behaviour in 2.11.56, but it does need
to be documented properly.
Trevor
mylyrics = \lyricmode {
Default
\override LyricText #'self-alignment-X = #LEFT Left
\override LyricText #'self-alignment-X = #CENTER Center
\override LyricText #'self-alignment-X = #RIGHT Right
}
\new Staff \new Voice = v {c' d' e' f'}
\new Staff \new Voice {c'2 d'4 e'8 f'8}
\new Lyrics \lyricsto v \mylyrics
\new Lyrics \mylyrics
/Mats
Mats Bengtsson wrote:
Trevor Daniels wrote:
The warnings are not exactly errors. Another thread with the words
durations needed in which Mats explained very well some related
issues, can be of help.
I've now been able to check back to 2.10.34, and the
warnings were issued there too. Seems like they might
have been there a long time. Perhaps all it needs
is a note in the manual to say warnings are expected.
Yes, as far as I can remember, these warnings have always
appeared when you use the Devnull trick. If you search the
mailing list archives, you'll find that Han-Wen has never
really agreed that this is a good way to do things. However,
I think that it's a clever trick that can be useful from time to
time. The manual should also point out that the alignment
will not be exactly the same as if you use \lyricsto or set
associatedVoice, but since you only need the Devnull trick
in situation where you do not have any typeset Voice to
associate the syllables to, I don't find it a critical issue.
/Mats
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
2.11.57 fails from Vista command line
The GUB release 2.11.57 for Windows seems to have a problem on Vista SP1. When started from the command line it returns immediately, even when given no arguments - 2.11.56 is fine - it gives brief help information when given no arguments. When started from another application like lilypondbook or ConTEXT, 2.11.57 processes the file correctly, but flashes up a command window at a late stage during compilation. Any ideas what might be wrong? Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.11.57 fails from Vista command line
Thanks for letting me know, Valentin. Unlike last time, at least this problem with Vista is not my fault - quite a relief! :) For now I've gone back to 2.11.56, as it was impossible trying to run lilypond-book on the docs - windows flashing everywhere and quite an increase in processing time. I've also put a bash script together so I can compile single .itely files, as 2.11.57 is needed for quite a few of them, but fortunately not for changing-defaults.itely - the one I'm working on at present. BTW, did this report appear on the -bug list? I don't remember seeing it. Trevor - Original Message - From: Valentin Villenave [EMAIL PROTECTED] To: Trevor Daniels [EMAIL PROTECTED] Cc: lilypond-devel [EMAIL PROTECTED]; Bug-Lilypond bug-lilypond@gnu.org Sent: Sunday, September 07, 2008 8:40 PM Subject: Re: 2.11.57 fails from Vista command line 2008/9/5 Trevor Daniels [EMAIL PROTECTED]: The GUB release 2.11.57 for Windows seems to have a problem on Vista SP1. Greetings Trevor, Actually this is a known (however annoying) bug, see http://code.google.com/p/lilypond/issues/detail?id=668 Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Running accessory programs (convert-ly, etc.)
Graham Percival wrote: On Thu, 11 Sep 2008 16:02:50 + (UTC) Albert Bickford [EMAIL PROTECTED] wrote: convert-ly -e myfile.ly However, convert-ly is a python program, not an .exe, so what I had to do was python convert-ly.py -e myfile.ly I don't know how it works on windows with a properly configured system, but the first command is fine as written on Linux and OSX. Trevor? Well, convert-ly works on my system as is, but I can't remember if I fiddled with the paths to python or not. I use python for other things, so I had it installed independently of LilyPond. You do have to execute it in the directory containing the Lily file, or give it a fully qualified name, of course. Cheers, - Graham Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond documentation Custos
Date: Thu, 09 Oct 2008 18:51:14 +0200
From: Martial [EMAIL PROTECTED]
Subject: Lilypond documentation Custos
To: bug-lilypond@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=UTF-8; format=flowed
Hello
doc error ?
I think that it is
\override Custos #'style = #'mensural
in the doc 2.11.62
2.8.3.2 Custodes
\layout {
\context {
\Staff
\consists Custos_engraver
Custos \override #'style = #'mensural
}
}
Fixed in 2.11 docs ...
the same error in 2.10.33 doc
7.7.8 Custodes
... but not in 2.10
Regards
--
Martial
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 694 in lilypond: Enhancement: better support for microtone accidentals
Graham Percival wrote Mon, 13 Oct 2008 00:02:37 -0700 [EMAIL PROTECTED] wrote: This is good news: it means LilyPond is ready for microtonal musics, spectral music, non-equal temperaments etc.; we'd just need to have more ready-to-use macros, and document it better. I'll look into it. We used to include makam.ly in pitches.itely. I don't know what happened to it. There is a snippet called makam-example.ly which is tagged with the snippets for World music and \includes makam.ly. It shows 1/9th tone microtones. Is this what you meant? Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 694 in lilypond: Enhancement: better support for microtone accidentals
Graham Percival wrote Tuesday, October 14, 2008 10:39 PM On Tue, 14 Oct 2008 21:52:11 +0100 Trevor Daniels [EMAIL PROTECTED] wrote: Graham Percival wrote Mon, 13 Oct 2008 00:02:37 -0700 We used to include makam.ly in pitches.itely. I don't know what happened to it. There is a snippet called makam-example.ly which is tagged with the snippets for World music and \includes makam.ly. It shows 1/9th tone microtones. Is this what you meant? Yeah, that's what I was talking about. I guess we took it out of Pitches when World was created, but we probably should have kept it in the Pitches Snippet List, and included in the @snippets of Accidentals. I've added makam-example.ly to the @snippets of Accidentals. It's already tagged for Pitches. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Index entries leading to @seealso
I've just noticed that there are many entries in the index to the Notation
Reference which lead you to the @seealso sections. It seems that the @r..{}
macros generate index entries automatically. But these entries are pretty
useless as they take to the place where the reference is made, rather than
the place being referenced. For example, look at the entries for
fingering.
Should this be classified as a documentation bug?
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Character change on Vista
I get the same result on Vista. Here's a minimal
example which shows the problem:
\score {
\override Score.LyricText #'font-name = #Times New Roman
\relative c'' { g }
\addlyrics { nN }
}
Trevor
- Original Message -
From: sdfgsdhdshd [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 24, 2008 10:16 AM
Subject: Character change on Vista
With 2.11.62 on a PC with XP and another PC with Vista, i tested the code
below.
The result is fine on both.
Then i uncomment the line. The result is still fine on XP, but on Vista
the
uppercase N (and only this one) is changed to another character.
Any ideas?
\include italiano.ly
#(ly:set-option 'point-and-click #f)
Un = \lyricmode
{
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
}
\score
{
% \override Score.LyricText #'font-name = #Times New Roman
\new ChoirStaff
\new Staff
\new Voice = Sopranos { \voiceOne { sol'4 re'' } }
\new Lyrics = UnLyrics { s1 }
\context Lyrics = UnLyrics \lyricsto Sopranos \Un
}
--
View this message in context:
http://www.nabble.com/Character-change-on-Vista-tp20146841p20146841.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Character change on Vista
Valentin Villenave wrote Friday, October 24, 2008 12:02 PM 2008/10/24 Trevor Daniels [EMAIL PROTECTED]: I get the same result on Vista. Here's a minimal example which shows the problem: Hi Trevor, may i ask you to send a png? (since you're about the only one who can reproduce it :-) Sure - attached. Trevor attachment: badN.png___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental hiding fingering indication
This accidental/fingering collision appears to be a bug, so I'm copying to
the bug list. I can't find a similar bug in the bug DB.
The collision occurs only when the chord is the first chord/note in the bar,
and the fingered note precedes the sharpened note in that chord. Here's a
short example:
\relative c' {
\time 2/4
\set fingeringOrientations = #'(left)
a-3 cis-4 % first chord in bar - collision
a-3 cis!-4 % not first chord in bar - no collision
a-3 cis!-4 % first chord in bar - collision
a-3 cis!-4 % not first chord in bar - no collision
cis-4 a-3 % reverse order - no collision
}
Trevor
- Original Message -
From: Nick Payne [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 10, 2008 7:05 PM
Subject: Accidental hiding fingering indication
At several places in the attached score, an accidental on a note in a
chord
is obscuring a fingering indication for another note in the chord. The
strange thing is that in some places the fingering is correctly moved to
avoid the accidental and in others it isn't.
e.g. In the lower voice in bars 3 and 9 the fingering on the adjacent note
in the chord is moved to avoid the accidental, whereas in bar 10 it is
not,
and in the upper voice the problem happens in bars 6 and 12. There's also
the same problem in bar 11, but I'm guessing that it happens there because
the accidental is in one voice and the fingering in the other.
Lilypond 2.11.63 on Vista.
Nick Payne
___
lilypond-user mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 38 in lilypond: collision fingering beam
I've added a snippet based on the example supplied by Mark
to the repository in a form which is suitable for inclusion
in the selected snippets section of NR 1.7 Editorial annotations.
It will appear in the docs in due course.
See Avoiding collisions of chord fingering with beams
Thanks Mark
Trevor
Comment #2 by n.puttock:
This is invalid.
i don't really understand what is invalid - there is a collision, it is
not
readable and it is not what we are used from liylpond!!!
Stems are deliberately excluded from the supports of fingerings inside
chords unless
'add-stem-support = ##t.
i searched the manuals for an example how to use this option and found it
with the snippets repository search which pointed to version 2.10.12:
User backend properties
add-stem-support (boolean)
If set, the Stem object is included in this script's support
and
text-script-interface
An object that is put above or below a note
User settable properties:
add-stem-support (boolean)
If set, the Stem object is included in this script's support
so i would like to illustrate it and hope it will also be mentioned in the
actual docs one day:
\relative {
\set fingeringOrientations = #'(up)
\set stringNumberOrientations = #'(up)
\set strokeFingerOrientations = #'(up)
r 16 [ r
f c'^5 16
\override Fingering #'add-stem-support = ##t
f c'^5
f c' \5
\override StringNumber #'add-stem-support = ##t
f c' \5
f c'-\rightHandFinger #2
\override StrokeFinger #'add-stem-support = ##t
f c' -\rightHandFinger #2 ]
}
--
View this message in context:
http://www.nabble.com/Issue-38-in-lilypond%3A-collision-fingering-beam-tp20389835p20531266.html
Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com.
--
Message: 4
Date: Sun, 16 Nov 2008 19:02:24 -0800 (PST)
From: Mark Polesky [EMAIL PROTECTED]
Subject: MetronomeMark doesn't respond to #'font-series override
To: bug-lilypond bug-lilypond@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Developers,
Is this a bug?
- Mark
_
%% MetronomeMark doesn't respond to #'font-series override
\version 2.11.63-1
\score {
\new Staff \relative {
\tempo Allegro
g' a b c
}
\layout {
\context {
\Score
%% these 3 lines affect tempo mark as expected:
\override MetronomeMark #'font-family = #'sans
\override MetronomeMark #'font-size = #2
\override MetronomeMark #'font-shape = #'italic
%% but tempo remains bold despite adding this line:
\override MetronomeMark #'font-series = #'medium
}
}
}
-- next part --
A non-text attachment was scrubbed...
Name: font-series-bug.png
Type: image/png
Size: 3086 bytes
Desc: not available
Url :
http://lists.gnu.org/pipermail/bug-lilypond/attachments/20081116/b9a7a9f1/font-series-bug.png
--
Message: 5
Date: Sun, 16 Nov 2008 19:05:42 -0800
From: [EMAIL PROTECTED]
Subject: Issue 347 in lilypond: ragged-last-bottom=##f fails if
ragged-bottom=##t
To: bug-lilypond@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Issue 347: ragged-last-bottom=##f fails if ragged-bottom=##t
http://code.google.com/p/lilypond/issues/detail?id=347
Comment #4 by joeneeman:
Ragged is currently used in 2 ways: to determine the page breaking (what
looks good
normally might look bad with ragged spacing) and for actually laying out
the systems.
What if we put in some functionality to separate these uses and allowed
better tuning
for the part that doesn't affect page breaking? This is much nicer because
things are
tricky if we want to enhance the page-breaking effects of ragged.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--
Message: 6
Date: Sun, 16 Nov 2008 22:09:49 -0800
From: [EMAIL PROTECTED]
Subject: Issue 347 in lilypond: ragged-last-bottom=##f fails if
ragged-bottom=##t
To: bug-lilypond@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Issue 347: ragged-last-bottom=##f fails if ragged-bottom=##t
http://code.google.com/p/lilypond/issues/detail?id=347
Comment #5 by lemzwerg:
Can you give an example where `ragged page breaking' gives a different
appearance? I
can't imagine a situation where page breaking depends on raggedness and
not
on the
available vertical (stretchable?) space.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--
___
Re: Issue 38 in lilypond: collision fingering beam
Ah, I'm sorry, Eluze, and thank you! I replied from the bug digest and I must have looked at the wrong message headers when I looked to see who wrote it. Trevor - Original Message - From: Mark Polesky [EMAIL PROTECTED] To: Trevor Daniels [EMAIL PROTECTED]; bug-lilypond@gnu.org Sent: Wednesday, November 19, 2008 5:53 AM Subject: Re: Issue 38 in lilypond: collision fingering beam From: Trevor Daniels I've added a snippet based on the example supplied by Mark Thanks Mark Credit should go to Eluze for the example mentioned. I had nothing to do with it. - Mark ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics
Reinhold Kainhofer wrote Monday, November 24, 2008 6:14 PM PS: Note that the comment in the documentation about the setting applying only to the second next syllable (fas in this case), is actually no longer true in LilyPond 2.11.x. The setting now applies to the very next lyrics syllable already! Ah - I missed that change. I'll fix the docs! Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Undefined concepts used in Learning Manual
John Sellers wrote In reading through the Learning manual, all concepts seeming to be well introduced before using them in examples. The clarity of these sections could not be better. However in section 2.5.1, Organizing pieces with variables it seems that several concepts are used in examples without having been previously defined. Also new syntax is introduced without explanation. These include paper, variable, types, objects, new kinds of use of backslash, cm, 21.0 (e.g. numbers with decimal points), =, (e.g. quoted strings), line-width (e.g. control variables), etc. This is a valid criticism. An easy solution is to delete this small section, but the real problem is that the tutorial doesn't mention any means of controlling output. The right solution would be to have a short introduction to controlling output, mentioning \paper etc, which would be a suitable vehicle to introduce the other topics you mention. Then the example would flow nicely later. I'll make a note to look at this. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Non-standard octave-limited key signature does not persist
If a non-standard key signature is defined using the format which limits the
alterations to a single octave, the alterations defined in the key signature
persist only up to the end of the first bar which contains a pitch to be
altered.
They should persist indefinitely.
In this example the F# and Ab are notated correctly only in bar 1. A Bb
does not
appear until bar 3, when it is notated correctly, but is incorrect in bar 4.
\relative c' {
\set Staff.keySignature = #`(((0 . 3) . ,SHARP)
((0 . 5) . ,FLAT)
((0 . 6) . ,FLAT))
fis fis aes aes
fis fis aes aes
fis aes bes bes
fis aes bes bes
}
If the alternative (not limited to a single octave) form is used the key
alterations
do correctly persist indefinitely:
\relative c' {
\set Staff.keySignature = #`((3 . ,SHARP)
(5 . ,FLAT)
(6 . ,FLAT))
fis fis aes aes
fis fis aes aes
fis aes bes bes
fis aes bes bes
}
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: (attn doc team) Re: Diatonic notation system
Graham Breed wrote Thursday, December 11, 2008 1:01 AM
I can demonstrate the bug with that file though. Here's an example:
\version 2.11.65
\include arabic.ly
melody = \relative {
\key re \bayati
do re mi fa sol la si do
}
\score {
\new Staff \melody
\layout { }
\midi { }
}
It fails with
Interpreting music...
bayati_ar.ly:5:2: warning: No ordering for key signature alterations
\key re \bayati
Preprocessing graphical objects...
Interpreting music...
/home/graham/lilypond/usr/share/lilypond/current/scm/lily-library.scm:149:5:
In procedure ly:book-process in expression (process-procedure book
paper ...):
/home/graham/lilypond/usr/share/lilypond/current/scm/lily-library.scm:149:5:
Wrong type (expecting exact integer): -3/2
Removing the \midi{} line fixes it. Similarly, removing the \midi{ }
from Hans's file fixes that. So it's not that it works with
quartertones but not other inflections. It looks like it doesn't work
with any pitch-bent MIDI.
I pointed out this bug some time ago, see
http://lists.gnu.org/archive/html/lilypond-user/2008-06/msg00642.html
but at the time no one verified it so it didn't make it to the bug list.
Now
you have verified it I'll post it there now.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Non-standard octave-limited key signature does not persist
Neil Puttock wrote Thursday, December 11, 2008 5:23 PM
2008/12/11 Trevor Daniels t.dani...@treda.co.uk:
In this example the F# and Ab are notated correctly only in bar 1. A Bb
does not
appear until bar 3, when it is notated correctly, but is incorrect in bar
4.
\relative c' {
\set Staff.keySignature = #`(((0 . 3) . ,SHARP)
((0 . 5) . ,FLAT)
((0 . 6) . ,FLAT))
fis fis aes aes
fis fis aes aes
fis aes bes bes
fis aes bes bes
}
Unfortunately, an alist entry in keySignature of the form ((octave .
pitch) . alteration) is swallowed up by localKeySignature since it
looks the same as a generated entry (which must include the octave,
otherwise most accidental rules would break). Consider this
simplified version of your snippet:
\relative c' {
\set Staff.keySignature = #`(((0 . 3) . ,SHARP))
fis1
fis1
}
In the first bar, localKeySignature is identical to keySignature:
(((0 . 3) . 1/2))
By the time the Accidental_engraver checks whether the fis in the
second bar needs an accidental, the time signature entry in
localKeySignature has disappeared, replaced by the entry automatically
generated for the second note:
(((0 . 3) 1/2 1 . #Mom 1))
As you can see, the key signature has the same alist key (0 . 3) as
the new entry and is replaced by the new value. Compare this with the
output output using octaveless keySignature entries, where the key
signature is present at the end of the list:
(((0 . 3) 1/2 1 . #Mom 1) (3 . 1/2))
The simplest way around this would be to pass both localKeySignature
and keySignature to check_pitch_against_signature () and use both when
extracting from_key_signature; currently this code only uses the pitch
as an alist key, since it assumes that any entry of the form (pitch .
alteration) comes from the key signature.
SCM from_key_signature = ly_assoc_get (scm_from_int (n),
key_signature, SCM_BOOL_F);
Thanks for this insight into the code. I had looked at it briefly, and
suspected that localKeySignature was somehow involved.
A patch is on its way. :)
Great! In which case I'll leave the docs as they are for now. When this is
fixed I'll have a look at expanding the section which covers non-standard
key signatures.
Regards,
Neil
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Crash if \layout omitted with \midi
Using \midi without \layout in 2.11.64-1 causes an exception in Windows
Vista:
\score {
\new Staff {
\new Voice { a }
}
% \layout { }
\midi { }
}
Exception Code: c005
Exception Offset: 001bfa19
OS Version: 6.0.6001.2.1.0.768.3
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Crash if \layout omitted with \midi
Trevor Daniels wrote Tuesday, December 16, 2008 10:09 AM
Using \midi without \layout in 2.11.64-1 causes an exception in Windows
Vista:
Sorry, this should read 2.11.65-1
\score {
\new Staff {
\new Voice { a }
}
% \layout { }
\midi { }
}
Exception Code: c005
Exception Offset: 001bfa19
OS Version: 6.0.6001.2.1.0.768.3
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: beam settings
Herbert Liechti wrote Tuesday, December 23, 2008 6:40 AM
Neil Puttock schrieb:
2008/12/22 Trevor Daniels t.dani...@treda.co.uk:
Reinhold Kainhofer wrote Monday, December 22, 2008 4:22 PM
He sent me the whole file and the culprit is a PianoStaff, which seems
to
somehow override the score's beamGrouping. So, one cannot use
\set Score.beatGrouping = #'(1 1 1 1 1 1)
but rather has to use
\set Staff.beatGrouping = #'(1 1 1 1 1 1)
Then the beaming also works fine for staves inside a PianoStaff.
Hmm. Does that mean that context properties set at the Score
level are inherited by the Staff context only if there is no
interposed staff grouping?
I've never noticed this to be the case; I think we need to see
Herbert's file to work out whether there's something else that's
influencing this behaviour.
I'm attaching the file. I already changed the beatGrouping from
Score to Staff context.
I've tracked down the problem here. It is nothing to to do with the
PianoStaff. It is due to placing a second \time command in the lower
staff. Here's an extract from the score which shows the problem
clearly. Uncomment the second \time command and the
beamGrouping override in the Score context fails in both staves.
Specify \time in only one staff and it works fine in both staves.
\score {
\new Staff {
\time 6/8
\set Score.beatGrouping = #'(1 1 1 1 1 1)
\repeat unfold 6 { \times 2/3 { bes16 as es } }
}
\new Staff {
% \time 6/8
\repeat unfold 6 { \times 2/3 { bes16 as es } }
}
}
Copied to bug-lily for further comment there.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: beam settings
Carl D. Sorensen wrote Thursday, December 25, 2008 12:21 AM
On 12/24/08 3:31 PM, Trevor Daniels t.dani...@treda.co.uk wrote:
Herbert Liechti wrote Tuesday, December 23, 2008 6:40 AM
Neil Puttock schrieb:
2008/12/22 Trevor Daniels t.dani...@treda.co.uk:
Reinhold Kainhofer wrote Monday, December 22, 2008 4:22 PM
He sent me the whole file and the culprit is a PianoStaff, which
seems
to
somehow override the score's beamGrouping. So, one cannot use
\set Score.beatGrouping = #'(1 1 1 1 1 1)
but rather has to use
\set Staff.beatGrouping = #'(1 1 1 1 1 1)
Then the beaming also works fine for staves inside a PianoStaff.
Hmm. Does that mean that context properties set at the Score
level are inherited by the Staff context only if there is no
interposed staff grouping?
I've never noticed this to be the case; I think we need to see
Herbert's file to work out whether there's something else that's
influencing this behaviour.
I'm attaching the file. I already changed the beatGrouping from
Score to Staff context.
I've tracked down the problem here. It is nothing to to do with the
PianoStaff. It is due to placing a second \time command in the lower
staff. Here's an extract from the score which shows the problem
clearly. Uncomment the second \time command and the
beamGrouping override in the Score context fails in both staves.
Specify \time in only one staff and it works fine in both staves.
\score {
\new Staff {
\time 6/8
\set Score.beatGrouping = #'(1 1 1 1 1 1)
\repeat unfold 6 { \times 2/3 { bes16 as es } }
}
\new Staff {
% \time 6/8
\repeat unfold 6 { \times 2/3 { bes16 as es } }
}
Aha! This makes sense. This is because time 6/8 sets beatGrouping to (3
3). And beatGrouping doesn't live on the Staff level.
This probably becomes a documentation bug.
OK. I'll fix the docs.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Crash if \layout omitted with \midi
James E. Bailey wrote Sunday, December 28, 2008 8:35 AM Am 18.12.2008 um 09:57 schrieb Mark Polesky: Trevor Daniels wrote: Using \midi without \layout in 2.11.65-1 causes an exception in Windows Vista: in XP also. - Mark In OSX 10.4 Intel also. This is fixed in 2.12. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Not every sustainOn command works properly in midi output
It's because the \sustainOn and \sustainOff are written
to occur at the same musical moment. You'll need to
introduce a small time separation between them, perhaps by
adjusting the spacer rests.
Trevor
- Original Message -
From: Michael Pozhidaev m...@altlinux.org
To: bug-lilypond@gnu.org
Sent: Saturday, January 03, 2009 6:00 AM
Subject: Not every sustainOn command works properly in midi output
Hello!
I have noticed something strange, looks like a bug
with producing midi files for piano pieces.
It appears in lilypond 2.11.61 and 2.12.1 built from sources for 64-bit
linux
and lilypond 2.12.1 from the binary linux-x86_64 distribution.
Everything was OK in old lilypond-2.11.0 (but using \sustainDown command
instead of \sustainOn)
In the following snippet there are two marks, 1 and 2.
The \sustainOn command in the line below mark1 works properly,
but the one below mark2 do nothing. In this message there is midi file I
got
with this code. Is it a bug or I do something wrong?
Thanks!
\version 2.11.61
partOneLeft = {
\key c \minor
\time 6/8
\clef bass
\tempo 4 = 140
f as c'4. f'4( c'8
f4 as2)
g b d'4. g'4( d'8
g4 b2)
c4( es8 g4 c'8
c2.)
}
partOneLeftMidi = {
%%mark1:
s4. \sustainOn s4 s8
s4 s2
%%mark2:
s4. \sustainOff \sustainOn s4 s8
s4 s2
s4 \sustainOff \sustainOn s8 s4 s8
s2. \sustainOff
}
\score {
\new PianoStaff
\set PianoStaff.instrumentName = piano
\new Staff = lower
{
\partOneLeft
}
{
\partOneLeftMidi
}
\midi { }
}
--
Michael Pozhidaev. E-mail: m...@altlinux.ru.
Tomsk State University. http://www.csd.tsu.ru
ALT Linux Team. http://www.altlinux.ru
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: (attn doc team) Re: Diatonic notation system
Valentin Villenave wrote Sunday, January 11, 2009 2:56 PM
2008/12/11 Trevor Daniels t.dani...@treda.co.uk:
Graham Breed wrote Thursday, December 11, 2008 1:01 AM
I can demonstrate the bug with that file though. Here's an example:
\version 2.11.65
\include arabic.ly
melody = \relative {
\key re \bayati
do re mi fa sol la si do
}
\score {
\new Staff \melody
\layout { }
\midi { }
}
It fails with
Interpreting music...
bayati_ar.ly:5:2: warning: No ordering for key signature alterations
\key re \bayati
Preprocessing graphical objects...
Interpreting music...
/home/graham/lilypond/usr/share/lilypond/current/scm/lily-library.scm:149:5:
In procedure ly:book-process in expression (process-procedure book
paper ...):
/home/graham/lilypond/usr/share/lilypond/current/scm/lily-library.scm:149:5:
Wrong type (expecting exact integer): -3/2
Removing the \midi{} line fixes it. Similarly, removing the \midi{ }
from Hans's file fixes that. So it's not that it works with
quartertones but not other inflections. It looks like it doesn't work
with any pitch-bent MIDI.
I pointed out this bug some time ago, see
http://lists.gnu.org/archive/html/lilypond-user/2008-06/msg00642.html
but at the time no one verified it so it didn't make it to the bug list.
Now
you have verified it I'll post it there now.
Hm, I'd happily add such things but I need to (remotely) understand
what the bug is... Sorry for digging this out after a month, but could
you provide me with some help?
I'll try.
A mode contains a quarter tone generates the warning:
D:/Users/Trevor/Leisure/Music/LilyPond/Tests/test1.ly:7:4: warning: No
ordering for key signature alterations
and if a \midi { } statement is included this error is also generated:
Interpreting music... C:/Program
Files/LilyPond/usr/share/lilypond/current/scm/lily-library.scm:149:5: In
procedure ly:book-process in expression (process-procedure book paper ...):
C:/Program
Files/LilyPond/usr/share/lilypond/current/scm/lily-library.scm:149:5: Wrong
type (expecting exact integer): -1/2
Here's a minimal file to demonstrate the problem:
mode = #`((1 . ,SEMI-FLAT))
\score {
\relative c'' {
\key c \mode
c4
}
\layout { }
\midi { }
}
This example is musical nonsense, but the same construct is
used, for example, in the bayati mode in ly/arabic.ly, and
generates similar errors.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SeparationItem #'padding not working anymore?
Mats
This was changed by committish
3d90d1d4096a6fae5826445cd66e95d25de2110a by
Joe Neeman on 29 Jun 2007. The commit message
says:
use PaperColumns instead of SeparationItems.
It was part of a massive set of changes to the
spacing engine by Joe.
As you say, it looks like a doc change is needed.
Trevor
- Original Message -
From: Mats Bengtsson mats.bengts...@ee.kth.se
To: Lilypond bug bug-lilypond@gnu.org
Sent: Thursday, January 29, 2009 3:31 PM
Subject: SeparationItem #'padding not working anymore?
What happened to the SeparationItem #'padding property? The following
setting
used to give a large gap in version 2.10, but has no impact at all in
2.12.
Regression!?
\relative c'{c d e \once \override Score.SeparationItem #'padding = #30
f }
If there's a good reason that it doesn't work anymore, the corresponding
description in Known issues and warnings of
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Horizontal-spacing-overview#Horizontal-spacing-overview
should be corrected.
/Mats
--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260
Email: mats.bengts...@ee.kth.se
WWW: http://www.s3.kth.se/~mabe
=
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SeparationItem #'padding not working anymore?
Jonathan Kulp wrote Friday, January 30, 2009 6:21 PM
Graham Percival wrote:
Jonathan, this is your job now. Please either update the docs, or
bug the relevant people for more info so that you can update the
docs.
Ok Graham. I've been trying for 20 minutes and can't figure how to use
PaperColumn to change spacing, though. Joe, could you send me a snippet
that shows how to use this?
Me neither. The only thing that seems to affect
note spacing is to override the X-extent of the Stem,
as suggested by Kieren. (Other than messy tricks like
hidden text, slurs, etc. with modified lengths.)
I did find what appears to be a typo at the end of NR 6.8 Difficult
Tweaks:
Note, however, that \override, applied to NoteMusicalPaperColumn and
PaperColumn, still works as expected within \context blocks.
Should this read NonMusicalPaperColumn instead of
NoteMusicalPaperColumn? I don't see the latter in the list of all
graphical objects. If this is the case then I'll make a patch to fix the
typo and send it to Carl.
I'm sure you're right. Please fix this now, although much
of NR 6 is yet to be rewritten.
Trevor
Jon
On Thu, Jan 29, 2009 at 05:28:04PM -, Trevor Daniels wrote:
Mats
This was changed by committish
3d90d1d4096a6fae5826445cd66e95d25de2110a by
Joe Neeman on 29 Jun 2007. The commit message
says:
use PaperColumns instead of SeparationItems.
It was part of a massive set of changes to the
spacing engine by Joe.
As you say, it looks like a doc change is needed.
Trevor
- Original Message - From: Mats Bengtsson
mats.bengts...@ee.kth.se
To: Lilypond bug bug-lilypond@gnu.org
Sent: Thursday, January 29, 2009 3:31 PM
Subject: SeparationItem #'padding not working anymore?
What happened to the SeparationItem #'padding property? The following
setting
used to give a large gap in version 2.10, but has no impact at all in
2.12.
Regression!?
\relative c'{c d e \once \override Score.SeparationItem #'padding = #30
f }
If there's a good reason that it doesn't work anymore, the
corresponding
description in Known issues and warnings of
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Horizontal-spacing-overview#Horizontal-spacing-overview
should be corrected.
/Mats
--
Jonathan Kulp
http://www.jonathankulp.com
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: docs: Stems info in Editorial annotations section?
Valentin Villenave wrote Sunday, January 11, 2009 2:44 PM 2008/12/7 Mark Polesky markpole...@yahoo.com: NR 1.7.1 Editorial annotations: Inside the staff (strangely) contains the info on stems directions. It makes sense to me (strangely). How are stem directions related to editorial annotations? I think the Stem entry would be better placed either in 1.2 Rhythms or 1.5.2 Simultaneous notes: Multiple voices. That should be mentioned as a link. Trevor, thoughts? Hi Valentin I'm still catching up with my old in-tray I agree. The direction of the stem has nothing to do with the rhythm but I'll add Stems to the See also lists in 1.2.1 Durations. It does have more to do with separating voices, but this is usually set automatically by other commands. The _manual_ setting of the stem direction _is_ an editorial decision, so the current placement seems right to me. I'll add a link in the See also list in 1.5.2 Single-staff polyphony too, though. I'll also move the index entry for stem, direction to the top of the Stem section. Cheers, Valentin Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Crash: Midi and Instrument_name_engraver in StaffGroup (was Re: TAB question -- frescobaldi tab support)
This looks like a bug. An attempt to add the
Instrument_name_engraver to a StaffGroup context *and* produce MIDI
output causes a Crash under Vista. Doing either separately is fine.
Here's a minimal example:
\version 2.12.2
\score {
\new StaffGroup \with { \consists Instrument_name_engraver }
a'
\midi { }
}
Trevor
- Original Message -
From: Grammostola Rosea rosea.grammost...@gmail.com
To: lilypond-u...@gnu.org
Cc: Wilbert Berendsen i...@wilbertberendsen.nl
Sent: Tuesday, February 17, 2009 10:07 PM
Subject: Re: TAB question -- frescobaldi tab support
Daniel Hulme wrote:
On Tue, Feb 17, 2009 at 10:25:19PM +0100, Grammostola Rosea
wrote:
My default Debian lenny version, works ok. But how do I install
the newest lilypond on Debian testing?
When I install the sh script, it doesn't work properly.
In what way? Please give any error messages.
I think there is a bug here!? Or a fault in the template?
When I comment out this:
%\consists Instrument_name_engraver
%instrumentName = Electrische bas
It runs ok.
\r
\version 2.12.2
\include nederlands.ly
global = {
\key g \minor
\time 4/4
}
electricBass = \relative c {
\global
% Muziek volgt hier.
e,4\4 g\4 a\3 d8\3 c\3 e2\4
}
\score {
\new StaffGroup \with
{
%\consists Instrument_name_engraver
%instrumentName = Electrische bas
}
\new Staff \with {
midiInstrument = electric bass (finger)
} { \clef bass \electricBass }
\new TabStaff \electricBass
\layout { }
\midi {
\context {
\Score
tempoWholesPerMinute = #(ly:make-moment 100 4)
}
}
}
___
lilypond-user mailing list
lilypond-u...@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Crash: Midi and Instrument_name_engraver in StaffGroup (was Re: TAB question -- frescobaldi tab support)
Jonathan Kulp wrote Wednesday, February 18, 2009 12:16 AM
Trevor Daniels wrote:
This looks like a bug. An attempt to add the
Instrument_name_engraver to a StaffGroup context *and* produce
MIDI output causes a Crash under Vista. Doing either separately
is fine. Here's a minimal example:
\version 2.12.2
\score {
\new StaffGroup \with { \consists Instrument_name_engraver }
a'
\midi { }
}
It works if you also put a \layout block:
\version 2.12.2
\score {
\new StaffGroup \with { \consists Instrument_name_engraver }
a'
\midi { }
\layout { }
}
I still get a crash even with the layout block here, i.e. under
Vista SP1.
It also causes a crash with 2.11.57-1.
Maybe it's OS-dependent :( What OS are you using?
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Crash: Midi and Instrument_name_engraver in StaffGroup (was Re: TAB question -- frescobaldi tab support)
Jonathan Kulp wrote Wednesday, February 18, 2009 12:16 PM
Trevor Daniels wrote:
Jonathan Kulp wrote Wednesday, February 18, 2009 12:16 AM
Trevor Daniels wrote:
This looks like a bug. An attempt to add the
Instrument_name_engraver to a StaffGroup context *and* produce
MIDI output causes a Crash under Vista. Doing either
separately is fine. Here's a minimal example:
\version 2.12.2
\score {
\new StaffGroup \with { \consists Instrument_name_engraver }
a'
\midi { }
}
It works if you also put a \layout block:
\version 2.12.2
\score {
\new StaffGroup \with { \consists Instrument_name_engraver }
a'
\midi { }
\layout { }
}
I still get a crash even with the layout block here, i.e. under
Vista SP1.
It also causes a crash with 2.11.57-1.
Maybe it's OS-dependent :( What OS are you using?
Trevor
I'm running Ubuntu 8.04. I'll reboot in Vista and see if it still
works for me...Nope. It crashes in Vista Home Premium, works
under Linux.
That's bad news. OS dependent faults are difficult.
What might be the connection between the Instrument_name_engraver,
a StaffGroup context and MIDI?
FWIW, here's the info about the crash:
Exception Code: c005
Exception Offset: 000b15a6
OS Version: 6.0.6001.2.1.0.768.3
Locale ID: 2057
Additional Information 1: 8157
Additional Information 2: e5c125f1fe4801129baf2589875a8741
Additional Information 3: c78b
Additional Information 4: 010e8fc734af15e2e734bc021cc92ff0
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SeparationItem #'padding not working anymore?
Mats Bengtsson wrote Sunday, March 01, 2009 8:17 AM Quoting Patrick McCarty pnor...@gmail.com: On Sat, Feb 28, 2009 at 6:00 AM, Valentin Villenave v.villen...@gmail.com wrote: 2009/2/2 Joe Neeman joenee...@gmail.com: On Fri, 2009-01-30 at 12:21 -0600, Jonathan Kulp wrote: Ok Graham. I've been trying for 20 minutes and can't figure how to use PaperColumn to change spacing, though. Joe, could you send me a snippet that shows how to use this? This is very embarrassing, I'm just testing the fix: spacing-spanner.cc:306: set_column_rods (cols, 0.1); // FIXME: padding Greetings Joe, where are we now? Does this SeparationItem thingy deserve an issue in the tracker? I don't think it deserves an issue. We have two options: 1) Remove SeparationItem from LilyPond's source (scm/define-grobs.scm). Then we would need a convert-ly rule. 2) Keep SeparationItem, even though it is never used. I guess it all depends on whether SeparationItem will ever be used again in the future. The main thing is that the documentation is modified to show a solution that works, i.e. that gives the same result as you previously could obtain setting SeparationItem #'padding = ... Yes, we're waiting for Joe to complete his fix so we can use 'spacing-spanner in the docs. At present no one has found a way to make it work. Or has this been fixed silently? Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SeparationItem #'padding not working anymore?
Thanks Jon. Pushed to git. Trevor - Original Message - From: Jonathan Kulp jonlancek...@gmail.com To: Graham Percival gra...@percival-music.ca Cc: Joe Neeman joenee...@gmail.com; Lilypond bug bug-lilypond@gnu.org; Mats Bengtsson mats.bengts...@ee.kth.se Sent: Sunday, March 01, 2009 2:51 PM Subject: Re: SeparationItem #'padding not working anymore? Patch attached. Jon On Sun, Mar 1, 2009 at 8:11 AM, Graham Percival gra...@percival-music.cawrote: On Sun, Mar 01, 2009 at 07:24:53AM -0600, Jonathan Kulp wrote: 2. Doc policy discourages (forbids?) the use of @example, which is currently how this issue is addressed in NR 4.5.1 known issues and warnings. It would be easy enough to change the @example currently there to show the NonMusicalPaperColumn override, but this would perpetuate a breach of doc policy. Go ahead and keep the @example; NR 4 still needs to start its rewrite. This goes for anything else you see in NR 3 and upwards... I don't see this situation changing until the summer. Cheers, - Graham -- Jonathan Kulp http://www.jonathankulp.com ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: SeparationItem #'padding not working anymore?
Joe Neeman wrote Sunday, March 01, 2009 7:27 PM On Sun, 2009-03-01 at 15:38 +, Trevor Daniels wrote: Mats Bengtsson wrote Sunday, March 01, 2009 8:17 AM Quoting Patrick McCarty pnor...@gmail.com: On Sat, Feb 28, 2009 at 6:00 AM, Valentin Villenave v.villen...@gmail.com wrote: 2009/2/2 Joe Neeman joenee...@gmail.com: On Fri, 2009-01-30 at 12:21 -0600, Jonathan Kulp wrote: Ok Graham. I've been trying for 20 minutes and can't figure how to use PaperColumn to change spacing, though. Joe, could you send me a snippet that shows how to use this? This is very embarrassing, I'm just testing the fix: spacing-spanner.cc:306: set_column_rods (cols, 0.1); // FIXME: padding Greetings Joe, where are we now? Does this SeparationItem thingy deserve an issue in the tracker? I don't think it deserves an issue. We have two options: 1) Remove SeparationItem from LilyPond's source (scm/define-grobs.scm). Then we would need a convert-ly rule. 2) Keep SeparationItem, even though it is never used. I guess it all depends on whether SeparationItem will ever be used again in the future. The main thing is that the documentation is modified to show a solution that works, i.e. that gives the same result as you previously could obtain setting SeparationItem #'padding = ... Yes, we're waiting for Joe to complete his fix so we can use 'spacing-spanner in the docs. At present no one has found a way to make it work. Or has this been fixed silently? I believe it was fixed in 35db77b06dc96ec680668dfb70b17cdc56c5f24f. Does it still fail? No, you're quite right. It works. I must have missed the commit. Jon's already fixed the docs. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: How to chop a slur over a rest in a 1. volta repeat
There's a way, but it's rather messy.
Here's some code to give you a start. Essentially you draw a
coloured box
with \markup, experiment to get the right size, move it into the
right
position, and place it in layer 2 to put it above everything else,
and
then make the box white. If you add this when everything else is
stable
it is just about do-able. One problem is it pushes the volta marks
too
high. Offhand I don't know how to prevent this.
\alternative {
{ r1
% move to right position
-\tweak #'extra-offset #'(-2 . -1.5)
% place in higher layer
-\tweak #'layer #2
^\markup {
% specify color
\with-color #white % start with a visible colour
% specify size
\filled-box #'(0 . 10) #'(0 . 1) #0
}
|
}
- Original Message -
From: Maestraccio maestrac...@gmail.com
To: bug-lilypond@gnu.org
Sent: Friday, March 20, 2009 12:10 AM
Subject: How to chop a slur over a rest in a 1. volta repeat
I'm not top posting.
Recently I stumbled upon this problem and did not find a
satisfying answer
in neither the Documentation segment nor in the archives:
-
\version 2.10.33
\paper{ ragged-right=##t }
\relative c'' {
\repeat volta 2 {
c,2^\markup {tacet la 1 \hspace #-1.5 \raise #1.0 {ma} volta}\p(
b a g4) g'8( f |e4 c d2) |r4 e8( c cis4 a' |
}
\alternative {
{r1 |}
{c,!2 b) |}
}
}
-
Please note the important tacet la 1ma volta line, which
indicates rests
during the first occurrence of this part.
It is a fragment taken from a bigger score and printing the whole
thing twice
(which may seem obvious here) is not a solution.
I experimented with laissezVibrer and repeatTie, but these
commands
really end and rebegin the tie (not even a slur) al niente
(among other
drawbacks) instead of chopping the slur in two at a thick point.
Is there a way of radically ending a slur at a predefined point at
a certain
thickness (and beginning it likewise at the other end) or somehow
interrupting/blanking/hiding the slur over this 1. volta rest?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Limitation with beat grouping
Cameron Horsburgh wrote Monday, March 23, 2009 12:54 AM I've had a problem with some auto beaming, and after some discussion on -user[1] I believe it's a limitation with LilyPond's autobeaming mechanism. Here's my problem: I am setting a piece in 4/4 that has many examples of the figure a8 a a a16 a beginning on either the first or third beats of the bar. The beaming LilyPond gives me is a8[ a a a16 a] when I would prefer a[8 a] a[ a16 a] I had a go at writing a rule to get this behaviour but there doesn't sem to be any way of doing it. This was confirmed by Trevor Daniels in the discussion on -user. This raises two questions: first, what should the default beaming be in this case? I don't see a lot of the one that LilyPond generates, and I find it reasonably hard to sight-read. Most scores I see seem to use the one I am trying to get. Second, the autobeaming mechanism should allow this sort of construct. The problem is that the beaming between the second and third notes depends on the length of the fourth and fifth notes. Or, to quote Trevor, You need some sort of back-tracking so that when the 16th notes were found the beaming was restarted using a different set of rules. I imagine the first issue (if it is an issue) would depend on the second issue being fixed, and I presume that would be a rather difficult problem to solve. Still, if they are legitimate problems I think they rate a mention in the bug tracker. Just to clarify, the problem is to automatically beam the pattern with 16th as a[8 a] a[ a16 a] while _also_ beaming four 8ths as a8[ a a a]. That is, to end the 8th beam after two notes if later on it runs into 16th but to continue otherwise. The first pattern on its own can be done easily now. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Limitation with beat grouping
Hans Aberg wrote Monday, March 23, 2009 8:47 AM On 23 Mar 2009, at 01:54, Cameron Horsburgh wrote: I've had a problem with some auto beaming, and after some discussion on -user[1] I believe it's a limitation with LilyPond's autobeaming mechanism. Here's my problem: I am setting a piece in 4/4 that has many examples of the figure a8 a a a16 a beginning on either the first or third beats of the bar. The beaming LilyPond gives me is a8[ a a a16 a] when I would prefer a[8 a] a[ a16 a] I had a go at writing a rule to get this behaviour but there doesn't sem to be any way of doing it. This was confirmed by Trevor Daniels in the discussion on -user. This raises two questions: first, what should the default beaming be in this case? I don't see a lot of the one that LilyPond generates, and I find it reasonably hard to sight-read. Most scores I see seem to use the one I am trying to get. Hindemith, Elementary Training, p. 18, says that the one you want is more frequent, and that the one LilyPond wants is less frequent though possible. He gives a rule (4) that the two halves of the measure must be recognizable. Second, the autobeaming mechanism should allow this sort of construct. The problem is that the beaming between the second and third notes depends on the length of the fourth and fifth notes. Or, to quote Trevor, You need some sort of back-tracking so that when the 16th notes were found the beaming was restarted using a different set of rules. I am not sure what you mean here. Can you give an example? See my later note The problem, as I see it, is tied to the metric interpretation of 4/4, which is ambiguous: it can be taken as a strong beat (metric accent) on 1 followed by weaker on 2, 3 and 4. Alternatively, 3 can be accented more than 2 and 4, but less that 1: | | | | 4a - - - 4b - () - Then 4a gets the beaming with the 1/4 note groups together and the second gets the beaming with the 1/2 note groups together. If this is the accepted standard then there is no problem with LilyPond as it stands. Either of these two patterns can be specified by overriding the current beam-ending rules. What can't be done is to mix the two stress patterns depending on beam duration. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Limitation with beat grouping
Patrick McCarty Monday, March 23, 2009 11:07 PM
On Mon, Mar 23, 2009 at 2:58 PM, Cameron Horsburgh
ca...@netcall.com.au wrote:
I've also just noticed another thing: the figure
a8 a16 a16 a8 a16 a6
is rendered
a8[ a16 a16] a8[ a16 a6]
which is my preferred option. In fact, I would prefer everything
to be
broken to one beat groups *except* for the special case of four
quavers which can appear as one group. It might be easier to
write a
rule for that and manually beam the four quaver figure which is
far
less common in my score.
I agree. This example highlights the issue very clearly:
\relative c'' {
a16 a a8 a a
a8 a16 a a8 a
a8 a a16 a a8
a8 a a a16 a % beaming is different
}
I agree this behaviour is inconsistent, although it has been this
way for all the 2.12, 2.11 and 2.10 releases and probably several
earlier ones too.
The autobeaming rules have been substantially modified for
2.13 (probably 2.13.1, although the version naming in 2.13
is unclear at the moment). In 4/4 time I've decided to go with
a 4-beat pattern by default, so this particular inconsistency
has been corrected. The main reason for changing the rules
is to permit beatLength and beatGouping to be used in more
cases. For example, to change the default unit in 4/4 time from
quarter note to half note (so four 8th notes are beamed together)
all you will need to do is set beatLength to 1/2.
(It still will not be possible to automatically beam
a8[ a a a] and a8[ a] a[ a16 a] simultaneously, though. That
is a basic limitation of the autobeaming method, not the rules.)
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Chords below and above the staff
Pekka Siponen wrote Tuesday, March 24, 2009 4:24 PM
In the notation reference: 2.7.2 Displaying chords,
is a snippet for a simple lead sheet:
\chords { c2 g:sus4 f e }
\relative c'' {
a4 e c8 e r4
b2 c4( d)
}
\addlyrics { One day this shall be free __ }
Why does the following shift the chords below the staff, and how
can you get
them back up? This would be a welcome documentation subject.
It's because a Staff context cannot contain a Chords context
by default, so the Chords context is pushed below the Staff.
This is mentioned in Section 5.4.2 of the Notation Reference,
but I grant you it's not very easy to find or obvious.
See below for the solution.
\score {
\new Staff {
\chords { c2 g:sus4 f e }
\relative c'' {
a4 e c8 e r4
b2 c4( d)
}
\addlyrics { One day this shall be free __ }
}
}
I can't seem to find a way to get them up in anything more
complicated than the
first example.
Here's how:
\score {
\chords { c2 g:sus4 f e }
\new Staff {
\relative c'' {
a4 e c8 e r4
b2 c4( d)
}
\addlyrics { One day this shall be free __ }
}
}
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: wide-char is wide
Robin Bannister wrote Wednesday, March 25, 2009 12:46 PM Where NR 3.3.3 is talking about \char it says The following example shows UTF-8 coded characters being used which got me typing in a UTF-8 byte pair after the ##x. But, of course, it is more like UTF-32. In fact, referring to UTF-32 would make it easier to google for these high code points. No, the manual is correct. LilyPond uses UTF-8. UTF-8 is a variable-length encoding for Unicode in which the common characters are encoded in 8 bits and the less common in 16, 24 or 32 bits. UTF-32 is an encoding which uses exactly 32 bits for every code point. However, I agree the description of \char in the manual could be clearer. It needs to indicate the hex string is a variable length dependent on the character being encoded. I'll fix it. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: wide-char is wide
Robin Bannister Wednesday, March 25, 2009 4:17 PM Francisco Vila. wrote: the right googleable word is Unicode, do you agree? Well, not fully. When I google for unicode arabic percent I certainly end up at a relevant place http://www.fileformat.info/info/unicode/char/066a/index.htm But I am not done. I need to collect whatever it is \char needs, so I go looking for hexadecimals. There are lots of them in a nice table, and they are not all saying the same thing. This is where UTF-32 could keep me straight. Back to NR 3.3.3 The following example shows UTF-8 coded characters being used My main point was: UTF-8 is wrong. As this is describing the argument to \char you are right. \char takes the hexadecimal number representing the Unicode code point. So the Arabic percent can be x66a, x066a, x00066A, ... When you criticize UTF-32 as a replacement, are you implying that the next word coded is wrong too? If we specify UTF-32 this would imply all the leading zeros need to be expressed. This is not required; any valid hexadecimal representation of the integer is acceptable. If so, I agree. The proper term is Unicode code point (mentioned at the top of 3.3.3) and it is just an integer - no need to constrain how it is represented. (But base 16 and the codespace slicing went hand in hand.) No problem with that. So lets say The following example shows Unicode code points being used OK. I agree UTF-8 here is wrong. And further up, lets use this same term instead of Unicode escape sequence and Unicode hexadecimal code Happy to replace them but I prefer to use Unicode hexadecimal value. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: wide-char is wide
Hans Aberg wrote Wednesday, March 25, 2009 11:23 PM On 25 Mar 2009, at 23:30, Francisco Vila wrote: From your kind explanation would be right to say that the argument to the LilyPond \char command is a simple natural number and not a multibyte utf-8 sequence? This is what --I think-- still has to be made clear. Everything you write out and see as a hexadecimal number on the screen is an ordinary number. In the computer, it is represented as a sequence of bytes from the ASCII set. Anything from UTF-8, if you have an editor capable of handling it, will look as just ordinary characters. The manual says that \char #65 produces the letter A. Here, 65 is an ordinary integer. Which position number basis? The ASCII hexadecimal number for A is 41, in languages like C/C++ written as 0x41, and in Unicode U+0041. What is the decimal number? In decimal, 4*16+1 = 65. What is the representation in the computer? All ASCII characters are translated as binary numbers. Since the hexadecimal form is 41, 0x4 is binary 0100, and 0x1 is binary 0001, 0x41 is binary 0101. So 0x41 is one 8-bit byte. So the manual is a bit short: it should say that the number is a decimal integer representing the Unicode code point. No, the argument to \char is a hex number. Also, since all Unicode tables use hexadecimal numbers, there should be a convenient way to give a hexadecimal number, either as a hexadecimal-to-decimal conversion function, or a new variation of \char (with a different name). Hans Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: wide-char is wide
Hans Aberg wrote Thursday, March 26, 2009 8:57 AM On 26 Mar 2009, at 00:55, Trevor Daniels wrote: The manual says that \char #65 produces the letter A. Here, 65 is an ordinary integer. Which position number basis? The ASCII hexadecimal number for A is 41, in languages like C/C++ written as 0x41, and in Unicode U+0041. What is the decimal number? In decimal, 4*16+1 = 65. What is the representation in the computer? All ASCII characters are translated as binary numbers. Since the hexadecimal form is 41, 0x4 is binary 0100, and 0x1 is binary 0001, 0x41 is binary 0101. So 0x41 is one 8-bit byte. So the manual is a bit short: it should say that the number is a decimal integer representing the Unicode code point. No, the argument to \char is a hex number. No, the argument is an integer: Robin Bannister pointed out that Guile, which LilyPond calls, has syntax for different number basis: http://www.gnu.org/software/guile/manual/html_node/Number-Syntax.html So when you have used it, you probably have written \char #x41 Right? You and Robin are right - you can specify either hex or decimal encodings for the code point in \char. I'll amend the NR (again!) to clarify this. Hans Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lilypond-book is not flavor independent
Graham Percival wrote Thursday, March 26, 2009 1:13 PM Now, I'll admit that we have very few lilypond users on OpenServer and Unicos (WTM is Unicos, anyway?!). A bit off topic, but Unicos is the OS on some high performance computers from Cray Research: http://www.cray.com/home.aspx . Not much good for LilyPond though, as LP wouldn't vectorise or parallelise easily or effectively. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: must 'layer be between 0 and 2?
Mark
If you look up layers in the index to the Notation
Reference you'll find there that it says the layer
property should be set to an integer and most objects
are drawn by default with a value of 0 or 1. Also
the example shown uses a value of -1. Maybe we
ought to change define-grob-properties to reflect
this, though.
Trevor
- Original Message -
From: Mark Polesky markpole...@yahoo.com
To: bug-lilypond bug-lilypond@gnu.org
Sent: Thursday, April 09, 2009 4:09 AM
Subject: must 'layer be between 0 and 2?
define-grob-properties.scm claims 'layer should be
between 0 and 2, but other values clearly work.
Is there any reason why users should avoid other
values? I'm finding it *very* handy to use negative
values, for instance.
Perhaps it should be stated that no grob has a
default value for 'layer below 0 or above 2, but
that the user can set values outside that range.
This way, a user who sets only one 'layer value
over 2 is guaranteed to have that grob print over
everything else.
Is that correct, btw?
- Mark
\version 2.13.0
{
\once \override Staff.Clef #'layer = #-2
\once \override Staff.StaffSymbol #'layer = #0
\once \override Staff.TimeSignature #'layer = #4
\once \override Staff.Stem #'layer = #6
\once \override Staff.Clef #'color = #red
\once \override Staff.TimeSignature #'color = #green
\once \override Staff.Stem #'color = #yellow
c''4
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad character encoding in console output under WinXP
Piero The file which contains this translation string (po/it.po) is encoded (correctly) in UTF-8, in which è is written (correctly) as è. Is it possible your console output is not correctly rendering utf-8-encoded characters? Trevor - Original Message - From: Piero Faustini pierofaust...@hotmail.com To: bug-lilypond@gnu.org Sent: Saturday, April 11, 2009 8:30 AM Subject: Bad character encoding in console output under WinXP Hello, I use lilypond in WinXP. The italian console output, when I launch the program, is wrong encoded. E.G.: L'output MIDI è inviato a midifile instead of L'output MIDI è inviato a midifile (MIDI output has been sent to midifile) I can't remember if it has always been like this, sure it's since v. 2.10.5x This of course doesn't affect at all the functionality of the program (as I can guess) but if it could not be a source of problem, it sure is not nice, expecially for the average new WinXP italian/non-english user, already scared by the non-GUI interface. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad character encoding in console output under WinXP
Valentin Villenave Saturday, April 11, 2009 9:10 AM 2009/4/11 Trevor Daniels t.dani...@treda.co.uk: The file which contains this translation string (po/it.po) is encoded (correctly) in UTF-8, in which è is written (correctly) as è. Is it possible your console output is not correctly rendering utf-8-encoded characters? IIRC that's a known issue with Windows console codepages. Using LilyPond on a French Windows is a nightmare wrt accented chars :-) Actually this may be a LilyPond issue. I notice on my system (Vista) that these po files are rendered correctly when viewed with gitk or a utf-8-aware editor like NotePad, but not by, for example, the ConTEXT editor, which is not utf-8 capable. This suggests it is the responsibility of the application to correctly render utf-8 characters. If this is correct, it is a LilyPond bug. Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: midi2ly.py v2.12.2
Eluze Seems ok here, maybe your file somehow got corrupted. There were no significant changes to midi2ly.py between these two releases (a few lines to do with copyright were changed, but no 'big block of lines' was moved) so using the older version should be fine if that works for you. Trevor - Original Message - From: -Eluze elu...@gmail.com To: bug-lilypond@gnu.org Sent: Tuesday, April 14, 2009 11:32 PM Subject: midi2ly.py v2.12.2 using *midi2ly.py* without arguments, - with v2.11.65 i get a list of options - with v2.12.2 an error is dispayed using it with a file name as argument, - 2.11.65 converts - 2.12.2 issues errors comparing the two python-files one can see a big block of lines having been moved from the original location! -- View this message in context: http://www.nabble.com/midi2ly.py-v2.12.2-tp23049320p23049320.html Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \set stanza = needs a blank
-Eluze wrote Wednesday, June 10, 2009 1:29 PM
i just had the a cross experience with this code:
\context Voice = melody { c'}
\context Lyrics \lyricsto melody \lyricmode { \set
stanza=#1. hi }
}
resulting in errors:
Fehler: Grob-Name sollte alphanumerisch sein
\context Lyrics \lyricsto melody \lyricmode { \set
stanza=#1. hi }
Fehler: syntax error, unexpected UNSIGNED, expecting '='
\context Lyrics \lyricsto melody \lyricmode { \set stanza=#
1. hi }
it's easy to fix the code ( just adding a blank or a tab after
stanza )
but actually i think Lilypond should handle this, shouldn't it?!
Not in lyricmode. Although this particular circumstance
is not mentioned in the docs, section 2.1.2 of the Notation
Reference, under Lyrics explained, says that spaces are
needed in lyricmode before a terminating } and around
the elements of property commands. That section also
explains why this is.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Are cross-staff beams and 'remove-empty *really* not compatible?
Valentin Villenave wrote Wednesday, January 07, 2009 12:21 AM
Greetings,
NR1.2.4 says:
Known issues and warnings
Automatically kneed cross-staff beams cannot be used together with
hidden staves.
Why?
The following piece of code works well (and if you uncomment the
last
line, an ugly #76 collision happens)
\layout {
\context {
\Staff
\remove Axis_group_engraver
\consists Hara_kiri_engraver
%\override Beam #'auto-knee-gap = #'()
\override VerticalAxisGroup #'remove-empty = ##t
}
}
I can't see why the warning is there either. I've tried various
combinations and all seem to work perfectly. The wording of
the warning has changed several times over the years. It was
originally added by Han-Wen on 10 June 2002 (!) as,
Auto knee beams can not be used together with hara kiri staffs.
So much has changed since 2002 that it is quite likely this
restriction no longer applies. I'll remove it from the docs
unless someone shouts quickly.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Crash: Midi and Instrument_name_engraver in StaffGroup (was Re: TAB question -- frescobaldi tab support)
Valentin Villenave wrote Thursday, July 16, 2009 2:26 PM
2009/2/18 Trevor Daniels t.dani...@treda.co.uk:
This looks like a bug. An attempt to add the
Instrument_name_engraver to a
StaffGroup context *and* produce MIDI output causes a Crash under
Vista.
Doing either separately is fine. Here's a minimal example:
\version 2.12.2
\score {
\new StaffGroup \with { \consists Instrument_name_engraver }
a'
\midi { }
}
Greetings Trevor,
I have unfortunately let this untracked for a while... Can you
test
this piece of code again with a more recent Lily build, and tell
me if
it still causes LilyPond to crash? (If so, I'll finally add it to
the
tracker.)
Hi Valentin
It fails in the same way in both 2.13.2-0 and 2.13.3-0 under Vista,
with a crash - exception code c005.
Incidentally the Application Version number in the error report
appears not to have been bumped - it reports 2.13.1.1.
Could you check if it also crashes under unix?
Trevor
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Strange bug with \addlyrics
Francisco Vila Friday, August 07, 2009 10:08 AM
2009/8/7 Benjamin Kwong benjamin.kw...@mail.mcgill.ca:
The following produces weird behavior with the use of \addlyrics
over barlines.
\version 2.13.3
\relative c' { { { a4 a a a | a } \addlyrics { a a a a } d d d
| f f f f } \\
{ c,1 c c } }
\relative c' { { { a4 a a a | a } \addlyrics { a a a a a } d d
d | f f f f }
\\ { c,1 c c } }
with
\addlyrics { a8 a a a a }
we see that the subsequent 'd d d' inherit the rhythms of the
lyrics.
So maybe addlyrics is not well intended to be inside a polyphonic
construct like this.
Putting the lyrics outside they behave well.
\relative c' { { \new Voice=one { a4 a a a | a } d d d | f f
f f }
\\ { c,1 c c } }
\new Lyrics \lyricsto one \lyricmode { a a a a a }
But it doesn't need to be polyphonic nor
does it need \addlyrics to go wrong. Nor
it is anything to do with the implicit
creation of contexts. Try:
\version 2.13.3
\relative c' {
\new Staff {
\new Voice = A { a4 a a a | a }
\new Lyrics \lyricsto A \lyricmode {
a a a a a }
\context Voice = A { d d d | f f f f }
}
}
It seems more a problem of timing synchonisation
between lyricmode and notemode. In lyricmode it
seems the last syllable extends to the end of the
second bar, causing the following notes to squash
up until the notemode timing catches up.
The ordering is unusual, but it does seem like a
bug.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Regression: spacing single full-bar notes with ragged-right=##f
The positioning of a single note which
occupies a bar fully is not correct if
ragged-right = ##f.
The following example illustrates the problem.
\layout { ragged-right = ##f }
\relative a' {
a1 a a
\break
a a a
\break
\time 2/4
a2 a a
\break
a
\time 1/4
a4 a
}
This is a regression from 2.10. Both 2.13
and 2.12 show the problem, but 2.10.33 does not.
It appears the regression was introduced between
2.11.9 and 2.11.10. pngs of this example generated
with these two releases are attached. There are
several commits which modify spacing between these
two tags, but as I can't compile LilyPond I can't
narrow this down any further.
Trevor
attachment: 2.11.9.pngattachment: 2.11.10.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Regression: spacing single full-bar notes with ragged-right=##f
Neil Puttock wrote Tuesday, August 25, 2009 9:17 PM 2009/8/25 Trevor Daniels t.dani...@treda.co.uk: This is a regression from 2.10. Both 2.13 and 2.12 show the problem, but 2.10.33 does not. Are you sure? I think it's covered by this news entry for 2.12: `Notes or rests, such as a typical end note, that fill an entire measure are preceded by some more space.' If the spacing is stretched, then the extra space is going to be much more noticeable. I'd forgotten that news item, but the extra space seems to be too large. I've checked the scores of three publishers and all of them position a single note in a bar close to the left bar line. One of the LilyPond examples I showed positioned the note almost in the centre of the measure - surely that cannot be correct. Furthermore, the positioning in the first measure of every line is different to the rest of the measures on the line. The first bar is correct, I believe, but surely the positioning should be consistent. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Regression: spacing single full-bar notes with ragged-right=##f
Neil Puttock wrote Thursday, August 27, 2009 10:21 PM 2009/8/25 Trevor Daniels t.dani...@treda.co.uk: I'd forgotten that news item, but the extra space seems to be too large. I've checked the scores of three publishers and all of them position a single note in a bar close to the left bar line. One of the LilyPond examples I showed positioned the note almost in the centre of the measure - surely that cannot be correct. Hmm, with current git, the first 1/4 bar is even worse: the crotchet is positioned in the last third of the bar's width; furthermore, it's not possible to correct this by overriding 'full-measure-extra-space unless you use negative values. The default value for 'full-measure-spacing-width appears to be just the default value for the distance property of a Spring object, which is 1, so setting 'full-measure-extra-space to -1 effectively sets the space added to all but the first bar to 0. This looks like it might be a solution to Werner's original problem, and it also gives a means for reducing the extra space when bars are seriously stretched. I'll explore it a little more. Furthermore, the positioning in the first measure of every line is different to the rest of the measures on the line. The first bar is correct, I believe, but surely the positioning should be consistent. Yes, I've noticed that before; I'm not sure whether that is by design though. Looking in spacing-spanner.cc, it appears that the criterion for the extra space is that the paper column to the left of the SpacingSpanner has a break status of CENTER, which explains why the first bar in each system doesn't get any extra space. OK, thanks for the explanation. There doesn't seem to be anything we can do about this (other than changing the code). Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: cueing bug
Neil Puttock wrote Tuesday, September 08, 2009 11:28 PM 2009/9/8 Trevor Daniels t.dani...@treda.co.uk: John Ervin wrote Tuesday, September 08, 2009 6:05 AM Subject: cueing bug Also, slurring doesn't seem to transfer into the cueing. This would be nice to have. Setting quotedEventTypes should do the trick (there's a snippet demonstrating its use in 1.6.3 Writing parts, `Quoting another voice'). At the risk of duplicating content slightly, I can add another LSR snippet for cues; or perhaps it might be worth generalizing the current example for both sections in 1.6.3. This snippet is a little misleading. By default 'quotedEvent Types is set to (note-event rest-event tie-event beam-event tuplet-span-event), not just (note-event rest-event). Might also be worth saying where the event types are listed (the list of Music classes in the IR seems the best list although it contains some events that are irrelevant to the printed output.) It's already rather long so it might be best to simply say under Formatting cue notes that the music event types transferred into the cue notes are controlled by the quotedEventTypes property as shown in ... Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 865 in lilypond: Enhancement: ancient tablatures support
Comment #1 on issue 865 by Carl.D.Sorensen: Enhancement: ancient tablatures support http://code.google.com/p/lilypond/issues/detail?id=865 There was some discussion about this on the -devel website some time ago with Dana Emery, but I'm not sure anything useful came of it. http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00085.html Well, it contained a lot of useful information, even if the discussion was a little divergent! And you mapped out the way to go: develop the output form first, using standard LP tab syntax, extended if necessary, then develop an input mechanism suitable for users who are not familiar with staff, based on tab-like notation. This could be either a separate program, as you suggested, or a new input mode. We already have chordmode, drummode, figuremode, lyricmode, and markup mode, all with a syntax different from notemode, so adding tabmode would not be impossible. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: automatic accidental style voice: too many written accidentals
Frédéric Bron wrote Sunday, October 25, 2009 6:45 PM
Here is my first post:
In voice style, when switching from one voice to two voices, the
program writes too much accidentals.
This example demonstrates the problem (2.12.2 and 2.13.6): the
second
bes should not have a written flat.
\relative c'' {
#(set-accidental-style 'voice)
\key f \major
bes1
{ bes } \\ { g }
}
This is not a bug. The two voices in the \\ construct are
distinct from the main voice. This is explained in the Learning
Manual in section 3.2.1. You have requested accidentals
to be cancelled only within a voice, and the second bes is in
a different voice to the first bes, so it should be given an
accidental.
The default accidental style will behave as you expect as this
cancels accidentals for all voices within a staff.
That probably explains why it wasn't added to the bug tracker
the first time around.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: automatic accidental style voice: too many written accidentals
Frédéric Bron wrote Monday, October 26, 2009 6:30 AM
Here it is not an accidental cancelation, it is just printing the
accidentals from the key!
I consider this as a bug because the new voices should inherit the
key
from the Staff context as it is what's the musician think. No
musician will say: warning this is a new voice, foget what's on
the
key!). Look at that new example:
\relative c'' {
#(set-accidental-style 'voice)
\key f \major
a1
{ b } \\ { g }
}
The b is this time natural but it has no natural sign. How a
musician can imagine that is is not a b flat?
This behaviour with an accidental style of 'voice is certainly
unexpected! The question is, should the accidental style of
'voice affect just cancellations or should it give every voice an
independent key? If the former, then there is indeed a bug. If the
latter, then the manual needs to explain it. At presently coded,
an accidental style of 'voice gives every voice an independent
key, so is this intended?
Seems to me Frédéric is right - this is a bug. What are others'
views?
Trevor
Frédéric
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: wrong beaming of dotted 8th followed by 8ths
Valentin Villenave wrote Thursday, October 29, 2009 10:32 AM On Sat, Oct 3, 2009 at 12:41 AM, luis jure l...@internet.com.uy wrote: Hi Luis, sorry for the delay, % this shows the default beaming and how it should be beamed r16 c8. c8 c r16 c8. c8[ c] | I'm not sure what to do. The first half of the measure does look ugly indeed (see attached), but I can't decide whether it's a bug or not. Trevor, what would you do? (I'm asking you because beaming is kind of your speciality now, isn't it? ;-) Not really; Carl developed all the new beaming code. But if you really want my opinion I believe this should be classed as an enhancement, namely to take rests into account when determining the shortest note in the beaming interval. It should be a switchable option to preserve the current behaviour and to accommodate both preferences, as I don't believe there is a generally accepted rule here. Bug 638 is related, as solutions to that and this require a different approach to beaming - one which assesses the duration of notes (and rests) within a whole bar before selecting the most appropriate beaming for that bar. Valentin Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Regression: spacing single full-bar notes with ragged-right=##f
Valentin, you wrote Thursday, October 29, 2009 9:27 AM On Fri, Aug 28, 2009 at 11:41 PM, Trevor Daniels t.dani...@treda.co.uk wrote: Greetings Trevor and Neil, sorry for bumping this so late: The default value for 'full-measure-spacing-width appears to be just the default value for the distance property of a Spring object, which is 1, so setting 'full-measure-extra-space to -1 effectively sets the space added to all but the first bar to 0. This looks like it might be a solution to Werner's original problem, and it also gives a means for reducing the extra space when bars are seriously stretched. I'll explore it a little more. Have you had another look at this issue? The output is still meh with 2.13.6 :-) I honestly can't remember whether I looked at it further or not. But as I don't seem to have posted any more about it I guess I didn't. Or maybe I did but discovered nothing more. We were not sure why this extra space had been added, so were reluctant to remove it (is that right, Neil?) The effect of it on a bar containing a single note is clearly wrong, so I think it should be added to the tracker as a bug. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 818 in lilypond: Bus error when addingInstrument_name_engraver to StaffGroup and outputting MIDI.
Note this error occurs only on Windows and Macs. I just tried the minimal example again on Windows Vista and it still crashes: Problem signature: Problem Event Name: APPCRASH Application Name: lilypond.exe Application Version: 2.13.6.1 Application Timestamp: 4adf3175 Fault Module Name: lilypond.exe Fault Module Version: 2.13.6.1 Fault Module Timestamp: 4adf3175 Exception Code: c005 Exception Offset: 000b0fa6 OS Version: 6.0.6001.2.1.0.768.3 Locale ID: 2057 Additional Information 1: 74de Additional Information 2: 0174e7c8daf8e23884ae775d54430d12 Additional Information 3: 69b6 Additional Information 4: 38b850dcdd1169b3963c1a1b399c00cb Trevor - Original Message - From: lilyp...@googlecode.com To: bug-lilypond@gnu.org Sent: Friday, November 27, 2009 11:24 PM Subject: Re: Issue 818 in lilypond: Bus error when addingInstrument_name_engraver to StaffGroup and outputting MIDI. Updates: Status: Invalid Comment #4 on issue 818 by jameseli...@googlemail.com: Bus error when adding Instrument_name_engraver to StaffGroup and outputting MIDI. http://code.google.com/p/lilypond/issues/detail?id=818 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 818 in lilypond: Bus error when addingInstrument_name_engraver to StaffGroup and outputting MIDI.
Graham Percival wrote Friday, November 27, 2009 11:53 PM Interesting. I'm pretty certain that James is using OSX, so that's not at play... but perhaps it was fixed after 2.13.6? Is the Application Version string correct (are you using 2.13.6), or is there some problem with GUB (i.e. you're using 2.13.8, but gub hasn't updated the appstring) I used 2.13.6, the latest version I had downloaded. I'll download a more recent one and try again. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 818 in lilypond: Bus error whenaddingInstrument_name_engraver to StaffGroup and outputting MIDI.
Trevor Daniels wrote Saturday, November 28, 2009 12:14 AM Graham Percival wrote Friday, November 27, 2009 11:53 PM Interesting. I'm pretty certain that James is using OSX, so that's not at play... but perhaps it was fixed after 2.13.6? Is the Application Version string correct (are you using 2.13.6), or is there some problem with GUB (i.e. you're using 2.13.8, but gub hasn't updated the appstring) I used 2.13.6, the latest version I had downloaded. I'll download a more recent one and try again. Fails the same way with 2.13.8 under Vista here: Problem signature: Problem Event Name: APPCRASH Application Name: lilypond.exe Application Version: 2.13.8.1 Application Timestamp: 4b09985a Fault Module Name: lilypond.exe Fault Module Version: 2.13.8.1 Fault Module Timestamp: 4b09985a Exception Code: c005 Exception Offset: 000b1066 OS Version: 6.0.6001.2.1.0.768.3 Locale ID: 2057 Additional Information 1: 74de Additional Information 2: 0174e7c8daf8e23884ae775d54430d12 Additional Information 3: c86c Additional Information 4: 78468be3bf716a1e9cef72771d571d69 Can anyone else confirm? Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Uneven empty measures
Francisco Vila wrote Sunday, November 29, 2009 8:20 PM
I can not find something similar in open issues. It seems that
lines
filled with spacing or multimeasure rests or give a first measure
wider than the others, in each line:
\version 2.13.8
{ \time 6/8
R2.*3 \break
R2.*4 \break
R2.*5
}
It would be a regression as 2.12 did not show it; also with notes
instead of spacing or multimeasure rests do not make the bug to
arise.
This might be related to 899, although I haven't
looked at it in detail.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
