On Sun, 17 Aug 2008 16:02:10 -0400
Kieren MacMillan <[EMAIL PROTECTED]> wrote:
> Hi Graham,
>
> > The rest of the docs place the { or << on the same line:
> > \header {
> > Please do the same here.
>
> I will, but I officially file a protest: I find it *much* harder to
> visually match delimiters (braces, brackets, etc.) with that
> convention, just as I find it harder in Java code (where they use
> the same Mao-ing convention).
Protest noted but overruled: we're not going to redo the entire
manual. :) Besides, as long as you use proper indentation,
matching blocks of code is simple.
> > I very rarely include s1*4 \bar "|." in my global variable --
> > is this good practice?
>
> 1. Why wouldn't it be?
Dunno. :)
> 2. If the \bar command ___ or any command, for that matter ___ is in
> literally every note variable (as it is in the existing templates),
> doesn't it scream "I'm a global value!"? What if you need to change
> it?
I normally just dump it in the first violin, but of course then I
always need to go back and add it manually to the other
instruments when creating separate parts.
I'm content to keep it in the global var. In this case, I was
just asking.
> > Why manually number the bars?
>
> I'll give you my most recent opera score WITH MY CODE BAR NUMBERS
> REMOVED, and then ask you to add a cautionary accidental to the
> first quarter note in m. 413 of the violin music... ;-)
Welcome to the world of point-and-click? ;)
(not that I use it myself, but wasn't it invented for exactly this
purpose?)
> 2. Good to see that templates are capable of teaching even the most
> jaded ___ I mean "experienced" ___ Lilyponders! ;-)
I'm jaded, not experienced. I've never done vocals other than
\addlyrics (in the tutorial), I've never played with proportional
notation other than creating two-bar exercises, the biggest scheme
I've done was rewriting NR 6, etc. Half of the doc team now knows
more about lilypond than I do -- especially Trevor, who started as
an almost complete newbie a year ago.
That, more than anything else, tells me that I did a good job with
GDP.
> > - is it worth including instr or shortName or whatever that
> > command is called these days?
>
> Maybe!
>
> > - how do you feel about adding a newline after the \with { ?
> > Again, that's the style of the rest of the docs.
>
> I think code should always aim for the sweet spot of
> comprehensibility and terseness, in that order ___ we can debate
> various options, and come to a collective agreement.
I'm willing to discuss this point, especially with reference to
including instr in the \with{} section.
> > - manual style calls for comments to be placed on the line above:
> > %% uncomment this line to enable MIDI output
> > % \midi{}
>
> 1. So you uncomment the comment to enable MIDI output? ;-)
> 2. I'm not a fan of adding code lines unnecessarily.
I'm not willing to discuss this point. ;) Again, for consistency
with the rest of the manual. Please change to:
%% uncomment the next line to enable MIDI output
% \midi{}
(hey, we save so many lines by writing \header{ that we can afford to
add one more line for the separate-line comment! :)
Cheers,
- Graham
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
