[Top][All Lists]

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

Re: an LM update

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 James

Thanks 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.


----- 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

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

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

The best way to get started (although it's not the easiest) is to
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]