Reviewers: ,
Message:
I was about to push this, but then I started thinking that
the change was big enough to ask you guys for approval.
Any opposition? I'm aiming for clarity, accuracy, and
comprehensiveness. The idea is to reduce the amount of
time users spend being confused, and reduce the n
The following code causes a segfault.
LilyPond 2.13.36, GNU/Linux x86_64.
toto =
#(define-music-function (parser location arg) (ly:music?)
(display (ly:event-property arg 'name))
(make-sequential-music arg))
{ \toto a }
Also reproduced with today's git.
--verbose output isn't of any help:
[current git]
It seems that it is not possible to have a comment within #{ ... #}.
In this example
T = #(define-music-function (parser location music) (ly:music?)
#{
\times 2/3 $music ; $
#}
)
\relative {
\T { c c c }
}
lilypond complains about
On Fri, Oct 22, 2010 at 12:10 PM, Werner LEMBERG wrote:
> It seems that it is not possible to have a comment within #{ ... #}.
I believe it is (using %, as you point out). #{ #} introduces a
LilyPond syntax mode, so I wouldn't expect the ; character to suddenly
behave otherwise than in plain Lily
>> It seems that it is not possible to have a comment within #{ ... #}.
>
> I believe it is (using %, as you point out).
Have you tried it? For me, it doesn't work.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.
I think it looks very nice. Great job!
Carl
http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely#newcode232
Documentation/
On Fri, Oct 22, 2010 at 1:16 PM, Werner LEMBERG wrote:
> Have you tried it? For me, it doesn't work.
This does work:
foo =
#(define-music-function (parser location music) (ly:music?)
#{ $music % comment
#})
{ \foo a }
Cheers,
Valentin.
___
li
On 10/22/10 3:10 AM, "Valentin Villenave" wrote:
> The following code causes a segfault.
> LilyPond 2.13.36, GNU/Linux x86_64.
>
> toto =
> #(define-music-function (parser location arg) (ly:music?)
>(display (ly:event-property arg 'name))
>(make-sequential-music arg))
>
> { \toto a }
On Fri, Oct 22, 2010 at 3:02 PM, Carl Sorensen wrote:
> As near as I can tell, this code is triggering an infinite loop that fails
> when the scheme heap overflows.
Interesting.
> arg is *not* a stream-event, it's a music-event.
Indeed. But I wasn't expecting it to cause a segfault.
> Segfault
http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2670041/diff/11001/Documentation/notation/spacing.itely#newcode244
Documentation/notation/spacing.itely:244: @item @code{space} -
Hi Patrick,
On 21/10/10 01:12, pnor...@gmail.com wrote:
> Hi Ian,
>
> I just tested your patch.
>
> In addition to the small tweak that is needed (see my comment below), it
> seems that the `(use-modules (ice-9 curried-definitions))' statement
> does not carry over to display-lily.scm. I am a bi
Hi,
I'm from Poland and we use here a different chord naming convention: the
main difference is that minor chords are written with lowercase and major
chords are written with uppercase. I'd like to add this to Lily.
I found .ly files with alternative note names (used in other languages) in
\LilyPo
Hi Patrick,
Patch is attached.
Cheers,
Ian
On 18/10/10 21:31, pnor...@gmail.com wrote:
> LGTM.
>
> Ian, please send me the git patch, and I'll apply it for you.
>
> Thanks,
> Patrick
>
> http://codereview.appspot.com/2204044/
>From a12cb1e44df280a1f4320d2be1ebb34711f979f4 Mon Sep 17 00:00:00
On 10/22/10 5:08 AM, "Janek Warchoł"
wrote:
> Hi,
>
> I'm from Poland and we use here a different chord naming convention: the main
> difference is that minor chords are written with lowercase and major chords
> are written with uppercase. I'd like to add this to Lily.
I believe this has alr
On 2010/10/22 13:07:27, Mark Polesky wrote:
It will be, but that change is beyond me. I'll need to ask
Joe to do it, but I wanted to clear up everything else that
I can do on my own first. Besides, I've grown to dislike
even "base-distance" because it sounds too much like the
distance between
carl.d.soren...@gmail.com writes:
> On 2010/10/22 13:07:27, Mark Polesky wrote:
>
>> It will be, but that change is beyond me. I'll need to ask
>> Joe to do it, but I wanted to clear up everything else that
>> I can do on my own first. Besides, I've grown to dislike
>> even "base-distance" becau
Le 22/10/2010 02:20, Graham Percival disait :
Bonjour Jean-Charles,
Je ne pense pas que nous voudrons avoir @funindex
RemoveEmptyStaffContext dans la documentation, parce-que cette
commande est désapprouvé. Ligne sept cent, trente-un dans
Documentation/fr/notation/staff.itely
A votre santé, -
Am 20.10.2010 15:30, schrieb Werner LEMBERG:
The README also says that we shouldn't apply transformations to
fills, but instead transform the path then fill the path. The
current varsegno transforms the penstroke, which I think is contrary
to this instruction.
Yep. For this glyph it
> This does work:
>
> foo =
> #(define-music-function (parser location music) (ly:music?)
>#{ $music % comment
>#})
>
> { \foo a }
Interesting. This
T = #(define-music-function (parser location music) (ly:music?)
#{
\times 2/3 $music % $
#}
)
W dniu 22 października 2010 16:47 użytkownik Carl Sorensen <
c_soren...@byu.edu> napisał:
> On 10/22/10 5:08 AM, "Janek Warchoł" > wrote:
>
> > Hi,
> > I'm from Poland and we use here a different chord naming convention: the
> main
> > difference is that minor chords are written with lowercase an
On Fri, Oct 22, 2010 at 6:06 AM, Valentin Villenave
wrote:
> On Fri, Oct 22, 2010 at 3:02 PM, Carl Sorensen wrote:
>> As near as I can tell, this code is triggering an infinite loop that fails
>> when the scheme heap overflows.
>
> Interesting.
>
>> arg is *not* a stream-event, it's a music-event
Am Freitag, 22. Oktober 2010, um 20:30:29 schrieb Werner LEMBERG:
> Interesting. This
>
> T = #(define-music-function (parser location music) (ly:music?)
> #{
>\times 2/3 $music % $
> #}
> )
>
> does *not* work. Looks like a bug...
It seems like the way to
>>> The README also says that we shouldn't apply transformations to
>>> fills, but instead transform the path then fill the path. The
>>> current varsegno transforms the penstroke, which I think is
>>> contrary to this instruction.
>>>
>> Yep. For this glyph it works accidentally. Thanks f
On Tue, Oct 19, 2010 at 12:07:29AM +0100, Graham Percival wrote:
> >> python/ yes, since it's not something that people call manually.
> >> But stuff in scripts/build/ shouldn't have @PYTHON@, otherwise
> >> it'll bork if you call it manually.
> >
> > But are those scripts supposed to be used witho
On Fri, Oct 22, 2010 at 8:30 PM, Werner LEMBERG wrote:
> Interesting. This
> [...]
> does *not* work. Looks like a bug...
Sure does.
Added as http://code.google.com/p/lilypond/issues/detail?id=1356
Nice catch!
Valentin.
___
lilypond-devel mailing
Reviewers: ,
Message:
Patrick Schmidt has added two- and three-note power chords to the known
set of chord names.
He's provided both code and docs.
Please review.
Thanks,
Carl
Description:
doc additions power chords
additions to fretted-strings.itely description and examples for the use
of
Reviewers: ,
Message:
Here's a completely rewritten version of
NR 4.4.1 Vertical spacing inside a system
Comments?
Thanks.
- Mark
Description:
Doc: NR 4.4.1: Rewrite.
Please review this at http://codereview.appspot.com/2642043/
Affected files:
M Documentation/notation/spacing.itely
Mark,
I think this is a great start, and will greatly help.
The major issues I see are (1) repeating information (i.e. the meanings
of space, minimum-distance, padding, and stretchability), and (2)
introducing exhaustive lists into the NR.
Repeating information is prohibited by policy because i
On Fri, Oct 22, 2010 at 07:49:43PM +0200, Jean-Charles Malahieude wrote:
> Le 22/10/2010 02:20, Graham Percival disait :
> >
> >Je ne pense pas que nous voudrons avoir @funindex
> >RemoveEmptyStaffContext dans la documentation, parce-que cette
> >commande est désapprouvé. Ligne sept cent, trente-un
Looks mostly fine.
http://codereview.appspot.com/2686041/diff/1/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/2686041/diff/1/Documentation/notation/fretted-strings.itely#newcode1416
Documentation/notation/fr
On 2010/10/23 01:30:43, Graham Percival wrote:
Looks mostly fine.
Fixed all of these, plus another couple of lines of LilyPond code that
were incorrectly indented.
http://codereview.appspot.com/2686041/
___
lilypond-devel mailing list
lilypond-deve
On 2010/10/23 00:51:31, Carl wrote:
Mark,
I think this is a great start, and will greatly help.
The major issues I see are (1) repeating information
(i.e. the meanings of space, minimum-distance, padding,
and stretchability), and (2) introducing exhaustive lists
into the NR.
Carl,
(1) re
LGTM, go ahead and push.
http://codereview.appspot.com/2686041/diff/5001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/2686041/diff/5001/Documentation/notation/fretted-strings.itely#newcode1422
Documentation
More comments inlined.
Thanks,
Carl
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1501
Documentation/notation/spacin
LGTM, but we should add power chords to the glossary and reference it
from the @seealso.
Trevor
http://codereview.appspot.com/2686041/diff/5001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/2686041/diff/5001
35 matches
Mail list logo
