James E. Bailey wrote March 23, 2009 12:43 PM
Am 23.03.2009 um 13:24 schrieb Trevor Daniels:
Hi James
The main difficulty I have with this simple change is that Voices
have not been introduced at this point in the Tutorial. They are
not mentioned in the Learning Manual until Chapter 3. One of
the principles we adopted for the Learning Manual was not to use
a concept until it had been fully explained. That is why we did
it the way we did. Do you not think dumping a \new Voice
command here leads to even more confusion? Or do you think our
principle is wrong? It was getting around this difficult that
put me off doing it myself - it means a lot of work to do it
properly. Perhaps a better way would be to simply remove
section 2.3.5 from the tutorial and leave polyphony until
Chapter 3 and do it properly there. What do you think?
I asked myself all of those same questions. I understand the
philosophy of not using a term until it's been explained, I think
it's a very good policy, especially in the learning manual. I
tried re-writing the section a couple of times, but I could never
get it as well written as it is in the NR. Although the terms
aren't defined, per se, I think the context is clear, it's very
clear that for single- staff polyphony, at least two voices will
be on one staff, and we see in the example that there is a \new
Voice. I also considered using the first example from the NR,
simply because it explicitly creates both voices, but decided
against it because that what the shorthand does, and where the
problems arise.
Personally, I think that if single-staff polyphony is introduced
here, I think it would suffice to give beginning users the tools
to be able to use the construct, without going into the specifics
of everything that's happening, and simply have pointers in the
See Also to the relevant sections.
OK, if you want to do it this way I think you need at the
minimum to add a para which says something like this is just
a recipe, terms are not explained here, see ... for a full
explanation of Voices. Just to recognise the principle is
being violated.
I'd like to say that I think removing polyphony here is a viable
solution, but I don't really believe that. Vocal music is heavily
reliant on this single staff polyphony. It's far too important
and often-used concept to really not introduce in the Learning
Manual.
Personally I'd prefer to either remove it, or replace it with
something like, "The concepts required to write polyphony
are not introduced until section 3.2." And of course fix 3.2.
And, I want to re-iterate how amazingly well the NR discusses this
topic. It's thorough, concise, and well-written. I really think
that the short version introduction in the LM, with pointers to
the more thorough version in the NR is the best solution.
Trevor
----- Original Message ----- From: "James E. Bailey"
<[email protected]>
To: "Trevor Daniels" <[email protected]>
Cc: "Carl D. Sorensen" <[email protected]>; "lilypond-devel"
<[email protected]>; "lilypond-user Mailinglist" <lilypond-
[email protected]>
Sent: Monday, March 23, 2009 11:51 AM
Subject: Re: an LM update
Am 17.03.2009 um 10:39 schrieb Trevor Daniels:
Hi James
You wrote Tuesday, March 17, 2009 9:00 AM
On 17.03.2009, at 00:47, Carl D. Sorensen wrote:
On 3/16/09 11:52 AM, "James E. Bailey"
<[email protected]> wrote:
On 16.03.2009, at 16:43, Graham Percival wrote:
c) Can we just make the change so that more people aren't
confused by
the issue. (I've answered another question related to this
in the
last
week)
Yes, please do. Carl can help you get started as a Frog;
we
desperately need more people writing patches for such
problems.
Perfect, where do I begin? I already know exactly what to
change
and
where.
Please look at the Contributor's Guide in the docs. From the
main doc page
choose Developer's Resources, then you'll see the
Contributor's
Guide.
The best way to get started (although it's not the easiest)
is to
install
git and pull a copy of the repository from Savannah. Then
you
can make the
changes and create a patch. The Contributor's Guide
describes
how to do it.
I've gotten this far, and everything is fine.
If I understand this correctly, you're proposing to make
changes
to the
docs, rather than the code. Is that right? If so, you
should
submit your
patch to Trevor Daniels, rather than to me.
Correct, will do.
Please let me know if you have further questions.
I don't know where to find the files that I would use to make
the
change. The Producing a patch and Documentation policy didn't
help
much in this regard. Is there somewhere that explains what the
files are? I have the Documentation, and I imagine that what
I
need is somewhere in the user folder, but I'd hoped for a
structure that would have the learning manual and then the
various sections of the learning manual, so I can make the
change. Regardless of how it's organized, I just don't see
where
to find section 2.3.5 of the Learning Manual. Help?
The source code of the LM is all in the
Documentation/user directory. The file names are
roughly the same as the chapter or section names in
the manual, so you'll find 2.3.5 in tutorial.itely.
Attached is my attempt to make a .diff. It's my first time, so
if I
didn't do it right, let me know. It's a learning process for me.
All
I did was copy/paste the polyphony instructions from the
Notation
Reference, and updated the examples. I really do think it's very
well
written, and explains everything so well as it goes along, that
I
couldn't have done a better job trying to re-write it.
If this is okay, I'll take a look at the fundamental and see if
I can
help there.
----------------------------------------------------------------------
----------
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
