Re: 2/4 not before repeat line in incipit to `Repeats'
On 8 Aug 2009, at 15:41, Valentin Villenave wrote: Er, I got lost in the discussion. Could you sum up your report (possibly with a picture)? The default rule is really that one should have a minimum number of time signatures if the repeat construct is expanded*). An alternative way to put it: if one reads the music as it is performed, one should not encounter unneeded time signatures (with the exception below). To make this possible, the bars in :||: may have to be separated and the time signature written between these lines. In addition, if the meter change appears on the first measure of the staff lines, eventual staff lines immediately before at the end has the time signature written there as well (a duplicate), with no bar | following it**). This seems to be the default, but might be an option. *) The example in Hindemith, "Elementary training", p. 50(c), shows that it is not necessary to have a time signature before the |: if it is necessary to have one after because of a meter change within the repeats. So, for example in: 3/4 ... |: 4/4 ... | 3/4 ... :| there is no need to add an extra 4/4 before the |:. **) Like this: 3/4 ... | ... |4/4 4/4 | . | Hans ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2/4 not before repeat line in incipit to `Repeats'
>> Er, I got lost in the discussion. Could you sum up your report >> (possibly with a picture)? > > Meter changes should occur before an opening repeat sign. If there > is a closing one immediately adjacently, opening and closing one are > placed apart, and the meter change in between. I've sent an image to the list earlier in this thread. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
lyric extender problem
[I'm sitting in a train, walking over notation.pdf -- I currently can't look up the bug database. In case this problem is already reported please ignore this mail.] The attached image is taken from notation.pdf, subsection `Multiple notes to one syllable'; the bug IMHO is that the extender line is too short. Similar to `-- _ _' (with respect to the length), `__ _ _ _' should construct an extender line up to the `e'. Werner <>___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Ghostscript fails with special characters in filename
On Sat, Aug 08, 2009 at 03:45:25PM +0200, Valentin Villenave wrote: > 2009/8/4 Harmath Dénes : > > No. It otherwise works perfectly on an Intel Mac. It only fails always with > > the mentioned characters. (Strangely, similar special characters, like ű or > > ê, work). > > Could you run lilypond --verbose on your file? That still looks a lot > like #811; perhaps I'll Fwd it to the ghostscript team. Also note that Ghostscript 8.70 has been released, which I am currently using. Maybe 8.70 final has fixed the problem, as I can't seem to reproduce this problem here... -Patrick ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2/4 not before repeat line in incipit to `Repeats'
Valentin Villenave writes: > 2009/8/8 Werner LEMBERG : >> Yes. By default, a meter change should be positioned before the >> repetition sign. >> >> This should be added to the bug tracker... > > Er, I got lost in the discussion. Could you sum up your report > (possibly with a picture)? Meter changes should occur before an opening repeat sign. If there is a closing one immediately adjacently, opening and closing one are placed apart, and the meter change in between. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Ghostscript fails with special characters in filename
2009/8/4 Harmath Dénes : > No. It otherwise works perfectly on an Intel Mac. It only fails always with > the mentioned characters. (Strangely, similar special characters, like ű or > ê, work). Could you run lilypond --verbose on your file? That still looks a lot like #811; perhaps I'll Fwd it to the ghostscript team. > Is there a workaround for this (e.g. a command-line option to use ps2pdf > instead of gs)? There should be IMO (see the discussion on the tracker page). But we don't have the resources to implement it right now. Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2/4 not before repeat line in incipit to `Repeats'
2009/8/8 Werner LEMBERG : > Yes. By default, a meter change should be positioned before the > repetition sign. > > This should be added to the bug tracker... Er, I got lost in the discussion. Could you sum up your report (possibly with a picture)? Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 827 in lilypond: Tuplet brackets should be continued after a line break
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Priority-Low Engraving-nitpick
New issue 827 by v.villenave: Tuplet brackets should be continued after a
line break
http://code.google.com/p/lilypond/issues/detail?id=827
As shown below (LSR #406), the tuplet bracket is not reprinted after a line
break (only the TupletNumber).
\version "2.13.3"
\layout {
\context {
\Voice
% Permit line breaks within tuplets
\remove "Forbid_line_break_engraver"
% Allow beams to be broken at line breaks
\override Beam #'breakable = ##t
}
}
\relative c'' {
a8
\repeat unfold 5 { \times 2/3 { c[ b a] } }
% Insert a manual line break within a tuplet
\times 2/3 { c[ b \bar "" \break a] }
\repeat unfold 5 { \times 2/3 { c[ b a] } }
c8
}
--
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
Re: broken tuplet lacks continuation bracket
2009/8/5 Werner LEMBERG : > (see section 1.2.1), shows IMHO a problem: The tuplet bracket isn't > continued after the line break to `finish' the tuplet. Looks like a > bug... Thanks, added as http://code.google.com/p/lilypond/issues/detail?id=827 Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \fermataMarkups should flip when below staff
2009/7/31 gnomino : > I think this would be a useful modification of the \fermataMarkup command. Thanks, applied: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=f924264773699f778097efc9b5869f530179466a Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: missing `arrow down' glyph in PDF
2009/8/8 Werner LEMBERG :
> I suggest to replace this with
> \mark \markup { \char ##x2193 }
OK, done.
Regards,
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
missing `arrow down' glyph in PDF
The snippet
aligning-marks-with-various-notation-objects.ly
uses U+2193, the `arrow-down' character. Unfortunately, this is not
available as a real glyph in PDF output due to limitations of the
glyph repertoire of the CM fonts used by texinfo. In the PDF, you now
see
\mark ""
instead of the correct
\mark "↓"
I suggest to replace this with
\mark \markup { \char ##x2193 }
to fix it.
Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 826 in lilypond: Wrong bounding box for \longa glyph
Status: Accepted Owner: v.villenave CC: lemzwerg Labels: Type-Defect Priority-Medium New issue 826 by v.villenave: Wrong bounding box for \longa glyph http://code.google.com/p/lilypond/issues/detail?id=826 As demonstrated by the attached skyline, the longa's stem is currently not taken into account. Patrick said: " The root problem lies in various bounding-box calculations in the Metafont code (search for `set_char_box'). The Parmesan font glyphs (the \longa glyph is one example) often use symmetrical lengths for their Y-extent -- for example, #(-0.5 . 0.5). This sometimes seems appropriate, but it often seems inaccurate. " The whole discussion is to be found at http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00240.html Attachments: longa-skyline.png 10.7 KB -- 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
Re: lilypond-book turns longas below the staff into breves
2009/8/7 Werner LEMBERG : > > This is not a clue, this is clearly a bug. Not just "a" bug: now the famous #826 bug! :-) http://code.google.com/p/lilypond/issues/detail?id=826 Regards, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
