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

[pkx166h]

Thanks Marc and Heikki.




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

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2656
Documentation/notation/input.itely:2656: way for aurally checking music
output; e.g. notes that have been entered
On 2014/09/27 20:52:40, ht wrote:
> More precisely (cf. the previous version of the text), it's not (just)
the MIDI
> standard, but the possibility to have LilyPond produce files
conforming to this
> standard, which allows checking the music output aurally (with the
help of an
> application or device that understands MIDI).

Thanks, I reworded the paragraph.

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2658
Documentation/notation/input.itely:2658: easy to spot when listening to
MIDI output.
On 2014/09/27 20:52:40, ht wrote:
> Instead of making promises here, I'd write "Listening to MIDI output
may help in
> spotting these errors." (Speaking only from my own experience :-)

Done.

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2661
Documentation/notation/input.itely:2661: software to extract sound from
them.
On 2014/09/27 20:52:40, ht wrote:
> Since MIDI files do not contain sound, is "extract" the correct term?
("Produce"
> could be a possible alternative.)

Done.

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2677
Documentation/notation/input.itely:2677: @code{\midi} block within the
@code{\score} block;
On 2014/09/27 20:52:40, ht wrote:
> "To create simple MIDI output from a LilyPond input file, insert ..."
> => "To create a MIDI output file from a LilyPond input file, insert
..."

> (I guess the simplicity of the output depends on the input, unless
"simple" is
> supposed to refer to the limitations in the MIDI output...  Also, it's
important
> to mention that a file will be output as a result, as plain "MIDI
output" could
> also mean other things, such as sending MIDI events directly to a MIDI
device.)

Done.

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2703
Documentation/notation/input.itely:2703: in existing channels being
overwritten.
On 2014/09/27 20:52:40, ht wrote:
> The fact that it's channel #10 that is used for drums is a MIDI
technicality (as
> the user has no direct way of controlling the MIDI channel allocation
except for
> possibly reordering staves in a score, assuming the default
"channel-per-staff"
> allocation mode).  It could be simpler to say that there are 15 MIDI
channels
> available, and one additional channel for drums.

> Also, scores with more than 15 staves will result in some of the
staves
> *sharing*, but not overwriting, the same MIDI channel.  Whether this
is really a
> problem depends on whether there are conflicting changes to
channel-based MIDI
> properties (such as the MIDI instrument) in these staves.

Done.

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2747
Documentation/notation/input.itely:2747: @emph{two} @code{\score}
blocks; one for MIDI (with unfolded repeats)
On 2014/09/27 16:53:21, marc wrote:
> this is a bit misleading IMHO:

> You don't need two \score blocks when using \unfoldRepeats
> but you rather need \unfoldRepeats when dealing with both printable
output and
> MIDI

OK just to confirm the example given (and so hence my misleading
wording) is

%%
\score {
  ... music ...
  \layout { }
}
\score {
  \unfoldRepeats {
   ... music ...
  }
  \midi { }
}
%%

But simply writing

%%
\score {
  \unfoldRepeats {
   ... music ...
  }
  \layout { }
  \midi { }
}
%%

is OK? And the 'convention' (of some I suppose) to have two score blocks
is to simply make it easier to separate the notation part of the
LilyPond input file from the MIDI part of the LilyPond input file?

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2781
Documentation/notation/input.itely:2781: instruments, @code{\midi} block
properties and/or using the the
On 2014/09/27 20:52:40, ht wrote:
> "using the the" => "using the"

Done.

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2866
Documentation/notation/input.itely:2866: @cindex context definitions
with MIDI
On 2014/09/27 20:52:40, ht wrote:
> Up to this point, the flow of material in the MIDI section has been
very logical
> and easy to follow.  The examples in this subsection however seem to
break this
> flow by referring to concepts (such as dynamics, and performers) that
haven't
> been fully introduced.  Of course, this could well be acceptable -
after all,
> the NR is a reference manual - however, understanding the examples of
this
> subsection could perhaps be helped with a description about the
various MIDI
> performers and their purpose (now that the MIDI section is being
improved).

> Also, unlike the material presented so far, information about context
> modifications and rearrangements may be not as immediately relevant
for "basic"
> MIDI usage (such as generating MIDI, and changing instruments, tempo,
or
> dynamics).  Therefore the subsection could possibly be even moved as
"more
> advanced" material nearer the end of the MIDI section, after the
subsection on
> MIDI dynamics.

Yes I agree, I have moved this whole section as suggested to the end.

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2926
Documentation/notation/input.itely:2926: to match any articulations,
tempo indications, dynamic marks etc.
On 2014/09/27 20:52:40, ht wrote:
> I think that the Articulate script doesn't concern itself at all with
MIDI
> dynamics; even when using the script, dynamics are still handled by
LilyPond's
> standard Dynamic_performer.

> However, there's a previous patch by Devon Schudy (issues 3664 and
3740) which
> makes some expressive marks (such as staccato) affect MIDI dynamics
when *not*
> using the \articulate function (this function in effect removes all
such
> expressive marks from the input, so no MIDI volume adjustments are
made).
> (There's documentation about the improvements in the 2.19 Changes
document.)

I've removed the mention of 'dynamics' - stacatto et al is already
mentioned in the @knownissues (it being an 'issue' in that we only
support 'simple' articulations).

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode2933
Documentation/notation/input.itely:2933: volume linearly between their
two extremes.
On 2014/09/27 20:52:40, ht wrote:
> This paragraph is not specific to the Articulate script; it actually
describes
> the behavior of the standard Dynamic_performer.

I moved this para lower down, within but towards the end of the
subsection previously referenced that is now at the end of this section
and included an explicit reference to the Dynamic_performer in
internals, just in case it was not clear.

https://codereview.appspot.com/120480043/diff/100001/Documentation/notation/input.itely#newcode3011
Documentation/notation/input.itely:3011: marking.
On 2014/09/27 20:52:40, ht wrote:
> The new version of the text omits the detail that each of the dynamic
markings
> corresponds to a fraction of the available volume range.  I think that
it would
> still be useful to describe the range for the "internal values", for
example, to
> help understand what the number 0.9 means in the \rfz snippet.

Yes. Thanks, done.

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