"Keith OHara" <k-ohara5...@oco.net> writes:
> On Wed, 27 Feb 2013 00:47:21 -0800, <d...@gnu.org> wrote:
>
>> On 2013/02/27 07:40:59, Keith wrote:
>>
>>> Oops. It was \oldTransposition but it was not put into LilyPond.
>>
>> Since the sign of instrumentTransposition has been inverted, it would
>> require serious trickery or a separate music event type to implement
>> \oldTransposition with the previous semantics.
>
> The \oldTransposition you suggested in
> <https://codereview.appspot.com/7303057> has the required trickery,
> and I just re-checked that it works fine.
Would you believe that I had already forgotten about this contraption?
It did not exactly get a favorable review from you, either.
Ok, but we'd still need to figure out how to deal with this abomination.
I'd prefer not giving it a name of its own, instead load a Scheme file
on-demand that redefines \transposition (of course, that does not work
using the given definition with #{ \transposition ... #} inside but that
is easily fixed). That way, our proper code base steers clear of this
kind of cruft.
The question is what convert-ly should try doing about it. Just issue a
diagnostic when seeing \transposition? Load the compatibility file
unconditionally? Load/warn only given certain patterns?
> Probably no-one has used \addInstrumentDefinition for transposition,
> but if someone has, the instrumentTransposition assignments already
> use ly:make-pitch, so inserting ly:pitch-negate is not too much work.
Patterns for that will not exactly be easy to make since
instrumentTransposition is usually an alist.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
