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
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 jann...@gnu.org | 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
Re: build: missing explicit dependency?
2013/3/12 Julien Rioux jri...@lyx.org: 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: 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: 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
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: 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: GUB usage
On 14 March 2013 05:14, Jan Nieuwenhuizen jann...@gnu.org 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
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
attachment: lyrics-behaviour.png___
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ł janek.lilyp...@gmail.com
To: LilyPond Developmet Team lilypond-devel@gnu.org; Mike Solomon
m...@mikesolomon.org; Han-Wen Nienhuys han...@xs4all.nl; David
Kastrup d...@gnu.org
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
Re: alignment of unattached lyrics - opinions needed
Janek Warchoł janek.lilyp...@gmail.com 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: 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
2013/3/14 David Kastrup d...@gnu.org:
Janek Warchoł janek.lilyp...@gmail.com 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
