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

[pkx166h]

Thanks to Trevor and Heikki.

Issues still to be resolved:

Do we still need to move the articulate section and if so, where?


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

https://codereview.appspot.com/120480043/diff/200001/Documentation/notation/input.itely#newcode2677
Documentation/notation/input.itely:2677: To create a MIDI output file
from a LilyPond input file, insert an empty
On 2014/12/07 23:43:00, Trevor Daniels wrote:
> It doesn't have to be empty.  Maybe "insert a @code{\midi} block,
usually empty,
> within ..."

Done.

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#newcode2683
Documentation/notation/input.itely:2683: To create a MIDI output file
from a LilyPond input file, insert an empty
On 2014/12/07 23:43:00, Trevor Daniels wrote:
> It doesn't have to be empty.  Maybe "insert a @code{\midi} block,
usually empty,
> within ..."

Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2852
Documentation/notation/input.itely:2852: @code{channel 10 drum-kits}
entries listed in @file{scm/midi.scm} for
On 2014/12/07 23:43:00, Trevor Daniels wrote:
> I'm not convinced this is an improvement.  It is unfair to expect
> non-programming drummers to (a) locate a file buried deep in the file
hierarchy
> and (b) understand enough of Scheme to read far enough to find this.
I think
> the original wording was more helpful, although I don't mind adding
the
> reference to the Scheme file with something like, "a full list can be
found ...
> ".  But then you'd need to add a @seealso to LM 4.7.4 Other sources of
> information.

Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2880
Documentation/notation/input.itely:2880: turns) to be processed.A full
list of supported items can be found in
On 2014/12/07 23:43:00, Trevor Daniels wrote:
> 2 spaces please

Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2881
Documentation/notation/input.itely:2881: the script itself.  See
@file{ly/articulate.ly}.
On 2014/12/07 23:43:00, Trevor Daniels wrote:
> Another @seealso to 4.7.4 Other sources of information.

Done.

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
On 2014/12/14 14:07:24, ht wrote:
> mght -> might

Done.

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
On 2014/12/14 14:07:24, ht wrote:
> 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.

Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2971
Documentation/notation/input.itely:2971: the @code{Staff} context.
On 2014/12/14 14:07:24, ht wrote:
> 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.

Thanks I've swapped the sections around (I appreciate the time you take
to explain the reasoning). I have left in the 'simple' example though as
I think it is more helpful with both the single and multi-staff
examples.

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