Re: Doc: NR section 3.5.x MIDI file creation tidy up (issue 120480043 by address@hidden)

[ht . lilypond . development]

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2890
Documentation/notation/input.itely:2890: @warning{The @file{articulate}
script may shorten chords, which mght not
mght -> might

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2893
Documentation/notation/input.itely:2893: and breaths and so could sound
worse; in this case reconfigure the
Technically, possibly a more relevant reason why the output could sound
worse is that the \articulate function will alter the default output
even for *notes without any articulations* (as every note without any
articulation will get "shortened" by ac:normalFactor), and slurs just
(temporarily) *disable* this shortening behavior (so, in fact, the note
at which a slur ends is the only note which \articulate will shorten, at
least in the simple case where the slurred notes don't have any other
articulations).

I don't wish all this technical detail to be added here: instead, I'd
change the part added to the previous documentation (after the sentence
about shortening chords) to something like:

    The \articulate function also shortens notes that do not have any
    articulations and so could make them sound worse; to compensate for
    unwanted side effects, restrict the use of the function to shorter
    segments of music, or modify the values of the variables defined in
    the @file{articulate} script to customize the shortening behavior.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2971
Documentation/notation/input.itely:2971: the @code{Staff} context.
I'm sorry to still return to this section, but I noticed that the
proposed new organization of the material here could leave some
confusion as to how the different ways of setting the minimum and
maximum MIDI volume interact.

I think that it might be clearer (as in the previous documentation) to
still start with describing how to set midiMinimumVolume and
midiMaximumVolume on the Score level, and only then move to tuning the
volume ranges on the Staff level (since Staff-level properties will
override any Score-level ones), or using a custom
Score.instrumentEqualizer (which is really an alternative to setting
midiMinimumVolume and midiMaximumVolume – in the Dynamic_performer
implementation, it looks like Score.instrumentEqualizer will not be
consulted at all in a context if either midiMinimumVolume or
midiMaximumVolume has been set in any enclosing context).

This could be achieved by switching the order of the current text (about
Staff.midi{Minimum,Maximum}Volume) and the text about setting the
properties at the Score level (starting at line 3015 below).  In this
case also the example starting at line 2973 is possibly redundant: the
example which follows that one would then "continue" the flute+clarinet
example used to demonstrate setting the context properties on the Score
level.

https://codereview.appspot.com/120480043/