Re: alignment of unattached lyrics - opinions needed
2013/3/14 David Kastrup : > Janek Warchoł writes: > >> Hi hackers, >> >> I need your opinion on this to proceed with generalizing alignment >> stuff (https://codereview.appspot.com/7768043). >> >> What should be the the desired behaviour of "standalone" lyrics, i.e. >> lyrics that don't have associatedVoice set? If you look at this >> snippet (output attached), >> >> { c'2 c' d' d' } >> \addlyrics { foo bar la mmm } >> >> << >> { c'2 c' d' d' } >> \new Lyrics { \lyricmode { foo2 bar la mmm } } >> >> you'll see that lyrics attached to notes (\addlyrics sets >> associatedVoice) are centered, while "independent" lyrics are >> left-aligned. I think that this behaviour is suboptimal - in my >> opinion it would be better if lyrics were centered in both cases. >> What are your opinions? Hi Janek, if neither \addlyrics nor \lyricsto or associatedVoice is used, why align the lyrics? This is a user-error or it is intended. In the latter case I'm with David: > at least it should be reason > enough to make the alignment configurable in a very straightforward way. > > -- > David Kastrup Offtopic: But there's another, ununderstandable issue: In the Code below, why is the lyric-line in \firstScore not removed but in \secondScore ? I'd have expected it the other way around. \version "2.17.15" m = { \repeat unfold 12 { c'4 } \break \repeat unfold 16 { c'4 } } lyrI = \lyricmode { \repeat unfold 64 { bla } } lyrII = \lyricmode { \repeat unfold 12 { "" } \repeat unfold 16 { foo } } lyrIII = \lyricmode { \repeat unfold 12 { " " } \repeat unfold 16 { xy} } firstScore = << \new Voice = "m" \m \new Lyrics \lyricsto "m" \lyrI \new Lyrics \lyricsto "m" \lyrII \new Lyrics \lyricsto "m" \lyrI >> secondScore = << \new Voice = "m" \m \new Lyrics \lyricsto "m" \lyrI \new Lyrics \lyricsto "m" \lyrIII \new Lyrics \lyricsto "m" \lyrI >> \firstScore \markup\vspace #2 \secondScore Regards, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes '-signs in vectors - follow-up (issue 7834043)
Please review this patch as follow-up fix for issue 3010. It was the first time I run scripts/auxiliar/makelsr.py Hope I did it right. https://codereview.appspot.com/7834043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: alignment of unattached lyrics - opinions needed
Janek Warchoł writes: > Hi hackers, > > I need your opinion on this to proceed with generalizing alignment > stuff (https://codereview.appspot.com/7768043). > > What should be the the desired behaviour of "standalone" lyrics, i.e. > lyrics that don't have associatedVoice set? If you look at this > snippet (output attached), > > { c'2 c' d' d' } > \addlyrics { foo bar la mmm } > > << > { c'2 c' d' d' } > \new Lyrics { \lyricmode { foo2 bar la mmm } } >>> > > you'll see that lyrics attached to notes (\addlyrics sets > associatedVoice) are centered, while "independent" lyrics are > left-aligned. I think that this behaviour is suboptimal - in my > opinion it would be better if lyrics were centered in both cases. > What are your opinions? Without an associated voice, there is, with some likeliness, no longer a strict per-note relation with lyrics. In this case, lyrics are likely to _not_ be split into syllables. Typical use cases are songbooks _without_ notes, consisting just of chords and words. Why use LilyPond in the first place for that? Because it makes transposing easy. I am not sure this is enough reason to make the default alignment with and without \addlyrics different, but at least it should be reason enough to make the alignment configurable in a very straightforward way. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: alignment of unattached lyrics - opinions needed
- Original Message - From: "Janek Warchoł" To: "LilyPond Developmet Team" ; "Mike Solomon" ; "Han-Wen Nienhuys" ; "David Kastrup" Sent: Thursday, March 14, 2013 7:59 PM Subject: alignment of unattached lyrics - opinions needed Hi hackers, I need your opinion on this to proceed with generalizing alignment stuff (https://codereview.appspot.com/7768043). What should be the the desired behaviour of "standalone" lyrics, i.e. lyrics that don't have associatedVoice set? If you look at this snippet (output attached), { c'2 c' d' d' } \addlyrics { foo bar la mmm } << { c'2 c' d' d' } \new Lyrics { \lyricmode { foo2 bar la mmm } } you'll see that lyrics attached to notes (\addlyrics sets associatedVoice) are centered, while "independent" lyrics are left-aligned. I think that this behaviour is suboptimal - in my opinion it would be better if lyrics were centered in both cases. What are your opinions? The code that's responsible for this behaviour is in lines 134-135 of self-alignment-interface.cc, and was introduced by commit ebb1f1f1. I've taken the liberty to cc Han-Wen because he wrote the code in the first place, as well as David because he's usually interested in consistency and polishing rough edges. thanks, Janek Without doubt, lyrics that are only a single note long should be centred on the note. Left alignment is only correct where a single syllable occupies two notes or more. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
alignment of unattached lyrics - opinions needed
Hi hackers, I need your opinion on this to proceed with generalizing alignment stuff (https://codereview.appspot.com/7768043). What should be the the desired behaviour of "standalone" lyrics, i.e. lyrics that don't have associatedVoice set? If you look at this snippet (output attached), { c'2 c' d' d' } \addlyrics { foo bar la mmm } << { c'2 c' d' d' } \new Lyrics { \lyricmode { foo2 bar la mmm } } >> you'll see that lyrics attached to notes (\addlyrics sets associatedVoice) are centered, while "independent" lyrics are left-aligned. I think that this behaviour is suboptimal - in my opinion it would be better if lyrics were centered in both cases. What are your opinions? The code that's responsible for this behaviour is in lines 134-135 of self-alignment-interface.cc, and was introduced by commit ebb1f1f1. I've taken the liberty to cc Han-Wen because he wrote the code in the first place, as well as David because he's usually interested in consistency and polishing rough edges. thanks, Janek <>___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB usage
On 14 March 2013 05:14, Jan Nieuwenhuizen wrote: > Jordi Gutiérrez Hermoso writes: > >> Where are these two other branches? > > Follow github's forks > > https://github.com/janneke/gub/network > > then look at branches. Here > > https://github.com/janneke/gub/branches I prefer to avoid using non-free software for development. It's important to not depend on github's features for GNU: http://mako.cc/writing/hill-free_tools.html I already have your public branches in my hg clone: http://hg.octave.org/gub/bookmarks > I have at least two unpublished branches with conflicting changes > (patches for specific LilyPond releases and mingw cross building). If you would like me to merge the whitespace changes into those branches, please publish them. > AFAIC Denemo is here > > https://github.com/jjbenham/gub Thanks, I'll see what I can merge from them. > Just make sure that you avoid making whitespace changes manually and > check-in the final whitespace cleanup script, eg as bin/2pep-8.py. No, I have to do it somewhat manually. Good style is a matter of taste, not automation. PEP-8 itself says that sometimes you should break some elements of it when you deem it's more readable otherwise: http://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds I don't mind merging my changes and doing all the pepeighting manually. But if we are going to do this, you have to be aware of PEP-8 yourself and agree to mostly follow it from now on. The only glaring problem I see is very long lines that should be broken up into shorter lines. If you're using Emacs, its default X frame is already 80 columns wide. - Jordi G. H. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove -d old-relative compatibility option (issue 7764046)
LGTM https://codereview.appspot.com/7764046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Remove -d old-relative compatibility option (issue 7764046)
LGTM https://codereview.appspot.com/7764046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gives invisible stems point extents. (issue 7762049)
On 14 mars 2013, at 08:05, k-ohara5...@oco.net wrote: > So then the convention for an extent is > '(+inf.0 . -inf.0) is empty, but for skylines in the cross direction it > is an infinite wall; > '(0 . 0) is a point, but ignored for skylines; > '(-inf.0 . +inf.0) is an infinite wall all the time. > > Could you filter out this effect on RhythmicStaves ? > > My heavy-metal band uses a flame-shaped glyph for some Stems, and it > needed zero X-extent for some spacing reason. While fixing another MIDI > bug I had the Midi_performer listen for Stems and send a message, if on > channel 10, when it sees a zero-width Stem, by convention. That message > fires the flamethrowers, so if you push this change I have to remind the > boys to avoid that part of the stage in case the drummer has any beamed > rests. > > https://codereview.appspot.com/7762049/ New patch up that doesn't get in the way of your band! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses single algorithm for side-position spacing. (issue 6827072)
On 14 mars 2013, at 06:44, m...@mikesolomon.org wrote: > > On 14 mars 2013, at 06:42, k-ohara5...@oco.net wrote: > >> issue 3242 >> >> >> https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc >> File lily/axis-group-interface.cc (right): >> >> https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode902 >> lily/axis-group-interface.cc:902: Skyline_pair skylines >> (inside_staff_skylines); >> \relative c'' { >> r2^\f r4 f8^[ r] >> } >> >> https://codereview.appspot.com/6827072/diff/38003/lily/stencil-integral.cc >> File lily/stencil-integral.cc (right): >> >> https://codereview.appspot.com/6827072/diff/38003/lily/stencil-integral.cc#newcode992 >> lily/stencil-integral.cc:992: xex.set_full (); >> Oops. >> >> https://codereview.appspot.com/6827072/ > > Yup, just caught this myself, we're on the same page. > This set_full needs to happen for other grobs, but by giving invisible stems > a point stencil instead of an empty stencil, things are fixed. Running the > regtests. > > Cheers, > MS Another solution is to introduce the idea of "blocking grob." The comment I put about SystemStartBracket and BassFigureAlignmentPositioning is because both of them conceptually need to extend forever in both directions to never be moved over/under/left/right of another grob. This could perhaps be done via two properties: horizontal-skyline-minimum-height and vertical-skyline-minimum-height Thoughts? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build: missing explicit dependency?
2013/3/12 Julien Rioux : > OK I see, so testing for the binaries is not enough. We`ll need to > find out what else is required and add a test for it. Does anybody > know? If you or anyone else do uninstall texlive-metapost and provide > a log from a failed make, I think that would be useful. I uninstalled texlive-metapost and removed the mf/out directory. Then issued ./autogen.sh and obtained the green light to run 'make'. It stopped with these last lines: Output written on parmesan-noteheads26.600gf (101 characters, 29364 bytes). Transcript written on parmesan-noteheads26.log. mv parmesan-noteheads26.log parmesan-noteheads26.tfm ./out rm -f parmesan-noteheads26.*gf parmesan-noteheads26.*pk ~/source/lilypond/scripts/build/out/mf-to-table \ --global-lisp=./out/feta11.otf-gtable \ --lisp=./out/feta11.lisp \ --outdir=./out \ --enc ./out/feta11.enc \ out/feta11.log cd ./out \ && touch mf2pt1.mem \ && mpost -progname=mpost -ini ~/source/lilypond/mf/mf2pt1.mp \\dump This is MetaPost, version 1.504 (kpathsea version 6.1.0) (~/source/lilypond/mf/mf2pt1.mp ! I can't open file `mfplain'. l.27 input mfplain ; Please type another input file name: That's it. I searched for mfplain and found that texlive-metapost provides /usr/share/texlive/texmf-dist/metapost/base/mfplain.mp and /usr/share/texlive/texmf-dist/metapost/config/mfplain.ini So I installed the package and compiling could continue. Thanks -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB usage
Jordi Gutiérrez Hermoso writes: > Where are these two other branches? Follow github's forks https://github.com/janneke/gub/network then look at branches. Here https://github.com/janneke/gub/branches I have at least python-2.6 and guile-2.0 which are interesting. I have at least two unpublished branches with conflicting changes (patches for specific LilyPond releases and mingw cross building). AFAIC Denemo is here https://github.com/jjbenham/gub Of course, this only gives us github forks. > I'll be glad to merge your changes and Denemo's in myself with my very > intrusive changes. You can then pull back. I'll do it in a separate > pep-8 branch. Just make sure that you avoid making whitespace changes manually and check-in the final whitespace cleanup script, eg as bin/2pep-8.py. That way, we should be able to merge in from unknown forks by first running 2pep-8.py on it. Greetings, Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Gives invisible stems point extents. (issue 7762049)
So then the convention for an extent is '(+inf.0 . -inf.0) is empty, but for skylines in the cross direction it is an infinite wall; '(0 . 0) is a point, but ignored for skylines; '(-inf.0 . +inf.0) is an infinite wall all the time. Could you filter out this effect on RhythmicStaves ? My heavy-metal band uses a flame-shaped glyph for some Stems, and it needed zero X-extent for some spacing reason. While fixing another MIDI bug I had the Midi_performer listen for Stems and send a message, if on channel 10, when it sees a zero-width Stem, by convention. That message fires the flamethrowers, so if you push this change I have to remind the boys to avoid that part of the stage in case the drummer has any beamed rests. https://codereview.appspot.com/7762049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel