https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/new/applying-note-head-styles-depending-on-the-step-of-the-scale.ly
File
Documentation/snippets/new/applying-note-head-styles-depending-on-the-step-of-the-scale.ly
(right):
https://codereview.appspot.com/7834043/diff/2001/Do
2013/3/25 :
>
> Comment #5 on issue 3266 by k-ohara5...@oco.net: \box overlaps
> http://code.google.com/p/lilypond/issues/detail?id=3266
>
> Without the boxes, the nested braces look quite pretty to me, but I have no
> idea what musical meaning they are meant to convey.
>
> Version 2.14 and earlie
Thanks for taking the time to do this. No-one else knows enough of the
various stages of processing to bring all the pieces together.
It looks like you try to use a common UP/DOWN direction for the portions
of a broken slur, and the image you posted to the bug-tracker showed a
common direction f
Code looks good, but we could get the same result with
\override Accidental #'horizontal-skylines = #'()
Incorporating the detailed outline of the accidental into the skyline of
the chord costs time, then the iterative alignment of fingering costs
more time, and if that alignment does anything
janek.lilypond wrote
> However, I think when discussing case-sensitiveness, we agreed to a
> following convention: LilyPond should differentiate between upper- and
> lowercase, but no commands/properties/etc. should differ only by case.
so the validity of a command/property/etc. can be checked by
https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/preventing-final-mark-from-removing-final-tuplet.ly
File
Documentation/snippets/preventing-final-mark-from-removing-final-tuplet.ly
(right):
https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/preventing-
LGTM.
https://codereview.appspot.com/7686046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/7836046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Another patch i understood in first reading :)
LGTM
Janek
https://codereview.appspot.com/7988043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
judging mostly from description, LGTM.
https://codereview.appspot.com/7799048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/7949044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I can still learn something new about LilyPond!
Thanks David - LGTM
(with a further suggestion)
https://codereview.appspot.com/7494049/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/7494049/diff/1/Documentation/notation/
"Trevor Daniels" writes:
> Joram Berger wrote Sunday, March 24, 2013 6:03 PM
>
>> In my opinion, it is more important to make things easy for users (more
>> than for developers). And here: x-offset or y-extent would feel more
>> consistent. Such things would not be called RIGHT-align, would they?
Joram Berger wrote Sunday, March 24, 2013 6:03 PM
> In my opinion, it is more important to make things easy for users (more
> than for developers). And here: x-offset or y-extent would feel more
> consistent. Such things would not be called RIGHT-align, would they?
> There is the constant UP, but
On 2013/03/24 19:06:49, mike7 wrote:
On 24 mars 2013, at 14:59, mailto:d...@gnu.org wrote:
>
>
https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly
> File input/regression/instrument-name-x-align.ly (right):
>
>
https://codereview.appspot.com/757404
On 24 mars 2013, at 14:59, d...@gnu.org wrote:
>
> https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly
> File input/regression/instrument-name-x-align.ly (right):
>
> https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-ali
> I really don't think we are doing people favors with trying to be as
> tricky as possible about the situation. The current situation is
> less that pretty, but at least it is not a trap.
Well, I don't want to actively push such a change, but consistency
(cf. the e-mail from Joram) is quite val
Werner LEMBERG writes:
>>> Maybe we can add some code to prevent the redefinition of `Scheme
>>> constants' (in the broadest sense) like x, y, left, right, #t, #f?
>>
>> I don't think we can really do this for Scheme, so we'd lose the
>> Scheme/LilyPond equivalence of variables.
>
> Hmm, so what
Am 24.03.2013 12:34, schrieb David Kastrup:
> Werner LEMBERG writes:
>
The axis names are #X and #Y so I am not in favor.
>>>
>>> What about changing axis names as well?
>>
>> I'm all for it.
>
> Not really easy. We have in C++ macros X Y LEFT RIGHT etc, and making
> them lowercase would h
>> Maybe we can add some code to prevent the redefinition of `Scheme
>> constants' (in the broadest sense) like x, y, left, right, #t, #f?
>
> I don't think we can really do this for Scheme, so we'd lose the
> Scheme/LilyPond equivalence of variables.
Hmm, so what about a warning:
The variable
Patchset 5 warns the user when the extent is empty and stencil isn't.
However, i'm not sure if we should warn about such situations at all;
i haven't found any similar warnings in the codebase. Also, detecting
non-empty stencils with empty extents is quite unrelated to alignment
code.
Please
Werner LEMBERG writes:
>> I really would not want to see x and y predefined as Scheme
>> identifiers. It is far too likely that someone will write things
>> like
>>
>> x = { c' d' e' f' }
>>
>> and then everything relying on #x being 0 will go southwards.
>
> Well, this can happen with everyth
> I really would not want to see x and y predefined as Scheme
> identifiers. It is far too likely that someone will write things
> like
>
> x = { c' d' e' f' }
>
> and then everything relying on #x being 0 will go southwards.
Well, this can happen with everything, so I think this argument is a
LGTM.
https://codereview.appspot.com/7949044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2013/03/24 12:45:38, dak wrote:
On 2013/03/24 12:37:14, Trevor Daniels wrote:
> I was a little concerned that problems might
> result when a non-empty stencil was given an
> empty extent, but as this passes all tests it
> looks like this fear was unfounded.
I don't think your fear is unfoun
Werner LEMBERG writes:
>> We have in C++ macros X Y LEFT RIGHT etc, and making them lowercase
>> would heavily conflict with typical variable names.
>
> Yes: cpp stuff should be uppercase.
>
>> Making things different between C and Scheme here is definitely an
>> option.
>
> I think the same: we
> We have in C++ macros X Y LEFT RIGHT etc, and making them lowercase
> would heavily conflict with typical variable names.
Yes: cpp stuff should be uppercase.
> Making things different between C and Scheme here is definitely an
> option.
I think the same: we already substitute `-' in Scheme wi
Phil Holmes wrote Sunday, March 24, 2013 2:12 PM
> In the command index of the NR, we have an entry for DS al Fine:
>
> http://lilypond.org/doc/v2.17/Documentation/notation/lilypond-index#lilypond-index_cp_letter-D
>
> However, it's not mentioned at all in the manual. Should we delete the
>
I just changed the summary of the commit messages since one commit in
the middle referred to a syntax that was only provided by a commit later
in the sequence. Just a technicality.
https://codereview.appspot.com/7799048/
___
lilypond-devel mailing lis
On 2013/03/24 12:45:38, dak wrote:
On 2013/03/24 12:37:14, Trevor Daniels wrote:
> I was a little concerned that problems might
> result when a non-empty stencil was given an
> empty extent, but as this passes all tests it
> looks like this fear was unfounded.
I don't think your fear is unfoun
In the command index of the NR, we have an entry for DS al Fine:
http://lilypond.org/doc/v2.17/Documentation/notation/lilypond-index#lilypond-index_cp_letter-D
However, it's not mentioned at all in the manual. Should we delete the
index entry?
--
Phil Holmes
__
Suggestion for regression test doc-string.
It's a bit wordier but clearer and shows you're covering cases for other
wide accidentals on the note being fingered like half-flat etc.
Cheers, Ian
https://codereview.appspot.com/7988043/diff/2001/input/regression/fingering-column-snap-radius.ly
File i
https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm
File scm/define-music-types.scm (right):
https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm#newcode77
scm/define-music-types.scm:77: \n(no direction specified), and where
@code{y} is an articulat
LGTM bar a nit-pick with the doc-string in define-music-types.scm. Sorry
for the previous message without the draft comment attached.
Cheers, Ian
https://codereview.appspot.com/7742044/diff/5001/scm/define-music-types.scm
File scm/define-music-types.scm (right):
https://codereview.appspot.com/7
On 2013/03/16 20:51:05, dak wrote:
On 2013/03/16 19:19:57, lemzwerg wrote:
> LGTM. The combination `\' `\n' `\(' is probably worth a comment in
the
> contributors' manual.
If \( was defined, things would be so much easier: one would just put
\( in the
first column. \ \n( is the best I co
https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly
File input/regression/instrument-name-x-align.ly (right):
https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly#newcode33
input/regression/instrument-name-x-align.l
On 2013/03/24 12:37:14, Trevor Daniels wrote:
I was a little concerned that problems might
result when a non-empty stencil was given an
empty extent, but as this passes all tests it
looks like this fear was unfounded.
I don't think your fear is unfounded: there just does not seem to be any
sens
I was a little concerned that problems might
result when a non-empty stencil was given an
empty extent, but as this passes all tests it
looks like this fear was unfounded.
So LGTM apart from a nitpick.
Trevor
https://codereview.appspot.com/7533046/diff/15001/lily/self-alignment-interface.cc
F
Werner LEMBERG writes:
>>> The axis names are #X and #Y so I am not in favor.
>>
>> What about changing axis names as well?
>
> I'm all for it.
Not really easy. We have in C++ macros X Y LEFT RIGHT etc, and making
them lowercase would heavily conflict with typical variable names.
Making things
On 2013/03/23 16:38:21, t.daniels_treda.co.uk wrote:
A 'programming error' should be issued only when an internal
inconsistency
in LilyPond's code or data structures is detected. Any such message
should
always result in a bug being reported and tracked. If the problem is
due to
suspect us
>> The axis names are #X and #Y so I am not in favor.
>
> What about changing axis names as well?
I'm all for it.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi David,
On Sun, Mar 24, 2013 at 8:15 AM, David Kastrup wrote:
> Eluze writes:
> please also consider making LP fully case-insensitive
>
> We had that discussion a few times already and the reasoning has not
> changed. Upper/lowercase is not defined independently from locale, and
> having iden
Hi,
On Thu, Mar 21, 2013 at 11:17 PM, David Kastrup wrote:
> Janek Warchoł writes:
>> virtually all grob properties are lowercase words separated with
>> dashes. I think we should get rid of exceptions to this rule and make
>> all grob properties lowercase [...]:
>> self-alignment-[XY]
>> [XY]-
Eluze writes:
> Jan Nieuwenhuizen wrote
>> Eluze writes:
>>
>>> please also consider making LP fully case-insensitive
>>
>> Why consider stupid ideas? While it was a misguided
>> thing to do with ascii, especially in the era of utf-8
>> case-insensivity has become an impossible can of worms.
>
44 matches
Mail list logo
