lilypond-devel
[Top][All Lists]
Advanced

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

Re: Cues (CueVoice) and quoted instrument name : InstrumentSwitch


From: David Kastrup
Subject: Re: Cues (CueVoice) and quoted instrument name : InstrumentSwitch
Date: Sun, 09 Oct 2011 13:54:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Xavier Scheuer <address@hidden> writes:

> On 9 October 2011 04:31, Keith OHara <address@hidden> wrote:
>>
>> I had so much trouble trying to use it
>> (http://lists.gnu.org/archive/html/lilypond-user/2010-10/msg00099.html)
>> that I convinced Trevor to purge it from the documentation.
>
> Hi Keith,
> Thanks for the answer.
>
> Mmh, using a zero-duration invisible rest is quite tricky (considering
> we want to print an instrument cue name)!
> I'm not confident in having tricky things in the doc.
>
> Sure there is a problem and it can be "solved" (more like a workaround,
> IMHO) but better to report the problem in order to have a proper
> solution to be implemented (like a true "InstrumentCueName" object or
> whatever the devs would consider).  And then mention this new feature
> in the doc.
>
>> They work fine for when a player switches from Flute to Piccolo and back.
>> <http://lilypond.org/doc/v2.14/Documentation/notation/writing-parts#index-instrumentSwitch>
>>
>> The difficulty was in trying to inject the right instrumentSwitch text
>> into the automatically-created CueVoice.  When instruments cue from each
>> other, it becomes a very difficult to keep the voices straight.
>
> There is actually a snippet implementing "namedCueDuring" that use this
> instrumentCueName!  And it seems to work well AFAICS.
> http://lsr.dsi.unimi.it/LSR/Item?id=388
>
> It would be great if someone could "extend" cueDuring so it can take
> *optional* arguments, like cueClef, instrumentCueName, etc.
> A "\with-like" syntax:
>
>   \cueDuring #flute \with {
>     instrumentCueName = "flute"  % if not set, do not print InstrumentCueName
>     cueClef = "treble"  % if not set, no clef
>     % or alternatively cueClef could be defined but printed only when
>     % needed; in this case we need an automatic "thing" that should
>     % know if the clef currently used by the "main instrument" is
>     % the same as the clef used for the cue (quoted) instrument.
>     cueDirection = NEUTRAL
>     % actually I need this, currently we can only define cued UP or
>     % DOWN but I have seen in many scores cues with normal ("neutral")
>     % stem directions (idem for ties, slurs, etc. -> equiv. \oneVoice).
>   } { R1 }
>
>
> Maybe Reinhold would have better thoughts about this.

I can offer to implement a ly:context-mod? predicate, also optional, for
music functions, that would offer this syntax.  Note, however, that you
could already employ this predicate as long as you use the following call
syntax:

\cueDuring #flute ##{ \with { instrumentCueName = "flute" } } { R1 }

You just write
cueDuring =
#(define-music-function
   (parser location what mods main-music) (string? (ly:context-mod?) ly:music?)

Then use something like
  (or mods (a-call-creating-the-default-modifications))
inside.

Once ly:context-mod? is _properly_ supported as an argument type, you
can remove the ##{ ... } around the \with.

With the current approach to music function arguments, you will _need_
to remove ##{ ... } if ly:context-mod? gets its own argument parsing
support in the current manner (let's call it a €50 job, and I suppose
that it's straightforward enough on the current code base that most
programmers could do it, probably not requiring more than 30 lines
total).

With the stuff I am currently designing, Lilypond would not need special
support for supporting either syntax in the call.  But that will likely
take at least a month to get finished, and I suspect the changes to be
rather controversial: Basically, pretty much all existing code would
stay working, but there will be wagonloads of situations where totally
"naive code" will rather surprisingly just do what was intended.  Rather
dangerously close to GLISS status, but again: I doubt that much working
code would be affected.

-- 
David Kastrup




reply via email to

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