Re: set-octavation after clefchange

Thanks, entered as http://code.google.com/p/lilypond/issues/detail?id=336 Cheers, - Graham Wolfgang Suppan wrote: I'm not top posting. %%%start % octavation -> clefchange -> octavation: % position of the pitches is wrong % all pitches are c' \version "2.10.20" \paper{ ragged-right=##t } \

Issue 336 in project lilypond

Issue 336: octavation, change clef produces incorrect note positions http://code.google.com/p/lilypond/issues/detail?id=336 New issue report by gpermus: \version "2.10.20" \paper{ ragged-right=##t } \relative c' { \clef "bass" c1 #(set-octavation 1) c #(se

Issue 335 in project lilypond

Issue 335: extender passes beginning of second node http://code.google.com/p/lilypond/issues/detail?id=335 New issue report by gpermus: % the lyric extender is too long; it should end before the second note. \version "2.11.19" << \relative c'' { a2 b } \addlyrics { one __ } >> Attachments:

Re: how to set staff size in safe mode

Thanks, added as http://code.google.com/p/lilypond/issues/detail?id=334 Cheers, - Graham Mats Bengtsson wrote: This seems like a bug, so I forward it to bug-lilypond. For example, #(set-global-staff-size 16) {c' d' e' f'} works without problems in version 2.8 but fails with the error message

Issue 334 in project lilypond

Issue 334: setting staff size not longer safe http://code.google.com/p/lilypond/issues/detail?id=334 New issue report by gpermus: tsubasa:~/tmp gperciva$ lilypond -dsafe foo.ly GNU LilyPond 2.11.20 Processing `foo.ly' Parsing... foo.ly:2:1: error: GUILE signaled an error for the expression beginni

Re: Weird tie behaviour when changing Tie_engraver context

2007/3/14, Graham Percival <[EMAIL PROTECTED]>: Yes. Solution: don't move the tie engraver around. Why did you want to move it, anyway? If it was to avoid some bug, it would probably be easier just to fix that bug. Well, It's useful for notating guitar music. There isn't any other way I kno

Re: Arpeggio between voices doesnt respect the arpeggio direction

\arpeggioUp macro only sets the corresponding property in the Voice context, but when you use arpeggios across several voices, the property has to be set in the Staff context instead. Thanks Mats, as always :-) I leave as an exercise for the reader to figure out the corresponding definition of

Fwd: Weird tie behaviour when changing Tie_engraver context

If you move the tie engraver from voice to staff, how is lilypond supposed to know which voice a tie applies to? Of course every note in the staff will be tied! This is not a bug. But one thing is when you create a tie, then it will tied to the next note of any voice, and different thing is th

Re: Arpeggio between voices doesnt respect the arpeggio direction

It's not a bug! The default implementation of the \arpeggioUp macro only sets the corresponding property in the Voice context, but when you use arpeggios across several voices, the property has to be set in the Staff context instead. Just add the following redefinition of the \arpeggioUp macro at

Issue 282 in project lilypond

Issue 282: tuplet bracket printed over the wrong staff http://code.google.com/p/lilypond/issues/detail?id=282 Comment #3 by joeneeman: I think this is not a cross-staff issue but a slur scoring issue. If you override the Slur details to be `((debug-slur-scoring . ,#t)) then you get a "programmin

Re: Weird tie behaviour when changing Tie_engraver context

José Luis Cruz wrote: I was very happy because of finding a way to make ties between voices, simply changing the context of Tie_engraver from Voice to Staff. But I've found a non desired consecuence of that. > Look at the example I provide. There are 2 voices. If I tie the first one, ties are c

Re: Arpeggio between voices doesnt respect the arpeggio direction

Please send a minimal example; see http://lilypond.org/web/devel/participating/bugs for hints. Cheers, - Graham José Luis Cruz wrote: Ok, I think this is a bug. I've just learned how to make an arpeggio crossing voices (thanks Mat), the problem is that I want arpeggios with arrow and when I

Weird tie behaviour when changing Tie_engraver context

I was very happy because of finding a way to make ties between voices, simply changing the context of Tie_engraver from Voice to Staff. But I've found a non desired consecuence of that. Look at the example I provide. There are 2 voices. If I tie the first one, ties are created also in the second

Arpeggio between voices doesnt respect the arpeggio direction

Ok, I think this is a bug. I've just learned how to make an arpeggio crossing voices (thanks Mat), the problem is that I want arpeggios with arrow and when I say to connect the arpegios, it's converted to a neutral one. %%% START CODE %%% \new Staff \with {\consists "Span_arpeggio_engraver"} {

Staff lines not drawn when line breaking algorithm fails

If the line-breaking algorithm fails to find a good place to break a line, so that notes fall off the right edge of the page, the staff lines are not drawn, making it difficult to read the notes that *are* printed. This makes debugging note entry for rhythmically complex polyphony more difficult