On Mon, 24 Jan 2011 20:47:24 -0800, wrote:
This patch also resolves the problem in issue 1229 of notes extending
beyond the right-hand bar line.
Adding additional extra-spacing-height to the TimeSignature grob
resolves the 1229 issue of overlapping the time signature.
This patch seems to have
This patch also resolves the problem in issue 1229 of notes extending
beyond the right-hand bar line.
Adding additional extra-spacing-height to the TimeSignature grob
resolves the 1229 issue of overlapping the time signature.
This patch seems to have some very good benefits.
http://codereview.a
We have had multiple contributors (Keith O'Hara, Mike Solomon, Valentin
Villenave) who were unable to successfully upload patches to Rietveld for
review.
Keith tracked it down to a missing entry in /etc/mime.types on his system.
I've added a note to the CG, so we don't lose Keith's information, b
On Mon, Jan 24, 2011 at 9:40 PM, Neil Puttock wrote:
> + common[a] = common_refpoint_of_array (covered_grobs, me, Axis (a));
>
> I suspect this line needs changing, otherwise it junks the calculated
> refpoint for the stems (which means we no longer get the correct
> refpoint for cross-staff
On 2011/01/24 16:33:22, Graham Percival wrote:
Almost there.
Could you run makelsr and then don't forget to do
git add Documentation/snippets/*.ly
Done, and new patch set uploaded.
Thanks,
Carl
http://codereview.appspot.com/4061043/
___
li
On 1/24/11 5:15 PM, "Neil Puttock" wrote:
> On 25 January 2011 00:10, Carl Sorensen wrote:
>
>> If you use pairs, instead of lists, for the property overrides then the
>> override list is a standard alist:
>>
>> \overrideGrobProps #'Accidental #`((color . ,red) (font-size . 4)
>> (extra-of
On 25 January 2011 00:10, Carl Sorensen wrote:
> If you use pairs, instead of lists, for the property overrides then the
> override list is a standard alist:
>
> \overrideGrobProps #'Accidental #`((color . ,red) (font-size . 4)
> (extra-offset . (1.5 . 3)))
Yup, but then you have to type those
On 1/24/11 4:55 PM, "Neil Puttock" wrote:
> On 24 January 2011 17:30, James Lowe wrote:
>
>> So I wondered if it is possible to save some lines of code/simplify
>> overrides for the same context/Grob such that I can write 'something like'
>>
>> \override context.GrobName ( ( #'property1 = #
On 24 January 2011 17:30, James Lowe wrote:
> So I wondered if it is possible to save some lines of code/simplify
> overrides for the same context/Grob such that I can write 'something like'
>
> \override context.GrobName ( ( #'property1 = #value1) (#'property2 =
> #value2) (#'property3 = #value3
On 24 January 2011 14:28, Han-Wen Nienhuys wrote:
> See attached (it applies on top of issue3928041_55001.diff)
+ common[a] = common_refpoint_of_array (covered_grobs, me, Axis (a));
I suspect this line needs changing, otherwise it junks the calculated
refpoint for the stems (which means we
On 1/24/11 3:31 PM, "Benkő Pál" wrote:
>>> please advise me about regression tests: can I modify ligatures within
>>> mensural-ligatures.ly? if not, can I add new ones to the same file?
>>
>> Ancient music has been abandoned by developers for a number of years.
>> IMO, you may do whatever you t
On 2011/01/24 21:27:35, benko.pal wrote:
new patchset up.
please advise me about regression tests: can I modify ligatures within
mensural-ligatures.ly? if not, can I add new ones to the same file?
Ancient music has been abandoned by developers for a number of years.
IMO, you may do whatever
>> please advise me about regression tests: can I modify ligatures within
>> mensural-ligatures.ly? if not, can I add new ones to the same file?
>
> Ancient music has been abandoned by developers for a number of years.
> IMO, you may do whatever you think makes the most sense as you try to
> bring
new patchset up.
please advise me about regression tests: can I modify ligatures within
mensural-ligatures.ly? if not, can I add new ones to the same file?
http://codereview.appspot.com/3797046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
now I see I forgot to answer a question:
> http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode380
> lily/mensural-ligature-engraver.cc:380: {
> Why put the {} in this case?
because variables defined there should not be seen in the default case.
p
On 1/24/11 11:15 AM, "Bernard Hurley" wrote:
> Is there any point in anyone working on 1474 before this is resolved?
I don't think so. 1120, 1472, and 1474 are intimately connected and will be
resolved together.
Thanks,
Carl
___
lilypond-devel
Is there any point in anyone working on 1474 before this is resolved?
/Bernard
On Mon, Jan 24, 2011 at 02:24:16PM -, Phil Holmes wrote:
> - Original Message - From:
> To:
> Cc: ;
> Sent: Monday, January 24, 2011 5:15 AM
> Subject: Re: Fix 1120 in a way to avoid issues 1472,
-Original Message-
From: Graham Percival
Date: Mon, 24 Jan 2011 18:07:13 +
To: Phil Holmes
Cc: lilypond-devel
Subject: Re: Going on hols
>On 1/24/11, Phil Holmes wrote:
>> Having a few days skiing in the USA from Tuesday (tomorrow) to Thursday
>>3rd
>> Feb. Will not have my deskto
On 1/24/11, Phil Holmes wrote:
> Having a few days skiing in the USA from Tuesday (tomorrow) to Thursday 3rd
> Feb. Will not have my desktop with me - just me little laptop that's set up
> differently and so may not be able to contribute too much.
Have fun!
> Wonder whether we'll have a stable
Hello,
According to the NR it states:
\override context.GrobName #'property = #value
Is more-or-less equivalent to:
\set context.GrobName = #(cons (cons 'property value)
So I wondered if it is possible to save some lines of code/simplify
overrides for the same context/Grob such that I can wr
Having a few days skiing in the USA from Tuesday (tomorrow) to Thursday 3rd
Feb. Will not have my desktop with me - just me little laptop that's set up
differently and so may not be able to contribute too much.
Wonder whether we'll have a stable release for my return?
--
Phil Holmes
Bug Squad
On 1/24/11, pkx1...@gmail.com wrote:
>
> No problem. What would be the best thing to do with this 'code' would
> putting the 'patch' I have on the tracker issue, with explanation and
> appropriate comments from this Rietveld thread, be the right thing if
> only to save re-doing more work for anyon
On 2011/01/24 16:20:20, c_sorensen_byu.edu wrote:
snip...
But -- Neil's comment indicated that this approach wrong for getting
this
functionality into the LilyPond distribution. He suggests that a new
engraver will be needed.
Therefore, putting this up as an LSR snippet in the original fo
On 1/24/11 9:33 AM, "percival.music...@gmail.com"
wrote:
> Almost there.
>
>
> http://codereview.appspot.com/4061043/diff/19001/Documentation/snippets/new/ly
> rics-old-spacing-settings.ly
> File Documentation/snippets/new/lyrics-old-spacing-settings.ly (right):
>
> http://codereview.appspo
On 2011/01/23 22:35:02, Neil Puttock wrote:
Sorry Graham, my comment on the regtest should've been clearer: I
wasn't
proposing we add that information to the test (since it only applies
to the new
case fixed by this patch); it's just that the original text is
ambiguous (the
part about two n
Almost there.
http://codereview.appspot.com/4061043/diff/19001/Documentation/snippets/new/lyrics-old-spacing-settings.ly
File Documentation/snippets/new/lyrics-old-spacing-settings.ly (right):
http://codereview.appspot.com/4061043/diff/19001/Documentation/snippets/new/lyrics-old-spacing-setting
On 1/24/11 9:14 AM, "pkx1...@gmail.com" wrote:
> Patch v.3 is up. Still having compile issues even after Carl's
> suggestions - so I wonder if someone can take a look and see if I have
> edited in the correct place.
>
> PS. I am not seeing any emails go to dev when I update or upload so I am
> n
Patch v.3 is up. Still having compile issues even after Carl's
suggestions - so I wonder if someone can take a look and see if I have
edited in the correct place.
PS. I am not seeing any emails go to dev when I update or upload so I am
not sure if my gmail account is set up for dev properly. So I
>> By the way, how to call mf with changed output directory? I tried
>> mf '\mode:=proof; input feta-noteheads20'-output-directory=../build
>> and
>> mf '\mode:=proof; -output-directory="../build" input feta-noteheads20'
>> but both failed...
>
> It fails for me too... I've just reported this to
> Calling
> perl scripts/build/mf2pt1.pl
> from lilypond-git directory says
> Can't exec @PERL@ at scripts/build/mf2pt1.pl line 1.
> First line of that file reads
> #!@PERL@
>
> Strange...
Well, the perl script gets `massaged', and the @PERL@ construct gets
replaced with a real path to the
On Mon, Jan 24, 2011 at 11:22 AM, Han-Wen Nienhuys wrote:
> Let me whip up a prototype for you to see how it works.
See attached (it applies on top of issue3928041_55001.diff)
It is imperfect in several ways,
- see TODOs in the code.
- 4th beat 1st line: should go below
- 5th beat 1st line: sho
- Original Message -
From:
To:
Cc: ;
Sent: Monday, January 24, 2011 5:15 AM
Subject: Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
Extended to cover the other issues that were fixed along with 1120. The
regression test that /could/ have caught the breakage of issu
when going thru the snippets i came upon this confusing aggregation of voices
and staves ( http://lsr.dsi.unimi.it/LSR/Snippet?id=141 LSR 141 )
\score {
\context Voice \relative c {
\context Staff <<
\new Voice {
i don't understand this construction and i think it sho
2011/1/24 Werner LEMBERG :
>
>> mf2pt1: command not found
>
> Ah, sorry, the script is in /scripts/build, so you should
> say
>
> perl /path/to/lilypond/src/directory/scripts/build/mf2pt1.pl ...
Calling
perl scripts/build/mf2pt1.pl
from lilypond-git directory says
Can't exec @PERL@ at scripts
On 1/24/11 6:04 AM, "Mike Solomon" wrote:
> Answered my own question...new patch attached that does collision management
> before quanting and then does correct quanting.
> First one who throws it up on Rietveld wins!
>
Uploaded. I win!
Carl
P.S. Mike, did you see the email from Keith?
On Mon, Jan 24, 2011 at 10:49 AM, Mike Solomon wrote:
> I had just reverted it to the old behavior (I think...).
>
> The question is: when we have a collision like the third example, how much do
> we shorten the stems before it becomes ridiculous? We could shorten the
> stems to avoid the colli
I had just reverted it to the old behavior (I think...).
The question is: when we have a collision like the third example, how much do
we shorten the stems before it becomes ridiculous? We could shorten the stems
to avoid the collision there, but if the note were a perfect 5th lower, it'd
lead
> mf2pt1: command not found
Ah, sorry, the script is in /scripts/build, so you should
say
perl /path/to/lilypond/src/directory/scripts/build/mf2pt1.pl ...
> Or would it provide some important information?
Yes, what mf2pt1 produces shows the exact outlines of the font. This
is always good to
On Mon, Jan 24, 2011 at 9:42 AM, Mike Solomon wrote:
> Fixed, although I have no idea what the "desired output" is in this case (I
> have a feeling it's "Hey...you asked for it...").
IMO, in the last case, the stems should be shortened so there is no
collision; why is there a collision now?
--
Hey all,
I am trying to understand beam-quanting.cc better, and I think I know how I'm
gonna tackle this.
I'm going to put my collision callback before beam quanting, and then try
something to the effect of:
if (the beam was pushed up during the collision callback)
impose an insanely prohibi
Thanks Carl.
I'll check with Mike to see how he'd like to proceed with this.
Trevor
- Original Message -
From: "Carl Sorensen"
To: "Trevor Daniels" ; "LilyPond-Devel list"
Sent: Monday, January 24, 2011 2:08 AM
Subject: Re: Pentatonic Diatonic Transposition?
On 1/23/11 4:03 AM, "
hi Carl, thanks for reviewing!
> Let me start by saying I know *nothing* about mensural notation.
>
> The code looks good to me.
>
> I found only one real issue:
>
> LilyPond coding standards for C++ say that if there is only one
> statement in an if clause, we omit {} around that clause.
that's
Apologies for repeating my original message. I just subscribed and
thought that the first one didn't go through!
-Chris
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> By the way, how to call mf with changed output directory? I tried
> mf '\mode:=proof; input feta-noteheads20'-output-directory=../build
> and
> mf '\mode:=proof; -output-directory="../build" input feta-noteheads20'
> but both failed...
It fails for me too... I've just reported this to the TeXLi
2011/1/24 Werner LEMBERG :
>>> In one of my previous mails I gave you a recipe how to produce a
>>> `proof' version of the font using `mf' and `gftodvi'. It doesn't
>>> help to get the exact outline since it is always based on the
>>> rasterized output of `mf', but it nicely shows the construction
Original Message
> Somebody this weekend posted, either in an email or in an issue comment,
> that they were finally able to upload patches to Rietveld.
That was me, in an issue comment explaining why my first patch set was
bad.
I intended to follow-up to say that Python finds
Carl, having struggled myself trying to smooth the transition to the new
spacing with a snippet(s), I appreciate the simplicity of this solution.
It looks good to me.
Having text in CHANGES seems important.
A little sugar would help the medicine go down; if spin is not your
style, one of the ot
47 matches
Mail list logo
