Reviewers: Keith, mike_apollinemike.com,
Message:
Running regtests. Will post new patch once it gets a clean bill of
health.
http://codereview.appspot.com/5843063/diff/7/input/regression/pure-from-neighbor-interface-pure-height.ly
File input/regression/pure-from-neighbor-interface-pure-height.
On Wed, Mar 21, 2012 at 3:49 AM, Han-Wen Nienhuys wrote:
> 2012/3/20 Łukasz Czerwiński :
>>>
>>> Can you share your thoughts?
>>
>> Lilypond would never be useful for Google products. There is absolutely no
>> point for Google to pay for code that would never be useful for them.
>
> The point of G
Nick
On 19 March 2012 05:19, Nick Payne wrote:
> In a chord with two accidentals, if I set the fingering script-priority to
> -99, the fingerings still avoid both accidentals, but if I set it to -100,
> each fingering indication is positioned without regard to the accidental on
> the other note.
Janek Warchoł writes:
> On Wed, Mar 21, 2012 at 3:49 AM, Han-Wen Nienhuys wrote:
>> 2012/3/20 Łukasz Czerwiński :
Can you share your thoughts?
>>>
>>> Lilypond would never be useful for Google products. There is absolutely no
>>> point for Google to pay for code that would never be use
http://codereview.appspot.com/5843063/diff/7/scm/output-lib.scm
File scm/output-lib.scm (right):
http://codereview.appspot.com/5843063/diff/7/scm/output-lib.scm#newcode437
scm/output-lib.scm:437: (let* ((height (ly:grob-pure-height grob grob 0
1000))
On 2012/03/21 07:05:50, MikeSol wrote:
O
Am 21.03.2012 03:20, schrieb David Kastrup:
Marc Hohl writes:
Is this a feasible approach? What am I currently doing wrong?
#(define bar-line-stencil-alist
'(("|" . thin-stil)
("." . thick-stil)
("" . empty-stil)
))
(thin-stil (bar-line::simple-bar-line grob hai
Marc Hohl writes:
> Am 21.03.2012 03:20, schrieb David Kastrup:
>> Marc Hohl writes:
>>
>>> Is this a feasible approach? What am I currently doing wrong?
>>
>>> #(define bar-line-stencil-alist
>>>'(("|" . thin-stil)
>>> ("." . thick-stil)
>>> ("" . empty-stil)
>>> ))
>>>
Am 21.03.2012 11:03, schrieb David Kastrup:
Marc Hohl writes:
Am 21.03.2012 03:20, schrieb David Kastrup:
Marc Hohl writes:
Is this a feasible approach? What am I currently doing wrong?
#(define bar-line-stencil-alist
'(("|" . thin-stil)
("." . thick-stil)
("" . empty-stil
Am 21.03.2012 02:11, schrieb Thomas Morley:
Hi Marc,
Some observations:
the main problem seems to be the storing of the new stencils in an
alist and how to call them. Directly in bar-line::compound-bar-line
works.
Ok, this is what David explained to me, too.
Also, I created bar-line-stencil-a
http://codereview.appspot.com/5844052/diff/3001/lily/beaming-pattern.cc
File lily/beaming-pattern.cc (right):
http://codereview.appspot.com/5844052/diff/3001/lily/beaming-pattern.cc#newcode361
lily/beaming-pattern.cc:361: }
My comment has nothing to do with your patch but with this function - it
http://codereview.appspot.com/5844052/diff/3001/lily/beaming-pattern.cc
File lily/beaming-pattern.cc (right):
http://codereview.appspot.com/5844052/diff/3001/lily/beaming-pattern.cc#newcode361
lily/beaming-pattern.cc:361: }
On 2012/03/21 10:51:29, MikeSol wrote:
My comment has nothing to do wit
Marc Hohl writes:
> Anyway, I don't get the case statement right - am I too stupid?
Stupid enough to follow my advice without checking the manual first (or
afterwards). Looking in the Guile manual, it turns out that case uses
eqv? for checking equality.
guile> (eqv? "x" "x")
#f
guile>
So you
On Wed, Mar 21, 2012 at 1:39 AM, wrote:
>
> http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py
> File scripts/lilypond-book.py (right):
>
> http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py#newcode639
> scripts/lilypond-book.py:639: global_options.include_pa
http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py
File python/auxiliar/postprocess_html.py (right):
http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py#newcode71
python/auxiliar/postprocess_html.py:71: browser_language_url =
"/misc/brow
On Wed, Mar 21, 2012 at 4:33 PM, wrote:
>
> http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py
> File python/auxiliar/postprocess_html.py (right):
>
> http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py#newcode71
> python/auxiliar/postpro
http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi
File Documentation/common-macros.itexi (right):
http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi#newcode185
Documentation/common-macros.itexi:185:
@uref{http://www.lilypond.org/misc/\MI
On Wed, Mar 21, 2012 at 5:16 PM, wrote:
>
> http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi
> File Documentation/common-macros.itexi (right):
>
> http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi#newcode185
> Documentation/common-macro
On Wed, Mar 21, 2012 at 4:42 PM, Julien Rioux wrote:
> On Wed, Mar 21, 2012 at 4:33 PM, wrote:
>>
>> http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py
>> File python/auxiliar/postprocess_html.py (right):
>>
>> http://codereview.appspot.com/5870043/diff/1/python/aux
On 3/20/12 9:08 PM, "lilyp...@googlecode.com"
wrote:
>Updates:
> Labels: -Patch-countdown Patch-push
>
>Comment #11 on issue 2389 by ColinPKCampbell: Patch: Fix make error in
>regression tests coming from midi2ly
>http://code.google.com/p/lilypond/issues/detail?id=2389
>
>Counted down to
- Original Message -
From: "Carl Sorensen"
To: "Lily-Devel List"
Sent: Wednesday, March 21, 2012 5:50 PM
Subject: FW: Issue 2389 in lilypond: Patch: Fix make error in
regressiontests coming from midi2ly
On 3/20/12 9:08 PM, "lilyp...@googlecode.com"
wrote:
Updates:
Labels: -Pat
Reviewers: ,
Message:
This is a continuation of Issue: http://codereview.appspot.com/5651069/
Description:
Corrected style of comments
Please review this at http://codereview.appspot.com/5862052/
Affected files:
M .gitignore
M flower/include/direction.hh
M lily/accidental-placement.cc
The next patch set was by mistake placed by me in a new issue:
http://codereview.appspot.com/5862052.
http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc
File lily/accidental-placement.cc (right):
http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc#ne
- Original Message -
From: "Carl Sorensen"
To: "Lily-Devel List"
Sent: Wednesday, March 21, 2012 5:50 PM
Subject: FW: Issue 2389 in lilypond: Patch: Fix make error in
regressiontests coming from midi2ly
On 3/20/12 9:08 PM, "lilyp...@googlecode.com"
wrote:
Updates:
Labels: -Pat
On Wed, Mar 21, 2012 at 9:46 AM, Frank Steinmetzger wrote:
> On Sat, Mar 17, 2012 at 01:53:10PM -0700, Joe Neeman wrote:
>> There are two competing desires here [...]. Could you suggest, therefore, an
>> extra parameter (or a modification to the [vertical spacing] algorithm) that
>> would give yo
Le 20 mars 2012 à 09:39, Marc Hohl a écrit :
> Hello list,
>
> I want to rewrite most if not all definitions currently settled in
> lily/bar-line.cc in scheme. Please see the attached file for my
> progress so far; I don't get any error messages, but no bar lines either :-(
>
> Is this a feasib
> I suggest that the vertical spacing alrogithm should calculate the
> area between the objects (staves, systems, lyrics etc). See here
> how it would work: http://www.freeimagehosting.net/tsr21
Looks right: The area between horizontal skylines should influence the
spacing. However, I think we
On Wed, Mar 21, 2012 at 9:41 PM, Werner LEMBERG wrote:
>
>> I suggest that the vertical spacing alrogithm should calculate the
>> area between the objects (staves, systems, lyrics etc). See here
>> how it would work: http://www.freeimagehosting.net/tsr21
>
> Looks right: The area between horizont
>> Looks right: The area between horizontal skylines should influence the
>> spacing. However, I think we need a parameter to adjust the amount of
>> influence.
>
> I'm not sure what you mean.
I mean that some people probably want a more rigid spacing, only
slightly influenced by the area inbetw
No remaining issues to verify for the 2.15.34 release.
Cheers,
Colin.
--
Colin Hall
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This feels like a dangerous change. Obviously we don't /want/
"bleed-through" of parameters or memory from one file to the next, but I
would be shocked if we don't have any of that right now. I also have
vague memories of some problems with this in the past.
I guesstimate that not reloading ini
30 matches
Mail list logo
