|From:||James E . Bailey|
|Subject:||Re: an LM update|
|Date:||Mon, 23 Mar 2009 13:43:50 +0100|
Trevor forgot to cc the list. Am 23.03.2009 um 13:24 schrieb Trevor Daniels:
Hi JamesThanks for doing this, but it doesn't seem to apply. I'm not familiar enough with patches to identify the problem with certainty, but git apply says "Error: no changes" and terminates.It would be best if you simply edit tutorial.itely (being sure to have no trailing spaces) and then make a patch as described in the Contributors Guide 1.3.1. This will include your email address (or should if you have set up git correctly), so you will be correctly identified in the commit message. Email this to me as an attachment and all should be well. But before you do ... read on.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.
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.
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 updateAm 17.03.2009 um 10:39 schrieb Trevor Daniels:Hi James You wrote Tuesday, March 17, 2009 9:00 AMOn 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 bythe issue. (I've answered another question related to this in thelast 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.---------------------------------------------------------------------- ----------
|[Prev in Thread]||Current Thread||[Next in Thread]|