[Top][All Lists]

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

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

From: pkx166h
Subject: Re: Doc: NR section 3.5.x MIDI file creation tidy up (issue 120480043 by address@hidden)
Date: Sat, 27 Sep 2014 21:48:14 +0000

Thanks Marc and Heikki.
File Documentation/notation/input.itely (right):
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.
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 :-)

Documentation/notation/input.itely:2661: software to extract sound from
On 2014/09/27 20:52:40, ht wrote:
Since MIDI files do not contain sound, is "extract" the correct term?
could be a possible alternative.)

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

Documentation/notation/input.itely:2703: in existing channels being
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
allocation mode).  It could be simpler to say that there are 15 MIDI
available, and one additional channel for drums.

Also, scores with more than 15 staves will result in some of the
*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.

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

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

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
been fully introduced.  Of course, this could well be acceptable -
after all,
the NR is a reference manual - however, understanding the examples of
subsection could perhaps be helped with a description about the
various MIDI
performers and their purpose (now that the MIDI section is being

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,
dynamics).  Therefore the subsection could possibly be even moved as
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.
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
dynamics; even when using the script, dynamics are still handled by
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
expressive marks from the input, so no MIDI volume adjustments are
(There's documentation about the improvements in the 2.19 Changes

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]