Re: Documentation for issues 3601 (based on 3581), 4042 (NR: "MIDI output", Section 3.5)

[James]

Heikki,

On 09/08/14 22:14, Heikki Tauriainen wrote:
> Hi,
>
> In response to
> <http://lists.gnu.org/archive/html/lilypond-devel/2014-08/msg00060.html>,
> here's some new documentation for Section 3.5 ("MIDI output") of the
> Notation Reference (v2.19.11).  The main goal of the proposed additions
> is to describe the MIDI context properties implemented in issues 3581
> (with issue 3601 about the missing documentation) and 4042.  (I'm the
> author of the code patches in those issues.)
>
> To support this goal, I'll also propose changes to some existing
> sections of the documentation: these changes include an attempt to (at
> least partially) document the Score.midiChannelMapping context property,
> and an expanded description of MIDI channels.
>
> The changes proposed (in plain text) to the documentation are
> interleaved with my comments and questions.  If it'd be more useful to
> format the actual changes in some other way, please tell me what I need
> to do.  (I'm already sorry about any procedural mistakes I've probably
> made here because the changes likely already qualify as "larger
> contributions" mentioned in the Contributor's guide, however from the
> previous discussion I understood that it would still be OK to just send
> these suggestions to the bug list.  This is the first time I've ever
> proposed any changes to the documentation...)
>
> Best regards,
> Heikki Tauriainen
>
> ======================================================
...

Thanks, I created

http://code.google.com/p/lilypond/issues/detail?id=4059

For this email.

I am currently using

http://code.google.com/p/lilypond/issues/detail?id=2877

As the tracker for my changes to the section. Once I have done this then 
I will apply your corrections from 4059.

I could do one huge re-write of 3.5 patch but I have learned (the hard 
way) that this is usually counter-productive as no one wants to review 
huge changes to documentation. So I am going to do the re-write and then 
over the next week or so merge those changes into the current 
documentation, so as to make it easy to review but also not leave the 
documentation in an even-worse state than it was before.

James