Successive Lyrics context no longer vertically aligned
Greetings everybody, this has been reported on the -fr list; it does look a lot like #1309 but I'm not entirely sure. % With older versions (e.g. 2.13.28), the % lyrics are printed as a single line. \score { << \new Staff { \new Voice = aa { a1 } \new Voice = bb { b1 } } \new Lyrics \lyricsto "aa" \lyricmode { aa } \new Lyrics \lyricsto "bb" \lyricmode { bb } >> } Cheers, Valentin. <>___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1407 in lilypond: Glyphs with an extra Y-offset are not positioned correctly
Updates: Status: Fixed Labels: fixed_2_13_40 Comment #2 on issue 1407 by pnorcks: Glyphs with an extra Y-offset are not positioned correctly http://code.google.com/p/lilypond/issues/detail?id=1407 (No comment was entered for this change.) Attachments: khmer-fixed.png 1.5 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1396 in lilypond: Enhancement: an option to turn unterminated ties into slurs
Updates: Status: Invalid Comment #5 on issue 1396 by percival.music.ca: Enhancement: an option to turn unterminated ties into slurs http://code.google.com/p/lilypond/issues/detail?id=1396 Since there is no clear need (or even desire) for this, I'm marking it invalid. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1407 in lilypond: Glyphs with an extra Y-offset are not positioned correctly
Comment #1 on issue 1407 by pnorcks: Glyphs with an extra Y-offset are not positioned correctly http://code.google.com/p/lilypond/issues/detail?id=1407 Here is an image of the Khmer syllable with two diacritics offset in the wrong direction. Attachments: khmer-current.png 1.4 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1407 in lilypond: Glyphs with an extra Y-offset are not positioned correctly
Status: Started Owner: pnorcks Labels: Type-Defect Priority-High New issue 1407 by pnorcks: Glyphs with an extra Y-offset are not positioned correctly http://code.google.com/p/lilypond/issues/detail?id=1407 This is taken from a report by Didi, under the heading "Khmer Unicode does not get rendered correctly #3": http://lists.gnu.org/archive/html/bug-lilypond/2010-05/msg00016.html The problem is that Pango and LilyPond do not agree on a Y-axis orientation for glyph offsets. That is, Pango provides the glyph-offset value, and LilyPond shifts the glyph in the wrong direction. For example, one of the wrongly-positioned glyphs is this one (0.0 -0.309423720472441 1.36359832677165 "uni17bb") This specifies that glyph "uni17bb" has a width of 0, extra X offset of -0.31, and extra Y offset of 1.36. Since the backends expect to see a Y-axis with positive values tending to the north, LilyPond offsets the glyph 1.36 units *up*. The correct offset is 1.36 units *down*. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: multiple fret-diagram-x markup commands and lilypond-book safe-mode
Hi Julien, On 2010-11-15, Julien Rioux wrote: > On 15/11/2010 2:59 PM, Patrick McCarty wrote: > >Compiling with debug flags*might* help to narrow down the issue. The > >easiest way to compile without optimization is by running autogen.sh > >like so > > > > ./autogen.sh --disable-optimising > > I have done this now, and get the problem again, with little more > information on screen. Attached is a log of the output on the > terminal. I don't understand this output but hope it might help. Hmm, the only important difference I see in your logs is this: -Wrong type argument in position 1 (expecting module): # +Wrong type argument in position 1 (expecting module): # These types of errors are very similar to those I've been encountering when compiling against the development version of Guile (1.9). I've never seen them with Guile 1.8 though... > Next step is compiling guile, I guess. Yes, I think that would be the best thing to do. Hopefully we will figure this out soon! Thanks, Patrick ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: multiple fret-diagram-x markup commands and lilypond-book safe-mode
On 15/11/2010 2:59 PM, Patrick McCarty wrote: Compiling with debug flags*might* help to narrow down the issue. The easiest way to compile without optimization is by running autogen.sh like so ./autogen.sh --disable-optimising I have done this now, and get the problem again, with little more information on screen. Attached is a log of the output on the terminal. I don't understand this output but hope it might help. Next step is compiling guile, I guess. Thanks, Julien # lilypond-book --safe --output out2 safe-mode-crash.lytex lilypond-book (GNU LilyPond) 2.13.40 Reading safe-mode-crash.lytex... Running latex...This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) restricted \write18 enabled. entering extended mode (/tmp/tmpSsjn4J.tex LaTeX2e <2009/09/24> Babel and hyphenation patterns for english, usenglishmax, dumylang, noh yphenation, french, basque, ngerman, german, german-x-2009-06-19, ngerman-x-200 9-06-19, ukenglish, loaded. (/usr/share/texmf-texlive/tex/latex/base/article.cls Document Class: article 2007/10/19 v1.4h Standard LaTeX document class (/usr/share/texmf-texlive/tex/latex/base/size10.clo)) No file tmpSsjn4J.aux. textwidth=345.0pt columnsep=10.0pt (./tmpSsjn4J.aux) ) No pages of output. Transcript written on tmpSsjn4J.log. Dissecting... Writing snippets... Processing... Running lilypond...GNU LilyPond 2.13.40 Processing `snippet-map-1517400283.ly' Parsing... Processing `safe-mode-crash.lytex' Parsing... Layout output to `ea/lily-d3fe7bea.eps'... Layout output to `ea/lily-d3fe7bea-1.eps'... Writing ea/lily-d3fe7bea-systems.texi... Writing ea/lily-d3fe7bea-systems.tex... Writing ea/lily-d3fe7bea-systems.count... Processing `safe-mode-crash.lytex' Parsing... safe-mode-crash.lytex:12:21: error: GUILE signaled an error for the expression beginning here \fret-diagram-terse # "x;x;o;2;3;2;" Wrong type argument in position 1 (expecting module): # /usr/local/share/lilypond/2.13.40/scm/fret-diagrams.scm:868:17: In procedure string-split in expression (string-split definition-string #\;): /usr/local/share/lilypond/2.13.40/scm/fret-diagrams.scm:868:17: Wrong type argument in position 1 (expecting string): # command failed: /usr/local/bin/lilypond --formats=ps -dbackend=eps -I "/scratch/lilypond-samples" --formats=eps -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir "/home/jrioux/lilypond-samples/out2/snippet-names-1517400283.ly" Child returned 1 ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: multiple fret-diagram-x markup commands and lilypond-book safe-mode
On 2010-11-15, Julien Rioux wrote: > On 13/11/2010 4:51 PM, Patrick McCarty wrote: > > If you want to start again with a pristine git checkout (I don't > > know if this is in the Contributor's Guide yet), the following > > command sequence usually works for me. > > > >make doc-clean > >make distclean > >git clean -f -x > > > > Then proceed with ./autogen.sh , etc. to rebuild. > > > > Let me know if you still have problems after trying this. > > I have done the procedure above to start from a fresh checkout, > compile lilypond and run the same example file I provided in the > beginning of this thread. I get the same error message. Okay, thanks for testing it though. > I would like to help providing more information on the crash if > necessary. Maybe compile with debug flags? Compiling with debug flags *might* help to narrow down the issue. The easiest way to compile without optimization is by running autogen.sh like so ./autogen.sh --disable-optimising That being said, this could be a problem with Guile on Ubuntu. As an additional test, I would try compiling/installing Guile 1.8.7 from scratch to see if this solves the problem. Can you send the output of running `./autogen.sh --disable-optimising' ? It would be nice to compare that with my output. Thanks, Patrick ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: multiple fret-diagram-x markup commands and lilypond-book safe-mode
Hi Patrick, On 15/11/2010 2:59 PM, Patrick McCarty wrote: That being said, this could be a problem with Guile on Ubuntu. As an additional test, I would try compiling/installing Guile 1.8.7 from scratch to see if this solves the problem. I won't try this now, don't have much time. Can you send the output of running `./autogen.sh --disable-optimising' ? It would be nice to compare that with my output. Log attached. I'm recompiling at the moment. Will this give me a more verbose output on the error, or merely a hope that the bug goes away when we turn off optimization? Thanks, Patrick Thanks for your support, Julien processing . Running autoconf ... Running ./configure --disable-optimising ... checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking Package... LILYPOND checking builddir... /home/jrioux/git/lilypond checking for stepmake... ./stepmake (${datarootdir}/stepmake not found) checking for gmake... no checking for make... make checking for find... find checking for tar... tar checking for bash... /bin/bash checking for python... python checking python version... 2.6.6 checking for python... /usr/bin/python checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether compiler understands -pipe... yes checking for IEEE-conformance compiler flags... none checking for fc-list... fc-list checking New Century Schoolbook PFB files... /usr/share/fonts/type1/gsfonts/c059016l.pfb /usr/share/fonts/type1/gsfonts/c059036l.pfb /usr/share/fonts/type1/gsfonts/c059033l.pfb /usr/share/fonts/type1/gsfonts/c059013l.pfb checking for python... /usr/bin/python checking /usr/bin/python version... 2.6.6 checking for /usr/bin/python... /usr/bin/python checking gcc version... 4.4.4 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking g++ version... 4.4.4 checking whether explicit instantiation is needed... no checking for stl.data () method... yes checking for ar... ar checking for ranlib... ranlib checking for dlopen in -ldl... yes checking for dlopen... yes checking for bison... bison -y checking for bison... bison checking bison version... 2.4.1 checking for flex... flex checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking FlexLexer.h usability... yes checking FlexLexer.h presence... yes checking for FlexLexer.h... yes checking for yyFlexLexer.yy_current_buffer... no checking FlexLexer.h location... /usr/include/FlexLexer.h checking language... English checking for gettext in -lintl... no checking for gettext... yes checking for msgfmt... msgfmt checking for mf-nowin... mf-nowin checking for mpost... mpost checking for working metafont mode... ljfour checking for kpsewhich... kpsewhich checking for guile-config... guile-config checking guile-config version... 1.8.7 checking guile compile flags... -pthread checking guile link flags... -pthread -lguile -lltdl -Wl,-Bsymbolic-functions -lgmp -lcrypt -lm -lltdl checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... yes checking for scm_boot_guile... yes checking for scm_t_hash_fold_fn... no checking for scm_t_hash_handle_fn... no checking GUILE rational bugfix... ok checking for python-config... python-config checking Python.h usability... yes checking Python.h presence... yes checking for Python.h... yes checking for gs... gs checking for gs... /usr/bin/gs checking /usr/bin/gs version... 8.71 checking for fontforge... fontforge checking for fontforge... /usr/bin/fontforge checking /usr/bin/fontforge version... 20090923 checking for fontforge... (cached) fontforge checking for fontforge... (cached) /usr/bin/fontforge checking /usr/bin/fontforge version... 20090923 checking for t1asm... t1asm checking for t1asm... /usr/bin/t1asm checking assert.h usability... yes checking assert.h presence... yes checking for assert.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking libio.h usability... yes checking libio.h presence... yes checking for libio.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for
Re: multiple fret-diagram-x markup commands and lilypond-book safe-mode
On 2010-11-15, Julien Rioux wrote: > On 15/11/2010 2:59 PM, Patrick McCarty wrote: > > > Can you send the output of running `./autogen.sh --disable-optimising' ? > > It would be nice to compare that with my output. > > > > Log attached. I'm recompiling at the moment. Will this give me a > more verbose output on the error, or merely a hope that the bug goes > away when we turn off optimization? It might give more verbose output; it's hard to say in this particular case. The last error comes from Guile, but the "GUILE signaled an error for ..." line comes from LilyPond. I don't see any striking differences between your ./autogen.sh output and mine. Thanks, Patrick ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1384 in lilypond: annotate-spacing draws system-system instead of last-bottom
Updates: Status: Fixed Cc: -joeneeman Labels: fixed_2_13_40 Comment #6 on issue 1384 by pnorcks: annotate-spacing draws system-system instead of last-bottom http://code.google.com/p/lilypond/issues/detail?id=1384 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: multiple fret-diagram-x markup commands and lilypond-book safe-mode
On 13/11/2010 4:51 PM, Patrick McCarty wrote: If you want to start again with a pristine git checkout (I don't know if this is in the Contributor's Guide yet), the following command sequence usually works for me. make doc-clean make distclean git clean -f -x Then proceed with ./autogen.sh , etc. to rebuild. Let me know if you still have problems after trying this. I have done the procedure above to start from a fresh checkout, compile lilypond and run the same example file I provided in the beginning of this thread. I get the same error message. I would like to help providing more information on the crash if necessary. Maybe compile with debug flags? Regards, Julien ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1247 in lilypond: Use new modules provided by Guile V2 - Part 1 (ice-9 curried-definitions)
Updates: Labels: Patch Comment #4 on issue 1247 by pnorcks: Use new modules provided by Guile V2 - Part 1 (ice-9 curried-definitions) http://code.google.com/p/lilypond/issues/detail?id=1247 The patch is here: http://codereview.appspot.com/2219044/ ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1384 in lilypond: annotate-spacing draws system-system instead of last-bottom
Updates: Owner: pnorcks Comment #5 on issue 1384 by pnorcks: annotate-spacing draws system-system instead of last-bottom http://code.google.com/p/lilypond/issues/detail?id=1384 Thanks, I'll push this shortly. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1358 in lilypond: run convert-ly on translations
Updates: Status: Fixed Labels: fixed_2_13_40 Comment #7 on issue 1358 by paconet.org: run convert-ly on translations http://code.google.com/p/lilypond/issues/detail?id=1358 Now convert-ly runs on all docs without errors or warnings, in branch lilypond/translation. Closing. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1336 in lilypond: skipTypesetting segfaults when set during a skipBars-induced MultiMeasureRest spanner
Comment #5 on issue 1336 by percival.music.ca: skipTypesetting segfaults when set during a skipBars-induced MultiMeasureRest spanner http://code.google.com/p/lilypond/issues/detail?id=1336 A bit more data: in the crash-case, grob-property.cc internal_get_property() calls internal_get_property_data () with minimum-X-extent, and receives the answer of () I'm guessing that at some other place, it tries to add up these values, and can't handle adding 0.0 and (). I see two options: 1) make Grob::internal_get_property_data (SCM sym) const not return a () when looking up minimum-X-extent in this case. 2) robustify the addition such that it automatically treats () as a 0. I'm guessing that #1 is the preferable option, but I have no real feeling for this stuff. I won't be working on this for another week, so if anybody else wants to jump in now, go right ahead. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \chordmode chords jumping about on PDF
Hello, On 15/11/2010 17:01, James Bailey wrote: http://code.google.com/p/lilypond/issues/detail?id=1353 Should the status be changed? Probably, but not sure if this is a 'bug' or not such that we need an @KNOWNISSUE or not (being that we don't doc bugs). There is nothing explicit in the doc that I can see that would stop a user from running into this again and it looks like it should work, the main question I have is what is this problem if all the windows and linux users never have the problem? It must be OS X specific and so that is why I am wondering if this is something 'buggy' in this environment. regards James ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1382 in lilypond: Segfault when setting 'staff-space to 0.0
Updates: Status: Fixed Labels: fixed_2_13_40 Comment #11 on issue 1382 by Carl.D.Sorensen: Segfault when setting 'staff-space to 0.0 http://code.google.com/p/lilypond/issues/detail?id=1382 Patch is pushed. 11cb980eb068c4d4bcaf20c27f8a0b8eda731c29 ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \chordmode chords jumping about on PDF
On Nov 15, 2010, at 9:41 AM, Dmytro O. Redchuk wrote: > On Mon 18 Oct 2010, 12:37 James wrote: >> Hello > Hello, > >> I am using Mac OSX Snow Leopard (10.6.x) with LilyPond 2.13.35 > i could not reproduce this issue in linux, 3.13.39. > > Please, anybody, what do you think about this? > > Thanks! http://code.google.com/p/lilypond/issues/detail?id=1353 Should the status be changed? ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1384 in lilypond: annotate-spacing draws system-system instead of last-bottom
Comment #4 on issue 1384 by joeneeman: annotate-spacing draws system-system instead of last-bottom http://code.google.com/p/lilypond/issues/detail?id=1384 lgtm ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 839 in lilypond: Enhancement: improving midi2ly conversion
Comment #8 on issue 839 by v.villenave: Enhancement: improving midi2ly conversion http://code.google.com/p/lilypond/issues/detail?id=839 I'm not sure this patch is still relevant, since Jan has fixed issue 834 in the meantime. Creating a new abandoned_patch label seems to be the appropriate thing to do here. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1384 in lilypond: annotate-spacing draws system-system instead of last-bottom
Updates: Status: Started Owner: n.puttock Cc: joeneeman Comment #3 on issue 1384 by percival.music.ca: annotate-spacing draws system-system instead of last-bottom http://code.google.com/p/lilypond/issues/detail?id=1384 The patch and output look good to me. Joe? ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 839 in lilypond: Enhancement: improving midi2ly conversion
Updates: Status: Accepted Labels: -Patch abandoned_patch Comment #7 on issue 839 by percival.music.ca: Enhancement: improving midi2ly conversion http://code.google.com/p/lilypond/issues/detail?id=839 Unless future emails happened off-list, it's been over a year since any action. I do not believe that Martin Tarenskeen is still working on this, so I shall remove the Started and Patch label. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 903 in lilypond: Enhancement: a more user-friendly way to specify notename languages
Updates: Status: Verified Comment #31 on issue 903 by v.villenave: Enhancement: a more user-friendly way to specify notename languages http://code.google.com/p/lilypond/issues/detail?id=903 Oh, indeed. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)
Comment #3 on issue 1211 by percival.music.ca: [PATCH]Optimizations for pure-height approximations. (issue1817045) http://code.google.com/p/lilypond/issues/detail?id=1211 And here's an updated patch for 15 Nov master. I can't speak to the memory or speed optimization, but the regtest comparison shows no changes (other than test-output-distance). Attachments: optimize-15-nov.diff 5.6 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug in rest-placement in polyphonic music
> "D" == Dmytro O Redchuk writes: D> Actually, i can understand why this output is _wanted_, but can D> not imagine good Summary for issue report. D> "Rest in lower voice should be placed above notes in in upper if D> voices are crossed"? Or if lower voice's noteheads are above the D> middle line, while upper voice's stems are staring from the D> middle line? D> I am not sure that either is correct. No, the point is that the rests belong to the upper voice, and get pushed below a lower voice if the stem-direction of the upper voice is flipped. See the attached examples. Dont know what is wanted in a "Summary for issue report", but perhaps something along these lines: "Place rests where the noteheads of the voice goes in the column - by default: odds up, evens down - regardless of stem-direction of voice." There may be reasons to not have them like this by default, but i cant figure any places where the opposite (the current behaviour) would be wanted (ie. in one voice: noteheads above, rests below). -anders ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 903 in lilypond: Enhancement: a more user-friendly way to specify notename languages
Updates: Status: Fixed Labels: fixed_2_13_28 Comment #30 on issue 903 by percival.music.ca: Enhancement: a more user-friendly way to specify notename languages http://code.google.com/p/lilypond/issues/detail?id=903 This was pushed as 5e25fb3bf792636e329bc1a063ef82f67d181a63 ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1247 in lilypond: Use new modules provided by Guile V2 - Part 1 (ice-9 curried-definitions)
Updates: Labels: -Patch Comment #3 on issue 1247 by percival.music.ca: Use new modules provided by Guile V2 - Part 1 (ice-9 curried-definitions) http://code.google.com/p/lilypond/issues/detail?id=1247 I do not see any patch to review on in this issue, so I'm removing the "patch" label. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Please forgive me for bumping this discussion, but I was wondering if Valentin, I am sorry I have disappeared from the Lilypond scene for a while. My work on Lilypond development has been temporarily put on the back burner. Right now, we are concentrating on something slightly different: we are working to secure a very large Lilypond-based contract, for a major series of critical editions by a major publisher (I'm not allowed to divulge any details yet including who the publisher is, but I am sure everyone on this list is familiar with the name). IF we are successful, it will mean a radical breakthrough in acceptance for Lilypond. Some time ago, I was talking about how I wanted to transform Lilypond from "a volunteer project with limited resources" (Graham's definition), into a professional open-source project where at least some of the core people can afford to spend non-trivial amounts of time on their passion. I'll come back as soon as I have something to announce (either good or bad). Boris ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1406 in lilypond: renaming StreamEvent
Status: Accepted Owner: CC: markpolesky, pnorcks Labels: Type-Other Priority-Low New issue 1406 by v.villenave: renaming StreamEvent http://code.google.com/p/lilypond/issues/detail?id=1406 This issue has been discussed before: http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg0.html http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg00448.html When looking at the following page, you'll notice that StreamEvent is the only item that's CamelCased and not hyphenated like a lisp-identifier: http://lilypond.org/doc/latest/Documentation/internals/music-classes The obvious fix would be to rename StreamEvent into stream-event in define-event-classes.scm (i.e. hardcoding the hyphenated name, unlike other music events that are automatically converted). However (from what I understand), StreamEvent is not limited to music event types. Therefore, one could argue that it would be more consistent to drop the "Event" thing instead, and replace it with "StreamToken" or "StreamElement" or StreamWhathaveyou. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1405 in lilypond: Web: website Google search-bar should allow to search the website.
Status: Accepted Owner: Labels: Type-Other Priority-Medium website New issue 1405 by v.villenave: Web: website Google search-bar should allow to search the website. http://code.google.com/p/lilypond/issues/detail?id=1405 Jan WarchoĊ has just made an interesting discovery: using the search bar on the website to look up, for instance, for "frogs"... doesn't return any results! http://www.google.com/search?q=site%3Alilypond.org+%2Bv2.12+frogs The reason, of course, is that the search bar is supposed to work only with the latest stable documentation... However, the unfortunate side-effect is that it prevents the website from being included in search results. Although a lot of useful material is to be found in the docs (obviously), we should also assume that users may want to find stuff on the website. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1283 in lilypond: Some fingering indications and fingering related commands are not displayed when entered in a separate expression
Updates: Status: Duplicate Mergedinto: 1404 Comment #1 on issue 1283 by v.villenave: Some fingering indications and fingering related commands are not displayed when entered in a separate expression http://code.google.com/p/lilypond/issues/detail?id=1283 I've opened a new issue 1404 to address the underlying cause of this limitation. I think it's safe to close this one. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1404 in lilypond: Enhancement: fingering properties should not require a chord construct
Comment #1 on issue 1404 by v.villenave: Enhancement: fingering properties should not require a chord construct http://code.google.com/p/lilypond/issues/detail?id=1404 Issue 1283 has been merged into this issue. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1404 in lilypond: Enhancement: fingering properties should not require a chord construct
Status: Accepted Owner: Labels: Type-Enhancement Priority-Low Syntax New issue 1404 by v.villenave: Enhancement: fingering properties should not require a chord construct http://code.google.com/p/lilypond/issues/detail?id=1404 As of yet (version 2.13.40), FingeringEvents, StrokeFingerEvents and StringNumberEvents are not regarded as 'articulations when they're not entered inside a chord construct. As a result, c'-1 will be printed, but setting fingeringOrientations or add-stem-support will not work. It's even worse with StrokeFingerEvents and StringNumberEvents: c'-\rightHandFinger #2 or c'\2 will not be printed at all. As a side-effect, these cannot be entered in a separate variable, as shown in issue 1283. It is possible that addressing issue 1403 would make this issue a lot easier to fix. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1264 in lilypond: Enhancement: defining dynamics on-the-fly (with postfix syntax)
Comment #2 on issue 1264 by v.villenave: Enhancement: defining dynamics on-the-fly (with postfix syntax) http://code.google.com/p/lilypond/issues/detail?id=1264 Addressing issue 1403 would probably make this issue irrelevant. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1403 in lilypond: Enhancement: defining postfix commands in Scheme.
Status: Accepted Owner: Labels: Type-Enhancement Priority-Medium Syntax New issue 1403 by v.villenave: Enhancement: defining postfix commands in Scheme. http://code.google.com/p/lilypond/issues/detail?id=1403 This limitation of LilyPond's current parser (as of version 2.13.40) has first been discussed when addressing issue 817: in many cases the only way to modify an EventChord or a music expression, is to pass it as a ly:music? argument to a music function. Said music-function has to be invoked *before* the music expression, which makes it impossible to have a cleaner, more LilyPond-ish looking, postfix syntax. David as mentioned a possible way of implementing this improvement: http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00161.html """ You'd put an appropriate 'syntax property on the music function definition (possibly by allowing a :syntax keyword argument in define-music-function, defaulting to 'SequentialMusic or something else that makes sense), the lexer would check it and return an appropriately different token that would make the parser execute it without finishing the current time step first, using pretty much the same parser for argument lists as normal music functions do. " According to Graham, this improvement "almost" qualifies as a "necessity". (A possible workaround within the current parsing abilities is to manually "attach" a Scheme variable to a NoteEvent, using a dash, as Neil pointed out: http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00162.html However it is limited and hackish, and doesn't replace a genuine native postfix syntax.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1358 in lilypond: run convert-ly on translations
Updates: Status: Started Comment #6 on issue 1358 by paconet.org: run convert-ly on translations http://code.google.com/p/lilypond/issues/detail?id=1358 As soon as that version string is updated, only a few warnings in Deutsch still remain. Hopefully, that small edit together to a merge of lilypond/translation into master will suffice to close the issue (if we can live with those warnings for a while) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1344 in lilypond: [Patch:] Corrections in notation/spacing.itely
Updates: Status: Invalid Comment #3 on issue 1344 by paconet.org: [Patch:] Corrections in notation/spacing.itely http://code.google.com/p/lilypond/issues/detail?id=1344 Thanks for the patch. The English section has changed and we can not apply it, but the German team has been noticed on the issue wrt not to translate variable names in examples and code. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Mon, Nov 15, 2010 at 08:40:26AM +0100, David Kastrup wrote: > > In commercial settings, stagnation often means death. With free > software, stagnation mostly means stagnation. > This is one of the strenghts of free software. Another is that over time it becomes tayored to actual users and actual potential users as opposed to those in some salesman's head. If lily had been a commercial product it might well have died years ago. It would be nice to have commercial backing but wheter or not this happens my guess is that lily will become the defacto standard for computer typesetting of music over the next 10 years or so. Bernard ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1402 in lilypond: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals
Updates: Status: Verified Mergedinto: -1401 Comment #2 on issue 1402 by brownian.box: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals http://code.google.com/p/lilypond/issues/detail?id=1402 Yes!-) Server displayed a big "Server Error" message and i hit Ctrl+R to shut it down completely... But it survived ,) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1402 in lilypond: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals
Updates: Status: Duplicate Mergedinto: 1401 Comment #1 on issue 1402 by v.villenave: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals http://code.google.com/p/lilypond/issues/detail?id=1402 Duplicate of 1401 :-) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1401 in lilypond: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals
Comment #1 on issue 1401 by v.villenave: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals http://code.google.com/p/lilypond/issues/detail?id=1401 Issue 1402 has been merged into this issue. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lilypond ourput to pdf
On 14 November 2010 17:24, verhagen wrote: > > Using Lilypond 2.13.5-0 or higher I cannot convert the output to .pdf > > I get the error > > > s -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -d > DEVICEHEIGHTPOINTS=841.89 -d > CompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -s > DEVICE=pdfwrite -sOutputFile="./Scorekl.pdf" -c .setpdfwrite -f "Scorekl.ps"' > gefaald (256) > fout: gefaalde bestanden: "Scorekl.ly" > LilyPond [Scorekl.ly] stopte met foutcode 1. Hi! Are you sure you are not trying to compile while your score is actually opened with Acrobat Reader? Close your score PDF from Acrobat Reader and then compile. IIRC, I had similar error message when I tried to compile a score that was actually opened as a PDF. It happened only under Windows and with Acrobat Reader. But I may be wrong (I have not used LilyPond under Windows recently). Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1402 in lilypond: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals
Status: Accepted Owner: Labels: Type-Documentation Priority-Medium New issue 1402 by brownian.box: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals http://code.google.com/p/lilypond/issues/detail?id=1402 Proposed by Xavier Scheuer, http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg00122.html : %-- Hi! I know that NR 2.1 have been recently (is currently being?) improved. I looked only at the latest _online_ (i.e. not git) version (2.13.39 at kainhofer.com), so please excuse me if what I'm talking about has been already modified/improved. I'm not used to enter vocal music using LilyPond and I have recently struggled with "Lyrics and repeats". Actually I find the advise to have to use \skip "number of notes" really "tricky", not user-friendly at all! The same for the suggestion to use a temporary voice for the repeated section. I have been able to achieve the same (desired) result using some kind of "nested Lyrics" (similarly to nested staves, cf. NR 1.6.2 Ossia staves). These nested Lyrics expressions do not require the trick to use \skip or temporary voices anymore. What do you think about it? Here is a proposal to use instead of the first snippet using \skip . I had to use \set associatedVoice instead of \lyricsto for the nested Lyrics because \lyricsto was shifting the lyrics one syllable to the right! \score { << \new Staff { \new Voice = "melody" { \relative c'' { a4 a a a \repeat volta 2 { b4 b b b } } } } \new Lyrics \lyricsto "melody" { Not re -- peat -- ed. << { The first time words. } \new Lyrics { \set associatedVoice = "melody" Sec -- ond time words. } >> } >> } And here is a proposal to use instead of the the one that was using a temporary voice (not needed anymore). \score { << \new Staff { \new Voice = "singleVoice" { \relative c'' { a4 a a a \repeat volta 3 { b4 b b b } c4 c c c } } } \new Lyrics \lyricsto "singleVoice" { Not re -- peat -- ed. << { The first time words. } \new Lyrics { \set associatedVoice = "singleVoice" Sec -- ond time words. } \new Lyrics { \set associatedVoice = "singleVoice" The third time words. } >> The end sec -- tion. } >> } Cheers, Xavier %-- ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1401 in lilypond: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals
Status: Accepted Owner: Labels: Type-Documentation Priority-Medium New issue 1401 by brownian.box: Doc: NR 2.1.2 Lyrics and repeats, improvement proposals http://code.google.com/p/lilypond/issues/detail?id=1401 Proposed by Xavier Scheuer, http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg00122.html : %-- Hi! I know that NR 2.1 have been recently (is currently being?) improved. I looked only at the latest _online_ (i.e. not git) version (2.13.39 at kainhofer.com), so please excuse me if what I'm talking about has been already modified/improved. I'm not used to enter vocal music using LilyPond and I have recently struggled with "Lyrics and repeats". Actually I find the advise to have to use \skip "number of notes" really "tricky", not user-friendly at all! The same for the suggestion to use a temporary voice for the repeated section. I have been able to achieve the same (desired) result using some kind of "nested Lyrics" (similarly to nested staves, cf. NR 1.6.2 Ossia staves). These nested Lyrics expressions do not require the trick to use \skip or temporary voices anymore. What do you think about it? Here is a proposal to use instead of the first snippet using \skip . I had to use \set associatedVoice instead of \lyricsto for the nested Lyrics because \lyricsto was shifting the lyrics one syllable to the right! \score { << \new Staff { \new Voice = "melody" { \relative c'' { a4 a a a \repeat volta 2 { b4 b b b } } } } \new Lyrics \lyricsto "melody" { Not re -- peat -- ed. << { The first time words. } \new Lyrics { \set associatedVoice = "melody" Sec -- ond time words. } >> } >> } And here is a proposal to use instead of the the one that was using a temporary voice (not needed anymore). \score { << \new Staff { \new Voice = "singleVoice" { \relative c'' { a4 a a a \repeat volta 3 { b4 b b b } c4 c c c } } } \new Lyrics \lyricsto "singleVoice" { Not re -- peat -- ed. << { The first time words. } \new Lyrics { \set associatedVoice = "singleVoice" Sec -- ond time words. } \new Lyrics { \set associatedVoice = "singleVoice" The third time words. } >> The end sec -- tion. } >> } Cheers, Xavier %-- ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1400 in lilypond: Inconsistency: slurs attached to skips
Status: Accepted Owner: Labels: Type-Other Priority-Low New issue 1400 by brownian.box: Inconsistency: slurs attached to skips http://code.google.com/p/lilypond/issues/detail?id=1400 Reported by Valentin Villenave, http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg00108.html : %--- I couldn't find this specific question discussed anywhere, but I'd appreciate if someone could point me to an existing tracker page or a former discussion on the lists. If you do \relative { c( s) } You'll see that a slur is produced, from the note to an invisible point. However if you do \relative { c( d s) r } You'll see that the slur ends on the second note, and isn't extended to include the skip (which would be the expected behavior IMO): in other words, it behaves just as if you'd written \relative { c( d) s r } %--- Well, at least it's an inconsistency. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Inconsistency: slurs attached to skips
On Wed 10 Nov 2010, 11:51 Valentin Villenave wrote: > Greetings everybody, Hi, i've added this as 1400: http://code.google.com/p/lilypond/issues/detail?id=1400 , thank you. > I couldn't find this specific question discussed anywhere, but I'd > appreciate if someone could point me to an existing tracker page or a > former discussion on the lists. > > If you do > \relative { > c( s) > } > > You'll see that a slur is produced, from the note to an invisible point. > > However if you do > \relative { > c( d s) r > } > > You'll see that the slur ends on the second note, and isn't extended > to include the skip (which would be the expected behavior IMO): in > other words, it behaves just as if you'd written > \relative { > c( d) s r > } > > Cheers, > Valentin. -- Dmytro O. Redchuk Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \chordmode chords jumping about on PDF
On Mon 18 Oct 2010, 12:37 James wrote: > Hello Hello, > I am using Mac OSX Snow Leopard (10.6.x) with LilyPond 2.13.35 i could not reproduce this issue in linux, 3.13.39. Please, anybody, what do you think about this? Thanks! > Here is the smallest example I could get down to > > -- > > \version "2.13.35" > > RH = \relative c'' { > \repeat unfold 30 { a8 a a a } > } > > LH = { >\clef bass >\repeat unfold 30 { a8 a a a } > } > > \score { >\new PianoStaff ><< > \chords { f1*5 bes :m } > \new Staff \RH > \new Staff \LH >>> > } > > --- > > The symptom is after each compile the chord symbols move 'randomly' > up and down on the next PDF output. No changes are made to the .ly > file, the file is just compiled again and the chord symbols move. > > If I use > > \chords { f1 bes :m } instead (as a test) then the jumping about > isn't so weird - that is it does still jump up and down but it seems > to be consistent - but it occurs every time I recompile. > > All other notes in the score are fine. > > I have attached a small screen-shot to show you what I mean, from > left to right is the output of the PDF after each compile. > > There is no pattern I can see, occasionally I get a message about > -- > > Finding the ideal number of pages... > Fitting music on 1 page... > Drawing systems... > programming error: insane spring min_distance requested, ignoring it > continuing, cross fingers > Layout output to `test.ps'... > Converting to `./test.pdf'... > > -- > > But there is no correlation to this message and the output. > > Also I have tried this same file on Windows 7 and cannot (yet) get > this to occur. > > regards > > James > > ___ > bug-lilypond mailing list > bug-lilypond@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-lilypond -- Dmytro O. Redchuk Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1399 in lilypond: extraNatural is quietly set to #f as part of setting the modern-* or piano-* styles
Status: Accepted Owner: Labels: Type-Other Priority-Medium New issue 1399 by brownian.box: extraNatural is quietly set to #f as part of setting the modern-* or piano-* styles http://code.google.com/p/lilypond/issues/detail?id=1399 Reported by Keith E OHara, http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg00057.html %-- % Low priority, but easy, Enhancement, or possibly Documentation % % extraNatural is quietly set to #f as part of setting the % modern-* or piano-* styles for automatic accidentals % (music-functions.scm) % This can be a confusing surprise to users not yet % familiar with what extraNatural does : { #(set-accidental-style 'piano 'Score) \key des \major 1 \bar "||" \key cis \minor 1 } % Suggest instead that choosing these styles for automatic % accidentals should set extraNatural % to the documented default of #t %-- I've set its type to "Other" -- please decide whether it should be Doc or Enhancement. Thanks. Attachments: nontraditional.png 6.4 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: accidental-style surprise
On Thu 04 Nov 2010, 23:00 Keith E OHara wrote: > % Low priority, but easy, Enhancement, or possibly Documentation > % > % extraNatural is quietly set to #f as part of setting the > % modern-* or piano-* styles for automatic accidentals > % (music-functions.scm) > % This can be a confusing surprise to users not yet > % familiar with what extraNatural does : > { > #(set-accidental-style 'piano 'Score) > \key des \major 1 \bar "||" > \key cis \minor 1 > } > % Suggest instead that choosing these styles for automatic > % accidentals should set extraNatural > % to the documented default of #t Thank you, added as 1399: http://code.google.com/p/lilypond/issues/detail?id=1399 -- Dmytro O. Redchuk Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Hairpin following a text crescendo starts too late
On Thu 04 Nov 2010, 02:08 Reinhold Kainhofer wrote: > If a hairpin follows immeditately after a text crescendo, the hairpin does > not > start on the note but after the note. Thank you, added as 1398: http://code.google.com/p/lilypond/issues/detail?id=1398 > Simple example file (including comparison to case without text crescendo) is > attached. -- Dmytro O. Redchuk Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1398 in lilypond: Hairpin following a text crescendo starts too late
Status: Accepted Owner: Labels: Type-Defect Priority-Medium New issue 1398 by brownian.box: Hairpin following a text crescendo starts too late http://code.google.com/p/lilypond/issues/detail?id=1398 Reported by Reinhold Kainhofer: http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg00030.html %-- If a hairpin follows immeditately after a text crescendo, the hairpin does not start on the note but after the note. Simple example file (including comparison to case without text crescendo) is attached. %-- << \new Staff \relative c' { c2\cresc c | c c\< | c c | c\! } \new Staff \relative c' { c2 c | c c\< | c c | c\! } %-- Attachments: test.png 2.5 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1217 in lilypond: clean up undocumented regtests in 2.14.0.
Comment #1 on issue 1217 by brownian.box: clean up undocumented regtests in 2.14.0. http://code.google.com/p/lilypond/issues/detail?id=1217 "Document \breakDynamicSpan" by Reinhold Kainhofer: http://lists.gnu.org/archive/html/bug-lilypond/2010-10/msg00560.html ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Document \breakDynamicSpan
On Wed 27 Oct 2010, 17:02 Graham Percival wrote: > On Wed, Oct 27, 2010 at 05:52:57PM +0200, Reinhold Kainhofer wrote: > > With 2.13.x we added \breakDynamicSpan to allow lilypond to break a text > > dynamic spanner prematurely (while the cresc/decresc for MIDI-purposes > > still > > lasts until the \! or the next dynamic sign). > > I see this as part of 1217, although I certainly wouldn't object > to patches before then. I've linked this to 1217: http://code.google.com/p/lilypond/issues/detail?id=1217 -- Dmytro O. Redchuk Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug in rest-placement in polyphonic music
On Thu 04 Nov 2010, 08:59 Anders Vinjar wrote: > > I'm not top posting. Sorry for delay. > \version "2.13.39" > %% rests in one voice crossing other voice > > << > {c4 c}\\ > { r8 c'' r c''} > >> > > %% Rests in mixed (rests+notes) columns don't obey Rest 'direction = #UP: > << > {c4 c}\\ > {\override Rest #'direction = #UP r8 c'' r c''} > >> > > %% wanted output > << > {c4 c}\\ > {\stemNeutral \override Stem #'neutral-direction = #UP r8 c'' r c''} > >> Actually, i can understand why this output is _wanted_, but can not imagine good Summary for issue report. "Rest in lower voice should be placed above notes in in upper if voices are crossed"? Or if lower voice's noteheads are above the middle line, while upper voice's stems are staring from the middle line? I am not sure that either is correct. Can anyone help me? Or i've missed something badly? Thanks. -- Dmytro O. Redchuk Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1394 in lilypond: Key signatures that include double-sharps are printed inconsistently
Comment #6 on issue 1394 by d...@gnu.org: Key signatures that include double-sharps are printed inconsistently http://code.google.com/p/lilypond/issues/detail?id=1394 When viewing the corrected and the original example images side-by-side, it becomes apparent that the last measure, contrary to what was stated in the original report, had been wrong as well because of stacking its naturals wrongly, in correspondence with the wrongly arrayed double sharps of the preceding measure. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond