lilypond-devel
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: an LM update

From: Trevor Daniels
Subject: Re: an LM update
Date: Mon, 23 Mar 2009 14:19:34 -0000 

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" <address@hidden> 
To: "Trevor Daniels" <address@hidden>
Cc: "Carl D. Sorensen" <address@hidden>; "lilypond-devel" <address@hidden>; "lilypond-user Mailinglist" <lilypond- address@hidden> 
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"
<address@hidden> 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.




----------------------------------------------------------------------
----------
reply via email to
[Prev in Thread] Current Thread [Next in Thread]