Issue 754: \transpose should not affect \transposition

Issue 754: \transpose should not affect \transposition

This is just the first pitch, to get a view of the affected regtests
involving quoting (the Midi will usually not be compared by the
regtests).

[dak, 2013-02-05 15:36:14]

Invert meaning of instrumentTransposition again (cf 1965ca6b70aa)

[dak, 2013-02-05 16:32:32]

Change quote-transposition regtest description

[Keith, 2013-02-06 07:11:34]

This works, including midi and cues between transposing instruments.

I somewhat recommend doing only patch set 1 and the update to the regtest
documentation in set 3.  
(Or, at least put the change in patchset 2 as a separate commit, with a
convert-ly rule to say NOTSMART on any instrumentTransposition in user input.)

Although most people find it confusing (and would not mind changing their
scores) some people might have used the strange but consistent logic of the
behavior in master:

 clarinet = { \transposition bes \key d\major
    d'4 e' fis' g' }
 % the clarinet player is ill; give his part to the flute
 flute = \transpose d c { \clarinet }  
 % ... and for some reason we need midi or cues.

If someone depended on that behavior (maybe in a more elegant or clever way than
we have foreseen) we would want to let that someone use a version of
\transposition that works as it does in current master.

https://codereview.appspot.com/7304044/diff/6001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

https://codereview.appspot.com/7304044/diff/6001/ly/music-functions-init.ly#n...
ly/music-functions-init.ly:491: instrumentSwitch =
If and when you revert the negation of instrumentTransposition, you need to get
set an untransposable property on the music created here.
Otherwise, \transpose c d { ... \instrumentSwitch  ... }  has the problem
originally reported by Werner in 2004.

[dak, 2013-02-06 11:15:41]

On 2013/02/06 07:11:34, Keith wrote:
> This works, including midi and cues between transposing instruments.
> 
> I somewhat recommend doing only patch set 1 and the update to the regtest
> documentation in set 3.  
> (Or, at least put the change in patchset 2 as a separate commit, with a
> convert-ly rule to say NOTSMART on any instrumentTransposition in user input.)

Well, the current commit structure is

commit 055502c402fc90ba208e48c39e6d4f1c50a19fa6
Author: David Kastrup <dak@gnu.org>
Date:   Tue Feb 5 14:48:46 2013 +0100

    Invert the meaning of instrumentTransposition again.
    
    This basically reverts commit 1965ca6b70aaf2c04a25ace9ed3f1fb4e1222f5a
    and the preceding one.
    
    Files affected:
    
        lily/note-performer.cc
        lily/quote-iterator.cc
        ly/music-functions-init.ly
        scm/define-context-properties.scm

commit 881f2ef1698f1d01276212bb826a31b4e9edd141
Author: David Kastrup <dak@gnu.org>
Date:   Tue Feb 5 17:31:48 2013 +0100

    Adapt input/regression/quote-transposition.ly to new realities

commit f4bc3312b498d9bf304d82b7d56fcd6d872a5dd6
Author: David Kastrup <dak@gnu.org>
Date:   Tue Feb 5 12:06:26 2013 +0100

    Issue 754: \transpose should not affect \transposition

We really need to check out Gerrit at some point of time.  I don't see
the point in _not_ inverting the instrumentTransposition sign: our
documentation gets it wrong, and all regtests are wrong.  What is a
nuisance is that marking QuoteMusic from \cueDuringWithTranspose (or
whatever it is called) as untransposable in order to save
quote-transposition from tampering is not feasible as 'element _has_
to be transposed.

I am currently rewriting the whole mess of \cueDuringWhatever to give
it a sensible interface.  LilyPond is sometimes such an arcane heap
of junk.

[dak, 2013-02-06 11:15:48]

https://codereview.appspot.com/7304044/diff/6001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

https://codereview.appspot.com/7304044/diff/6001/ly/music-functions-init.ly#n...
ly/music-functions-init.ly:491: instrumentSwitch =
On 2013/02/06 07:11:34, Keith wrote:
> If and when you revert the negation of instrumentTransposition, you need to
get
> set an untransposable property on the music created here.

Well, that makes sense.  Except for the "If and when" part.  There is
no point in making \instrumentSwitch behave any different from
\transposition on its own either case.

[Keith, 2013-02-07 07:05:34]

On 2013/02/06 11:15:41, dak wrote:
> I don't see
> the point in _not_ inverting the instrumentTransposition sign: 
> our documentation gets it wrong, and all regtests are wrong.  

I cannot follow the multiple negatives, but I can see some point to /either/
convention.

1) Storing the pitch written to sound middle C in instrumentTransposition as in
ver2.16 (i.e., the inverse of pitch we use to describe the transposition, d' for
clarinet in B-flat ) means that all pitches in the stream are /written/ pitches.
 

The pitch in the event that sets instrumentTranposition would usually be
protected from \transpose, but users would retain the capability to \set
instrumentTransposition  without the protection.  Since all \transpose'd pitches
are written pitches, the effect is consistent.  Some people took advantage of
that consistent behavior
<https://lists.gnu.org/archive/html/lilypond-user/2006-10/msg00074.html>

2) Storing the sounding pitch corresponding to written middle C in the
instrument part (i.e., storing directly the pitch we use to describe the
transposition) is simpler, and most of the documentation thinks LilyPond works
this way already.

[dak, 2013-02-07 08:45:48]

On 2013/02/07 07:05:34, Keith wrote:
> On 2013/02/06 11:15:41, dak wrote:
> > I don't see
> > the point in _not_ inverting the instrumentTransposition sign: 
> > our documentation gets it wrong, and all regtests are wrong.  
> 
> I cannot follow the multiple negatives, but I can see some point to /either/
> convention.

A "convention" is something that gets adopted by consensus among
different choices.  Since neither the documentation writers nor the
programmers writing the regtests have joined that consensus, the
current behavior would seem to lack what it takes to make a
convention.

> 1) Storing the pitch written to sound middle C in
> instrumentTransposition as in ver2.16 (i.e., the inverse of pitch we
> use to describe the transposition, d' for clarinet in B-flat ) means
> that all pitches in the stream are /written/ pitches.

Wrong.  instrumentTransposition does not store a written pitch, it
stores a pitch _difference_.  It does not correspond to any written
pitch.

> The pitch in the event that sets instrumentTranposition would
> usually be protected from \transpose, but users would retain the
> capability to \set instrumentTransposition without the protection.

Frankly, it is probably a mistake to store instrumentTransposition in
the form of a pitch susceptible to transposition at all.  Maybe one
should instead store it as a pair or list of pitches and thus make it
impervious to transposition.  Or maybe property-setting commands
should have 'untransposable' set by default.  That probably makes a
_whole_ lot more sense than meddling with \transposition and
\instrumentSwitch.

> Since all \transpose'd pitches
> are written pitches, the effect is consistent.

Not at all.  \transposition c' should be a noop.  Instead it means
"break \transpose for the purpose of Midi and quoting".  That's not
consistent.

You can't transpose a piece as a whole if it contains any
\transposition.  That's the opposite of consistent.

> Some people took advantage of that consistent behavior
> <https://lists.gnu.org/archive/html/lilypond-user/2006-10/msg00074.html>

Sure, people will take advantage of _any_ _reproducible_ (not
necessarily "consistent") behavior.  But if we let this rule our
decisions, LilyPond is finished.  We can't improve it any more.

And since \transposition is slated to _not_ get warped by \transpose
in future, it seems like a weak substitute to now offer a
property-setting command as an alternative for breaking \transpose.
In fact (see above) I would propose that the property-setting command
behaves _identically_.

> 2) Storing the sounding pitch corresponding to written middle C in
> the instrument part (i.e., storing directly the pitch we use to
> describe the transposition) is simpler, and most of the
> documentation thinks LilyPond works this way already.

It is not just the documentation.  It is also the regtests, apart from
the single regtest where Han-Wen convinced himself that this behavior
was worth describing and checking.  The description of this regtest as
far as I can see was not touched while the definition of
instrumentTransposition was changed back and forth.  That's creepy,
man.