Doc: Issue 4059: Document MIDI mapping and MIDI effects

Doc: Issue 4059: Document MIDI mapping and MIDI effects

  Based on original text supplied by Heikki Tauriainen

[Keith, 2015-07-04 03:59:36]

Sorry I'm late.
You might still slip in a correction, or just remove mention of
midiChannelMapping='voice since we haven't found a use for it.

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

https://codereview.appspot.com/249980043/diff/1/Documentation/notation/input....
Documentation/notation/input.itely:3279: @ref{MIDI channel mapping}).
This is the part that doesn't work.  We could say
"the MIDI channel associated with the current Staff (or the current the Voice if
you have moved the Staff_performer to the Voice context).  If you set
midiChannelMapping to 'instrument, all staves with the same instrument are
affected when you set one of these context properties.  Setting
midiChannelMapping to 'voice often prevents the context properties form having
effect."

[Trevor Daniels, 2015-07-06 22:19:20]

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

https://codereview.appspot.com/249980043/diff/1/Documentation/notation/input....
Documentation/notation/input.itely:3279: @ref{MIDI channel mapping}).
On 2015/07/04 03:59:36, Keith wrote:
> This is the part that doesn't work.  We could say
> "the MIDI channel associated with the current Staff (or the current the Voice
if
> you have moved the Staff_performer to the Voice context).  If you set
> midiChannelMapping to 'instrument, all staves with the same instrument are
> affected when you set one of these context properties.  Setting
> midiChannelMapping to 'voice often prevents the context properties form having
> effect."

Doesn't the paragraph under 'voice above explain explicitly what happens?  That
seems better than the rather vague "often prevents the context properties ...". 
There already is a reference back to that explanation.

Trevor

[Keith, 2015-07-07 05:55:03]

On Mon, 06 Jul 2015 15:19:20 -0700, <tdanielsmusic@googlemail.com> wrote:

>> Setting
>> midiChannelMapping to 'voice often prevents the context properties
>> from having effect."
>
> Doesn't the paragraph under 'voice above explain explicitly what
> happens?  That seems better than the rather vague "often prevents the
> context properties ...".  There already is a reference back to that
> explanation.
>

I didn't think the paragraph under 'voice sufficiently discouraged its use.  It
describes a first-approximation of the behavior, but the description isn't
complete, and the behavior isn't transparent:
\score{
   \new Staff <<
     \new Voice = "violin" {
       c'4
       % set the voice below to flute
       \set Staff.midiInstrument = "flute"
       r g' r }
     \new Voice = "flute" {
       % set the voice above to violin
       \set Staff.midiInstrument = "violin"
       r4 c' r g' } >>
   \layout{}
   \midi{\context {\Score midiChannelMapping=#'voice }}

I don't think midiChannelMapping='voice has any use.  Somebody added the code
under sponsorship from Fruity Loops Sequencer, so if it has any use it is in
conjunction with that software, so let the sponsor document it there.

That programmer who added the code didn't know about Lilypond's
engraver/performer method of routing events and property-changes to output, and
didn't know much about midi, so the data flow doesn't make much sense in the
context of Lilypond and MIDI.

[dak, 2015-07-07 07:01:27]

"Keith OHara" <k-ohara5a5a@oco.net> writes:

> That programmer who added the code didn't know about Lilypond's
> engraver/performer method of routing events and property-changes to
> output, and didn't know much about midi, so the data flow doesn't make
> much sense in the context of Lilypond and MIDI.

git log -S midiChannelMapping

flags the culprit as a certain Jan Nieuwenhuizen.  Our current dearth of
development power makes it inadvisable to discourage contributors
showing a certain promise.  There was obviously a perceived need for
this feature: maybe is could better be met with different semantics?  If
so, which?

-- 
David Kastrup

[Trevor Daniels, 2017-01-28 21:59:11]

Pushed to staging as
[r37cfad99ea310993f6c3012330d0b56c390cd146]

Closing ...