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: Keith OHara
Subject: Re: Issue 4078: Doc: Use variables rather than instrument definitions (issue 138950043 by address@hidden)
Date: Sun, 31 Aug 2014 11:36:55 -0700
User-agent: Opera Mail/12.16 (Win32)

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

{ \set instrumentCueName = "hautbois"
   c'4
   \set instrumentCueName = "hautbois"
   \set instrumentCueName = "cor.Ang."
   c'4
   \set instrumentCueName = "cor.Ang."
   c'4
   \set instrumentCueName = "cor.Ang."
   c'4 }

However, the (mis)use of instrumentCueName for labeling the instrument that is 
playing a cue (the topic of the documentation linked above) would not seem to 
benefit from suppression of repeated settings.  The use-case is something like

oboeNotes = \relative c'' {
   R1*32
   \new CueVoice { \set instrumentCueName = "flute" }
   \cueDuring #"flute" #UP { R1 }
   g2 c,
   R1*32
   \new CueVoice { \set instrumentCueName = "flute" }
   \cueDuring #"flute" #UP { R1 }
   g2 c, }




reply via email to

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