lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 4078: Doc: Use variables rather than instrument definitions (i


From: David Kastrup
Subject: Re: Issue 4078: Doc: Use variables rather than instrument definitions (issue 138950043 by address@hidden)
Date: Wed, 03 Sep 2014 10:21:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> "Keith OHara" <address@hidden> writes:
>
>> On Sun, 31 Aug 2014 00:14:11 -0700, <address@hidden> wrote:
>>
>>> On 2014/08/31 06:58:47, Keith wrote:
>>>
>>> https://codereview.appspot.com/138950043/diff/1/Documentation/notation/vocal.itely#newcode2646
>>>> \set instrumentCueName = "Flute"
>>>> This is the *other* use of instrumentSwitch,
>>>> which I'll probably put back to a <>^\markup
>>>
>>> I think one of the points of the instrument switches was that you could
>>> do as many as you liked in a row (namely, attaching the instrument
>>> switch to the start of any music variable to be used for a particular
>>> instrument) without triggering extraneous switch messages.
>>>
>>> <>^\markup would seem to defeat that part of the original design.  While
>>> we don't need the instrumentSwitch command as such, the respective
>>> engravers weeding out duplication still serve a purpose.
>>
>> This particular engraver seems to try, but fails, to suppress repeated
>> identical settings.  (Maybe incorrect use of Scheme's eq? to compare
>> the strings?)
>
> Not really incorrect since strings _do_ have identity and the string
> would be coming from the same instrument definition.

Aaaaand ptooey.  When we put the equivalent of the instrument definition
into a music variable and recall that music variable with the ilk of
\kaspar, the invocation of \kaspar will copy the music including the
string contained in \set ...Name = "..." recursively.

So when moving instrument definitions to music variables, we definitely
don't want to compare using eq? any more.

-- 
David Kastrup



reply via email to

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