lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Doc: LM: Reformat ly code. (issue1056041)


From: Carl . D . Sorensen
Subject: Re: Doc: LM: Reformat ly code. (issue1056041)
Date: Mon, 03 May 2010 13:48:52 +0000

I'm out of time to finish this review today, so I thought it would be
best to publish what I have.

My overall thought is that in the Learning Manual, we shouldn't enforce
yet-to-be-explained coding standards.  Instead, we ought to format the
examples to do the best job possible of explaining the particular item
the example is trying to explain.

Later in Learning, when we talk about larger projects, we should
introduce the code standards and even give a link to Contributors.  In
fact, I might prefer to have the coding standards mentioned in Learning
and linked to from Contributors, but I'm not positive about that.

Thanks,

Carl



http://codereview.appspot.com/1056041/diff/1/2
File Documentation/learning/common-notation.itely (right):

http://codereview.appspot.com/1056041/diff/1/2#newcode101
Documentation/learning/common-notation.itely:101: aeses1
During the GDP, we established the policy that simple lines such as this
could
be on one line, even though they had multiple bars.

Perhaps we could just change the durations in this to 4, and we wouldn't
even
be having a discussion.

http://codereview.appspot.com/1056041/diff/1/2#newcode226
Documentation/learning/common-notation.itely:226: c4~ c8 a~ a2
I don't think a requirement to eliminate unnecessary durations is wise.

Extra durations cause no problem at all, and may even make the music
more readable.

Making sure we have a minimum set of specified durations (start of
measure or start of line) makes sense to me.

http://codereview.appspot.com/1056041/diff/1/2#newcode253
Documentation/learning/common-notation.itely:253: b'2 a4 cis,\)
Add bar check, IMO.

In terms of the core concept for this snippet, the slur and the phrasing
slur, I think the original snippet shows the structure more clearly,
with the () nested inside the \( \).  So on a strictly pedagogical
basis, I would tend to violate the general code formatting rules for
this case and leave it as-is.

http://codereview.appspot.com/1056041/diff/1/2#newcode271
Documentation/learning/common-notation.itely:271: fis2 g)
Same comment as for the previous snippet.

http://codereview.appspot.com/1056041/diff/1/2#newcode299
Documentation/learning/common-notation.itely:299: c4-+ c-_
Since the objective here is to show the articulations, we may not want
to worry about splitting the line.

If we do want to split the line, we should find two more articulations
and add them, so we get two complete bars, and put a bar check in the
middle.

http://codereview.appspot.com/1056041/diff/1/2#newcode365
Documentation/learning/common-notation.itely:365: c2 c\!
See my comment at line 289

http://codereview.appspot.com/1056041/diff/1/2#newcode390
Documentation/learning/common-notation.itely:390: a1_"legato"
Repeat of 289

http://codereview.appspot.com/1056041/diff/1/2#newcode982
Documentation/learning/common-notation.itely:982: d4 b8 g4.
Bar checks here.

Pedagogically, it may be nice to have the notes and the lyrics have
lines of the same length.

http://codereview.appspot.com/1056041/show




reply via email to

[Prev in Thread] Current Thread [Next in Thread]